Um pedido de Guepardo chegou pela TI. Isso pode significar três coisas diferentes

Um pedido de orçamento chega da TI com o nome Guepardo no assunto. Ele pode significar três coisas completamente diferentes, e cotar antes de saber qual delas é a certa custa caro depois. A NTT descreve o Guepardo como um pacote completo de governança fiscal integrado ao ERP SAP. Essa descrição é verdadeira e, ao mesmo tempo, inútil para responder a pergunta que importa: o que esse pedido específico está tentando resolver? Um assunto de chamado como "mensageria Guepardo" normalmente traz o nome do módulo e pouco mais. Falta exatamente o que importaria: se é extensão de algo já instalado, primeira adoção, ou pedido sem patrocínio fiscal.

Em SAP com muitos anos de operação, a camada fiscal raramente nasceu de um projeto único e documentado. Ela se acumulou: parte nativa do SAP, parte customização, parte Guepardo, parte planilha. Um pedido de componente, sem entender essa camada, é decisão tomada no escuro.

O que a NTT descreve

A NTT posiciona o Guepardo como solução fiscal integrada ao SAP ERP, um pacote completo de governança tributária, fácil de monitorar e em evolução constante. É descrição de quem detém e publica o produto, correta dentro do que descreve: a ficha técnica de uma solução. Não descreve o que acontece quando esse produto entra numa operação que já roda SAP há quase duas décadas, com processos fiscais que foram se ajustando ano a ano, reforma a reforma.

Isso importa porque o Guepardo não entra num ambiente vazio. Entra sobre uma arquitetura fiscal que já existe, ainda que ninguém tenha desenhado essa arquitetura de propósito. A pergunta que a descrição comercial não responde é: o que essa camada fiscal atual faz hoje, e quem é responsável por ela?

Sem essa resposta, qualquer orçamento de componente é estimativa sobre uma superfície que ninguém mapeou.

Vale separar duas camadas de informação que normalmente chegam juntas num material de produto. Uma é o que o Guepardo faz, tecnicamente, em termos de módulo, integração e cobertura fiscal: isso é fato verificável, documentado, igual para qualquer cliente. A outra é o que acontece quando esse módulo encontra um SAP específico, com anos de customização, exceções manuais e regras que já foram ajustadas fora do padrão original. Essa segunda camada não está em nenhuma ficha técnica, porque é única para cada ambiente.

Na prática, essa diferença aparece no levantamento de escopo como um número de reuniões: cotar o módulo isolado costuma caber numa conversa com a TI. Dimensionar o que esse módulo encontra no SAP específico exige entrevistar quem hoje sustenta cada exceção manual da apuração fiscal, o que normalmente significa mais de uma área e mais de uma reunião que o orçamento inicial não previu.

Três situações possíveis

Quem pede orçamento de um componente do Guepardo parte de uma de três situações, e cada uma muda o escopo inteiro da conversa.

A primeira: a empresa já usa o Guepardo, em algum módulo, e quer expandir para uma funcionalidade nova, como mensageria fiscal. Nesse caso, a pergunta certa é sobre integração com o que já existe, não sobre implantação do zero. O risco aqui é tratar o pedido como projeto novo quando na verdade é extensão de algo que já tem dono, histórico e configuração prévia.

A segunda: a empresa está avaliando o Guepardo pela primeira vez, atraída por uma funcionalidade específica que resolve uma dor pontual. Aqui o risco é oposto: tratar como simples adição de módulo um projeto que, na prática, é a primeira camada de governança fiscal estruturada que o SAP vai receber. Subestimar esse escopo é comum, e caro.

A terceira: alguém na TI ouviu o nome Guepardo em outro contexto, talvez numa conversa de mercado, talvez numa recomendação de parceiro, e abriu o chamado sem que o fiscal tenha participado da decisão. Entre as três, essa tende a ser a que mais aparece com assunto puramente técnico de sistema, como mensageria, sem menção a processo fiscal, prazo de obrigação ou risco de autuação.

As três situações produzem o mesmo tipo de chamado, com o mesmo nome de produto no assunto. Só a pergunta certa separa uma da outra.

Vale notar uma variação da terceira situação, menos óbvia: o pedido nasce porque um consultor externo, numa reunião recente, mencionou o Guepardo como prática de mercado para empresas do mesmo porte ou setor. Isso aproxima do caso dois (primeira adoção), mas com uma diferença relevante: a motivação veio de fora, não de uma dor fiscal identificada internamente. Quando a motivação é externa, o risco de comprar funcionalidade sem necessidade real documentada aumenta, porque ninguém internamente articulou, antes, qual problema concreto a funcionalidade resolveria.

Identificar a situação real, antes de qualquer cotação, custa pouco: uma conversa de meia hora entre TI e fiscal, com as três descrições acima como roteiro. O custo de não fazer essa conversa aparece depois, em escopo mal dimensionado ou em componente sem uso reconhecido.

Por que a resposta muda escopo e responsável

Um pedido que nasce na TI como chamado de sistema carrega um risco específico: a dor fiscal que originou o pedido pode estar sem dono do lado fiscal. A TI sabe que precisa de uma funcionalidade, mas raramente sabe articular por que o fiscal precisa dela, em qual rotina ela se encaixa, ou quem vai validar se ela resolve o problema real.

Um sinal operacional concreto disso aparece no próprio ticket de chamado: quando o campo de justificativa de negócio vem vazio, ou preenchido só com o nome técnico da funcionalidade, sem referência a uma rotina fiscal específica que ela deveria resolver. Ticket sem justificativa de negócio é ticket sem dono fiscal declarado, mesmo que tecnicamente completo.

Não é falha de produto. É decisão tomada sem o patrocinador certo na mesa.

