O que é Classes de Serviço?

Classes de serviço foram sistematizadas na evolução do Método Kanban para trabalho de conhecimento. David J. Anderson relata sua identificação em uma implementação de 2007 e posteriormente descreveu os arquétipos em materiais sobre o método.

O glossário da Kanban University registra Expedite, Fixed Date, Standard e Intangible. O Kanban Guide de 2025 apresenta uma referência mínima de práticas e métricas de fluxo, sem exigir quatro classes. Já o Open Guide to Kanban trata classes de serviço como técnica opcional que pode complementar decisões sobre quais itens iniciar.

Uma classe informa como um item deve ser atendido no sistema: quando pode entrar, se precisa de acompanhamento especial, como disputar capacidade e quando sua política deve ser revista. Para escolhê-la, investigue a consequência de atrasar a entrega e a forma como essa consequência muda com o tempo. A explicação econômica detalhada pertence ao verbete Cost of Delay.

Expedite, ou urgente: o atraso produz consequência imediata e relevante. Pode justificar interromper ou ultrapassar a sequência normal de seleção. Justamente por isso, a entrada precisa de critério restrito e autoridade clara. Se vários itens recebem esse tratamento ao mesmo tempo, a política perde força e o serviço comum sofre. Um limite de um Expedite simultâneo pode ser útil em alguns sistemas, mas não é regra universal do Kanban Guide.

Data Fixa: existe uma data real após a qual o impacto muda de maneira importante. Uma exigência com prazo externo pode se encaixar; uma data escolhida apenas por preferência não basta. O atendimento precisa começar com antecedência compatível com a história de entrega e com a incerteza, em vez de esperar a véspera para tratar tudo como Expedite.

Padrão: o atraso tem efeito relevante, mas normalmente não apresenta uma ruptura imediata ou uma data crítica específica. A política pode usar ordem de chegada, valor ou outros critérios explícitos para escolher entre itens. Padrão não significa pouco importante: a maior parte do serviço pode estar nessa classe.

Intangível: a consequência de esperar é menos visível no curto prazo e pode crescer depois. Melhorias de infraestrutura ou redução de trabalho manual podem ser exemplos, desde que se examine seu risco real. Chamar algo de intangível não significa deixar sempre para quando sobrar tempo. Se nunca há capacidade reservada ou critério de escolha, esses itens podem envelhecer até virarem incidentes.

A mesma natureza de demanda pode aparecer em classes diferentes. Uma correção de defeito pode ser Padrão se houver alternativa de uso, ou Expedite se interromper um serviço essencial. Por isso, tipo de demanda e classe de serviço respondem a perguntas distintas. Uma organiza o que chegou; a outra define o tratamento apropriado diante do risco de esperar.

Uma classe pode mudar quando a situação muda. Um item com data fixa não vira automaticamente Expedite na véspera, se foi iniciado com antecedência suficiente. Ao contrário, uma informação nova pode mostrar que o impacto aumentou. Registre o motivo da revisão e seu efeito sobre outros compromissos.

As políticas precisam conviver com o WIP e o sistema puxado. Abrir uma raia de urgência que sempre recebe trabalho novo pode elevar o total em andamento e alongar o tempo de itens comuns. O serviço precisa observar essas consequências e ajustar a política, não apenas colorir cartões.

Também não atribua automaticamente uma Service Level Expectation distinta a cada classe. Uma SLE é uma previsão baseada em histórico para o tempo de entrega de um item. Pode ser útil segmentar dados quando há tratamentos e distribuições realmente diferentes, mas primeiro é preciso ter uma medida e uma pergunta adequadas. Uma data desejada pelo cliente não vira expectativa estatística só porque foi escrita na raia.

Imagine uma equipe que recebe 20 solicitações por semana. Tudo entra numa fila única. Em uma semana hipotética, aparecem 14 demandas comuns, 3 melhorias de automação, 2 correções com prazo externo e 1 falha que interrompe o acesso de clientes ao serviço. Antes de classificar, a equipe chamava as 6 últimas de urgentes, embora as consequências de esperar fossem diferentes.

O grupo cria políticas iniciais. A falha com interrupção comprovada pode entrar como Expedite, com avaliação conjunta do trabalho que será interrompido. As 2 correções têm Data Fixa: cada uma recebe uma data real e uma revisão de risco antes de se aproximar dela. As 14 demandas comuns seguem Padrão. As 3 automações entram como Intangível, com capacidade reservada para discutir e iniciar melhorias.

Após 2 semanas de teste, a equipe percebe que uma automação ficou parada porque sua descrição estava vaga. Ela não muda automaticamente para Expedite. Esclarece o problema, examina o custo da espera e decide se mantém ou muda a classe.

Antes, 6 pedidos disputavam a mesma etiqueta de urgência. Depois, existem quatro políticas que explicam por que e quando um item passa à frente. Os números são inventados para ilustrar a escolha. A qualidade da política será avaliada pelas decisões que permite e por seus efeitos sobre o tempo de atendimento, não pela quantidade de cores no quadro.

Cursos K21 recomendados