Recentemente, uma questão foi levantada na Conferência & Expo HDI 2019, perguntando sobre a melhor forma de classificar e tratar problemas de desempenho. Desempenho, para o propósito desta discussão, é a disponibilidade, confiabilidade ou responsividade de um serviço.

A resposta curta é que, na maioria dos casos, questões que são relatadas como problemas de desempenho deveriam ser classificadas como incidentes, não requisições de serviço. No entanto, existem exceções. Para entender o motivo, primeiro vamos dar uma olhada nas definições da indústria para incidentes e para requisições de serviço, o porque é importante definir o que significa “desempenho normal”, o impacto do planejamento e gerenciamento de capacidade sobre o desempenho (o que costuma desencadear um problema de desempenho), e por que é importante definir padrões e configurações de qualidade.

A versão atual da ITIL define um incidente como uma interrupção não planejada de um serviço de TI ou a redução na qualidade de um serviço de TI. Uma falha na configuração de um item que ainda não afetou o serviço também é um incidente. O processo de gerenciamento de incidentes da ITIL garante que a operação normal dos serviços seja restaurada o mais rápido possível, para que o impacto nos negócios seja minimizado.

Uma requisição / solicitação de serviço é um pedido do cliente por informações ou recomendações, ou por uma alteração de um padrão (uma mudança pré-aprovada que tem baixo risco, é relativamente comum e dá continuidade a um procedimento), ou para obter acesso a um serviço de TI. Um bom exemplo de uma solicitação de serviço ocorre quando um usuário pede uma redefinição de senha. Outros exemplos podem incluir uma solicitação para responder a uma pergunta comum ou para fazer uma atualização padrão pré-aprovada na configuração de uma estação de trabalho.

Conforme mencionei acima, desempenho tipicamente é entendido como disponibilidade, confiabilidade e responsividade de um serviço. Se o desempenho de um serviço, na perspectiva do cliente, não estiver “normal” e existir evidências que comprovem isso, a questão deve ser registrada e processada como um incidente (uma vez que o serviço foi interrompido ou perdeu qualidade). O processo de gerenciamento de incidente deve ser envolvido, juntamente com suporte de primeiro nível no service desk, para prosseguir com o atendimento e a resolução de um incidente de desempenho. Se a causa do incidente não for conhecida e a ação possuir uma garantia, um relatório do problema também deve ser criado e encaminhado para que o gerenciamento de problemas investigue a causa raiz do acontecimento.

Se, no entanto, o serviço estiver sendo executado normalmente e o cliente estiver solicitando um desempenho de nível superior, – por exemplo, um maior nível de disponibilidade, mais capacidade ou responsividade aumentada – a questão deve ser tratada como uma solicitação de serviço. Neste caso, não é um problema de funcionamento no desempenho do serviço e o usuário está apenas solicitando uma otimização ou um maior nível de capacidade – o que pode refletir em componentes adicionais ou mais poderosos. Isso poderia desencadear serviços de consultoria ou pedidos de trabalho de componentes adicionais para melhorar o serviço e seu desempenho.

· Um dos pontos cruciais do projeto de utilização do chatbot como um canal de atendimento é analisar o perfil dos clientes que o utilizarão. Analise se a mudança realmente faz sentido para a sua organização em termos de satisfação e adesão do cliente. Há experiência que empresas com usuários mais conservadores levaram até 2 anos para ter uma implantação efetiva, e em muitos outros, o uso foi extinto;

· Outro ponto é a expectativa sobre os serviços que serão solucionados pelo chatbot. É comum os clientes acharem que qualquer serviço será atendido por este canal, o que não é verdade. Assim é importante um plano de comunicação eficiente para este escopo esteja claro para o cliente.

· Diminuição na adesão: o que se tem percebido é que há uma curva de utilização, que mostra a grande adesão no início e posteriormente, essa utilização diminui. Muitas vezes a queda brusca na utilização relaciona-se com a utilidade percebida pelo cliente do novo canal. Por isso a definição e comunicação do escopo de serviços oferecidos por este canal é fator importante.