O escopo técnico de implantar mensageria fiscal, por exemplo, é relativamente contido: configurar o canal, mapear o evento que dispara o envio, testar o fluxo. O escopo de governança é outro: quem decide o que é enviado, quem valida o conteúdo antes do envio, quem responde se o conteúdo estiver errado. Quando o pedido nasce só do lado técnico, a parte de governança fica implícita, presumida, nunca formalmente atribuída a ninguém.

Essa lacuna de governança tem um custo que só aparece depois: quando um dado sai errado por mensageria, ou quando uma auditoria pede para rastrear quem autorizou determinado envio, a resposta técnica (o log do sistema) não substitui a resposta de processo (quem validou o conteúdo antes de sair). Sistemas registram o que aconteceu. Não registram quem deveria ter verificado antes.

O sintoma mais comum desse desalinhamento: o projeto técnico fecha como concluído, com status verde, enquanto a pergunta sobre a razão fiscal original do pedido continua sem dono dentro da empresa.

Quem governa a camada fiscal hoje

Antes de aprovar o pedido de componente, existe uma pergunta anterior que raramente é feita: qual camada fiscal já roda sobre o SAP hoje, e quem no fiscal é o responsável reconhecido por ela?

Em SAP com muitos anos de operação, é comum que a resposta a essa pergunta não exista de forma clara: a camada fiscal foi se formando por acréscimos sucessivos, cada um resolvendo um problema pontual, sem que ninguém tenha sido formalmente designado dono do conjunto.

Essa ausência de dono reconhecido é o que transforma um pedido de componente simples em decisão de risco. Não porque o componente seja complexo, mas porque ninguém vai poder dizer, com autoridade, se ele resolve o problema certo, se conflita com alguma regra já existente, ou se duplica algo que já roda em outro lugar da arquitetura.

Governança, nesse caso, não é burocracia adicional. É a diferença entre comprar um componente que resolve o problema e comprar um componente que vira mais uma camada técnica sem dono, somada às que já existem.

CIO e Head de SAP carregam a responsabilidade de aprovar o investimento técnico. Raramente carregam, sozinhos, a capacidade de validar se a resposta fiscal está correta. Quando essas duas responsabilidades não se encontram antes da compra, o componente entra, funciona tecnicamente, e a pergunta sobre se ele resolveu o problema fiscal certo fica sem resposta por tempo indefinido.

Existe um artefato que, nesses ambientes, normalmente deveria existir e, na prática, quase nunca foi criado: uma matriz simples que ligue cada funcionalidade fiscal ativa no SAP ao nome da pessoa que responde por ela do lado fiscal. Não é documentação técnica de sistema, é registro de responsabilidade. Sua ausência é o sinal mais confiável de que a camada fiscal cresceu por acréscimo, não por desenho.

Essa lacuna raramente é percebida como risco enquanto o sistema continua funcionando. Ela só se torna visível quando algo falha, quando uma auditoria pergunta e ninguém responde com segurança, ou quando o próximo projeto de atualização do SAP esbarra em dependências que ninguém documentou.

Roteiro de duas perguntas antes de aprovar

Existem duas perguntas que a TI pode levar ao fiscal antes de qualquer orçamento de componente ser aprovado, e nenhuma delas depende de conhecimento jurídico aprofundado da Reforma Tributária.

A primeira: qual é a situação real entre as três descritas acima, expansão de algo que já existe, primeira adoção, ou pedido técnico sem patrocínio fiscal declarado? A resposta determina se o projeto é pequeno, médio ou se precisa primeiro de um passo anterior, que é mapear a camada fiscal atual antes de decidir o que comprar.

A segunda: quem no fiscal assina como responsável pela funcionalidade depois que ela entrar em produção? Não quem aprovou o orçamento, quem vai responder, no dia a dia, se a mensageria falhar, se o conteúdo enviado estiver incorreto, ou se a auditoria perguntar por que aquele componente existe.

Essas duas perguntas, respondidas antes da compra, evitam descobrir meses depois que ninguém sabe dizer se a compra resolveu o problema que originou o pedido.

Vale acrescentar uma terceira checagem, útil quando a resposta às duas primeiras ainda deixar dúvida: pedir que o fiscal escreva, em uma frase, qual rotina de trabalho muda depois que o componente entrar em produção. Se ninguém consegue escrever essa frase com clareza antes da compra, é sinal de que a funcionalidade está sendo comprada por nome, não por necessidade articulada.

"Tax solution integrated to SAP ERP, full tax governance package, easy to monitor and constantly evolving." NTT, descrição do Guepardo como solução fiscal para o ecossistema SAP.

O mapeamento que precede o componente

Um Diagnóstico Fiscal SAP, aplicado antes da decisão de compra, mapeia o que a camada fiscal atual faz, onde o Guepardo já existe, se existir, e onde a responsabilidade fiscal hoje está diluída entre TI, fiscal e consultoria externa. Esse mapeamento transforma um pedido de componente isolado em decisão informada sobre o que falta, não sobre o que parece faltar.

O valor desse mapeamento cresce com o tempo de operação do SAP, não diminui. Quanto mais anos de ajustes acumulados, maior a chance de o pedido atual repetir, sem saber, algo que já foi parcialmente resolvido em algum ponto do passado, por alguém que já não está mais na empresa. Mapear antes de comprar é o que evita pagar duas vezes pelo mesmo problema, com nomes diferentes.

A DFSpro é especialista sênior em Guepardo Tax e parceira da NTT, o que significa falar do ecossistema por dentro, não só da ficha técnica do produto. Isso inclui reconhecer quando o pedido certo não é o componente anunciado, mas o mapeamento que vem antes dele. O Diagnóstico Fiscal Estruturado é o primeiro passo lógico para responder, com segurança, qual das três situações está em jogo antes de qualquer orçamento avançar.