Toda empresa que roda SAP há mais de uma década carrega um acervo que ninguém consegue descrever inteiro: relatórios, interfaces, cargas, enhancements, formulários e workflows construídos ao longo de anos, por gente que em boa parte já saiu. É o WRICEF — e ele é, quase sempre, a maior fonte de incerteza de um projeto de conversão.

A pergunta que o projeto precisa responder no começo é simples de enunciar e difícil de responder: quantos desses objetos existem, quais ainda são usados e quais precisam ser reescritos? Sem esses três números, qualquer estimativa de prazo é chute com cara de cronograma.

Por que o WRICEF assusta

Não é o volume em si. É a combinação de três desconhecidos.

Ninguém sabe o que cada objeto faz. A documentação, quando existe, descreve a intenção original — não o que o objeto virou depois de sete alterações. O conhecimento real está no código.

Ninguém sabe o que é usado. Relatório criado para um fechamento específico de 2016 continua transportado, mantido e migrado como se fosse essencial.

Ninguém sabe o que quebra. A mudança de modelo de dados no S/4 — tabelas que viraram visões, campos que mudaram de tamanho, o cliente e o fornecedor que viraram parceiro de negócios — atinge exatamente o código que lê tabela direto. E esse é justamente o código antigo.

O resultado é o padrão conhecido: o projeto estima por média, descobre a realidade no meio da execução e renegocia prazo.

Primeiro o dado, depois o julgamento

Inventariar é trabalho de ferramenta. O próprio ambiente sabe quais objetos customizados existem, quem os criou, quando foram alterados pela última vez e a qual pacote pertencem. E as ferramentas de verificação de compatibilidade apontam, objeto a objeto, o que conflita com o modelo de dados novo. Isso não é território de IA — é consulta, e consulta precisa ser exata.

Cortar pelo uso é o passo mais rentável e o mais esquecido. O ambiente registra execução. Cruzar o inventário com o dado de uso dos últimos dois anos costuma revelar que uma fatia grande do acervo simplesmente não roda. Objeto que ninguém executa não precisa ser analisado, nem reescrito, nem testado: precisa de uma decisão de aposentadoria, que é barata.

Só depois desses dois cortes o esforço restante vale julgamento — e é aí que a IA muda a economia.

Onde a IA entra de verdade

Explicar o que o objeto faz. Ler alguns milhares de linhas de ABAP e devolver, em linguagem de negócio, qual processo aquilo atende, quais tabelas toca e o que acontece se deixar de existir. É o insumo que permite ao usuário-chave dizer “isso eu uso” ou “isso a gente parou de usar em 2019” — conversa que hoje trava porque ninguém sabe explicar o objeto para quem decide.

Agrupar por finalidade. Costuma haver cinco relatórios que resolvem a mesma pergunta com pequenas variações, criados por áreas diferentes ao longo dos anos. Agrupar por semelhança de propósito — não de nome — mostra onde cinco objetos podem virar um. É a mesma capacidade de similaridade que usamos em saneamento de dados mestres, aplicada a código.

Propor o destino. Com o resultado da verificação de compatibilidade, o uso e a finalidade na mesa, o assistente sugere a classificação: aposentar, substituir por recurso padrão, reescrever dentro do modelo de extensibilidade liberado, ou manter com ajuste mínimo. Vem com justificativa e com a evidência que a sustenta.

Estimar com base comparável. Objetos parecidos que já foram tratados dão a referência de esforço. Estimativa por analogia rastreável é bem melhor que estimativa por sensação.

Apoiar a reescrita. Quando o objeto precisa mudar, o assistente propõe a versão que usa interface liberada em vez de leitura direta de tabela — e explica o que mudou. A revisão continua sendo de quem responde pelo código.

O que fazer com o que sobra

Depois dos cortes, o acervo restante se distribui em quatro destinos, e nomeá-los evita a discussão infinita.

Aposentar. Sem uso e sem dono. Bloquear, observar um ciclo de fechamento, remover.

Substituir por padrão. Muito relatório antigo existe porque o padrão da época não atendia. Boa parte já é coberta por recurso nativo — verificar antes de reescrever é o item que mais reduz esforço.

Reescrever no modelo liberado. O objeto é necessário, mas foi construído de um jeito que não sobrevive. Aqui é onde a reescrita assistida ganha tempo real.

Manter com ajuste. Funciona, é usado, e o ajuste é pontual.

Essa classificação é a ponte para a conversa seguinte, que é a mais importante do projeto: como chegar ao clean core — porque reescrever mantendo o mesmo vício apenas adia o problema para a próxima atualização.

O que muda no projeto

A estimativa deixa de ser chute. Com inventário, uso e classificação, o número de objetos a tratar é conhecido antes de começar — e é quase sempre bem menor que o total, o que costuma ser a melhor notícia da fase de preparação.

A conversa com o negócio muda. Em vez de “vocês precisam dizer o que usam”, o time chega com a lista do que não roda há dois anos e pede confirmação. Muito mais fácil de responder.

O conhecimento fica. A descrição de cada objeto, validada, vira documentação que sobrevive ao projeto — e que hoje simplesmente não existe.

O limite honesto: nada disso decide por você. O corte de escopo em desenvolvimento é decisão política dentro da empresa, porque cada objeto tem alguém que o pediu. A automação dá o argumento com dado; a conversa continua sendo humana.

Para preparar essa fase, na Inove Academy o guia de brownfield, greenfield e bluefield ajuda a entender o que cada abordagem exige do seu acervo de desenvolvimento — a escolha muda completamente o tamanho desse trabalho.