Os SLAs são promessas feitas aos clientes - as OLAs garantem que as suas equipas internas conseguem cumpri-las. Com a Trupeer, pode poupar horas na elaboração de OLAs começando com um modelo gratuito de acordo de nível operacional, personalizando-o com as suas orientações de marca e transformando a OLA numa visita guiada em vídeo que alinha todas as equipas internas com base em normas de serviço partilhadas.

O que é um modelo de acordo de nível operacional?

Um acordo de nível operacional, ou OLA, é um acordo interno entre equipas da mesma organização que sustenta um compromisso assumido para alguém fora dela. A central de serviços promete ao negócio uma resolução em quatro horas para incidentes graves. Essa promessa só se mantém se a equipa de rede, a equipa de aplicações e qualquer outra parte na cadeia desempenharem o seu papel dentro de um tempo conhecido.

É na OLA que essas partes internas ficam registadas. Não é um contrato, ninguém está a pagar ninguém, e a aplicação é totalmente gerencial, o que é simultaneamente a sua fraqueza e a razão pela qual pode ser honesta de formas que um contrato não consegue.

Um modelo de acordo de nível operacional é a estrutura reutilizável: as partes, os serviços abrangidos, os compromissos, as medidas e os arranjos de revisão. Encontrar modelos deste tipo é fácil. A maioria permite-lhe escrever uma OLA que é totalmente cumprida e ainda assim falha, e é isso que o resto desta página explica.

OLA vs SLA: o que cada um compromete, na prática

Há três documentos nesta família e misturá-los causa problemas reais.

Um acordo de nível de serviço é o compromisso com o cliente ou com o negócio. É escrito nos termos do cliente, normalmente de ponta a ponta, e é o que é reportado a pessoas fora da cadeia de entrega.

Uma acordo de nível operacional é interno, entre equipas que reportam ambas à mesma organização. Existe apenas para tornar o SLA exequível e nunca deve conter um compromisso que o SLA não precise.

Um contrato de suporte é o acordo comercial com um terceiro, um fornecedor ou um prestador subcontratado, que suporta a mesma cadeia. Tem força legal, o que a OLA não tem, e normalmente tem a menor flexibilidade dos três, pelo que deve ser acordado antes do SLA e não depois.

A consequência prática é uma regra de sequenciação. Primeiro, acordar os contratos de suporte; depois, o SLA com base no que esses contratos permitem; e, por fim, as OLAs que preenchem o restante. As organizações que fazem isto pela ordem inversa prometem rotineiramente ao negócio algo que nenhum fornecedor se comprometeu a entregar.

Como personalizar este modelo na Trupeer

Passo 1: Abrir a secção de Modelos

Aceda à secção de Modelos no menu principal.

Passo 2: Selecionar e abrir um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expandir a visualização do modelo

Se necessário, expanda a visualização do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Editar o modelo

Clique em Editar para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guardar o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Guardar para guardar o modelo atualizado como seu.

Passo 6: Pré-visualizar e afinar o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

No ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o pretende.

Com um modelo de acordo de nível operacional, pode:

• Poupar horas na escrita: Evite a página em branco com uma estrutura criada para OLAs.

• Alinhar equipas internas: Os campos incluídos garantem que cada equipa conhece a sua responsabilidade.

• Manter-se fiel à marca: Aplique o seu logótipo, fontes e cores usando o kit de marca da Trupeer.

• Proteger os SLAs dos clientes: As OLAs robustas evitam que as transferências internas quebrem promessas externas.

• Padronizar entre serviços: Use o mesmo modelo de OLA para cada acordo interno.

• Atingir equipas globais: Traduza OLAs para 65+ idiomas com um clique.

Porque é que todas as equipas cumprem a sua OLA e o SLA continua a ser violado

Este é o padrão mais comum na gestão de serviços e parece uma contradição.

Todas as equipas reportam verde. A rede responde dentro da sua hora. As aplicações resolvem dentro das suas duas. A central de serviços faz triagem em trinta minutos. O relatório mensal de conformidade da OLA é fácil de ler. E, ainda assim, o SLA do cliente é violado em um terço dos incidentes graves.

A explicação é que as OLAs medem o tempo dentro das equipas, enquanto o SLA mede o tempo de ponta a ponta. A diferença entre esses dois números é o trânsito: o ticket que fica numa fila após a reatribuição, à espera de ser levantado, ou devolvido para mais informações.

