ERP-herstel bij FMCG: één rapportage via SAP Analytics Cloud

Deze casestudy is bedoeld voor CFO's en IT-leiders die meer dan één ERP draaien en geen eenduidige set cijfers krijgen. In het kort: een vastgelopen grensoverschrijdend rapportageproject tussen Oracle in Singapore en SAP in het Verenigd Koninkrijk werd in zes maanden hersteld. Vijf dingen deden dat. Een kleinere stuurgroep met echte bevoegdheid. Scope teruggebracht tot de rapporten die beslissingen sturen. Afgesproken definities over beide systemen. SAP Analytics Cloud als de ene rapportagelaag. En lokale ambassadeurs in plaats van klassikale training. Zit u in dezelfde positie, begin dan bij governance en definities, niet bij het debat over de tool.

Het verhaal begint met een vastgelopen ERP-analyticsproject bij een bekende FMCG-groep met hoofdkantoor in Singapore. De groep hield een belang van 26% in een Brits energydrinkbedrijf. Ondanks het minderheidsbelang lag de managementcontrole in Singapore, dus de strategie in de boardroom in Azië bepaalde de dagelijkse rapportage en planning in Europa.

De technologie maakte het moeilijker. Singapore draaide Oracle ERP. Het VK draaide SAP ERP. Ze werkten elk op zichzelf, en samen vormden ze een rapportageprobleem dat al maanden aan inspanning had gekost.

De cijfers kwamen zelden overeen. Reconciliaties sleepten dagenlang voort. Zelfs eenvoudige omzetrapportage kwam anders uit, afhankelijk van welk systeem u raadpleegde.

Binnen zes maanden na de start van het herstel werd wat een mislukt initiatief leek een grensoverschrijdend rapportagemodel dat finance en operations allebei vertrouwden.

Vóór het herstelBij de relaunch

GovernanceVóór het herstelGrote stuurgroep, besluiten uitgesteldBij de relaunchAlleen echte besluitvormers, besluiten in de vergadering

ScopeVóór het herstelEen whiteboard vol verzoekenBij de relaunchRapporten die beslissingen sturen

DefinitiesVóór het herstelZelfde label, andere betekenis in elk ERPBij de relaunchAfgesproken omzet, kosten en marge

RapportageVóór het herstelAfstemming in Excel die dagen kostteBij de relaunchOracle- en SAP-data in één model in SAP Analytics Cloud

AdoptieVóór het herstelKlassikale training, daarna terug naar ExcelBij de relaunchLokale ambassadeurs, één team tegelijk

De tabel vat de uitgangspositie samen en laat zien hoe elk probleem werd opgelost.

Uitdaging	Impact	Oplossing met SAP Analytics Cloud
Twee ERP-systemen: Oracle in Singapore, SAP in het VK	De cijfers kwamen niet overeen, de reconciliatie kostte dagen	Beide voedden één rapportagemodel
Onduidelijk eigenaarschap van rapportage over grenzen heen	Strategie in Azië botste met operationele data in Europa	Standaard-KPI's zorgden dat beide entiteiten dezelfde maatstaven rapporteerden
Trage omzetrapportage	Cijfers verschilden per bronsysteem en vertraagden beslissingen	Uniforme planning en rapportage verkortten de cyclus
Planning niet op elkaar afgestemd	Singapore bepaalde de strategie, het VK voerde uit op andere aannames	Gedeelde planningsmodellen brachten beide bedrijven op één lijn

Rapporteren over twee ERP-systemen

Met Oracle in Singapore en SAP in het VK voelde rapporteren alsof u twee afzonderlijke bedrijven runde. Finance haalde dezelfde maatstaf uit elk systeem en kreeg verschillende antwoorden. In één maandelijkse review presenteerde Singapore een omzetcijfer en het VK sprak dat meteen tegen met een ander. De discussie duurde langer dan de review zelf.

Mensen vielen terug op Excel omdat dat veiliger voelde: uren exporteren, afstemmen en een eigen versie van de waarheid opbouwen. Op korte termijn werkte dat, en het veroorzaakte chronische vertragingen in de groepsrapportage. Mijn artikel over waarom CFO's nog steeds naar Excel grijpen behandelt dat patroon breder.

Consolidatie bij de maandafsluiting

