A empresa Amazon oferece serviços de hospedagem nas nuvens. Um de seus clientes era (isso mesmo, era), pois a parceria não durou uma semana, o famoso site Wikileaks, que faz publicações de documentos confidencias de vários governos. Sem muitas delongas e avisos a Amazon desligou e retirou do ar todo o conteúdo do site.

Tal fato poe na mesa de discussões a respeito do acordo de nível de serviço, em especial quando esse serviço está hospedados nas nuvens. Observe na fragilidade desse contrato entre Amazon e Wikileaks, ele permite que a empresa provedora do serviço encerre a qualquer momento a prestação do serviço, caso, considere a atividade do cliente ilegal e que possa prejudicar terceiros.

Agora pergunto, que SLA é esse que da tanto poder ao provedor de serviços? Essa é uma das características desses acordos para tais serviços na nuvens em favorecimento da própria empresa do que o cliente. Não houve nenhuma decisão judicial obrigando que a Amazon retirasse o site do ar. O que houve foi uma pressão de pessoas ligadas ao governo americano para retirar o site do ar. Alias o fundador do Wikileaks, Julian Assange está com voz de prisão pela Interpol.

Esse é apenas um exemplo, mas mostra a importância de um SLA, e como os termos definidos nele, podem e serão usados contra você, o cliente. Foi exatamente esse o caso, a decisão da Amazon tem valor legal e não nada que o Wikileaks possa fazer, a não ser, hospedar o site em outro provedor, que inclusive já fez.

Grande abraço.

Alexsander Oliveira

Existe um livro da versão três (V3) do Itil (Continual Service Improvement, 2007) que trata exclusivamente desse tema. É intitulado como um guia prático em avaliação e aperfeiçoamento da qualidade dos serviços, e é indicado para pessoas ligadas as boas práticas de gerenciamento dos serviços de TI que, pretendem compreendê-las e melhorá-las continuamente. Baseado no ciclo de Deming conhecido como Plan, Do, Check and Act, o famoso PDCA.

São definidos 7 passos para o processo de melhora continua.

1 – Definir o que você deve medir.
Converse com as pessoas do negócio, clientes, gerencia de TI. Utilize o catalogo de serviços como ponto inicial bem como os requisitos de níveis de serviço de diferentes clientes. No cenário ideal, o que deveria ser medido?O que é importante para o negócio?
Faça uma lista do que você entende que deveria ser medido, mas não uma lista complexa, seja objetivo.

2 – Definir o que você pode medir.
As organizações podem encontrar limitações no que ela está medindo, o fato é que, se você não pode medir, não deve nem aparecer no acordo de nível de serviço.
Identifique as ferramentas que você usa atualmente para isso. Essas ferramentas incluem softwares de gerenciamento, monitoramentos, relatórios, investigação, entre outros. Nessa etapa é possível inclusive identificar oportunidades.

3 – Coleta de dados.
Os dados coletados devem estar baseados nas metas e objetivos. Essa coleta pode ser feita por ferramentas de gerenciamento de monitoramento. Nesse ponto a informação que vem é bruta, ainda não está transformada e trabalhada, porém é importante que esteja estruturada de padronizada.

4 – Processamento de dados.
Nessa etapa os dados são processados de acordo com os anseios da melhora continuada do serviço e com os indicadores de desempenho. Ou seja, os dados serão processados de acordo com os objetivos de seu gerenciamento. As origens desses dados podem ser, por exemplo, de ferramentas de monitoração, relatórios, etc.

5 – Análise dos dados.
É nesse ponto que os dados são transformados em informação para identificar as lacunas nos serviços, tendências e impactos sobre os serviços.
Essa análise de dados transforma a informação em conhecimento e trás habilidades para organização.

6 – Apresentar e usar a informação.
As perguntas sobre o porquê de determinada informação foi pega e trabalhada são respondidas aqui. A idéia é apresentar exatamente os resultados que seriam obtidos com as melhorias.

7 – Implementar as ações corretivas.
O conhecimento aprendido é usado para aperfeiçoar, melhoras e corrigiradequar os serviços. O pessoal normalmente identifica os problemas e as soluções, entretanto é necessário controlaracompanhar esse processo de melhoria. As ações corretivas precisam ser tomadas para prover as melhorias necessárias ao negócio. Dessa forma cria-se uma baseline e novos ciclos são iniciados.

A melhora continuada dos serviços, trás diversas oportunidades a organização. Baseado em suas metas, objetivos e tipos de serviços prestados, você pode priorizar as atividades e iniciativas de melhorias.

Cada uma dessas etapas, integradas foram um ciclo, conforme a OGC no livro Continual Service Improvement, elas constituem uma espiral do conhecimento. Nas práticas atuais, conhecimento acumulado e sabedoria derivam desse conhecimento.

Alexsander Oliveira

Tem como principais objetivos:

1. Fazer seu dinheiro ter o valor adequado e justo
2. Ajustar o arcabouço jurídico (contratos) em conformidade com as demandas do negócio
3. Gerenciar o relacionamento e a performance dos fornecedores

