We horen het de laatste tijd vaak. Een financieel directeur die een overstap van BPC naar Group Reporting plant, zegt dan iets in de trant van: „We willen het eerst gewoon ‘lift and shift’. Het herontwerpen komt later wel.” Die reactie is begrijpelijk. De jaarafsluiting is een kwetsbare periode, en een schone kopie van wat je nu je , voelt veiliger dan herontwerpen tijdens een migratie. Het probleem is dat „eerst lift and shift” ervan uitgaat dat de twee systemen voldoende op elkaar lijken om dezelfde logica te kunnen hanteren. Dat is echter niet het geval.
BPC en groepsrapportage zijn gebaseerd op verschillende aannames
SAP BPC is een rapportageplatform met ingebouwde consolidatiefuncties: een kubus waarin je gegevens je je , waar je creatieve invoerformulieren je maken, geavanceerde berekeningen je uitvoeren, journaalposten in vrije indeling je boeken en resultaten naar een ander model je doorsturen. De architectuur is van nature flexibel. je vrijwel alles modelleren, naar behoefte dimensies toevoegen en berekeningen op elkaar stapelen.
Groepsrapportage is op een geheel andere basis gebouwd. Het is een uitbreiding van jouw , geen extra laag daarbovenop. De consolidatielogica bevindt zich daar waar de boekingen plaatsvinden: in hetzelfde universele journaal dat jouw boekhouding genereert. SAP heeft GR ontworpen om te werken met de gegevens die al in S/4HANA aanwezig zijn, en niet om een apart analytisch model te dupliceren.
Dat verschil is van belang voordat je ook maar één stap van jouw je .
Waarom de flexibiliteit van BPC een risico op lange termijn met zich meebrengt
De flexibiliteit van BPC is echt nuttig, maar er hangt een prijskaartje aan dat in de loop van de tijd steeds hoger wordt. Schema’s voor creatieve invoer leveren gegevens op je de herkomst je achterhalen. Berekeningen op scriptniveau worden ‘black boxes’: het getal verandert en niemand kan snel uitleggen waarom. Er worden journaalposten in vrije indeling geboekt om afwijkingen te corrigeren die nooit goed zijn begrepen.
Als je dat over meerdere opeenvolgende cycli heen opstapelt, je een consolidatieproces dat weliswaar het juiste cijfer oplevert, maar waarover het team niet langer de volledige controle heeft. Accountants stellen vragen die dagen in beslag nemen om te beantwoorden. Nieuwe teamleden kunnen niet snel inwerken zonder naast iemand te zitten die nog weet waarom een bepaalde berekening bestaat.
Flexibiliteit komt op de lange termijn neer op transparantie. Dat is niet specifiek een tekortkoming van BPC. Het is wat er gebeurt als een systeem je geeft om te improviseren en de druk van de maandafsluiting je aanzet je tijdelijke oplossingen je .
Wat SAP Group Reporting nu eigenlijk te bieden heeft
Groepsrapportage neemt een groot deel van die flexibiliteit weg, en voor consolidatiedoeleinden is dat ook grotendeels de bedoeling. De invoer is strenger. Boekingen in vrije indeling zijn aan beperkingen onderworpen. Aangepaste berekeningen hebben in GR vaak geen directe tegenhanger. Als je vanuit BPC je en verwacht dat je daar wat je daar je kunt reproduceren, zullen veel zaken simpelweg niet kloppen.
Maar GR heeft iets wat BPC nooit heeft gehad: het volledige S/4HANA-gegevensmodel als basis. BPC is gebaseerd op een kubus met een beperkte reeks dimensies. S/4 bevat veel meer details bij elke boeking: winstcentrum, segment, partner, transactietype, project en nog veel meer. Een groot deel van de flexibiliteit die BPC-teams in de loop der jaren hebben opgebouwd, was in feite bedoeld om het gebrek aan dimensionale details in de kubus te compenseren. In GR zijn die details al in het journaal opgenomen.
Dat verandert de migratiekwestie volledig.
Herontwerp: stel eerst de juiste vraag
In plaats van te vragen „hoe kunnen we elke BPC-functionaliteit in GR nabootsen?”, is de juiste vraag: welke BPC-oplossingen compenseerden voor beperkingen die het S/4-datamodel niet langer kent?
Dat gold voor veel van hen. Een berekening waarmee in BPC een segment uit een kostenplaats wordt afgeleid, is overbodig als het segment al in de boeking is opgenomen. Een aangepast invoerformulier waarmee gegevens tussen bedrijven werden verzameld, kan wellicht worden vervangen door een directe integratie met de boekhoudlaag. De ‘black box’ verdwijnt omdat de onderliggende gegevens uitgebreider zijn.
Dit betekent niet dat de migratie daardoor eenvoudig wordt. Sommige BPC-functies hebben geen equivalent in GR en vereisen een grondige herontwerp, niet alleen een andere technische implementatie. Maar juist het vroegtijdig onderscheiden van die twee categorieën – de functies die naadloos aansluiten op het S/4-datamodel en de functies die een grondige herziening vereisen – maakt het verschil tussen een migratie die wordt voltooid en een die vastloopt.
Bij Finext baseren we elke GR-opdracht precies op deze analyse: welke onderdelen van het Universal Journal kunnen de taken overnemen die voorheen in de aangepaste BPC-configuratie waren ondergebracht, en welke BPC-functies moeten volledig opnieuw worden opgebouwd.
Waar te beginnen bij de migratie van BPC naar groepsrapportage
De meest nuttige vraag die je aan jouw kunt stellen voordat je een migratie je , is: welke BPC-functionaliteit je het hardst willen behouden?
Dat is vrijwel altijd waar de belangrijkste beslissingen over de herinrichting worden genomen. Het is ook het punt waarop de flexibiliteit van BPC doorgaans de meeste complexiteit heeft opgeleverd, en waar de overgang naar het boekhoudkundige model van GR ofwel het meeste rendement zal opleveren, ofwel de meest kritische afwegingen zal vereisen.
Als je om over te stappen van BPC naar Group Reporting en dit samen met iemand wilt doorlopen die hier al ervaring mee heeft, dan denken we daar graag samen met je over na.
