Modelo de business case SAP: aprovação sem atrasos

Um business case SAP é aprovado quando quem decide enxerga, numa única página e nos próprios termos, o problema, o custo, o retorno e o risco. Use a estrutura de sete seções abaixo, inclua todos os custos por pelo menos cinco anos, mantenha as premissas de benefício conservadoras e escreva trechos separados para o CFO, a TI e o negócio. A maioria dos casos que travam falha na apresentação, não na ideia.

Já vi aprovações se arrastarem por semanas, às vezes meses, mesmo com uma ideia sólida. Lembro de uma migração para o S/4HANA em que o primeiro pitch fracassou. A proposta estava cheia de diagramas de arquitetura de sistemas e quase não tinha nada sobre ganhos operacionais. Refizemos o material para que a abertura tratasse de reduzir os atrasos de entrega, cortar os custos de estoque e mostrar como a equipe iria executar. O CFO aprovou em uma única reunião.

Mais um ponto antes do modelo. O seu parceiro de implementação não deve escrever o seu business case. O incentivo dele é iniciar o programa. O seu é concluí-lo. É assim que programas de US$ 40 milhões viram, sem alarde, programas de US$ 90 milhões.

O sumário executivo decide tudo

Mantenha em uma página. Os executivos podem não ler mais nada.

Comece pelo problema, em números. Apresente a proposta em uma ou duas frases, sem detalhe técnico. Depois traga os principais benefícios com valores, um cronograma simples, o investimento total e os principais riscos com suas mitigações.

Em uma das empresas que apoiei antes, o sumário abria com termos como “objetos técnicos” e “Embedded HANA”. O CFO largou o documento depois do primeiro parágrafo. Reescrevemos para começar com “US$ 2,5 milhões de economia anual com a redução de estoque” e “processamento de pedidos 40% mais rápido”. O mesmo CFO leu a página inteira e aprovou o projeto naquela semana.

Quando o sumário estiver pronto, entregue-o a alguém de fora do projeto. Se a pessoa conseguir explicá-lo de volta para você, ele funciona.

Escreva para três leitores

Uma versão única para todos não funciona. Já vi propostas fortes morrerem por terem sido escritas para o público errado.

CFO e conselhoTIUsuários de negócio

O que procuramCFO e conselhoNúmeros que possam repetir sem consultar anotaçõesTIEscopo de integração mapeado contra os sistemas atuaisUsuários de negócioUm retrato, tarefa a tarefa, da semana deles

O que entregarCFO e conselhoEconomia anual e payback, com os riscos declarados com clarezaTIO modelo de suporte após o go-liveUsuários de negócioAntes e depois, com um tempo de treinamento honesto

O que os conquistaCFO e conselhoFranqueza em vez de otimismoTIEvidência de que você sabe onde projetos semelhantes deram erradoUsuários de negócioHonestidade sobre cada clique extra

O CFO e o conselho querem números que possam repetir sem consultar anotações: “US$ 2 milhões de economia anual, payback em 18 meses.” Querem os riscos declarados com clareza. Com esse público, a franqueza vale mais que o otimismo.

A TI quer o escopo de integração mapeado contra os sistemas atuais, o modelo de suporte depois do go-live e a evidência de que você sabe onde projetos semelhantes deram errado.

Os usuários de negócio querem um retrato, tarefa a tarefa, da semana deles antes e depois, e um número honesto para o tempo de treinamento. Um pequeno clique extra, repetido milhares de vezes por semana, vira um problema de verdade.

Certa vez, uma CFO rejeitou um business case no meio da reunião porque ele não respondia a nenhuma das perguntas dela. Reconstruímos o documento em três seções, uma por público, e ancoramos cada uma em KPIs mensuráveis. O plano técnico nunca mudou. Só a forma de contá-lo mudou.

São as sete seções que eu uso, nesta ordem. Lembro de uma empresa de manufatura cujo CFO encontrou os detalhes de custo enterrados na página 23, enquanto o CIO não conseguia achar os riscos técnicos em lugar nenhum. A aprovação atrasou seis meses. Com uma versão estruturada, a aprovação levou duas semanas, e o conteúdo mal havia mudado.

