O que a governança fiscal precisa ter definido antes de implantar o GUEPARDO Tax?

Como controller, acrescento a fronteira de papéis. Segundo o material que temos, o produto não define estratégia tributária, não corrige dado mestre ruim e não substitui governança. Bem, em todo caso: o checklist deve ter um item de saúde do dado mestre e um de quem decide tributação, porque nada disso vem na licença. A manutenção da licença e a correção de defeitos do produto são da NTT, e a sustentação funcional é um serviço separado. Trabalho há 6 anos com fiscal e hoje estou no RISE with SAP.

Discordo de exigir tudo antes do kickoff. Agora, voltando ao ponto, se o checklist trava o início por completo, o projeto começa atrasado e o time passa a preencher papel para cumprir. Eu exigiria só o que bloqueia: dono, escopo e acessos. O resto vira marco com data dentro do projeto, e a controller cobra o marco. O material que temos afirma que a governança do cliente tem dono por regra e dossiê com data; a ordem de exigência é decisão do patrocinador.

Veja, no rollout: itens que dá para verificar na segunda-feira.

1. Dono por regra fiscal, com nome e substituto.
2. Quem decide tributação no cliente, por escrito.
3. Lista das obrigações do escopo e de quem entrega cada uma.
4. Ambiente de qualidade e acessos individuais, nunca credencial compartilhada.
5. Critério de aceite combinado, como o primeiro fechamento real.

Sem esses cinco, eu não marcaria o kickoff. Trabalho há 18 anos com fiscal e hoje estou no RISE with SAP.

Outro formato: em vez de checklist único, dois portões. Portão 1, antes do kickoff: papéis, escopo e acessos. Portão 2, antes do desenho: inventário do que já existe, incluindo extensões Z fiscais. E aí, veja bem: checklist único vira lista que ninguém lê. Segundo o material que temos, extensões Z em torno do fiscal são a parte que mais quebra na atualização, por isso entram cedo, com dono e objetivo.