De maandafsluiting was het moeilijkste onderdeel. Een kostenpost die in het ene ERP onder “operations” stond, belandde in het andere soms onder “admin”. Ik zag eens een consolidatieconcept waarin dezelfde uitgave twee keer onder verschillende koppen voorkwam. Dat sloeg het vertrouwen in de cijfers kapot. Te late resultaten werden de norm, en als de groep wel publiceerde, volgden er meestal correcties.

Operationele rapportage

De problemen reikten verder dan finance. Oracle volgde de zendingen, SAP volgde de voorraad, en er was geen enkele bron. Een magazijnmanager vertelde me dat hij in één week drie verschillende voorraadrapporten had ontvangen, alle met andere saldi. Hij lachte erbij, maar het vertraagde echte beslissingen. De bevoorrading liep achter, en verzendvertragingen waren moeilijker uit te leggen omdat operations de dashboards niet vertrouwde.

Het debat over de tool

Het kiezen van een rapportagetool werd een project op zich. Sommige managers hielden van het kostenprofiel van Power BI, anderen pleitten voor SAP vanwege de langere roadmap. Ik zat in een workshop waarin de helft van de tijd opging aan “waarom SAC en niet Power BI” in plaats van aan de rapportagebehoeften. Het debat duurde maanden en kostte momentum.

Weerstand van gebruikers

Ook nadat de eerste dashboards live waren, bleef de adoptie laag. Ik herinner me dat ik zag hoe iemand in een financevergadering een dashboard opende, er een blik op wierp, het sloot en terugging naar het eigen Excel-bestand. Niemand stelde er vragen over. Mensen vertrouwden wat ze kenden, en de dashboards hadden dat vertrouwen nog niet verdiend.

Governance opnieuw inrichten. Vergaderingen leken eindeloos en mensen vertrokken zonder te weten wie de knoop had doorgehakt. De leiding bracht de stuurgroep terug tot de echte besluitvormers. Sessies werden korter en daadkrachtiger en escalaties bereikten snel de juiste mensen. Perfect was het niet, maar er kwam beweging. Mijn gids over het leiden van een SAP-stuurgroep beschrijft dezelfde principes.

De scope onder controle krijgen. Mensen discussieerden voortdurend over welke cijfers in het groepsoverzicht thuishoorden, en de lijst met eisen was onbeheersbaar geworden. Ik herinner me een workshopwhiteboard dat van boven tot onder vol stond met verzoeken, waarvan de helft los stond van enige echte beslissing. De framing die werkte: rapportage hoeft alleen te dekken wat beslissingen stuurt. Toen dat was afgesproken, kwam de oplevering op gang.

Communicatie die relevant voelde. Eerdere updates waren generiek, waardoor finance, operations en IT elk een andere interpretatie meenamen. We stapten over op updates op maat: rapportagetijdlijnen voor finance, wijzigingen in logistieke processen voor operations, een technische roadmap voor IT. Mensen gingen betere vragen stellen omdat de updates hun taal spraken.

Lokale ambassadeurs. Alleen training werkte niet: mensen zaten de sessies uit en gingen de volgende ochtend terug naar Excel. De ommekeer kwam van lokale ambassadeurs, collega's die al geloofwaardig waren in hun teams en de dashboards informeel in hun eigen woorden uitlegden. Ik zat bij een van die sessies en het verschil was opvallend. Mensen stelden vragen die ze in een klaslokaal nooit zouden hebben gesteld. De adoptie verbeterde team voor team.

De tabel vat samen wat er veranderde en waarom het werkte.

Aandachtsgebied	Wat er veranderde	Impact
Governance opnieuw ingericht	Stuurgroep teruggebracht tot echte besluitvormers, kortere en scherpere sessies	Besluiten in de vergadering, escalaties gingen snel
Scopebeheersing	Eisen teruggebracht tot rapportage die beslissingen stuurt	Minder discussie, duidelijkere datamodellen, minder bewegende doelen
Communicatie op maat	Aparte updates voor finance, operations en IT	Elk team begreep wat voor dat team telde, het vertrouwen keerde terug
Lokale ambassadeurs	Collegiale coaching in kleine groepen in plaats van formele klassen	De adoptie verbeterde team voor team, de afhankelijkheid van Excel nam af