Esse tempo não pertence a ninguém. Não está na OLA de ninguém, não é reportado em lado nenhum e, frequentemente, é maior do que todo o tempo de trabalho somado.

O que significa que a falha é estrutural e não um problema de desempenho. Adicionar pressão às equipas para cumprirem os seus números atuais não ajuda, porque elas já os estão a cumprir.

A OLA rege a transferência, não o trabalho

A mudança de perspetiva que resolve isto é pequena e altera para que serve o documento.

Uma OLA escrita do modo habitual compromete uma equipa com o tempo que o seu próprio trabalho demora. Essa é a parte que a equipa controla, por isso é a parte que está disposta a assinar, e é também a menos útil para acordar, porque nunca foi a variável.

Uma OLA escrita bem compromete as equipas com a interface entre elas. O que tem de constar num ticket antes de ser passado. Quanto tempo a equipa recetora tem para o levantar. O que acontece quando o ticket está incompleto. Quem é responsável pelo ticket durante a lacuna.

Quando a transferência passa a ser o tema, os dois campos em falta tornam-se óbvios. Critérios de entrada, ou seja, o que tem de ser verdade antes de o relógio da equipa recetora começar. E uma alocação explícita do próprio tempo de trânsito, para que a lacuna entre equipas seja o número de alguém e não de ninguém.

Todo o resto num modelo de OLA é administração. Estes dois campos são o documento.

Critérios de entrada: o que tem de ser verdade antes de o relógio começar

O comportamento mais destrutivo numa cadeia com várias equipas é a devolução: um ticket chega sem informação suficiente, a equipa recetora devolve-o e o relógio dela é reiniciado.

A devolução é totalmente racional do ponto de vista da equipa recetora. Não conseguem trabalhar o ticket e a sua conformidade é medida no tempo de resolução delas, por isso devolvê-lo protege ambas as partes. É também onde passa uma grande parte do tempo decorrido e é invisível em qualquer relatório que mede as equipas separadamente.

Os critérios de entrada resolvem isto ao mover a obrigação para montante. Cada linha de OLA lista os campos específicos que têm de estar preenchidos para aquela equipa aceitar o trabalho. Numa transferência de rede, pode ser o nome do dispositivo, o código do local, o texto exato do erro, a hora em que foi observado pela primeira vez e se outros utilizadores são afetados. Numa transferência de aplicações, pode ser o utilizador, a referência da transação, os passos para reproduzir e um screenshot.

Depois, o compromisso da equipa que envia muda a redação. Não é “triagem em trinta minutos”, mas sim “passar um ticket que cumpra os critérios de entrada em trinta minutos”. O mesmo relógio, uma obrigação diferente, e o incentivo passa a estar com a equipa que consegue recolher a informação.

A equipa recetora mantém o direito de rejeitar, e esse direito deve ser limitado: a rejeição só é válida quando um critério de entrada nomeado estiver genuinamente em falta, e cada rejeição é registada com o motivo. O registo é o que transforma a devolução de um hábito invisível num número que alguém tem de explicar.

Modelo gratuito de acordo de nível operacional: a estrutura para copiar

Copie daqui. Os campos marcados com um asterisco são os que os modelos padrão omitem.

Cabeçalho. Referência e versão da OLA. Partes, ou seja, as duas equipas por nome. O SLA ou serviço que suporta. Data de entrada em vigor, data de revisão e o responsável nomeado de cada lado.

Âmbito. Quais serviços, sistemas ou tipos de pedidos isto abrange, e o que explicitamente não abrange.

Horas de serviço. Cobertura para cada parte, incluindo acordos fora de horas e como diferem. Horários incompatíveis entre duas equipas na mesma cadeia é uma lacuna comum e silenciosamente fatal.

Tabela de compromissos. Uma linha por tipo de pedido ou prioridade, com: o gatilho, os critérios de entrada, tempo de resposta, tempo de resolução ou de devolução, o tempo de trânsito alocado e o ponto de escalonamento.

Escalonamento. Quem é contactado em cada fase, por que via, e após quanto tempo. Inclua o caminho fora de horas.

Dependências. O que esta equipa precisa de outras, incluindo qualquer contrato de suporte com um terceiro, com os seus próprios tempos assinalados para que a aritmética possa ser verificada.

Medição. O que é medido, de que sistema, por quem e com que frequência é reportado. Inclua taxa de devolução juntamente com resposta e resolução, porque é a métrica que revela se os critérios de entrada estão a funcionar.