- Por fim, recomenda-se que o usuário / cliente atendido pelo chatbot, tenha consciência que está sendo atendido por um robô. Não tente ludibriar o cliente que o chatbot seria um humano, pois a descoberta o leva a ficar totalmente insatisfeito com o atendimento, mesmo se seu problema tenha sido resolvido ou o bot esteja funcionando adequadamente.

Para que um cliente ou usuário experiencie um problema de desempenho com seu serviço ou aplicação, ele deve ter uma ideia do que esperar como “normal”. Existem duas formas como você pode estabelecer as expectativas sobre o desempenho do serviço junto a um cliente/usuário:

• Nenhuma ação de acerto ou negociação proposta pelo provedor de serviço. Neste caso, não há nenhuma expectativa definida com o cliente sobre o que ele deveria esperar de seu serviço, no que diz respeito à disponibilidade, responsividade ou taxa de transferência. Na falta de uma definição explícita do que esperar, obviamente o cliente sempre terá expectativas irracionais – de que o serviço esteja sempre funcionando, disponível e desempenhando no nível mais alto que se possa imaginar. Essa não é uma opção ideal para o provedor de serviços, pois ele enfrentará dificuldades para atender expectativas tão altas sobre o desempenho do serviço que oferece.
• Através da provisão de um Acordo de Nível de Serviço (SLA) para o serviço. Um SLA define, de forma explícita, o que o cliente deve esperar como “a norma” para o serviço, no que diz respeito às características de desempenho – em geral, níveis de disponibilidade (o serviço está disponível quando eu desejo acessá-lo?), responsividade para os usuários e capacidade de transferência de dados. Oferecer um SLA a um cliente para um serviço é o método ideal para definir a norma, uma vez que não haverá nenhum questionamento sobre o que é considerado um desempenho aceitável para o serviço (já que o cliente e o provedor de serviços chegaram a um acordo antecipadamente).

• O nome do serviço e uma breve descrição
• Informações de autorização (com local e data)
• Informações de contato do cliente e do provedor de serviços
• Funções e responsabilidades do cliente e do provedor de serviços
• Custo/preço
• Resultados desejados pelo cliente sobre o serviço (como ele suporta e habilita os processos e objetivos de sua empresa)
• Horário de cobertura da equipe de serviços e suporte
• Termos do acordo
• Níveis acordados de suporte (caso existam múltiplos níveis de suporte disponíveis, como suporte “básico” ou suporte “premium”)
• Requisitos ou metas de nível de serviço
• Cronograma e relatórios de revisão do serviço
• Outras informações, como histórico de mudanças, referências e glossário

A seção crítica de um SLA que pertence à definição de expectativas de desempenho entre o cliente e o provedor de serviços é aquela que estabelece requisitos e metas de nível de serviço. Exemplos de níveis de serviço para determinada tarefa podem incluir:

• Nível de disponibilidade do serviço: 99,8% de disponibilidade durante os horários de serviço acordados
• Nível de capacidade: o serviço suportará, com um tempo aceitável de resposta, até três mil usuários simultâneos
• Nível de tempo de resposta: o tempo médio de resposta para usuários do serviço varia entre 3-5 segundos para uma consulta ao banco de dados

Ao declarar explicitamente os níveis e metas de desempenho, e concordar com eles, o cliente e o provedor de serviços chegam a um entendimento em comum sobre o que constitui o desempenho aceitável/esperado para um determinado serviço. O cliente pode, de forma razoável, esperar que esses níveis de desempenho sejam exibidos durante a utilização normal do serviço, enquanto o provedor de serviços pode usar tais níveis como se fossem alvos a serem atingidos durante o atendimento aos seus clientes. 

Assim, o contexto deve ser definido primeiro, seja sem um SLA para o serviço, que faria as expectativas de desempenho serem extremamente altas, ou através de um acordo e fornecimento de um SLA para o serviço, que deixa as metas de desempenho a serem atingidas muito claras (e muito mais possíveis) tanto para o cliente quanto para o provedor dos serviços.

