Lean IT no Service Desk: como dimensionar escala sem estourar a fila
Por que a fila não cresce em linha reta
Em planejamento de capacidade, a pergunta de partida costuma ser quantos agentes cobrem a demanda prevista. A resposta depende da forma como a espera se comporta. Em filas com vários atendentes, modeladas por Erlang C, o tempo de espera cresce devagar enquanto a utilização está longe de 100% e dispara quando ela se aproxima do limite. Uma redução pequena de equipe pode, portanto, produzir um aumento grande de fila.
O erro mais comum é aplicar o mesmo corte percentual em todos os níveis. O primeiro nível costuma ter atendimentos curtos e mais folga. N2 e N3 recebem os casos complexos, com tempo de manuseio maior e menos gente. É nesses níveis que a utilização já está mais perto do limite, e é neles que a fila aparece primeiro. O contexto de debate sobre a escala 6x1 aumenta o interesse no assunto, porque qualquer redução de jornada obriga a refazer essa conta por nível, não só no total.
Cinco conceitos que mudam o dimensionamento
- Utilização e ocupação
- Proporção do tempo disponível em que o agente está atendendo. Planejar para utilização muito alta deixa a operação sem margem para pico de chegada.
- Shrinkage
- Parcela do tempo pago em que o agente não atende: pausas, treinamentos, reuniões, férias e absenteísmo. Um dimensionamento que ignora shrinkage sai curto.
- WIP e limite de WIP
- WIP é o trabalho em andamento. Pela lei de Little, o WIP médio é a taxa de chegada vezes o tempo médio no sistema. Limitar o WIP por nível reduz troca de contexto e mostra o gargalo mais cedo.
- Shift-left e base de conhecimento
- Resolver no nível mais barato. Uma base de conhecimento bem mantida no N1 e o autosserviço reduzem o volume que sobe para N2 e N3, que é onde a capacidade é mais escassa.
- Kaizen e trabalho padrão
- Melhoria contínua em passos pequenos. Padronizar a forma de atender reduz o tempo de manuseio e a variabilidade, o que baixa a espera sem contratar ninguém.
O que aparece no cenário do simulador
O CSIBAI Lean Control Desk usa um cenário de help desk com três níveis: N1 Control Desk, N2 Especialistas e N3 Sustentação. Chegadas por dia da semana e hora, mix de atendimento e escala base vêm de dados agregados de uma operação real. Com a escala histórica, o cenário mostra o seguinte.
Com a escala a 70% da histórica, N2 e N3 passam de 100% de uso e a fila média do N2 passa de mil tickets, enquanto o N1 continua com folga. Esse é o ponto do exercício. A folga visível no primeiro nível não é capacidade que se possa retirar sem consequência nos níveis de cima.
Incidente maior: tratar o pai e ligar os filhos
Quando uma falha derruba um sistema, não chega um chamado, chegam dezenas ou centenas, todos do mesmo problema. A prática de ITIL é tratar o primeiro como incidente maior (o chamado pai), dar a ele prioridade máxima, ligar os demais (os filhos) e resolver a causa uma vez só. Os filhos esperam o pai e fecham junto com ele.
Nos dados agregados da operação que calibra o cenário, esse padrão existe, mas é uma parcela pequena dos tickets. Incidentes maiores chegaram a ter de 100 a mais de 400 chamados que citam o mesmo pai, quase sempre de SAP e software. O simulador traz um evento assim na semana 5, com cerca de 300 chamados, e deixa você escolher entre ligar os filhos ao pai ou atender cada chamado separado.
Numa partida com a escala histórica e a semente padrão, o resultado foi o seguinte. Ligando os filhos ao pai, o pai foi resolvido em cerca de 8 horas e os 300 chamados consumiram cerca de 10 horas de atendimento. Atendendo cada um separado, o pai levou cerca de 248 horas, os filhos consumiram cerca de 218 horas e 278 dos 300 chamados estavam fechados ao fim do jogo. É um resultado do cenário do jogo, que depende dos parâmetros e da semente, não uma medida de campo.
Como testar em 8 semanas
O simulador roda no navegador, sem instalação. Cada partida tem 8 semanas de operação, depois de quatro semanas de aquecimento, para a operação não começar vazia.
- Defina quantos agentes manter em cada nível, em relação à escala histórica.
- Escolha o limite de WIP de cada nível.
- Invista pontos de Kaizen em trabalho padrão, base de conhecimento no N1 ou autosserviço.
- Atravesse os três imprevistos do cenário, um pico de chegadas na semana 3 (25% acima do normal), um incidente maior na semana 5 e uma semana de ausência alta no N1 na semana 6. O jogo pausa quando o evento começa, para você reagir. No incidente maior, você decide como tratar.
- Compare o placar semanal de SLA, fila e custo com o que você esperava.
Abrir o simulador CSIBAI Lean Control Desk
Limites do simulador
O motor do simulador foi conferido contra a teoria de filas (Erlang C, aproximação de Allen-Cunneen e lei de Little). Isso valida a mecânica, não a realidade da sua operação. Os tempos de manuseio de N2 e N3, a meta de SLA do jogo, o custo por hora e o efeito do Kaizen são parâmetros do jogo, não medidos em campo. O simulador serve para treinar o raciocínio e discutir escala. Não serve como benchmark nem substitui um diagnóstico com os dados da operação.
Quem quiser conversar sobre aplicar a lógica com dados próprios pode escrever para marymtec@marymtec.com.
Perguntas frequentes
O que é Lean IT?
Lean IT é a aplicação dos princípios do Lean, como fluxo, redução de desperdício e melhoria contínua, a serviços de tecnologia como service desk, suporte e operações. Em vez de começar pela automação ou pelo aumento de equipe, começa por entender onde o trabalho espera e por quê.
Por que cortar a escala de forma linear costuma estourar a fila?
Porque o tempo de espera cresce de forma não linear conforme a utilização se aproxima de 100%. Se todos os níveis perdem a mesma proporção de agentes, os níveis de especialistas, que já trabalham mais perto do limite e têm atendimentos mais longos, saturam primeiro, e a fila cresce mesmo com o primeiro nível aparentando folga.
O que é shrinkage no dimensionamento de equipe?
Shrinkage é a parcela do tempo pago em que o agente não está disponível para atender, por pausas, treinamentos, reuniões, férias e absenteísmo. Ignorá-lo faz a equipe parecer maior do que é na prática, e o dimensionamento sai curto.
O que é limite de WIP e como ele ajuda um service desk?
WIP (work in progress) é a quantidade de trabalho em andamento. Limitar o WIP por nível reduz a troca de contexto, evita que tickets fiquem parados em atendimento e deixa o gargalo visível mais cedo. Pela lei de Little, o WIP médio é a taxa de chegada multiplicada pelo tempo médio no sistema, então reduzir um reduz o outro.
O simulador CSIBAI Lean Control Desk precisa de instalação ou é pago?
O simulador roda direto no navegador, sem instalação, e não cobra para jogar. O cadastro de e-mail na página é opcional.
O que é um incidente maior e como tratar os chamados ligados a ele?
Incidente maior é uma falha que gera muitos chamados do mesmo problema. A prática é tratar o primeiro como chamado pai, com prioridade máxima, ligar os demais a ele e resolver a causa uma vez só. Os chamados filhos esperam o pai e fecham junto com ele, em vez de cada um ser atendido e escalado separadamente.
Os números do simulador servem como benchmark?
Não. Chegadas, mix de atendimento e escala base vêm de dados agregados de uma operação de help desk, mas os tempos de manuseio de N2 e N3, a meta de SLA do jogo, o custo por hora e o efeito do Kaizen são parâmetros do jogo, não medidos em campo. O simulador serve para discutir a lógica de filas e escala, não para comparar com a sua operação.