Exceções. Circunstâncias acordadas em que os compromissos não se aplicam, como durante um incidente grave declarado ou uma pausa de alterações.

Revisão. Datas e o que desencadeia uma revisão fora do ciclo.

Copie até aqui. Mantenha-se entre duas ou três páginas. Uma OLA longa o suficiente para exigir uma segunda leitura não será consultada durante um incidente, e é durante um incidente que isso importa.

Como verificar se as OLAs somam mesmo ao SLA

Antes de assinar qualquer coisa, faça as contas. Leva quinze minutos e é ignorado quase universalmente, porque as OLAs são negociadas uma a uma com equipas diferentes em dias diferentes.

Duas regras tornam isto útil. O tempo de trânsito tem de aparecer como uma linha própria, porque esse é o objetivo. E cada cadeia precisa de margem, porque uma cadeia que soma exatamente ao SLA viola-o sempre que algo, mesmo que ligeiramente, corre mal. Dez a quinze por cento é uma margem razoável.

Se a soma exceder o SLA, tem três opções honestas: renegociar o SLA, reduzir o tempo de uma equipa com algo que torne isso possível, ou remover uma transferência. O que não pode fazer é assinar OLAs que garantem uma violação e depois gerir o desempenho com base nelas, que é a posição em que se encontram um número surpreendente de centrais de serviços.

O retalhista cujo tempo de trânsito foi maior do que o trabalho

O Grupo Rendlesham gere várias marcas de retalho com cerca de seis mil colaboradores e uma central de serviços de TI interna que suporta lojas e sede.

O seu SLA de incidentes P2 para o negócio era de quatro horas até à resolução. A taxa de violação em P2 rondava os trinta e oito por cento durante dois anos. A conformidade de cada equipa com a OLA era reportada mensalmente e todas as equipas estavam verdes.

Alguém finalmente registou com carimbo de data/hora todas as alterações de estado em cento e vinte incidentes P2 violados.

O tempo total decorrido mediano foi de seis horas e cinquenta e um minutos. Deste, três horas e doze minutos foram tempo dentro de uma equipa a trabalhar ativamente o ticket. Três horas e trinta e nove minutos foram trânsito: estar numa fila após a reatribuição, à espera de ser levantado, ou devolvido.

Mais de metade do tempo decorrido num incidente violado não era da responsabilidade de ninguém e não era reportado em lado nenhum.

O maior contributo individual foi a devolução. Quarenta e um dos cento e vinte tickets tinham sido devolvidos pelo menos uma vez por uma equipa recetora por informação insuficiente, e cada devolução acrescentou uma mediana de uma hora e vinte minutos, além de reiniciar o relógio daquela equipa. As duas razões mais comuns foram não haver texto do erro ou screenshot anexado e não haver confirmação de qual loja foi afetada pelo incidente.

As mudanças foram limitadas. Os critérios de entrada foram escritos em todas as linhas de OLA. O compromisso da central de serviços foi reescrito de “triagem em trinta minutos” para “passar um ticket que cumpra os critérios de entrada em trinta minutos”. Foram alocados quinze minutos de trânsito por transferência e contabilizados contra a equipa recetora quando os critérios de entrada eram cumpridos. E cada devolução foi registada com um motivo.

Nos dois trimestres seguintes, a taxa de devolução caiu de trinta e quatro por cento dos P2 para nove. O tempo de trânsito mediano caiu de três horas e trinta e nove minutos para uma hora e seis. A taxa de violação de P2 caiu de trinta e oito por cento para onze.

O tempo interno de resolução de nenhuma equipa mudou materialmente. Ninguém trabalhou mais depressa. O tempo que antes não pertencia a ninguém foi simplesmente atribuído a alguém.

Como redigir um acordo de nível operacional, passo a passo

Comece pelo SLA, não por um modelo. Registe o que foi prometido ao cliente, de ponta a ponta, com a definição do relógio.

Mapeie a cadeia. Todas as equipas que tocam um pedido desse tipo, por ordem, incluindo qualquer terceiro. Desenhe as transferências como passos próprios e não como setas.

Para cada transferência, faça uma pergunta à equipa recetora: o que precisa no ticket para começar a trabalhar sem voltar a contactar-nos? A resposta, escrita, são os seus critérios de entrada. As equipas respondem a isto com facilidade e precisão, e a maioria nunca foi questionada.