Toen de toolselectie eindelijk was afgerond, won SAC, deels omdat het Oracle- en SAP-data in één model kon samenbrengen zonder zwaar maatwerk. Dat nam wat hitte uit de discussie. Rapporten weerspiegelden wijzigingen veel sneller dan de oude exportcyclus. Een financieel controller zei dat ze voor het eerst niet hoefde te wachten op een nachtelijke verversing van de data om haar dag te beginnen.

De eerste keer dat de financieel manager Oracle-data en SAP-data naast elkaar in één dashboard zag, viel er een last van de schouders. Dat moment sloot het debat.

SAC dekte ook meer dan finance. Operations wilde inzicht in logistiek en magazijnbeheer, en HR wilde personeelsplanning. Planning, rapportage en visualisatie op één platform maakten het verschil tussen een tactische oplossing en een fundament voor de langere termijn. De kant-en-klare sjablonen gaven het team een voorsprong, ook al voelden sommige generiek aan, en de snelheid van die eerste oplevering herstelde het vertrouwen na maanden vertraging.

Eén technisch punt als u dit ontwerp wilt kopiëren. Live-dataverbindingen van SAC zijn beperkt tot SAP-bronnen zoals SAP HANA, BW, S/4HANA, BPC embedded, BusinessObjects-universes en SAP Datasphere. Niet-SAP-data, zoals een Oracle ERP, komt meestal binnen via een importverbinding, een universe of een datalaag ertussen. Bepaal die architectuur vroeg, want die bepaalt hoe actueel de cijfers van elke kant kunnen zijn.

De eerste mijlpaal was het datamodel. Oracle en SAP moesten allebei één structuur voeden, wat moeilijker was dan het eruitzag. Velden droegen hetzelfde label maar betekenden in elk systeem iets anders. Het kostte weken aan het in kaart brengen van definities voordat finance het eens was over wat omzet, kosten en marge precies betekenden.

De dashboards werden stapsgewijs uitgerold. Finance kwam eerst, daarna sales en operations, elk met rapporten rond hun daadwerkelijke werk. Vroege versies voelden te star. Gebruikers zeiden dat, en ze hadden gelijk. De dashboards werden beter, en afgesproken KPI's namen de plaats in van wat voorheen steeds terugkerende maandelijkse discussies waren.

De relaunch was binnen zes maanden afgerond. Voor het eerst stonden Oracle- en SAP-data in één model binnen SAC. De discussies over reconciliatie namen af, en het management beoordeelde de cijfers zonder te wachten tot er Excel-bestanden rondgingen.

Planningscycli die weken hadden gekost, duurden dagen. Planners konden scenario's modelleren en vergelijken met de werkelijke cijfers. Sommige managers wilden meer detail dan de dashboards gaven, maar het feit dat ze de cijfers vertrouwden was al significant.

Een magazijnmanager vertelde dat de voorraadniveaus in zijn rapport voor het eerst overeenkwamen met wat finance liet zien. Die stille afstemming tussen afdelingen was de echte indicator. Niemand vroeg om terug te gaan naar het oude proces.

De tabel noemt de fouten die het project deden vastlopen en de les van elk.

Fout	Wat het veroorzaakte	Les
Onduidelijke governance	Eindeloze vergaderingen, geen besluiten, oplopende vertragingen	Leg rollen en beslisrechten vroeg opnieuw vast
Scopeverschuiving	Rapportagedoelen bleven verschuiven	Houd de scope strak en gekoppeld aan beslissingen
Gebruikers negeren	Gebruikers verloren vertrouwen en de adoptie vertraagde	Betrek gebruikers vroeg en geef ze context
Te veel maatwerk	Tijd verspild aan het herbouwen van rapporten	Begin met sjablonen en standaardconnectoren, pas later aan
Zwak verandermanagement	Training miste haar doel, oude gewoontes bleven hangen	Haal lokale ambassadeurs en collegiale coaching er vroeg bij

Drie lessen steken erboven uit. Governance weegt zwaarder dan de tool: zonder duidelijk eigenaarschap in een omgeving met meerdere ERP-systemen valt rapportage uit elkaar, welk platform ook. Stem data-definities af vóór de toolselectie: het debat Power BI tegen SAC miste de kern, want geen enkele tool lost definities op die niet overeenkomen. En verandermanagement bepaalt de adoptie: zonder ambassadeurs en gerichte communicatie waren de dashboards ongebruikt gebleven.