O desempenho de um serviço é frequentemente o resultado do quão bem você conduz o processo em andamento do planejamento e gerenciamento da capacidade. Um serviço de TI – digamos como exemplo, um serviço de e-mail baseado na web – é uma combinação de componentes que trabalham juntos para entregar seu valor para o usuário: o e-mail, que é composto por uma aplicação de e-mail do usuário, uma rede de suporte, um servidor, uma aplicação de servidor, sistemas de armazenamento, um banco de dados e outros componentes. Esses podem ser locais, baseados na nuvem ou uma combinação dos dois tipos de arquitetura.

Para que um serviço tenha um bom desempenho, ele deve ser projetado para o ambiente ao qual é destinado a operar. E isso significa que os componentes precisam ser suficientes e resilientes para atender aos padrões de demanda do serviço no ambiente do usuário, algumas vezes chamados de “padrões de atividades de negócios”. Isso simplesmente significa que a demanda para a maioria dos serviços não é contínua e estável, mas varia com o processo dos negócios. No caso do e-mail, isso pode ser refletido nas manhãs, logo após o almoço e no final do dia, quando há picos no número de usuários on-line e no volume de e-mails enviados e recebidos. 

Se o serviço e partes de seus componentes tiverem sido projetados levando em conta esses padrões – largura de banda suficiente na rede, armazenamento suficiente, poder computacional suficiente – o serviço terá um desempenho otimizado através dos ciclos dos mesmos. Se eles forem ignorados, é possível que o serviço demonstre sintomas de um problema de desempenho quando a demanda estiver alta e os componentes do serviço podem não responder adequadamente para atingir as expectativas.

Essa falta de responsividade será percebida pelos usuários como um problema de desempenho e reportada ao centro de suporte. Comentários como “fica muito lento de manhã” ou “está ficando lento e parece que vai quebrar” serão relatados como sintomas. Certifique-se de reunir informações descritivas detalhadas sobre os sintomas do problema de desempenho – data e hora, o que antecedeu o problema e o máximo de evidências de suporte possíveis. Problemas de desempenho podem, por vezes, ser intermitentes e difíceis de diagnosticar e solucionar, por isso quanto mais descritivas e detalhadas suas informações do incidente forem, mais provável será a identificação da causa e sua resolução através do gerenciamento de problemas.

Problemas de desempenho são uma percepção do cliente de que houve uma redução na qualidade de um serviço. Assim, na maioria dos casos, eles devem ser classificados como incidentes.

Problemas de desempenho, em minhas experiências como profissional e auditor, são normalmente relacionadas aos problemas de planejamento e gerenciamento de capacidade. O fator causal costuma ser atribuído a uma das seguintes opções:

• Capacidade de serviços e componentes insuficiente para atender a demanda. Por exemplo, largura de banda insuficiente na rede para lidar com o tráfego, capacidade insuficiente disponível em dispositivos de armazenamento (unidades de disco, unidade de estado sólido ou nuvem), força computacional inadequada (CPU insuficiente para atender a demanda)
• Demanda inesperada colocada sobre o serviço e nos componentes de suporte. Por exemplo, o serviço foi projetado, planejado e implementado considerando um determinado número de usuários e, de repente, há uma quantidade enorme deles tentando entrar no sistema.

Em uma ou ambas as situações, o serviço começa a se degradar na visão dos usuários, seu desempenho normal não está mais sendo realizado e eles experenciam o que é comumente conhecido como um incidente de desempenho (ou problema, se a causa for desconhecida).