Seção	O que deve conter
Sumário executivo	Problema em números, proposta, benefícios, investimento total, cronograma, principais riscos
Situação atual	Pontos de dor, o custo deles hoje e o custo de não fazer nada
Abordagem proposta	Escopo, módulos, modelo de implantação (RISE, GROW ou on-premise), principais integrações
Análise financeira	Custos e benefícios em cinco anos, ROI, payback, VPL para programas maiores
Plano de implementação	Fases, marcos, equipe, dependências
Riscos	Riscos específicos, com responsáveis e mitigações
Governança	Patrocinador, comitê de direção, controle de mudanças, regras de aprovação de extensões

Mantenha os diagramas de arquitetura e o detalhe de configuração em um apêndice.

Os custos que um diretor financeiro vai procurar

Custos incompletos matam mais business cases do que benefícios fracos. Inclua todos estes:

1. Software: licença mais suporte anual no on-premise, ou a assinatura no RISE e no GROW.
2. Honorários do parceiro de implementação.
3. Infraestrutura, se você mesmo a opera; no RISE, a SAP a opera dentro da assinatura.
4. Tempo da equipe interna. É a linha que mais costuma faltar.
5. Treinamento e gestão de mudanças.
6. Migração e limpeza de dados.
7. Suporte recorrente. No on-premise, o SAP Enterprise Support há muito tempo custa cerca de 22% do valor da licença por ano. Para o RISE e o GROW, mostre a assinatura em cada ano do contrato.
8. Hypercare após o go-live.

O item 7 é a primeira coisa que muitos diretores financeiros conferem. Se os anos dois a cinco estiverem ausentes, a credibilidade cai na hora. Meu guia de custos de implementação SAP traz as faixas típicas de cada linha, e meu guia de revisão de contratos para CFOs trata do lado do parceiro.

ROI, payback e benefícios em que o CFO vai acreditar

ROI é o benefício líquido dividido pelo investimento total. US$ 3,5 milhões de benefícios em cinco anos contra US$ 2 milhões de custo dão um benefício líquido de US$ 1,5 milhão, ou 75%.

Payback é o investimento dividido pelo benefício líquido anual em caixa. Um projeto de US$ 1,2 milhão que devolve US$ 400.000 por ano se paga em três anos.

VPL (valor presente líquido) traz os fluxos de caixa futuros para o valor de hoje. Se o conselho pedir, leve a equipe de finanças para a sala.

Quantifique os benefícios mostrando o cálculo:

• Estoque: US$ 10 milhões em mercadoria, reduzidos em 15%, com custo de manutenção de 20%, economizam US$ 300.000 por ano.
• Tempo de processo: uma tarefa de 45 minutos executada 200 vezes por dia, reduzida para 15 minutos, a US$ 30 por hora, economiza cerca de US$ 750.000 por ano ao longo de 250 dias úteis.

Mostre uma curva de ganho gradual. Os benefícios no primeiro ano após o go-live costumam ser menores do que no regime estável. Mantenha os benefícios que você não consegue quantificar em uma lista separada, para que não diluam os que você consegue.

Seja conservador. Já vi empresas conseguirem aprovar projetos SAP difíceis sendo brutalmente honestas sobre os custos e conservadoras nos benefícios. Um cliente de manufatura mostrou inicialmente um ROI de 30% para o projeto de S/4HANA. Quando foi questionado, revisou o caso para um ROI mais realista, de 18%. O CFO valorizou a franqueza e aprovou.

A assinatura substitui a licença e o suporte. O RISE e o GROW são assinaturas, então o primeiro ano custa menos do que a compra de uma licença on-premise. O total em cinco anos depende de usuários, escopo e prazo. Mostre os anos um, três e cinco lado a lado.

A contabilidade muda, não só o caixa. Pelo IFRS, um contrato em nuvem muitas vezes dá acesso a um software, e não um ativo de software que você controla. Nesse caso, a decisão de agenda de 2021 do IFRS Interpretations Committee significa que os custos de configuração e customização normalmente são lançados como despesa à medida que os serviços são recebidos, e não capitalizados. Isso pode deslocar uma parte grande do custo do programa do balanço patrimonial para a demonstração de resultados. Combine com os auditores o tratamento do seu contrato RISE ou GROW antes de levar a análise financeira ao conselho.