O Processo de Gerenciamento de Fornecedores presta atenção aos fornecedores e aos contratos de fornecimento de serviços recebidos pelo comprador. Via de regra, quanto maior a contribuição de um Fornecedor ao negócio maior o esforço dispendido no gerenciamento da relação – nao poderia ser diferente.

Resumidamente, os seguintes aspectos devem ser considerados:

• Políticas de inclusão e manutenção dos fornecedores
• Centralização (base de dados) para os contratos
• Categoriação dos fornecedores e o risco de invesitmento
• Avaliação de Contratos
• Negociação e Aprovação de Contratos
• Revisão, Renovação e Término dos Contratos

Tudo tem um começo

Parece simples quando assim descrito, mas como fazer para manter um bom ciclo de vida de um contrato? A proposição da ITIL é a de se seguir e armazenar os seguintes itens:

1. Identificação dos Requisitos
2. Seleção dos fornecedores
3. Categorização
4. Regulação
5. Gerenciamento
6. Renovação ou Término

Para que se alcance os objetivos da relação, ambas as partes devem estabelecer diretrizes com base em informações mútuas que permitam um relacionamento franco e produtivo e, para que isto se torne verdadeiro, algumas informações importantes devem ser compartilhadas, a  saber:

1. Informações sobres os negócios (Planos, Estratégias e Horizontes)
2. Estratégias de suprimento e contratos
3. Plano de Negócios Detalhado
4. Informações de Performance

Fica a breve visão a respeito, na certeza de que muito há de se explorar no tema.

Forte abraço!

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 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 SLA fornece a base para gerenciar o relacionamento entre o prestador de serviços de TI e seus clientes, mediante acordos que definem os objetivos dos serviços.

Mas e daí? Resumidamente, para que serve o SLM? Acompanhe:

1. Assegurar o cumprimento dos SLAs e OLAs (Acordos de Níveis Operacionais)
2. Prevenir e reduzir drasticamente os impactos na qualidade do serviço
3. Avaliar o impacto de Mudanças planejadas e realizadas na qualidade dos serviços
4. Manter e melhorar a qualidade dos serviços de TI, com um ciclo constante de aperfeiçoamentos
5. SLM é um processo chave para Service Support e Service Delivery que não funciona isoladamente. Ele depende do funcionamento de outros processos.

Para cumprir o seu papel de Assegurar o cumprimento do SLA (item 1 acima) uma boa prática é estabelecer bonificações e penalidades para as partes envolvidas no cumprimento de suas obrigações. Para que isto seja verdadeiro e resulte em ganho para todos a relação deve ser permeada por cumplicidade seja na entrega de indicadores que reflitam a realidade, seja pela disponibilidade de recursos (financeiros em especial).

A Qualidade do serviço acabará por refletir os Acordos sejam positivos quando da bonificação, sejam negativos quando da execução das penalidades. O mesmo se extende às Mudanças.

A idéia do ciclo de aperfeiçoamento constante deve ser regida claramente nos termos de um SLM de forma tal que as partes envolvidas consigam mensurar claramente os benefícios mútuos. Uma boa função a empregar nestes casos é a adoção de um ciclo de PDCA (Plan-Do-Check-Act) que possibilite a redução consistente e contínua do número de incidentes bem como o aumento da disponibilidade dos serviços envolvidos.

Marco Aurélio Neuwiem

Mais de 2 milhões de usuários da Telefônica, mais precisamente do serviço Speed, ficaram sem acesso, dentre esses clientes, podemos destacar Governo de São Paulo, que foi afetado em mais de 50% de sua capacidade.

O que foi divulgado: …é que a falha estava num roteador situado a mais de cem quilômetros de distancia, na cidade de Sorocaba…

Podemos fazer várias perguntas sobre esse acontecimento, mas a pergunta mais importante é : Existe cláusula de não comprimento de SLA?

Por mais que diversas justificativas sejam dadas, como a hilária “esse problema nunca havia acontecido no Brasil e no mundo”, etc o que importa para os usuários é o devido ressarcimento dos prejuízos causados. Depois de algumas conversas com PROCON, a Telefônica acertou em descontar 5 dias da próxima fatura, o que para ela não chega a alterar seu resultado financeiro no primeiro semestre.

É muito fácil usarmos os jargões: “Alinhar TI ao negócio” ou “Uso de melhores práticas” ou a melhor de todas: “Nós estamos implantando ITIL”, porém o difícil é entender que isso tem que ser dia-a-dia e não admitir que problemas como esse possam acontecer.

Espero que os usuários afetados tenham realmente SLA bem formatadas, com cláusulas de multa bem definidas, caso contrário terão cinco dias de desconto, o que em muitos casos não alivia a dor de cabeça sentida. Infelizmente hoje essa é mais uma historia triste na nossa trajetória sofrida de fornecedores confiáveis de TI.

* SLA vem do inglês Service Level Agreement e quer dizer Acordo de Nível de Serviço, um documento que retrata um acordo comum entre cliente e prestador de serviço de TI, com clausulas a respeito da qualidade desse serviço, e que deveria ter também cláusulas para o não comprimento desses serviços.

Emerson Saldanha