Drie dingen zouden veranderen als hetzelfde werk nu zou starten.

Een datalaag zou tussen SAC en de bronnen komen. SAP Datasphere, nu onderdeel van SAP Business Data Cloud, biedt gefedereerde toegang tot SAP- en niet-SAP-bronnen met een semantisch model erbovenop. In een geval met twee ERP-systemen zoals dit is het harmoniseren van Oracle- en SAP-data in die laag schoner dan het binnen elke SAC-story te doen. Het geeft SAC bovendien een live verbinding met het geharmoniseerde model.

Vragen in natuurlijke taal zouden een deel van de dashboardbouw vervangen. Met de natuurlijketaalquery van SAC en Joule kan finance bijvoorbeeld vragen om de omzet per regio voor het kwartaal, Singapore tegenover het VK. Er hoeft eerst geen story te worden gebouwd. Dat versnelt het werk zodra de data is geharmoniseerd. Het dicht geen definitiekloof.

Het commerciële gesprek zou beginnen bij het ERP-contract. Controleer welke analytics uw cloud-ERP-contract al bevat voordat u over SAC onderhandelt. Volledige SAC-planning wordt apart gelicentieerd, en hybride landschappen waarin de ene entiteit op cloud-ERP zit en de andere niet, vragen nog steeds om zorgvuldige licentiëring.

De governance-reset, de scopediscipline, de lokale ambassadeurs en de communicatie op maat zouden niet veranderen. Die patronen gelden ongeacht de technologie. Het menselijke werk om twee ERP-systemen dezelfde cijfers te laten rapporteren, wordt niet geautomatiseerd. Meer over SAC zelf leest u in mijn SAP Analytics Cloud-gids.

Waarom liep het ERP-rapportageproject van deze FMCG-groep vast?

Singapore draaide Oracle en het VK draaide SAP, en elke maand zette finance de cijfers met de hand aan elkaar. Dat kostte dagen en niemand vertrouwde het resultaat volledig. Reviews liepen vast wanneer Singapore één cijfer presenteerde en het VK dat met een ander tegensprak. De stuurgroep was ook te groot, dus niemand nam besluiten. De kosten stegen, het vertrouwen zakte en het project dreef af.

Wat veranderde de richting van het herstel?

De leiding erkende dat het project vastzat en stemde in met een herstelplan. De stuurgroep werd teruggebracht tot een kleine groep echte besluitvormers, er werden prioriteiten gesteld, SAP Analytics Cloud werd gekozen als de ene rapportagetool en de communicatie werd per doelgroep afgestemd. Vergaderingen gingen van schuldvraag naar wat er nu kwam, en mensen begonnen te geloven dat het project kon leveren.

Hoe ging SAP Analytics Cloud om met zowel Oracle als SAP?

SAC bracht Oracle- en SAP-data samen in één rapportagemodel, zodat beide naast elkaar in één dashboard verschenen zonder handmatige reconciliatiebestanden. Beide systemen in één overzicht zien was het moment dat het debat over de tool beëindigde. Let op dat de live-verbindingen van SAC alleen SAP-bronnen ondersteunen. Oracle-data komt doorgaans binnen via een importverbinding, een BusinessObjects-universe of een datalaag zoals SAP Datasphere.

Waarom boden gebruikers in het begin weerstand tegen de dashboards?

De dashboards gingen live zonder voldoende zakelijke context. Gebruikers kregen te horen dat ze SAC moesten gebruiken, maar niemand liet zien hoe het paste bij hun dagelijkse werk, en de training was generiek. Mensen vertrouwen wat ze kennen, en de dashboards hadden dat vertrouwen nog niet verdiend. Lokale ambassadeurs, die de dashboards in hun eigen woorden uitlegden, veranderden dat.

Hoe ziet een geslaagd herstel van ERP-rapportage eruit?

Het is zelden één ding. Hier was het een governance-reset, scopebeperking, afgesproken definities, communicatie op maat en ambassadeurs onder collega's die samenwerkten. SAC hielp omdat het beide ERP-systemen zonder zwaar maatwerk in één model bracht, maar technologie alleen had het project niet gered. Na zes maanden presenteerden mensen die hadden gewacht tot het zou instorten dashboards die ze zelf hadden gebouwd.