Um OLA (acordo de nível operacional, ou operational level agreement) é um acordo interno que define responsabilidades, prazos e condições entre as equipes que dão suporte a um serviço de TI, para que os compromissos assumidos com o cliente ou com a empresa sejam cumpridos. Em vez de se concentrar no que a empresa ou o cliente recebe, ele esclarece como os diferentes departamentos trabalham juntos para cumprir esses compromissos.
O objetivo é a coordenação prática: quem faz o quê, dentro de quais prazos e sob quais condições, para que a prestação de serviços não seja interrompida nos bastidores. Eles ajudam a enfrentar os desafios cotidianos, como falta de comunicação, sobreposição de tarefas e ITSM (Gerenciamento de Serviços de TI) inconsistente.
Definição de acordo de nível operacional
Um acordo de nível operacional é um acordo interno que define responsabilidades, tempos de resposta e dependências entre as equipes envolvidas na prestação de um serviço de TI. Os participantes típicos incluem suporte de TI, infraestrutura, segurança, Gerenciamento de Aplicações ou até mesmo áreas que não sejam de TI, como RH ou instalações, quando seu trabalho afeta os resultados do serviço.
Em um contexto de ITSM, os OLAs traduzem os compromissos de serviço em responsabilidades operacionais diárias. Ao estabelecer expectativas claras sobre tempos de resposta, procedimentos de escalonamento e outros aspectos críticos da prestação de serviços, os OLAs garantem que as equipes internas trabalhem juntas de forma eficiente.
As equipes de suporte, infraestrutura, segurança e aplicativos os utilizam para esclarecer as transferências, os caminhos de escalonamento e o tempo. Quando várias equipes contribuem para um único serviço, o OLA explica como o trabalho delas se encaixa e pelo que cada grupo é responsável.
A ITIL se baseia nesse fundamento de ITSM, formalizando os OLAs. Eles estão sob a égide do Gerenciamento de Nível de Serviço. Enquanto os SLAs (acordos de nível de serviço) descrevem os compromissos assumidos com os clientes ou com a empresa, os OLAs explicam como as equipes internas dão suporte a esses compromissos.
Por exemplo, se um SLA se compromete a resolver incidentes de alta prioridade em quatro horas, os OLAs relacionados definem a rapidez com que as equipes de suporte devem responder e quais ações devem ser tomadas. Essa estrutura mantém as metas de serviço realistas e evita confusão quando os problemas ultrapassam os limites da equipe.
Diferença entre OLA, SLA e SLO
Os OLAs, SLAs e SLOs definem as expectativas em relação ao desempenho do serviço, mas operam em níveis diferentes e têm finalidades diferentes.
Na prática, os SLAs definem o compromisso, os OLAs definem a execução interna e os SLOs fornecem as métricas que conectam os dois.
- Acordo de nível de serviço (SLA): um acordo formal entre um provedor de serviços e um cliente ou unidade de negócios.
- Acordo de nível operacional (OLA): um acordo interno entre as equipes que dão suporte a um serviço.
- Objetivo de nível de serviço (SLO): uma meta de desempenho específica e mensurável para um serviço ou processo, geralmente expressa como uma porcentagem, um limite ou uma meta baseada no tempo, como tempo de atividade ou taxas de erro.
Os SLAs estão no topo, definindo as expectativas da empresa ou dos clientes. Eles respondem à pergunta: que nível de serviço está sendo prometido? Os OLAs operam abaixo dessas promessas, definindo como as equipes internas devem trabalhar juntas para cumpri-las. Sem os OLAs, os SLAs geralmente dependem de suposições sobre a capacidade interna e o tempo. Por isso, a diferença entre SLA e OLA está em quem recebe o compromisso: o SLA é voltado ao cliente, o OLA é voltado às equipes que o tornam possível.
Os SLOs são transversais a ambos. Eles fornecem as metas mensuráveis que informam os SLAs e orientam os OLAs. Um único SLA pode se basear em vários SLOs, e cada OLA pode fazer referência a SLOs específicos para definir o desempenho aceitável para as etapas internas. A relação entre SLA e SLO é de compromisso e medição: o SLA promete, o SLO mede.
Exemplo de OLA
Imagine o serviço de e-mail corporativo de uma empresa, coberto por um SLA que promete resolver incidentes de alta prioridade em até quatro horas. Três partes participam da resolução: o service desk, a equipe de infraestrutura e o fornecedor externo da plataforma de e-mail em nuvem. Um OLA para esse cenário poderia ser assim:
- Serviço coberto: e-mail corporativo.
- SLA apoiado: resolução de incidentes de alta prioridade em até quatro horas.
- Horário de cobertura: 24 horas por dia, 7 dias por semana, para incidentes de alta prioridade.
- Revisão: a cada revisão do SLA ou quando houver mudança de equipes ou de fornecedor.
Somados, os prazos internos deixam uma margem dentro das quatro horas do SLA. O compromisso do fornecedor externo não faz parte do OLA: ele é formalizado em um contrato de apoio, e o OLA define apenas como a equipe interna o aciona e acompanha.
Por que você precisa dos OLAs da ITIL?
Muitas organizações dependem dos SLAs para definir as expectativas de serviço, mas ainda assim têm dificuldades para atendê-las de forma consistente. O problema geralmente não é a falta de um compromisso formal, mas o que acontece internamente quando esse compromisso existe. Os SLAs descrevem o que deve ser entregue, enquanto os OLAs explicam como as equipes fazem isso acontecer.
Os OLAs da ITIL ajudam a fechar essa lacuna, transformando as metas de serviço em responsabilidades operacionais compartilhadas. Eles dão às equipes internas tempos de resposta claros, propriedade e regras de transferência, para que o trabalho não fique parado quando um incidente ou solicitação ultrapassa os limites da equipe. Em vez de debater quem deve agir ou com que rapidez, as equipes podem consultar uma estrutura acordada. Na prática, o conceito de OLA ITIL funciona como o elo entre o que o Gerenciamento de Nível de Serviço promete e o que cada equipe executa.
Eles também suportam SLAs mais realistas. Quando os OLAs definem o que as equipes internas podem realmente entregar, os compromissos de serviço são baseados na capacidade operacional e não em suposições. Com o tempo, esse alinhamento reduz o atrito, melhora a previsibilidade e torna os relatórios de serviço mais significativos.
Quando os OLAs são necessários?
Os OLAs tornam-se necessários quando a prestação de serviços depende de mais de uma equipe. No início, um único grupo de suporte pode lidar com a maioria dos problemas de ponta a ponta, tornando suficiente a coordenação informal. À medida que os serviços crescem e as responsabilidades se dividem, os acordos informais começam a se desfazer.
Normalmente, as organizações precisam de OLAs quando a resolução de incidentes exige vários grupos, como equipes de service desk, infraestrutura e aplicativos. O mesmo se aplica quando fornecedores externos estão envolvidos, mas as equipes internas ainda têm parte da responsabilidade. Nesses cenários, os atrasos geralmente decorrem de uma propriedade pouco clara e não da complexidade técnica.
A maturidade também desempenha um papel importante. As equipes que já monitoram os SLAs e as métricas de desempenho geralmente chegam a um ponto em que a melhoria dos resultados depende do alinhamento interno. Os OLAs fornecem a próxima camada de estrutura, ajudando as organizações a deixar de reagir aos problemas e passar a gerenciar os serviços com mais consistência e controle.
Componentes do OLA de ITSM
Um acordo de nível operacional funciona melhor quando documenta claramente como se espera que as equipes internas ofereçam suporte a um serviço. Embora o nível de detalhes possa variar, a maioria dos OLAs inclui os seguintes componentes:
- Escopo do acordo: serviços, processos ou atividades cobertos pelo OLA, incluindo o que está fora de seus limites.
- Equipes e funções participantes: grupos internos envolvidos, juntamente com suas responsabilidades e pontos de contato.
- SLAs suportados: os acordos de nível de serviço que o OLA foi projetado para apoiar, criando um vínculo claro com os compromissos comerciais.
- Objetivos de nível de serviço (SLOs): metas internas mensuráveis, como tempos de resposta, tempos de resolução ou limites de disponibilidade.
- Responsabilidades e dependências: pelo que cada equipe é responsável e onde ocorrem as transferências durante a prestação do serviço.
- Caminhos de escalonamento: como e quando os problemas passam para níveis mais altos de suporte se as metas estiverem em risco.
- Horário de funcionamento e disponibilidade: janelas de cobertura, expectativas de plantão e quaisquer restrições baseadas em tempo.
- Comunicação e relatórios: como as equipes compartilham atualizações de status, dados de desempenho e exceções.
- Regras de análise e revisão: com que frequência o OLA é revisado e o processo para atualizá-lo à medida que os serviços mudam.
Como implementar acordos de nível operacional no InvGate Service Management
Os acordos de nível operacional funcionam melhor quando estão vinculados diretamente aos fluxos de trabalho diários. No InvGate Service Management, os OLAs podem ser configurados para coordenar as equipes internas, definir limites de tempo claros para cada etapa de uma solicitação e acompanhar o desempenho em relação aos compromissos internos que suportam os SLAs. Toda a configuração é feita pela interface, sem código, o que permite colocar os primeiros OLAs em funcionamento rapidamente.
Aqui estão as principais etapas a serem seguidas:
Etapa 1: defina a finalidade e o escopo do OLA
Comece identificando quais equipes internas estão envolvidas e a que parte do serviço elas dão suporte. No nível da prática, isso significa esclarecer as responsabilidades e as transferências entre as equipes para que o trabalho interno se alinhe aos compromissos de serviço.
No InvGate Service Management, os OLAs são criados a partir de Configurações > Solicitações > SLA e OLA. Ao criar um novo operational level agreement, você define seu escopo selecionando os help desks relevantes. Isso vincula o acordo diretamente às equipes responsáveis por cumpri-lo e garante que o OLA se aplique apenas onde a coordenação interna é necessária.
Etapa 2: estabeleça condições e cronogramas
Depois que o escopo for definido, estabeleça metas de resposta ou resolução para as equipes envolvidas. Esses limites de tempo internos devem apoiar os SLAs existentes, dividindo o tempo total do serviço em etapas gerenciáveis.
Dentro da configuração do OLA, o InvGate Service Management permite que você defina os limites de tempo em minutos, horas ou dias através das configurações de Tempo. Você também pode ativar a Pausa de acordo com a programação para levar em conta as horas não úteis e os feriados. Isso mantém as metas internas realistas e os dados de desempenho consistentes com a forma como as equipes realmente operam.
Etapa 3: defina condições de acionamento
Um OLA eficaz só se aplica quando condições específicas são atendidas. Do ponto de vista do processo, isso evita o rastreamento desnecessário e mantém os acordos internos focados nos cenários mais importantes.
No InvGate Service Management, essas regras são definidas na seção Condições do OLA. As condições podem se basear em atributos como a prioridade da solicitação, que costuma ser definida por uma matriz de prioridade de impacto e urgência, a categoria ou a atribuição. Por exemplo, um OLA pode ser ativado somente para incidentes de alta prioridade ou para solicitações tratadas por um help desk específico.
Etapa 4: configure ações automatizadas
A automação ajuda os OLAs a permanecerem ativos sem supervisão manual constante. Internamente, isso dá suporte à execução consistente e reduz os atrasos quando as metas estão se aproximando ou não são atingidas.
A guia Ações, no InvGate Service Management, permite definir o que acontece quando um OLA está perto de expirar ou foi violado. Você pode adicionar tarefas predefinidas, como:
- Enviar alertas quando o OLA se aproxima da expiração.
- Reatribuir automaticamente uma solicitação a outra equipe se nenhuma ação for tomada.
- Adicionar um observador ou acionar um processo de aprovação para tipos específicos de solicitações.
Etapa 5: monitore e refine o OLA
Depois que os OLAs estiverem em vigor, a revisão contínua os transforma em uma ferramenta de aprimoramento e não em uma documentação estática. A comparação do desempenho interno com os resultados do SLA ajuda a identificar quais etapas do fluxo de trabalho geram atrasos.
O InvGate Service Management exibe o desempenho do OLA diretamente em cada solicitação, juntamente com os dados do SLA. Os recursos de relatórios permitem analisar métricas como a resposta média e os tempos de resolução entre as equipes. Esses insights apoiam os ajustes nas condições, prazos ou ações do OLA à medida que os serviços e as cargas de trabalho mudam.
Quer coordenar suas equipes internas com OLAs configurados sem código e conectados aos seus SLAs? Fale com a nossa equipe de Vendas e veja como o InvGate Service Management pode ser implementado rapidamente na sua organização.
6 boas práticas para usar os OLAs com sucesso
Para facilitar sua implementação, considere as seguintes práticas recomendadas para o acordo de nível operacional:
- Padronizar: estabeleça um processo e um modelo padrão para a preparação de OLAs. Essa padronização garante consistência e eficiência na criação de OLAs. Exemplo: um único modelo com escopo, SLA apoiado, prazos por equipe e escalonamento, usado para todos os serviços.
- Envolver as partes interessadas: envolva todas as partes interessadas relevantes no processo de preparação e revisão. Esse envolvimento garante que todas as perspectivas sejam consideradas e que o OLA seja abrangente. Exemplo: antes de fechar o OLA do e-mail corporativo, o service desk e a infraestrutura validam juntos os prazos de cada etapa.
- Revisões e atualizações regulares: revise e atualize regularmente os OLAs para garantir que eles continuem relevantes e eficazes. À medida que as necessidades organizacionais mudam, os OLAs devem ser atualizados para refletir essas mudanças e promover a melhoria contínua dos serviços. Exemplo: ao trocar de fornecedor de e-mail, o OLA é revisado para atualizar os caminhos de escalonamento.
- Considere o alinhamento com o SLA e os objetivos comerciais: os níveis de serviço internos dão suporte aos compromissos externos para garantir a satisfação do cliente. Por sua vez, o acordo de nível operacional ajuda a agregar valor à organização. Exemplo: se o SLA de resolução cai de quatro para três horas, os prazos internos do OLA são redistribuídos na mesma proporção.
- Estabeleça níveis de serviço realistas: leve em conta as capacidades atuais das equipes e dos recursos e consulte as pessoas envolvidas. Exemplo: se a infraestrutura não tem plantão noturno, o OLA não deve prometer resposta em 30 minutos de madrugada.
- Treine e conscientize a equipe: instrua os membros do departamento sobre o conteúdo do OLA de TI, suas possíveis contribuições e responsabilidades. Exemplo: novos analistas do service desk aprendem, já no onboarding, para quem e em quanto tempo devem encaminhar cada tipo de incidente.
Perguntas frequentes
O que é OLA em TI?
Em TI, o OLA se resume a um acordo interno entre equipes que define quem faz o quê, em quanto tempo e sob quais condições para sustentar um serviço. Ele não é assinado com o cliente: serve para que as equipes internas consigam cumprir o SLA prometido.
Quem assina um OLA?
Um OLA é acordado entre os responsáveis pelas equipes internas que participam do serviço, como o coordenador do service desk e o gerente de infraestrutura. Normalmente, quem conduz a negociação é o responsável pelo Gerenciamento de Nível de Serviço, que garante que o OLA esteja alinhado ao SLA correspondente.
Qual a diferença entre OLA e contrato de apoio (UC)?
O OLA é um acordo interno entre equipes da mesma organização. Já o UC (contrato de apoio, ou underpinning contract) é um contrato com um fornecedor externo, com obrigações formais e, em geral, valor jurídico. Os dois apoiam o mesmo SLA: o OLA cobre a parte que as equipes internas entregam, e o contrato de apoio cobre a parte que o fornecedor entrega.
Com que frequência atualizar um OLA?
Não há um prazo único: o próprio OLA deve definir seu ciclo de revisão, de preferência acompanhando as revisões do SLA que ele apoia. Além disso, vale revisá-lo sempre que mudarem serviços, equipes ou fornecedores, ou quando os relatórios mostrarem violações recorrentes.