Existem exceções para esse cenário. Se o usuário estiver ligando e pedindo que o desempenho seja aumentado ou otimizado (por exemplo, ele deseja uma resposta ou transferência de dados mais rápida que o normal para suas transações, ou mais capacidade, ou responsividade), então obviamente não há um problema de desempenho sendo reportado – o normal já está sendo entregue. O que ele está pedindo é um desempenho aprimorado. Em tais casos, seria adequado registrar essas chamadas como Requisições de serviço ao invés de incidentes, e atender o problema como uma solicitação de serviço, potencialmente desencadeando a utilização de uma consultoria para otimizar ou aumentar o desempenho do serviço e seus componentes.

Atente-se ao uso da palavra “qualidade” na definição de um incidente. É importante que seu centro de suporte defina – para a equipe de TI, usuários e clientes – o que é acordado como qualidade de serviço. Um usuário ou cliente recebe o valor prometido pelo serviço, seus recursos, funcionalidades e desempenho por um preço que pode pagar. Essa definição de qualidade deve aparecer em um alto nível em seu catálogo de serviços e em um nível de suporte em seus SLAs junto aos clientes e usuários. Dessa forma, os clientes sabem o que esperar em termos de qualidade de serviços, enquanto seu centro de suporte sabe o que é esperado que seja entregue aos clientes e usuários.

Obviamente, você deve se certificar de incluir essas definições do que é um incidente e uma solicitação de serviço no conjunto de diretrizes e políticas do seu centro de suporte e seus procedimentos de operações padrão (SOPs), deixando claro à equipe de suporte, e também aos demais grupos de suporte, o que constitui qualidade, bem como o que deve ser considerado um incidente e o que é uma solicitação de serviço.

Seus procedimentos para atender incidentes e Requisições de serviço devem incluir não só as definições, como também exemplos comparativos de incidentes e Requisições, e perguntas que os analistas de suporte podem fazer durante o atendimento de uma chamada, para que se certifiquem de classificar, registrar e atender o problema de forma adequada – seja ele um incidente ou uma solicitação de serviço. Como resultado de colocar em ação tais políticas e procedimentos melhorados para atender problemas relacionados ao desempenho, você deve experienciar:

• Atendimento melhorado de problemas, seja com um incidente (maioria dos casos) ou uma solicitação de serviço
• Classificação mais consistente e escalonamentos precisos, se a necessidade surgir
• Planejamento e gerenciamento de capacidade melhorados, o que acarretará em um impacto favorável ao design e arquitetura dos serviços e, consequentemente, em seu desempenho
• Atendimento mais eficiente de incidentes de desempenho e problemas resultantes
• Oportunidades reconhecidas para otimização de desempenho, se estas forem relatadas como Requisições de serviço
• Satisfação do cliente e do usuário elevadas, como resultado de um desempenho de serviço otimizado

Espero que essa explicação ajude seu centro de suporte a lidar de forma mais eficiente com problemas de desempenho e, como resultado, você enfrente menos problemas desse tipo, alcance um desempenho mais alto de serviços e deixe clientes, usuários e a equipe de suporte mais felizes!

(*) Paul é o presidente e principal consultor da Optimal Connections LLC. Com mais de 30 anos de experiência no planejamento e gerenciamento de serviços de tecnologia, Paul já ocupou diversas posições em suporte e gerenciamento em empresas como Motorola, FileNet e QAD. Ele também possui experiência no desenvolvimento da infraestrutura de service desk, consolidação de centros de suporte, implementação de portais na web e sistemas de gerenciamento de conhecimento, bem como estratégias e atividades de marketing. Atualmente, Paul desempenha diversos serviços para organizações de TI, incluindo treinamento de Gerente e Analista de Centro de Suporte, treinamento de Fundação e Nível Intermediário de ITIL, Avaliações de Melhores Práticas, Auditorias de Centro de Suporte e consultoria geral de TI. Suas formações incluem um BA e um MBA. Paul é certificado na maioria dos níveis de ITIL Intermediário e certificado como ITIL Expert. Ele também está na HDI Faculty e treinamentos da ITpreneurs, Global Knowledge, Phoenix TS e outras organizações de treinamento. Para saber mais sobre Paul, visite www.optimalconnections.com.