Portal de Indicadores Operacionais
O indicador estava preso num sistema sem API, dentro da rede. Tiramos ele de lá.
- Python
- Flask
- Jinja2
- Supabase
- PostgreSQL
- Chart.js
- Leaflet
- launchd
- Vercel
- Situação
- Em produção
- Módulos
- 6
- Coletas por dia
- 6, agendadas
- Migrations versionadas
- 11
O problema
O que estava acontecendo
Os indicadores da operação viviam num sistema legado sem API, acessível apenas de dentro da rede da empresa. Cada análise significava alguém entrar no sistema, exportar um relatório e montar a leitura à mão.
Isso tinha dois custos. O primeiro é óbvio: tempo. O segundo é pior: como o dado só existia no momento em que alguém o exportava, não havia série histórica. Comparar dois meses era um projeto.
E os planos de ação que nasciam dessas análises viviam em planilha: sem dono, sem prazo e sem histórico de quem mudou o quê.
A solução
O que construímos
Separamos o problema em duas metades, porque elas têm restrições opostas.
Dentro da rede, um coletor agendado faz a extração do sistema legado e envia o resultado para um banco na nuvem. Ele roda sozinho, em horários fixos, e também sob demanda quando alguém pede atualização pelo portal.
Fora da rede, o portal lê apenas esse banco. Ele nunca fala com o sistema legado, e é justamente por isso que a arquitetura funciona: a nuvem não alcança um endereço privado, e insistir nisso seria construir sobre areia.
Sobre essa base, o portal consolida seis módulos de indicador e adiciona um módulo de Ações, onde o dado passa a nascer no próprio portal, com responsável, prazo e histórico.
A interface
Como ela se parece
A leitura desce do indicador para a causa: qualidade, causa raiz e a fila que explica o número.
Recriação da interface, construída com os tokens visuais do projeto. Os números exibidos são ilustrativos, e nenhum dado real de cliente é reproduzido.
Funcionamento
Como funciona na prática
Coleta agendada
Dentro da rede, o coletor extrai o sistema legado em horários fixos ao longo do dia. Um monitor registra sinal de vida, então se a coleta parar, a operação sabe.
Consolidação
Os dados são gravados na nuvem de forma incremental. O histórico se acumula sozinho: a série mensal passa a existir sem ninguém montá-la.
Leitura
O portal exibe os módulos com recorte de permissão: cada supervisor enxerga apenas a própria equipe, cada gestor apenas as próprias áreas.
Ação
Da leitura nasce o plano. O módulo de Ações registra responsável, prazo e andamento, com histórico que não se apaga.
Escopo
O que o sistema faz
Indicadores
- Painel gerencial que desce do indicador para a causa: qualidade → causa raiz → cancelamento → fila de agendamento → avaliação do atendimento
- Produtividade da equipe, com recorte por supervisor
- Índice de qualidade e reincidência, com série mensal
- Acompanhamento de indisponibilidades
Operação
- Módulo de ações com responsável, prazo, andamento e histórico append-only
- Módulo georreferenciado que cruza a malha da rede com uma fonte pública de avisos, com mapa interativo
- Transcrição e ata de reunião assistidas por IA, com ata editável
Governança
- Três papéis independentes: administração, supervisão vinculada a equipes e gestão vinculada a áreas
- Sem cadastro público: contas criadas pela administração, senha trocada pelo próprio usuário
- Tela de monitoramento da coleta, com sinal de vida e log
Engenharia
Os problemas difíceis
O que exigiu decisão de arquitetura, não apenas código.
A nuvem não alcança a rede interna
O sistema de origem só responde de dentro da rede corporativa, e a aplicação roda na nuvem. Em vez de furar isso, invertemos o fluxo: quem está dentro empurra o dado para fora, em horário agendado. A aplicação nunca precisa alcançar o legado.
Extrair de um sistema sem API
Não havia integração disponível. A extração é feita sobre a interface do próprio sistema, com autenticação, e precisa tolerar mudanças de layout e queda de rede sem corromper o histórico já coletado.
Dado que não tem de onde voltar
Alguns módulos espelham o legado e podem ser recoletados. Outros, como as ações e as ordens de serviço criadas no portal, só existem ali. Tratamos os dois tipos com regras diferentes: histórico append-only e proteção redobrada contra operação destrutiva.
Permissão que precisa ser real
Um supervisor enxergar a equipe de outro não é um detalhe de interface. O recorte é aplicado no servidor, antes de o dado chegar à tela.
Resultado
O que mudou na operação
- O indicador saiu da exportação manual e passou a estar sempre atualizado, sem ninguém operar nada
- A série histórica passou a existir, e comparar períodos deixou de ser um projeto
- O plano de ação ganhou dono, prazo e histórico, no mesmo lugar onde o problema aparece
- Cada pessoa enxerga exatamente o recorte que lhe cabe
- A operação sabe quando a coleta para, em vez de descobrir por um número estranho na tela
Quer uma solução parecida?
Começamos entendendo a sua operação, não vendendo este sistema. Retorno em até 24h úteis. Sem proposta e sem compromisso.
Solicitar diagnóstico gratuitoContinue
Outros projetos
Plataforma de Ordens de Serviço e Repasse
Prestadora de serviços de campo em telecom
Plataforma multi-tenant que importa a produção do sistema da operadora, aplica um motor de regras de preço versionado e calcula o repasse de cada técnico, com fechamento aprovado e conferência do próprio técnico.
- Next.js 15
- React 19
- TypeScript
- Tailwind CSS
- Supabase
- +8
ERP, CRM e Field Service em uma plataforma
Empresa de fibra óptica, CFTV e infraestrutura de redes
Plataforma única que cobre o ciclo inteiro: do funil comercial à obra, da obra ao despacho do técnico, do técnico à baixa de material, com controle de acesso por cargo e trilha de auditoria.
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS v4
- shadcn/ui
- +6