dhiego.spinillo
Índice

(001)EnxergarBHubHead de Dados

SLA de 60% para perto de 90%

Problema
O SLA rodava na casa dos 60%, e ninguém conseguia dizer onde o atraso nascia.
O que fiz
Um painel diário com o atraso de hoje, aberto até o operador, e o da semana que vem, num forecast.
Resultado
Com os rituais da operação em cima dele, o SLA chegou perto de 90%.
SLA quando cheguei
60%
com os rituais diários
~90%
gestores usando o painel
~50
tarefas acompanhadas
170 mil+

Tarefas que vencem por analista, dia a dia

Dados ilustrativos. O painel real mostrava esse desenho por carteira: os vencimentos de cada dia divididos pelas pessoas do time. Foi olhando para ele que o pessoal achou a configuração que empilhava os prazos.

Problema

Com cerca de 6 mil clientes e mais de 170 mil tarefas, a média esconde tudo. Um departamento muito atrasado e os outros em dia dão o mesmo número que todos um pouco atrasados.

E o número do dia engana. Estar com 90% no prazo no dia 8 parece ótimo, mas talvez só uma fração do mês tenha vencido até ali.

O que fiz

Um painel no Databricks Apps, em cima do lakehouse, que responde a duas perguntas:

Cerca de 50 gestores usavam o painel, e ele entrou nos rituais diários. Quem fez o SLA subir foi a operação. O papel dos dados foi mostrar onde.

Olhando para frente, o pico deixou de ser surpresa.

O que o forecast revelou

Muita tarefa vencia no mesmo dia sem motivo legal. Era configuração da ferramenta de tarefas. Os prazos foram diluídos ao longo do mês, sempre dentro do vencimento legal, e o trabalho parou de chegar em ondas.

O que quebrou

O responsável errado.

Para cobrar uma tarefa, é preciso saber de quem ela é. A base de responsáveis não batia com a alocação dos times em meados de 80% da carteira. Criei tabelas de snapshot e gold no dbt para acompanhar, dia a dia, a correção e as inconsistências. Em três meses, a divergência caiu para meados de 40%, junto com a subida do SLA.

Confiabilidade

Todo dia eu conferia os jobs que atualizavam as tabelas do Gestta e, por consequência, os que alimentavam o lake nas camadas bronze, silver e gold. E comparava o volume de cada tabela com o do dia anterior. Um salto grande podia ser base nova ou sujeira. Uma queda grande, um arquivo que chegou incompleto na bronze. Número que muda demais de um dia para o outro é investigado antes de chegar ao gestor.