Projeto de TI que já falhou antes leva a mais controle técnico. O risco fiscal continua sem dono

Empresa que já quebrou a cara num projeto de TI reforça controle no próximo. Mais teste, mais gate de aprovação, mais camada de validação técnica antes do go-live. O que esse reforço não cobre é uma pergunta diferente: o próximo sistema calcula, valida e concilia tudo que o anterior calculava, validava e conciliava sozinho, ou uma parte disso ficou para trás sem que ninguém tenha formalizado a perda?

O reforço pós-falha protege contra o risco errado

Depois de um projeto de TI que deu errado, a resposta organizacional é previsível, e é a resposta correta para o problema que já aconteceu: mais teste técnico, mais gate de aprovação, mais camada de governança sobre cronograma e estabilidade. Isso protege contra o tipo de falha que a empresa já viveu, sistema instável, integração quebrada, prazo estourado.

O que esse reforço não cobre é um tipo diferente de falha, que não aparece em nenhuma métrica de projeto de TI: a migração rodar tecnicamente perfeita, dentro do prazo, com todos os testes técnicos aprovados, e ainda assim entregar um ambiente fiscal mais fraco do que o anterior. Estabilidade técnica e paridade fiscal são duas promessas diferentes. A primeira, o projeto reforçado costuma cumprir. A segunda, na maior parte dos casos que acompanhamos, ninguém formalizou como requisito.

O time de TI mede sucesso pelo que consegue medir: o sistema não caiu, os testes técnicos passaram, o cronograma foi cumprido. Perda de capacidade fiscal não aparece em nenhuma dessas métricas, porque nenhuma delas foi desenhada para capturar esse tipo de risco.

O que um sistema antigo faz sozinho, e ninguém lista

Um SAP com anos de operação acumula capacidade fiscal de um jeito que não vira documentação formal. Uma validação automática que passou a existir depois de um erro específico anos atrás. Um relatório de conferência que alguém construiu para pegar uma inconsistência recorrente. Uma regra de exceção configurada para um cenário fiscal particular do negócio, que hoje ninguém mais lembra por que existe, só que existe e funciona. Nada disso está num documento de requisitos. Está no sistema, funcionando, e por isso mesmo invisível.

Quando o projeto de migração é desenhado a partir do reforço pós-trauma, o escopo técnico recebe atenção redobrada, porque a organização já sabe, na pele, o custo de negligenciar isso. Nos projetos que acompanhamos, o escopo fiscal costuma entrar como item de homologação, algo que o time fiscal valida numa das últimas fases, não como inventário de capacidade a preservar desde o desenho da arquitetura. A pergunta que orienta o projeto reforçado é "isso vai funcionar tecnicamente?", não "isso vai calcular, sozinho, tudo que o sistema anterior calculava sozinho?".

Por que isso não aparece antes do go-live

A ausência de uma validação, de um relatório ou de uma regra de exceção não gera erro de sistema. Gera silêncio. O ambiente novo simplesmente não faz aquilo que o antigo fazia, e como não há erro técnico associado, nenhum dos testes reforçados detecta a lacuna. O teste técnico confirma que o sistema funciona como foi configurado. Não confirma que o sistema foi configurado para preservar tudo que o anterior fazia.

Essa lacuna aparece meses depois do go-live, num contexto muito específico: alguém do time fiscal precisa de um número, uma conferência, uma exceção tratada, que o sistema antigo entregava sozinho, e descobre que agora precisa calcular na mão, ou pior, descobre que ninguém está calculando, porque ninguém sabia que precisava. Nos casos que acompanhamos, o primeiro sinal de downgrade fiscal costuma não ser um erro. É uma pergunta sem resposta pronta. E, diferente de um erro de sistema, essa pergunta não gera chamado, não gera ticket, não entra em nenhum painel de incidente. Ela fica só na cabeça de quem precisava daquele número, até virar rotina de trabalho manual que ninguém formalizou.

O trauma do projeto anterior explica o desequilíbrio

Faz sentido, do ponto de vista organizacional, que o reforço pós-falha se concentre no que já doeu. Empresa que sofreu com integração quebrada reforça teste de integração. Empresa que sofreu com estouro de cronograma reforça governança de prazo. É uma resposta racional a um risco conhecido e recente. O problema é que capacidade fiscal perdida silenciosamente não é o risco que a empresa acabou de viver, então não entra no radar do reforço, mesmo sendo, em muitos casos, um risco de exposição regulatória e financeira potencialmente maior do que o risco técnico que motivou o trauma original.

Isso não é uma crítica ao time de TI, que está fazendo exatamente o trabalho que lhe foi pedido: entregar um sistema tecnicamente estável, dentro do prazo, sem repetir o erro anterior. O ponto cego não é de execução, é de escopo: ninguém pediu, formalmente, para alguém tratar capacidade fiscal como algo que pode regredir e que precisa ser medido antes e depois da migração, do mesmo jeito que estabilidade técnica é medida.

Por que esse ponto cego pesa mais agora do que há cinco anos

O volume de decisões de migração para S/4HANA está concentrado neste período por um motivo concreto, não por moda de mercado. Segundo o cronograma de fim de suporte do SAP ECC 6.0, convergente entre fontes especializadas independentes (nenhuma delas é o SAP Support Portal, que bloqueia leitura automatizada, mas as três citam a mesma comunicação da própria SAP e chegam ao mesmo número), a manutenção mainstream para quem roda EHP 0 a 5 já encerrou em 31/12/2025, sem manutenção estendida oferecida para essa faixa. Para quem roda EHP 6 a 8, o prazo mainstream vai até 31/12/2027, com manutenção estendida disponível até 31/12/2030, mediante custo adicional.

