Ein neues CPM-System vor dem endg\u00fcltigen Umstieg von SAP BPC zu testen bedeutet: strukturiertes Testen in einer Parallelphase, bei der beide Systeme gleichzeitig betrieben werden, Ergebnisse verglichen und definierte Abnahmekriterien gepr\u00fcft werden. Der Testprozess umfasst dabei Datenvalidierung, Prozesssimulation und den Einbezug aller relevanten Fachbereiche. Die folgenden Fragen beleuchten die wichtigsten Aspekte einer sicheren CPM-Migration im Detail.<\/p>\n
Vor einer CPM-Migration sind mindestens vier Testszenarien unverzichtbar: die Datenintegration aus Quellsystemen, die Abschlusslogik f\u00fcr Monats- und Jahresabschl\u00fcsse, die Planungs- und Forecastprozesse sowie das Reporting. Nur wenn alle vier Bereiche im neuen System korrekte und reproduzierbare Ergebnisse liefern, ist die Basis f\u00fcr einen sicheren Umstieg gegeben.<\/p>\n
Konkret bedeutet das f\u00fcr Unternehmen, die SAP BPC abl\u00f6sen wollen: Zun\u00e4chst muss gepr\u00fcft werden, ob alle relevanten Datenquellen, also ERP-Systeme, HR-Daten und externe Quellen, sauber in das neue CPM-System geladen werden. Fehler in der Datenintegration wirken sich auf alle nachgelagerten Prozesse aus und sind deshalb als Erstes zu testen.<\/p>\n
Im zweiten Schritt sollten die Konsolidierungslogiken und Eliminierungen nachgebaut und gegen historische Abschl\u00fcsse gepr\u00fcft werden. Gerade bei der Konzernrechnungslegung nach IFRS oder HGB sind diese Berechnungen komplex und fehleranf\u00e4llig. Weichen die Ergebnisse im neuen System von den SAP-BPC-Werten ab, muss die Ursache vor dem Go-live eindeutig gekl\u00e4rt sein.<\/p>\n
Planungs- und Forecastszenarien bilden das dritte Testfeld. Hier geht es darum, ob die Eingabemasken, Workflow-Steuerungen und Berechnungsregeln so funktionieren, wie es die Fachbereiche gewohnt sind. Schlie\u00dflich sollten alle Standard-Reports und Dashboards auf Vollst\u00e4ndigkeit und Korrektheit gepr\u00fcft werden, bevor das neue System produktiv geht.<\/p>\n
Die Parallelphase zwischen SAP BPC und einem neuen CPM-System sollte mindestens einen vollst\u00e4ndigen Abschlusszyklus umfassen, also in der Regel einen Monatsabschluss und, wenn m\u00f6glich, einen Quartalsabschluss. F\u00fcr Unternehmen mit komplexer Konzernstruktur empfiehlt sich eine Parallelphase von zwei bis drei Monaten, um saisonale Besonderheiten und unterschiedliche Buchungskonstellationen abzudecken.<\/p>\n
Eine zu kurze Parallelphase birgt erhebliche Risiken: Fehler in der Konsolidierungslogik oder in der Datenintegration zeigen sich oft erst dann, wenn bestimmte Buchungskonstellationen auftreten, die im normalen Monatsbetrieb selten vorkommen. Wer die Parallelphase auf wenige Wochen beschr\u00e4nkt, riskiert, dass solche Ausrei\u00dfer erst nach dem produktiven Umstieg sichtbar werden.<\/p>\n
Gleichzeitig sollte die Parallelphase nicht unn\u00f6tig lang ausgedehnt werden. Der doppelte Betrieb beider Systeme bindet Ressourcen in der Finanzabteilung und erh\u00f6ht den manuellen Aufwand f\u00fcr die Teams. Ein klarer Zeitplan mit definierten Meilensteinen, etwa Abnahme nach dem ersten Monatsabschluss und finaler Go-live-Entscheidung nach dem Quartalsabschluss, hilft dabei, die Parallelphase effizient zu gestalten.<\/p>\n
F\u00fcr den Systemvergleich zwischen SAP BPC und dem neuen CPM-System sollten historische Abschlussdaten aus mindestens zwei bis drei abgeschlossenen Gesch\u00e4ftsjahren herangezogen werden, erg\u00e4nzt durch aktuelle Plandaten und einen vollst\u00e4ndigen Datensatz des letzten Monatsabschlusses. Diese Kombination stellt sicher, dass sowohl Stammdatenstrukturen als auch Bewegungsdaten korrekt \u00fcbertragen wurden.<\/p>\n
Besonders wichtig ist der Vergleich auf Ebene der Einzelgesellschaften sowie auf Konzernebene nach Konsolidierung. Abweichungen k\u00f6nnen auf unterschiedlichen Ebenen entstehen: bei der \u00dcbernahme der Stammdaten, bei der Anwendung von Eliminierungsregeln oder bei der Berechnung von Kennzahlen. Jede Abweichung muss dokumentiert und auf ihre Ursache zur\u00fcckgef\u00fchrt werden.<\/p>\n
Neben den Finanzdaten sollten auch Planungsdaten, also Budgets und Forecasts aus dem laufenden Jahr, im neuen System nachgebaut und verglichen werden. So l\u00e4sst sich pr\u00fcfen, ob die Eingabestrukturen und Berechnungslogiken des neuen Systems die gew\u00fcnschten Ergebnisse liefern. Wer CPM-Implementierungen<\/a> aus der Praxis kennt, wei\u00df: Gerade bei Intercompany-Abstimmungen treten Differenzen auf, die im Tagesgesch\u00e4ft leicht \u00fcbersehen werden.<\/p>\n Am Testprozess f\u00fcr ein neues CPM-System sollten zwingend die Fachbereiche Konzernrechnungswesen, Controlling und Planung beteiligt sein, erg\u00e4nzt durch die IT und, sofern vorhanden, die internen Systemverantwortlichen f\u00fcr SAP BPC. Entscheidend ist, dass der Test nicht allein durch die IT erfolgt, sondern durch die Personen, die das System im Tagesgesch\u00e4ft nutzen.<\/p>\n Die Fachbereiche kennen die inhaltlichen Anforderungen und k\u00f6nnen beurteilen, ob Berechnungen, Berichte und Workflows korrekt abgebildet sind. Die IT stellt sicher, dass Schnittstellen stabil laufen und die Systemumgebung den Anforderungen entspricht. Beide Perspektiven sind notwendig, um einen vollst\u00e4ndigen Testabdeckungsgrad zu erreichen.<\/p>\n Dar\u00fcber hinaus empfiehlt es sich, Key-User aus den einzelnen Gesellschaften oder Regionen fr\u00fchzeitig einzubinden. Sie kennen lokale Besonderheiten in der Buchungslogik oder im Reporting, die zentrale Teams m\u00f6glicherweise nicht im Blick haben. Ein strukturierter User-Acceptance-Test (UAT) mit klar definierten Testf\u00e4llen und einer R\u00fcckmeldeschleife sorgt daf\u00fcr, dass R\u00fcckmeldungen aus den Fachbereichen systematisch erfasst und bearbeitet werden.<\/p>\n Die h\u00e4ufigsten Fehlerquellen beim Testen eines neuen CPM-Systems sind unvollst\u00e4ndige Stammdaten, fehlende Testf\u00e4lle f\u00fcr Sonderkonstellationen, mangelnde Einbindung der Fachbereiche und ein zu enger Testzeitraum. Diese vier Punkte sind in der Praxis f\u00fcr den Gro\u00dfteil der Probleme verantwortlich, die nach einem Go-live auftreten.<\/p>\n Unvollst\u00e4ndige oder inkonsistente Stammdaten sind besonders t\u00fcckisch, weil sie sich durch alle Prozesse ziehen. Wenn Kontenstrukturen, Kostenstellenhierarchien oder Intercompany-Beziehungen nicht vollst\u00e4ndig migriert wurden, f\u00fchrt das zu falschen Konsolidierungsergebnissen, die erst im produktiven Betrieb auffallen.<\/p>\n Ein weiterer klassischer Fehler ist das Testen ausschlie\u00dflich mit Standardf\u00e4llen. Sonderkonstellationen wie W\u00e4hrungsumrechnungen bei volatilen Wechselkursen, unterj\u00e4hrige Unternehmensk\u00e4ufe oder Erstkonsolidierungen werden im Test h\u00e4ufig ausgelassen, weil sie selten vorkommen. Genau diese F\u00e4lle f\u00fchren aber nach dem Umstieg zu den aufwendigsten Nacharbeiten.<\/p>\n Schlie\u00dflich untersch\u00e4tzen viele Projekte den Aufwand f\u00fcr die Dokumentation von Testergebnissen. Ohne eine strukturierte Testdokumentation ist es nach dem Go-live schwer nachzuvollziehen, welche Szenarien tats\u00e4chlich getestet wurden und welche Abweichungen als akzeptiert freigegeben worden sind. Eine l\u00fcckenlose Dokumentation sch\u00fctzt das Projektteam und schafft Transparenz f\u00fcr alle Beteiligten.<\/p>\n Ein neues CPM-System ist bereit f\u00fcr den produktiven Einsatz, wenn alle definierten Abnahmekriterien erf\u00fcllt sind: Die Datenintegration l\u00e4uft fehlerfrei, Abschl\u00fcsse und Konsolidierungen liefern nachvollziehbare und mit SAP BPC \u00fcbereinstimmende Ergebnisse, alle kritischen Testf\u00e4lle sind ohne offene Fehler abgeschlossen und die Key-User haben den User-Acceptance-Test formal freigegeben.<\/p>\n Die Entscheidung f\u00fcr den Go-live sollte nicht unter Zeitdruck getroffen werden. Ein sinnvoller Ansatz ist die Definition eines Ampelsystems: Kritische Fehler (Rot) blockieren den Go-live vollst\u00e4ndig. Mittlere Fehler (Gelb) k\u00f6nnen mit einem dokumentierten Workaround akzeptiert werden, wenn eine L\u00f6sung im ersten Sprint nach Go-live garantiert ist. Kleinere kosmetische Fehler (Gr\u00fcn) stehen einem produktiven Start nicht im Weg.<\/p>\n Dar\u00fcber hinaus sollte vor dem Go-live ein Rollback-Plan existieren. Wenn nach dem Umstieg schwerwiegende Fehler auftreten, muss klar sein, wie schnell und unter welchen Bedingungen auf SAP BPC zur\u00fcckgekehrt werden kann. Dieser Plan muss nicht angewendet werden, aber seine Existenz gibt dem Management und den Fachbereichen die notwendige Sicherheit f\u00fcr die Go-live-Entscheidung. Wer den Kontakt zu erfahrenen CPM-Beratern<\/a> sucht, kann diesen Prozess erheblich beschleunigen.<\/p>\n Gramke Consulting unterst\u00fctzt Unternehmen bei der strukturierten Abl\u00f6sung von SAP BPC und der Einf\u00fchrung von CCH Tagetik als leistungsstarkem SAP-BPC-Nachfolger. Als zertifizierter CCH-Tagetik-Partner verf\u00fcgt das Team \u00fcber tiefgreifende Erfahrung in der Konzernrechnungslegung, im Konzerncontrolling und in der Planung, die direkt in den Testprozess einflie\u00dft. Das Leistungsangebot umfasst dabei alle Phasen einer sicheren CPM-Migration:<\/p>\nWer sollte am Testprozess beteiligt sein?<\/h2>\n
Was sind h\u00e4ufige Fehlerquellen beim Testen eines neuen CPM-Systems?<\/h2>\n
Wann ist ein neues CPM-System bereit f\u00fcr den produktiven Einsatz?<\/h2>\n
Wie Gramke Consulting den Umstieg von SAP BPC begleitet<\/h2>\n