Recuperação de ERP em FMCG: relatórios unificados com o SAP Analytics Cloud

Este estudo de caso é para CFOs e líderes de TI que operam mais de um ERP e não conseguem um único conjunto de números. A versão curta: um projeto de relatórios entre países, parado, com Oracle em Singapura e SAP no Reino Unido, foi recuperado em seis meses. Cinco coisas fizeram isso. Um comitê de direção menor, com autoridade real. Escopo reduzido aos relatórios que movem decisões. Definições acordadas entre os dois sistemas. O SAP Analytics Cloud como a camada única de relatórios. E campeões locais no lugar de treinamento em sala de aula. Se você está na mesma situação, comece pela governança e pelas definições, não pelo debate sobre ferramentas.

A história começa com um projeto de analytics de ERP parado em um conhecido grupo de FMCG com sede em Singapura. O grupo tinha uma participação de 26% em uma empresa de bebidas energéticas do Reino Unido. Apesar da participação minoritária, o controle de gestão ficava em Singapura, então a estratégia definida na sala do conselho, na Ásia, moldava os relatórios e o planejamento do dia a dia na Europa.

A tecnologia tornava tudo mais difícil. Singapura usava o Oracle ERP. O Reino Unido usava o SAP ERP. Cada um funcionava por conta própria e, juntos, criavam um problema de relatórios que já havia consumido meses de esforço.

Os números raramente batiam. As conciliações se arrastavam por dias. Até o relatório básico de receita saía diferente conforme o sistema que você consultasse.

Em seis meses de trabalho de recuperação, o que parecia uma iniciativa fracassada virou um modelo de relatórios entre países em que finanças e operações confiavam.

Antes da recuperaçãoNo relançamento

GovernançaAntes da recuperaçãoComitê de direção grande, decisões adiadasNo relançamentoSó quem decide de verdade, decidindo na reunião

EscopoAntes da recuperaçãoUm quadro branco de pedidosNo relançamentoRelatórios que movem decisões

DefiniçõesAntes da recuperaçãoO mesmo rótulo, significado diferente em cada ERPNo relançamentoReceita, custo e margem acordados

RelatóriosAntes da recuperaçãoConciliação no Excel que levava diasNo relançamentoDados do Oracle e do SAP em um único modelo no SAP Analytics Cloud

AdoçãoAntes da recuperaçãoTreinamento em sala de aula e depois de volta ao ExcelNo relançamentoCampeões locais, uma equipe por vez

A tabela resume a posição de partida e como cada problema foi resolvido.

Desafio	Impacto	Resolução com o SAP Analytics Cloud
Dois ERPs: Oracle em Singapura, SAP no Reino Unido	Os números não se alinhavam; a conciliação levava dias	Ambos alimentaram um único modelo de relatórios
Responsabilidade pelos relatórios pouco clara entre os países	A estratégia na Ásia entrava em choque com os dados operacionais na Europa	KPIs padronizados fizeram as duas entidades reportarem as mesmas métricas
Relatório de receita lento	Os valores diferiam conforme o sistema de origem, atrasando decisões	Planejamento e relatórios unificados encurtaram o ciclo
Desalinhamento de planejamento	Singapura definia a estratégia; o Reino Unido executava com premissas diferentes	Modelos de planejamento compartilhados alinharam os dois negócios

Relatórios em dois ERPs

Com o Oracle em Singapura e o SAP no Reino Unido, reportar parecia administrar dois negócios separados. Finanças tirava a mesma métrica de cada sistema e obtinha respostas diferentes. Em uma revisão mensal, Singapura apresentou um valor de receita e o Reino Unido o contestou na hora com outro. A discussão durou mais do que a revisão.

As pessoas voltavam ao Excel porque parecia mais seguro: horas exportando, conciliando e montando a sua própria versão da verdade. Funcionava no curto prazo e criava atrasos crônicos nos relatórios do grupo. O meu artigo sobre por que os CFOs ainda recorrem ao Excel trata desse padrão de forma mais ampla.

Consolidação do fim do mês