O Clean Core muda o custo de longo prazo. As extensões construídas sobre interfaces liberadas custam mais para desenhar, mas sobrevivem aos upgrades. As modificações são mais baratas hoje e caras a cada upgrade depois. Um modelo de cinco anos deve mostrar essa diferença, sobretudo na Private Edition, em que o core ainda pode ser modificado.

A IA só entra no business case com premissas no nível do fluxo de trabalho. O Joule e outros recursos de IA podem economizar tempo em tarefas específicas. Amarre cada benefício de IA a um fluxo de trabalho nomeado, a um número de usuários e a uma taxa de adoção que você consiga defender. Os CFOs veem pitches do tipo “a IA vai transformar o negócio” toda semana e os descontam bastante.

Deixar de fora o custo de não fazer nada. Se o sistema atual causa US$ 500.000 por ano em retrabalho, isso pertence ao business case. Às vezes é maior que o investimento em SAP.

Ignorar a disrupção. O tempo de treinamento, a indisponibilidade no cutover e um primeiro mês lento depois do go-live reduzem o retorno.

Riscos vagos. “Problemas de dados” não é um risco. “Divergência nos dados mestre causando rejeição de faturas nos primeiros 30 dias” é.

Uma única data de go-live, sem detalhe. Os atrasos costumam começar nas passagens de bastão: dos requisitos para a configuração, dos testes para a aprovação, do treinamento para a prontidão. Mostre essas passagens.

Ignorar o porte da empresa. Em um projeto em que trabalhei, um pequeno distribuidor copiou o processo de governança de uma grande corporação. As reuniões semanais do comitê de direção viraram horas de produtividade perdida até o processo ser enxugado. Para menos de 200 funcionários, de 8 a 10 páginas bastam. As grandes empresas esperam modelagem financeira completa e uma seção de governança detalhada.

Trabalhei com uma equipe de manufatura que levou seis meses para obter a aprovação. Eles revisaram o business case quatro vezes, porque cada versão respondia a um aprovador e ignorava os outros. Escrever para os três leitores desde o início teria poupado a maior parte desse tempo. Depois de aprovado, o documento seguinte é o termo de abertura do projeto.

O que um business case SAP deve incluir?

Sete seções: um sumário executivo, a situação atual e o custo de não fazer nada, a abordagem proposta e o modelo de implantação, uma análise financeira de cinco anos com ROI e payback, um plano de implementação, riscos específicos com responsáveis e um modelo de governança. Mantenha o detalhe técnico em um apêndice.

Por que os business cases SAP são rejeitados?

Em geral porque os benefícios são vagos ou os custos estão incompletos, sobretudo o suporte recorrente ou os anos posteriores da assinatura. Outras causas comuns: riscos tratados de forma superficial ou um documento escrito para um único público, quando finanças, TI e operações precisam ser convencidas.

Como calcular o ROI de uma implementação SAP?

Divida o benefício líquido do período, normalmente cinco anos, pelo investimento total. Inclua todos os custos: software ou assinatura, honorários do parceiro, tempo interno, treinamento, migração de dados, suporte recorrente e hypercare. Use benefícios conservadores, com uma curva de ganho gradual após o go-live. Um ROI realista de 18% fecha mais rápido do que um otimista de 35%.

Como o RISE with SAP muda o business case?

A assinatura substitui a licença e o suporte anual, então o business case precisa de uma visão de custos para cada ano do contrato. A SAP opera a infraestrutura, o que elimina o gasto com hardware. Pelo IFRS, os custos de configuração de um serviço em nuvem normalmente são lançados como despesa em vez de capitalizados, então combine o tratamento contábil com os auditores logo no início.

Qual deve ser a extensão de um business case SAP?

Um sumário executivo de uma página e, depois, algo entre 15 e 25 páginas para um programa de médio porte e até 40 para uma grande empresa. O que passar disso vai para apêndices. Se o patrocinador precisa de uma hora para fazer o briefing a partir dele, está longo demais.

Qual é o custo de não fazer nada em um business case SAP?

O que o negócio continua perdendo por permanecer no sistema atual: soluções manuais de contorno, esforço de reconciliação, atrasos em relatórios, suporte a sistemas envelhecidos e decisões tomadas com dados pouco confiáveis. Se você está no ECC, inclua o custo da manutenção estendida depois de 2027.