Mock · dados sintéticos

Relatório de auditoria
Ortelis Satellite

A Ortelis é uma operadora fictícia de internet por satélite residencial. O relatório mostra o aspecto de uma auditoria real, com cinco perdas inventadas.

Setembro 2026 · 5.000 pedidos · CAT + OMS + BPM + PROV · USD · execução demo-20260901

Este relatório é um mock. Nenhum motor o gerou. Os pedidos e os números vêm do dataset inventado. Tem a forma da saída planejada (findings.json + journeys).
Achados 5 4 críticos · 1 médio
Trabalho manual 1.268 h por mês, somente nos quatro sistemas
Custo USD 57.319 por mês, a USD 45 por hora carregada
Pedidos travados 50 1% do mês, sem evento posterior

A receita em risco dos pedidos travados soma USD 3.250 por mês (50 × ARPU 65). O custo de R03 já a inclui.

Resumo executivo

Um pedido leva 69 horas. Deveria levar menos de uma. Ninguém trabalha 60 dessas horas: são um vazio entre sistemas que nenhum processo reivindica.

Prioridade: adicionar capacity_profile ao catálogo técnico (USD 18.750/mês). Tentar de novo o provisionamento antes da fila manual (USD 12.750/mês). Compensar o timer de 48 horas (USD 14.104/mês). As três ações cobrem 80% do custo.

Mapa do fluxo

Cada passo ocorre em um sistema diferente. As caixas tracejadas marcam onde o pedido perde tempo ou se duplica.

passo normal espera manual vazio sem evento
Fluxo de um pedido entre catálogo, OMS, BPM e provisionamento O catálogo valida o pedido. O BPM abre uma checagem manual de capacidade. O OMS decompõe o pedido. O BPM instala. A ativação falha no provisionamento. A nova tentativa cria uma segunda ordem de serviço e depois ativa. Os achados R01, R02, R03 e R04 estão marcados. CATÁLOGO OMS BPM PROVISIONAMENTO Oferta validada sem capacity_profile R02 Checagem manual 2 h de trabalho manual R02 Decomposição SO + WO em minutos Instalação 6 h · timer 48 h R03 Ativação falha HUB_TIMEOUT R01 Nova tentativa cria uma 2ª SO R04 Ativo 60 h depois 60 h

Fonte: data/demo/ (dataset sintético). As setas cruzam de um sistema a outro. Nenhum identificador comum as une (R05). SO = ordem de serviço. WO = ordem de trabalho.

Máquina de estados

Os estados do pedido e três becos sem saída que a auditoria encontrou.

Estados do pedido e seus becos sem saída Caminho normal: pedido, validado, decomposto, agendado, instalado, provisionando, ativo. A partir de decomposto, uma nova tentativa cria uma segunda ordem de serviço. A partir de provisionando, uma falha sem nova tentativa cai em uma fila manual. Um timer de 48 horas sem compensação deixa o pedido travado. Pedido Validado Decomposto Agendado Instalado Provisionando Ativo 2ª ordem de serviço R04 Falha sem nova tentativa R01 Timer sem compensação R03 Fila manualalguém o resgata Travadosem evento posterior Sem identificador comum, unir os quatro registros exige uma janela de tempo (R05).

Uma nova tentativa manual tira o pedido da fila. O timer não tira. Os 50 pedidos travados continuam em PROVISIONING no fim do mês.

Para onde vão os dias

Um pedido do dataset sintético, ORD-1005: 69 horas de ponta a ponta. Ninguém trabalha 60 delas.

trabalho de um sistema espera manual vazio sem evento
Linha do tempo de ORD-1005 Duas horas de checagem manual. Seis de instalação. Uma falha de provisionamento. Sessenta horas sem nenhum evento. Uma nova tentativa cria uma segunda ordem de serviço e ativa o pedido. TRABALHO ESPERA SEM EVENTO 69 h de ponta a ponta checagem manual · 2 h (R02) instalação · 6 h falha HUB_TIMEOUT sem evento · 60 h (R01) nova tentativa + 2ª SO (R04) 0 h 12 h 24 h 36 h 48 h 60 h 69 h

O vazio começa quando a primeira tentativa falha. Termina quando alguém tenta de novo à mão 60 horas depois. Nesse intervalo não há nenhum evento: nem espera declarada nem nova tentativa agendada.

Achados

O exemplo mostra cinco achados sobre o mesmo mês de pedidos. A severidade será derivada do impacto.

Impacto mensal calculado com as taxas do dataset: 5.000 pedidos, USD 45 por hora carregada.
ID Achado Severidade Pedidos h/mês USD/mês Ação
R01 Fallout de provisionamento sem nova tentativa Crítica 400 · 8% 283 12.750 Tentar de novo automaticamente com backoff antes da fila manual.
R02 Checagem manual de capacidade por atributo ausente Crítica 5.000 · 100% 417 18.750 Adicionar capacity_profile à spec. Automatizar a atribuição de feixe.
R03 O timer do BPM vence sem compensação Crítica 150 · 3% 313 14.104 Encerrar ou reenfileirar o pedido às 48 h. 50 pedidos ficaram travados.
R04 A nova tentativa do OMS duplica a ordem de serviço Média 20 · 0,4% 30 1.590 Tentar de novo de forma idempotente, com a chave do pedido.
R05 Sem identificador de correlação de ponta a ponta Crítica 300 · 6% 225 10.125 Usar um id comum nos quatro sistemas, do pedido à tentativa.
Total 5.000 1.268 57.319

R03 inclui USD 3.250 de receita em risco. A evidência de cada achado está em data/report.json (texto do mock em espanhol).