O fim do mês era a parte mais difícil. Um custo que ficava em “operações” em um ERP às vezes acabava em “administrativo” no outro. Certa vez vi um rascunho de consolidação em que a mesma despesa aparecia duas vezes, sob títulos diferentes. Isso matou a confiança nos números. Resultados atrasados se tornaram a norma e, quando o grupo publicava, em geral vinham revisões depois.

Relatórios operacionais

Os problemas iam além das finanças. O Oracle controlava as remessas, o SAP controlava o estoque, e não havia uma fonte única. Um gerente de armazém me contou que recebeu três relatórios de estoque diferentes em uma semana, todos com saldos diferentes. Ele riu ao contar, mas aquilo estava atrasando decisões reais. A reposição ficava para trás, e os atrasos de envio eram mais difíceis de explicar porque a operação não confiava nos painéis.

O debate sobre a ferramenta

Escolher uma ferramenta de relatórios virou um projeto à parte. Alguns gestores gostavam do perfil de custo do Power BI; outros defendiam o SAP pelo roteiro mais longo. Participei de um workshop em que metade do tempo foi gasto em “por que SAC e não Power BI” em vez de nas necessidades de relatórios. O debate durou meses e drenou o ímpeto.

Resistência dos usuários

Mesmo depois que os primeiros painéis entraram no ar, a adoção continuou baixa. Lembro de ver alguém em uma reunião de finanças abrir um painel, dar uma olhada, fechar e voltar para a sua planilha de Excel. Ninguém questionou. As pessoas confiavam no que conheciam, e os painéis ainda não tinham conquistado essa confiança.

Reiniciar a governança. As reuniões pareciam intermináveis e as pessoas saíam sem saber quem tinha tomado a decisão. A liderança reduziu o comitê de direção aos verdadeiros decisores. As sessões ficaram mais curtas e mais decisivas, e as escalações chegavam rápido às pessoas certas. Não foi perfeito, mas as coisas começaram a andar. O meu guia sobre como conduzir um comitê de direção de projeto SAP apresenta os mesmos princípios.

Colocar o escopo sob controle. As pessoas discutiam o tempo todo quais números pertenciam à visão do grupo, e a lista de requisitos tinha se tornado ingerenciável. Lembro de um quadro branco de workshop coberto de ponta a ponta com pedidos, metade deles sem relação com qualquer decisão real. O enquadramento que funcionou: os relatórios só precisam cobrir o que move decisões. Depois que isso foi acordado, a entrega ganhou ritmo.

Comunicação que parecesse relevante. As atualizações anteriores eram genéricas, então finanças, operações e TI tiravam cada uma uma interpretação diferente. Passamos a atualizações sob medida: cronogramas de relatórios para finanças, mudanças de processos logísticos para operações, um roteiro técnico para TI. As pessoas começaram a fazer perguntas melhores porque as atualizações falavam a língua delas.

Campeões locais. O treinamento sozinho não havia funcionado: as pessoas assistiam às sessões e voltavam ao Excel na manhã seguinte. A mudança veio de campeões locais, colegas que já tinham credibilidade em suas equipes, explicando os painéis de maneira informal, com as próprias palavras. Assisti a uma dessas sessões e a diferença foi marcante. As pessoas fizeram perguntas que jamais fariam em uma aula. A adoção melhorou uma equipe por vez.

A tabela resume o que mudou e por que funcionou.

Área de foco	O que mudou	Impacto
Reinício da governança	Comitê de direção reduzido aos verdadeiros decisores; sessões mais curtas e mais objetivas	Decisões tomadas na reunião; as escalações andavam rápido
Controle de escopo	Requisitos reduzidos aos relatórios que movem decisões	Menos debate, modelos de dados mais claros, menos alvos móveis
Comunicação sob medida	Atualizações separadas para finanças, operações e TI	Cada equipe entendeu o que importava para ela; a confiança voltou
Campeões locais	Coaching entre colegas em pequenos grupos em vez de aulas formais	A adoção melhorou equipe por equipe; a dependência do Excel caiu