Agora, acordar os tempos, trabalhando com base na aritmética acima e não equipa a equipa. Fazer isto como uma conversa única com todos presentes demora uma hora e evita totalmente o problema da soma.

Alocar o trânsito explicitamente e decidir quem é responsável por ele. Quinze minutos por transferência é um bom ponto de partida e deve ser contabilizado contra a equipa recetora.

Acorde a medição, incluindo a taxa de devolução, e de onde vem. Se as suas ferramentas não conseguirem produzi-la, isso vale a pena saber antes de assinar e não na primeira revisão.

Depois, execute durante um trimestre antes de formalizar. As primeiras versões normalmente estão erradas em um ou dois pontos e é mais fácil corrigi-las antes de existirem assinaturas.

Erros comuns em OLAs e o custo de cada um

Medir equipas e não a cadeia. Toda a gente está verde e o SLA é violado. A falha mais comum e o tema desta página.

Sem critérios de entrada. A devolução torna-se a defesa racional da equipa recetora e o tempo decorrido aumenta de forma invisível.

Tempos que não somam. O conjunto de OLAs garante uma violação e ninguém nunca o somou.

Horas de serviço incompatíveis. Uma equipa cobre até às seis, a seguinte até às cinco. Tudo o que chega depois das cinco fica durante a noite, o que nenhum relatório mostra porque ambas as equipas estão dentro das suas horas.

Copiar linguagem de SLA para uma OLA. Penalizações, créditos e redação legal não pertencem aqui, e importá-los faz com que as equipas negociem de forma defensiva em vez de honesta.

Escrever uma OLA com um terceiro. Se o dinheiro muda de mãos, trata-se de um contrato de suporte e precisa de envolvimento de procurement e jurídico, não de um modelo. O nosso modelo de política de procurement de TI cobre o caminho de aprovação.

Assinar e arquivar. Uma OLA que ninguém revê descreve uma cadeia de serviço que já não existe passados cerca de um ano.

Como gerir e rever OLAs depois de existirem

Reporte a cadeia, não os componentes. Importa um número: o desempenho de ponta a ponta face ao SLA, e as métricas da OLA existem para o explicar e não para ficar isoladas.

Revise trimestralmente, com todas as partes na mesma sala. As revisões bilaterais reproduzem o problema original, porque as lacunas vivem entre as partes que nunca estão na mesma conversa.

Observe três coisas. A taxa de devolução por transferência, que lhe diz onde os critérios de entrada precisam de trabalho. O tempo de trânsito por transferência, que lhe diz onde as filas estão a formar-se. E a proporção de incidentes que seguiram um caminho que a OLA não descreve, o que lhe diz que o documento se desviou da realidade.

Desencadeie uma revisão fora do ciclo quando uma equipa se reorganiza, quando um sistema passa entre equipas, quando um terceiro entra na cadeia ou quando o SLA subjacente muda. Todas as quatro situações acontecem com mais frequência do que o ciclo anual de revisão assume.

OLA, SLA ou contrato de suporte: de que precisa?

Se o compromisso é para alguém fora da sua organização de entrega, seja um cliente externo ou uma unidade de negócio interna que está a ser servida, trata-se de um SLA.

Se é entre duas equipas dentro da mesma organização, sem dinheiro a mudar de mãos, trata-se de uma OLA.

Se é com um fornecedor ao abrigo de um acordo comercial, trata-se de um contrato de suporte e precisa de jurídico e procurement, em vez deste modelo.

O caso mais difícil é o do centro de serviços partilhados ou de uma equipa interna com um modelo de chargeback, que fica entre uma OLA e um SLA. A resposta prática é escrevê-lo como uma OLA e eliminar qualquer linguagem sobre penalizações, porque os regimes internos de penalização produzem de forma fiável comportamento defensivo e pior serviço.

Para as definições e a redação de resposta voltadas ao cliente que ficam por cima de tudo isto, o nosso modelo de resposta da central de serviços e modelo de ticket e resolução cobrem a camada que o utilizador final vê de facto.

Posso obter um modelo de OLA em Word ou Excel?

Word para o acordo, porque o âmbito, as exceções e as secções de revisão são texto corrido e o documento é distribuído para aprovação e assinatura.

Excel para duas partes especificamente. A tabela de compromissos, onde quer os critérios de entrada, os tempos e a alocação de trânsito em colunas que possa ordenar e verificar. E a folha de aritmética, onde cada cadeia soma ao seu SLA e sinaliza qualquer coisa sem margem. Essa segunda folha é a que vale a pena construir primeiro, porque muitas vezes muda o que estava prestes a acordar.

