Entre a primeira e a segunda linhas de suporte técnico

Com que frequência você conheceu administradores de aplicativos que gostam de lidar com a resolução de incidentes?

Além disso, um fluxo significativo de incidentes na segunda linha de suporte são os chamados incidentes de negócios, ou seja, incidentes que estão associados a uma violação da lógica do processo de negócios no serviço ou a ações incorretas do usuário.

Conseguimos remover essa funcionalidade da segunda linha, tanto quanto possível, transferindo-a para uma equipe separada montada dos funcionários da primeira linha de suporte técnico.

Vamos falar sobre como fizemos isso e que dificuldades encontramos neste artigo.

Tradicionalmente, a segunda linha de suporte técnico estava envolvida na solução de incidentes em sistemas, aqueles que fornecem suporte para o próprio serviço, executam definições de configuração do produto, ambientes de teste, monitoramento do sistema, instalam patches, participam de turnos de plantão, etc. E a solução de incidentes nessas equipes costumava ser acompanhada por um "princípio residual" (a menos que esse seja um incidente com prioridade crítica), no entanto, na maioria dos casos, eles se encaixam nos SLAs atribuídos.

Percebendo que muitos dos incidentes (e na frente dos sistemas - atrás de cada um) poderiam ser o problema do Cliente do Banco, decidimos minimizar o tempo necessário para concluir essas solicitações, mas não começamos aumentando o número de equipes de suporte, mas analisando cada uma das etapas deste processo.

O processo de apoio tradicional do Banco foi construído de acordo com o esquema clássico e tinha a seguinte aparência


Fig. 1 Esquema da organização do processo de suporte (foi)

A solicitação passada pela primeira, segunda e terceira linhas de suporte foi distribuída entre eles nas seguintes proporções: 15:75:10.

A primeira linha - Service Desk - recebendo, processando e roteando chamadas usando os seguintes canais de comunicação:

• telefone - 8% do número total de chamadas
  portal de autoatendimento - 83% do número total de chamadas
  email - 4% do número total de chamadas
  bot de bate-papo no Viber e no Telegram - 5% do total

A primeira linha também trata da resolução de incidentes remotamente nas estações de trabalho dos usuários, fornecendo acesso aos sistemas de informação do Banco. Eu escrevi sobre o trabalho desta unidade em um artigo separado - link aqui

A segunda linha - equipes de manutenção de software aplicativo + infraestrutura + DBA + ...,

A terceira linha são as equipes de desenvolvimento.

Como os sistemas bancários são integrados entre si, a ocorrência de um incidente em um dos sistemas geralmente resulta de um erro que ocorre em outro sistema. E os erros nos "sistemas de backup" aparecem principalmente na "frente", tendo um impacto direto nos usuários.

A identificação da causa raiz da ocorrência neste caso requer a participação de várias equipes de acompanhantes e, como resultado, uma série de roteiros.

Tomando uma amostra de incidentes por vários meses e analisando seu ciclo de vida, descobrimos que eles passam a maior parte de suas vidas na fila, aguardando uma análise da equipe de suporte da segunda linha (às vezes até 80%), periodicamente, com reatribuição entre equipes e uma longa correspondência no corpo da solicitação.

No processo de análise e análise desses incidentes, descobrimos que, para solucionar erros de integração, os colegas precisam de informações de sistemas de integração adjacentes (logs, análise de impacto etc.), para os quais se voltam, roteando incidentes.

Para minimizar o tempo de resolução de incidentes, como projeto piloto, decidimos criar uma equipe multifuncional integrada de funcionários de primeira e segunda linha para resolver incidentes nos sistemas de frente do Banco - Internet banking, mobile banking, serviços de envio de mensagens (sms e push) + frente principal - Sistema de escritório bancário.

Este comando é intermediário entre a primeira e a segunda linha - uma linha e meia de suporte, que chamamos de "Frontline".

Já na fase de formação dessa equipe, encontramos algumas dificuldades, inclusive do lado dos gerentes de segunda linha, de modo que a transferência de um funcionário para este projeto de cada um dos sistemas significou uma diminuição no capital da equipe atual. E os próprios funcionários de segunda linha, que deveriam participar do piloto, não estavam ansiosos para mergulhar de cabeça na solução de incidentes.

Por meio de negociações iterativas, pudemos concordar que a principal tarefa dos participantes da segunda linha deste projeto é o treinamento de funcionários de primeira linha, a criação conjunta de uma base de conhecimento comum, a construção de processos de interação interna, a provisão dos acessos necessários e, depois disso, um retorno gradual aos seus negócios. unidades.

A localização do Frontline era o Centro de TI do banco em Obninsk.

A primeira formação da linha de suporte de um ano e meio foi a seguinte:

• dois funcionários de suporte de primeira linha
• dois funcionários do grupo de suporte do sistema de front office
• dois funcionários do grupo de suporte de Internet banking e mobile banking
• um funcionário do grupo de suporte de serviços de informações ao cliente (sms e push)

O foco principal da equipe foi focado em 3 indicadores:

• VELOCIDADE - 70% dos pedidos recebidos pela equipe devem ser resolvidos em não mais de 8 horas úteis
• QUANTIDADE - a equipe não pode encaminhar mais de 20% das solicitações para a segunda linha de suporte
• QUALIDADE - a proporção de incidentes redescobertos pelos usuários não deve exceder 3%

fig. 2 Processo de tratamento de incidentes na linha de frente

A próxima dificuldade que encontramos no início do piloto foi a falta de uma equipe em nosso entendimento inicial, se houver.

Apesar de os funcionários da Frontline estarem nas proximidades na mesma sala, não houve tentativas de mudar para funcionalidade cruzada, troca de experiências, interação significativa dentro. Como resultado, cada participante, como antes, concentrou-se em resolver solicitações por meio de seu sistema - alguém estava "cheio de incidentes", alguém estava claramente mais livre.

Foi decidido "alterar sistemas" dentro da equipe, por exemplo, para que o representante do suporte bancário da Internet não resolva mais incidentes em seu sistema, mas comece a processar solicitações para o sistema de front office, e o representante do suporte do sistema de front office comece a resolver incidentes nos serviços de notificação etc. d.

Porque

1. Tente chegar à universalidade para que os funcionários possam alternar entre incidentes de sistemas diferentes, assim distribuindo uniformemente a carga em todos os participantes;
2. Fornecer às crianças conhecimento suficiente dos sistemas relacionados que os ajudarão a identificar rapidamente a causa do erro de integração;
3. Estabelecer comunicação dentro da equipe;

Criou as contas necessárias, forneceu acesso aos logs do aplicativo e do banco de dados e muito mais! :)

Inicialmente, a resolução de incidentes foi reduzida. É claro que, quando você não conhece os meandros do sistema e também precisa resolver incidentes nele, essa não é uma tarefa fácil. Mas os caras começaram a procurar ajuda, estudar e atualizar a base geral de conhecimento e, gradualmente, as coisas foram.

Além disso, todos os dias começamos a realizar pequenos levantamentos no início de cada dia útil, perto das folhas de papel que colamos nas paredes e com indicadores diários. Discutimos e finalizamos com um marcador, regozijando-nos em sua implementação ou discutindo o motivo da falha, se não conseguirmos alcançá-las.

Posteriormente, é claro, substituímos essas folhas de papel por painéis on-line.


fig. 3 Painel de eficiência da linha de frente

Aqui, preciso dizer um agradecimento especial ao chefe da equipe de suporte do sistema de atendimento ao banco, que assumiu o papel de liderança e cultivou o desenvolvimento da equipe por dentro - Alexey, obrigado! :)

Nos primeiros dois meses, a equipe não conseguiu lidar com os objetivos estabelecidos, o processo de treinamento estava em andamento, a base de conhecimento foi atualizada.

A partir do terceiro mês do projeto piloto, começamos a nos ajustar às metas e, após 6 meses, começamos a superá-las.


Fig. 4 Projeto piloto da linha de frente, primeiros indicadores

Logo ficou claro que o piloto “decolou” com sucesso e era aconselhável dimensionar o projeto.

Gradualmente, começamos a adicionar competências em outros sistemas à equipe, retirar funcionários de segunda linha e adicionar funcionários do Service Desk.

Gradualmente, mudamos para “T - funcionalidade cruzada”, quando cada participante recebeu um sistema principal e dois sistemas adjacentes.


fig. 4 Estatísticas comparativas para 2018 sobre o tempo de solução de solicitações entre as equipes de rastreamento Frontline e de segunda linha

Em 2018, a equipe da Frontline encerrou mais incidentes do que qualquer outra unidade de acompanhantes do Banco. Os caras excederam significativamente as metas estabelecidas, mostrando mais uma vez que o trabalho em equipe e as competências multifuncionais podem alcançar resultados significativos.

Para a segunda linha de suporte, o "Frontline" hoje é um "escudo" confiável, o que reduz significativamente o fluxo de chamadas que chegam a eles.


Fig. 5 Número e proporção de incidentes resolvidos na linha de frente (Fig. - Equipe1) em relação aos incidentes resolvidos na segunda linha para todos os sistemas do Banco

Hoje, todos os participantes do Frontline são funcionários do Service Desk que resolvem incidentes nos principais sistemas de fachada do Banco, cumprindo as metas estabelecidas.

Além disso, “Frontline” é o próximo passo para os funcionários do Service Desk em nossa carreira, antes de passar para a segunda linha de suporte.