Quando a seleção da ferramenta enfim terminou, o SAC venceu, em parte porque conseguia trazer os dados do Oracle e do SAP para um único modelo sem muito trabalho personalizado. Isso tirou um pouco do calor da discussão. Os relatórios refletiam as mudanças muito mais rápido do que no antigo ciclo de exportação. Uma controller financeira disse que foi a primeira vez que ela não precisou esperar uma atualização de dados durante a noite para começar o dia.

Na primeira vez em que o gerente financeiro viu os dados do Oracle e do SAP lado a lado em um único painel, foi como tirar um peso das costas. Esse momento encerrou o debate.

O SAC também cobriu mais do que finanças. Operações queria uma visão de logística e armazenagem, e RH queria planejamento da força de trabalho. Ter planejamento, relatórios e visualização em uma única plataforma fez a diferença entre um remendo tático e uma base de longo prazo. Os modelos prontos deram à equipe uma vantagem inicial, mesmo que alguns parecessem genéricos, e a rapidez dessa primeira entrega restaurou a confiança depois de meses de atraso.

Um ponto técnico, se você pretende copiar este desenho. As conexões live do SAC se limitam a fontes SAP, como SAP HANA, BW, S/4HANA, BPC embedded, universos do BusinessObjects e SAP Datasphere. Dados que não são SAP, como os de um Oracle ERP, normalmente entram por uma conexão de importação, um universo ou uma camada de dados intermediária. Defina essa arquitetura cedo, porque ela determina o quão atualizados podem estar os números de cada lado.

O primeiro marco foi o modelo de dados. O Oracle e o SAP tinham de alimentar uma única estrutura, o que era mais difícil do que parecia. Campos tinham o mesmo rótulo, mas significavam coisas diferentes em cada sistema. Foram semanas mapeando definições até que finanças concordasse sobre o que receita, custo e margem realmente significavam.

Os painéis foram liberados em etapas. Finanças veio primeiro, depois vendas e operações, cada uma com relatórios construídos em torno do seu trabalho real. As primeiras versões pareciam rígidas demais. Os usuários disseram isso, e tinham razão. Os painéis melhoraram, e KPIs acordados substituíram o que antes eram discussões mensais constantes.

O relançamento foi concluído em seis meses. Pela primeira vez, os dados do Oracle e do SAP estavam em um único modelo dentro do SAC. As discussões de conciliação diminuíram, e os executivos revisavam os números sem esperar a circulação de arquivos do Excel.

Ciclos de planejamento que levavam semanas passaram a levar dias. Os planejadores conseguiam modelar cenários e compará-los com o realizado. Alguns gestores queriam mais detalhe do que os painéis davam, mas o fato de confiarem nos números já era significativo.

Um gerente de armazém comentou que, pela primeira vez, os níveis de estoque do seu relatório batiam com o que finanças mostrava. Esse alinhamento discreto entre departamentos era o verdadeiro indicador. Ninguém pediu para voltar ao processo antigo.

A tabela lista os erros que paralisaram o projeto e a lição de cada um.

Erro	O que causou	Lição
Governança pouco clara	Reuniões intermináveis, nenhuma decisão, atrasos crescentes	Redefina papéis e direitos de decisão cedo
Deriva de escopo	As metas dos relatórios não paravam de mudar	Mantenha o escopo enxuto e ligado a decisões
Ignorar os usuários	Os usuários perderam a confiança e a adoção desacelerou	Envolva os usuários cedo e dê contexto a eles
Excesso de personalização	Tempo perdido reconstruindo relatórios	Comece com modelos e conectores padrão; personalize depois
Gestão de mudanças fraca	O treinamento não acertou o alvo; os velhos hábitos ficaram	Traga campeões locais e coaching entre colegas desde cedo

Três lições se destacam. Governança importa mais do que a ferramenta: sem responsabilidade clara em um cenário com vários ERPs, os relatórios desmoronam seja qual for a plataforma. Alinhe as definições de dados antes de escolher a ferramenta: o debate entre Power BI e SAC errava o ponto, porque nenhuma ferramenta corrige definições que não batem. E a gestão de mudanças decide a adoção: sem campeões e sem comunicação direcionada, os painéis teriam ficado sem uso.