Isso significa que uma fatia relevante das empresas que ainda operam SAP ECC está decidindo o projeto de migração sob pressão de prazo, não por planejamento de longo prazo. Projeto sob pressão de prazo tende a comprimir exatamente a etapa que exigiria mais tempo, o levantamento detalhado de capacidade fiscal acumulada, porque essa etapa não tem uma data de vencimento visível como o fim do suporte tem. A pressão de calendário empurra atenção e orçamento para o que tem deadline claro, o desligamento do suporte, e afasta atenção do que não tem deadline formal, a paridade fiscal.

O que muda quando paridade fiscal vira requisito formal

A correção não é reduzir o reforço técnico, que continua sendo necessário e correto. É acrescentar, ao lado dele, um inventário formal do que o sistema atual calcula, valida, concilia e trata como exceção fiscal sozinho, antes de qualquer decisão de arquitetura para o próximo ambiente. Esse inventário vira critério de aceite: cada item precisa de um responsável, um destino no novo sistema (mantido nativamente, redesenhado, ou assumido conscientemente como processo manual) e uma validação específica de que o destino escolhido realmente cobre o que o item cobria antes.

Isso muda o tipo de pergunta que orienta o projeto. Em vez de "os testes técnicos passaram?", a pergunta adicional é "cada função fiscal que o sistema anterior executava sozinho tem um dono confirmado no sistema novo, e alguém testou especificamente essa função, não só a estabilidade geral do ambiente?". A segunda pergunta não substitui a primeira. Ela cobre um risco que a primeira, por desenho, nunca foi feita para capturar.

Um padrão que vemos com frequência em diagnóstico

Um padrão que aparece com frequência quando avaliamos o ambiente fiscal de uma empresa que já migrou para S/4HANA depois de um projeto de TI anterior fracassado: a arquitetura nova é, tecnicamente, mais robusta que a antiga em quase todos os aspectos mensuráveis, performance, disponibilidade, integração entre módulos. E, ao mesmo tempo, existe uma ou mais rotinas fiscais que voltaram a ser manuais, porque a automação que existia no ambiente anterior não foi mapeada como requisito de migração, foi simplesmente descontinuada por não estar em nenhuma lista formal.

Em geral, ninguém decidiu remover essa automação de propósito. Ela não sobreviveu porque nunca foi nomeada. O time de TI, focado em entregar estabilidade técnica depois de um histórico de projeto fracassado, testou o que estava no escopo formal. A automação fiscal específica, que vivia como conhecimento tácito de quem operava o sistema antigo, não chegou a virar linha de requisito, e por isso não chegou a ser replicada nem testada no ambiente novo. O resultado técnico é impecável. O resultado fiscal é uma regressão silenciosa que só aparece quando alguém sente falta do que o sistema antigo fazia sozinho.

Quem deveria assinar o inventário de capacidade fiscal

Um inventário de capacidade fiscal só funciona como proteção real se tiver dono e assinatura formal, do mesmo jeito que o plano de teste técnico tem. Isso significa nomear, por escrito, quem no time fiscal é responsável por levantar cada função crítica do sistema atual, quem no time de TI é responsável por confirmar o destino de cada item no sistema novo, e quem, no comitê de projeto, assina que o levantamento está completo antes de a fase de construção avançar. Sem essa assinatura formal, o inventário vira um documento de boas intenções que ninguém cobra no meio da correria do cronograma técnico.

Essa exigência de assinatura importa especialmente porque um projeto pós-trauma nasce com prazo mais apertado, não mais folgado, do que o de um projeto anterior sem histórico de falha: a organização quer provar, o quanto antes, que desta vez a execução técnica vai dar certo, e esse cronograma comprimido compete, dia a dia, com o tempo necessário para levantar capacidade fiscal com cuidado. Um dono formal, com prazo e critério de aceite explícitos, é o que evita que essa etapa seja empurrada silenciosamente para depois do go-live, exatamente o padrão que gera o downgrade fiscal discutido neste artigo.

Um teste simples para saber se sua operação está exposta

Existe uma pergunta prática para verificar se esse ponto cego existe hoje no seu próximo projeto, ou já existiu num projeto recente: alguém consegue apresentar, por escrito, a lista completa do que o sistema fiscal atual faz sozinho, sem depender de conferência manual, planilha paralela ou memória institucional de quem está há mais tempo na empresa? Se a resposta é não, ou se a resposta existe só na cabeça de uma ou duas pessoas específicas, a capacidade fiscal atual não está documentada o suficiente para ser preservada de forma deliberada numa migração. Ela só sobrevive por acidente, se sobreviver.

Esse é um exercício que recomendamos rodar antes de qualquer decisão de escopo de projeto de S/4HANA, especialmente em empresas que já passaram por um projeto de TI fracassado e estão, por isso mesmo, mais inclinadas a colocar toda a energia de controle no lado técnico. O reforço técnico pós-trauma é necessário. Só não é suficiente, porque ele foi desenhado para resolver o problema que já aconteceu, não o problema fiscal que ainda não apareceu.

Decidir o que fazer com cada item desse inventário, manter, redesenhar ou aceitar como processo manual, é decisão do time fiscal e do negócio, não nossa. O papel que cabe à arquitetura de sistema é garantir que essa decisão seja tomada de forma consciente e documentada, com cada item nomeado, testado e com um dono claro, em vez de virar descoberta meses depois do go-live, quando alguém precisa exatamente daquele número que ninguém, na prática, está mais calculando.

Levantar esse inventário, com cada item nomeado, testado e com um dono claro, é o caminho que o Diagnóstico Fiscal Estruturado percorre antes que a decisão de arquitetura seja tomada sem ele.