PDF para a versão assinada, exportada da fonte. Mantenha a versão de trabalho editável, porque os critérios de entrada vão precisar de ajustes após o primeiro trimestre de devoluções reais.

Como manter a OLA e a realidade alinhadas

Uma OLA descreve uma cadeia de trabalho que muda constantemente. As equipas reorganizam-se, os sistemas mudam, as ferramentas alteram-se e o documento é a última coisa que alguém atualiza.

A parte que fica desatualizada mais depressa são os critérios de entrada, porque descrevem o que um ticket tem de conter e o que um ticket tem de conter depende de como funcionam, na prática, as ferramentas e o processo atuais.

A Trupeer AI ajuda ao tornar os procedimentos subjacentes baratos de manter atualizados. Registe o processo de triagem ou de transferência uma vez e obtém um procedimento escrito com os passos e os ecrãs capturados, que a central de serviços pode seguir e que mostra claramente que informação está a ser recolhida. Quando as ferramentas mudam, volte a registar em vez de reescrever.

Registe. Dê marca. Traduza. Trupeer.

O criador de SOP cobre os procedimentos de que a OLA depende, e o nosso modelo de SOP de TI cobre como decidir quais deles valem a pena manter. A documentação mantém os acordos e os procedimentos juntos, e as instruções de configuração estão no guia de configuração do modelo de documento.

Perguntas Frequentes

Existe um modelo gratuito de acordo de nível operacional em Word?

A estrutura acima é colada diretamente no Word ou no Google Docs, incluindo os campos de critérios de entrada e de alocação de trânsito que os modelos padrão omitem. Não há download com acesso restrito e não há formulário. Mantenha a tabela de compromissos numa folha de cálculo e faça referência a ela, porque essa parte precisa de ser ordenada e somada.

Existe um modelo gratuito de acordo de nível operacional em PDF?

Exporte a versão assinada para PDF assim que as partes a acordarem e mantenha a cópia de trabalho editável. Os critérios de entrada quase sempre precisam de ajustes após o primeiro trimestre, quando já consegue ver por que motivos os tickets estão a ser devolvidos.

Existe um modelo gratuito de acordo de nível operacional em Excel?

O Excel é o local certo para a tabela de compromissos e para a verificação da aritmética. Uma folha com uma linha por transferência e um total em execução face ao SLA, sinalizando qualquer cadeia com menos de 10% de margem. Construir essa folha antes de negociar tende a alterar o que acaba por ser negociado.

Onde posso encontrar um exemplo de OLA em PDF?

Vários fornecedores de ITSM e organismos governamentais publicam modelos de OLA e SLA como documentos, e são razoáveis em termos de estrutura. Leia-os pelas secções e não pelo conteúdo, porque os compromissos em qualquer exemplo publicado são a cadeia de outra pessoa e os tempos não têm significado fora do SLA para o qual foram criados.

Quem assina um acordo de nível operacional?

O responsável nomeado de cada lado, que deve ser o gestor responsável pela entrega daquela equipa e não uma função de gestão de serviços. Uma OLA assinada apenas pela gestão de serviços é uma aspiração, porque a pessoa que tem de disponibilizar recursos não estava na sala.

Quantas OLAs é que uma central de serviços precisa?

Menos do que a maioria das equipas espera. Uma por par de equipas que troca trabalho regularmente, cobrindo todos os tipos de pedidos numa única tabela de compromissos, em vez de uma por serviço. Para além de cerca de uma dúzia, a manutenção torna-se a restrição e os documentos ficam desatualizados mais depressa do que são revistos.

Uma OLA deve ter penalizações?

Não. Não existe uma relação legal para fazer cumprir e os regimes internos de penalização produzem de forma fiável comportamento defensivo: as equipas rejeitam trabalho, discutem quando o relógio começa e otimizam para o seu próprio número em vez do resultado. Em vez disso, reporte a cadeia de ponta a ponta, o que torna a consequência partilhada visível sem que ninguém seja multado.

Com que frequência devem ser revistas as OLAs?

Trimestralmente com todas as partes presentes, além de uma revisão fora do ciclo sempre que uma equipa se reorganiza, quando um sistema passa entre equipas, quando um terceiro entra na cadeia ou quando o SLA subjacente muda. O ritmo trimestral apanha desvios e os gatilhos apanharem as mudanças que tornam o documento errado durante a noite.