Governança não é barreira, é comunicação constante

A primeira versão da nossa governança era uma política bem escrita num portal que ninguém abria. Tinha regra clara, tinha escopo, tinha até fluxograma. E não governava nada: os makers continuavam criando app em ambiente pessoal, fluxo com conta nominal e conector de produção onde não devia.

O erro não era a política. Era achar que publicar é comunicar.

O que realmente mudou o comportamento

Quando invertemos a ordem, primeiro avisar e depois agir, a curva virou. Não porque ficamos permissivos, mas porque o maker passou a saber o que ia acontecer com o recurso dele antes de acontecer. Três coisas fizeram a diferença:

• Um aviso nominal, no canal onde a pessoa já está, dizendo qual recurso, por que e até quando.
• Um caminho de saída óbvio: o formulário de entrada de demanda no mesmo aviso, não escondido num portal.
• Uma sequência previsível de strikes, sempre igual, sem exceção silenciosa.

A política que ninguém leu não governa nada. O que governa é o aviso que chega na pessoa certa, antes da ação.

O modo Simulação como ferramenta de diálogo

A decisão mais útil do desenho foi separar Simulação de Ativo, e deixar isso no dado, não no código. Em Simulação o motor faz tudo, detecta, classifica, monta a notificação, registra a auditoria, e não toca em nada. Você roda uma semana, mostra o relatório para a liderança e para os makers, e a conversa deixa de ser hipotética.

O modo vive em dois níveis: um global na configuração e um override opcional por ambiente. O ambiente herda o global quando o override está vazio. Parece detalhe, mas é o que permite ligar governança de verdade num ambiente piloto sem assustar o resto do tenant.

De onde veio o KMAP

O KMAP não nasceu de um roadmap. Nasceu de uma planilha com nomes, e-mails e datas que eu atualizava à mão para saber quem já tinha sido avisado. Quando a planilha cresceu, ficou claro que o problema não era falta de controle, era falta de memória: ninguém lembrava quem já tinha sido avisado, de quê, quando.

O núcleo virou um modelo plano no Dataverse, com chave string e sem nenhum lookup. Foi uma decisão contraintuitiva e é a que mais defendo:

# exporta o núcleo antes de qualquer mudança
pac solution export --name KMAP_Core --managed false
pac solution unpack --zipfile KMAP_Core.zip --folder ./solution

Com dezenas de milhares de recursos no inventário, lookup trava ingestão em massa: exige que o alvo exista antes, obriga a ordenar a carga e resolve GUID a cada upsert. Guardando a chave natural como texto, o upsert vira idempotente e o relacional acontece onde ele é barato, no Power BI e no FetchXML, casando string com string.

Duas linhas, porque nem todo time tem o mesmo teto

Governança esbarra em orçamento antes de esbarrar em técnica. Por isso estou tocando duas versões em paralelo, e não uma só com funcionalidade escondida atrás de um plano.

A linha simples roda sem licenciamento adicional. Foca no que resolve a maior parte do problema: inventário, aviso e registro. É o suficiente para sair do zero e começar a conversa com os makers.

A linha premium é apoiada em licenciamento e entra onde a escala exige: automação de ação, telemetria mais profunda e integração com o resto da operação.

A régua para decidir o que fica em cada uma é simples: se a funcionalidade é pré-requisito para ter a conversa com o maker, ela vai para a linha simples. Cobrar por isso empurraria de volta para a planilha manual quem mais precisa sair dela.

A lição que fica

Governança madura não se mede pela quantidade de bloqueio, e sim pela quantidade de recurso que se regulariza sozinho antes do bloqueio. Quando o aviso funciona, a quarentena vira exceção, e aí você sabe que parou de brigar com o maker e começou a trabalhar com ele.

Se você está começando esse caminho agora, comece pelo inventário e pelo aviso. O motor de ação pode esperar.