Três coisas mudariam se o mesmo trabalho começasse agora.

Uma camada de dados ficaria entre o SAC e as fontes. O SAP Datasphere, agora parte do SAP Business Data Cloud, dá acesso federado a fontes SAP e não SAP, com um modelo semântico por cima. Em um caso de dois ERPs como este, harmonizar os dados do Oracle e do SAP nessa camada é mais limpo do que fazê-lo dentro de cada story do SAC. Isso também dá ao SAC uma conexão live com o modelo harmonizado.

Perguntas em linguagem natural substituiriam parte da construção de painéis. A consulta em linguagem natural do SAC e o Joule permitem que finanças peça, por exemplo, a receita por região no trimestre, Singapura contra o Reino Unido. Nenhuma story precisa ser construída antes. Isso acelera o trabalho depois que os dados estão harmonizados. Não fecha uma lacuna de definições.

A conversa comercial começaria pelo contrato do ERP. Verifique que recursos de analytics o contrato do seu ERP em nuvem já inclui antes de negociar o SAC. O planejamento completo do SAC é licenciado à parte, e ambientes híbridos, com uma entidade em ERP em nuvem e outra não, ainda exigem licenciamento cuidadoso.

A reinicialização da governança, a disciplina de escopo, os campeões locais e a comunicação sob medida não mudariam. Esses padrões valem seja qual for a tecnologia. O trabalho humano de fazer dois ERPs reportarem os mesmos números não se automatiza. Para saber mais sobre o próprio SAC, veja o meu guia do SAP Analytics Cloud.

Por que o projeto de relatórios de ERP deste grupo de FMCG travou?

Singapura usava Oracle e o Reino Unido usava SAP, e todo mês finanças costurava os números à mão. Levava dias e ninguém confiava totalmente no resultado. As revisões emperravam quando Singapura apresentava um valor e o Reino Unido o contestava com outro. O comitê de direção também era grande demais, então ninguém tomava decisões. Os custos subiam, a confiança caía e o projeto ia à deriva.

O que mudou o rumo da recuperação?

A liderança admitiu que o projeto estava travado e acordou um plano de recuperação. O comitê de direção foi reduzido a um pequeno grupo de verdadeiros decisores, as prioridades foram definidas, o SAP Analytics Cloud foi escolhido como a ferramenta única de relatórios e a comunicação passou a ser específica para cada público. As reuniões deixaram de buscar culpados e passaram a tratar do que vinha a seguir, e as pessoas começaram a acreditar que o projeto podia entregar.

Como o SAP Analytics Cloud lidou com Oracle e SAP ao mesmo tempo?

O SAC trouxe os dados do Oracle e do SAP para um único modelo de relatórios, de modo que ambos apareciam lado a lado em um único painel, sem arquivos de conciliação manual. Ver os dois sistemas em uma só visão foi o momento que encerrou o debate sobre a ferramenta. Observe que as conexões live do SAC só suportam fontes SAP; os dados do Oracle normalmente chegam por uma conexão de importação, um universo do BusinessObjects ou uma camada de dados como o SAP Datasphere.

Por que os usuários resistiram aos painéis no início?

Os painéis foram lançados sem contexto de negócio suficiente. Disseram aos usuários para usar o SAC, mas ninguém mostrou como ele se aplicava ao trabalho diário, e o treinamento era genérico. As pessoas confiam no que conhecem, e os painéis ainda não tinham conquistado essa confiança. Campeões locais, explicando os painéis com as próprias palavras, mudaram isso.

Como é uma recuperação bem-sucedida de relatórios de ERP?

Raramente é uma coisa só. Aqui foram uma reinicialização da governança, redução de escopo, definições acordadas, comunicação sob medida e campeões entre colegas trabalhando juntos. O SAC ajudou porque trouxe os dois ERPs para um único modelo sem muito trabalho personalizado, mas a tecnologia sozinha não teria salvado o projeto. Seis meses depois, pessoas que esperavam o projeto desabar estavam apresentando painéis que elas mesmas haviam construído.