Migration der klassischen Kostenstellenplanung in SAP S/4HANA in die SAP Analytics Cloud

Einleitung

Die Verbreitung von SAP S/4HANA gewinnt immer mehr an Fahrt. Ob nun durch eine Neueinführung oder ein Conversion Projekt – ganz ohne Steine ist der Weg leider nicht. Im Lauf der letzten Jahre haben wir die unterschiedlichsten Szenarien bei unseren Kunden gesehen und gemeinsam beschritten. Im Kontext der Integrierten Finanzplanung mit SAP S/4HANA und der SAP Analytics Cloud (SAC) möchte ich einige dieser Herausforderungen in diesem Blog einmal erläutern und mögliche Wege aufzeigen, mit diesen umzugehen. Ich beziehe mich immer auf ein S/4HANA On Prem.

Ich beschränke mich auf die Kostenstellenplanung mit SAC und S/4HANA ohne weitere Zwischensysteme. Im S/4HANA gibt es viele der klassischen Objekte (Tabellen COSP, COSL usw.) weiterhin. Allerdings ist die Empfehlung diese nicht mehr zu nutzen und auf die „neuen“ Tabellen und Anwendungen umzusteigen. Die zentralen Bausteine sind die Tabelle „ACDOCP“ (Accounting Documents Planning), welche die Plandaten enthält und die Tabelle „ACDOCA“ (Accounting Documents Actuals), in der die Istwerte abgelegt sind.

Für (Finanz-)Planung und Reporting in der „neuen Welt“ des S/4HANA Systems stehen Fiori Apps zur Verfügung. Diese greifen auf diese beiden neuen Tabellen zu. Die Daten in den klassischen Tabellen können nicht mit diesen Apps angezeigt werden. Allerdings gibt es Transferprogramme, mit denen die Plandaten aus den klassischen Tabellen in die neuen Tabellen transferiert werden können. Der Transfer funktioniert in beide Richtungen. Das erlaubt das Weiternutzen der klassischen Transaktionen (KP06) und die Nutzung der SAC gleichzeitig.

Ist die Entscheidung getroffen, die Kostenstellenplanung künftig mit der Kombination SAC und S/4HANA zu gestalten, gibt es grob gesagt drei häufig vorkommende Szenarien:

1. Planung wird komplett in der SAC durchgeführt und die Plandaten in die ACDOCP extrahiert. Meist bei Neukunden und „Green Field“ S/4HANA Implementierungen.
2. Planung wird komplett in der SAC durchgeführt, die Plandaten in die ACDOCP extrahiert und anschließend in die klassischen Tabellen übertragen. Hier kann das „klassische“ Reporting weiterverwendet werden.
3. Planung wird teilweise in der SAC und teilweise in den klassischen ERP-Transaktionen (KP06) im Controlling durchgeführt und anschließend mit den Transferprogrammen „synchronisiert“. Diese Möglichkeit wird genutzt, wenn nicht alle Pläne direkt in der SAC umgesetzt werden können oder sollen. Dann bleibt ein Teil der Planung im klassischen CO.

Um die Migration zu vereinfachen und schnell Ergebnisse zu erzielen, gibt es von der SAP vorbereitete Planungsapplikationen innerhalb der SAC. Über das SAC Content Network können diese Pakete aktiviert werden. Anschließend muss nur noch die Verbindung auf das entsprechende Quellsystem eingestellt und die Schnittstellen im Quellsystem aktiviert werden. Dieser Content geht aber davon aus, dass in den neuen Tabellen des S/4HANA Systems geplant wird. Der Content kann nicht ohne Customizing auf die alten Tabellen zugreifen. Bevor man diesen Content aktiviert, sollte man prüfen, ob seine Funktionalität für die eigene Planung ausreicht.

Was wird benötigt

Um die Kostenstellenplanung mit der SAC durchführen zu können, benötigt man neben einem SAC System und den entsprechenden Planungslizenzen ein paar weitere Dinge. Zum Thema Lizenzen haben wir bereites einen Überblick über das kleine 1×1 der Lizensierungen in der SAP Analytics Cloud erstellt.

Die SAC kann auf verschiedenen Wegen an ein S/4HANA ERP-System angeschlossen werden. Für die Planung ist allerdings der Import der Daten in die SAC zwingend erforderlich. Das bedeutet, dass die Daten aus S/4HANA in die SAC repliziert werden. Dafür ist die Import Verbindung vorgesehen. Die Verbindung erfolgt in diesem Falle über den so genannten Cloud Connector. Dieser wird auf einem Server innerhalb ihres Netzwerkes installiert und sorgt dafür, dass SAC und S/4HANA technisch sicher miteinander verbunden sind. Durch einen entsprechenden S/4HANA Schnittstellen-Benutzer kann sichergestellt werden, auf welche Daten die SAC zugreifen kann. Im Kontrast zur Live Verbindung wird dieser Benutzer direkt in der SAC Verbindung hinterlegt, so dass alle berechtigten SAC Benutzer (Entwickler, Administratoren, Key User, …) diese Verbindung unabhängig ihrer eigenen Berechtigungen im S/4HANA nutzen können.

Im Rahmen der Entwicklung des SAP Business Content „Integrierte Finanzplanung“ hat die SAP auch Schnittstellen für die üblicherweise notwendigen Stamm- und Bewegungsdaten im S/4HANA mitentwickelt. Eine Liste dieser Schnittstellen liefert die SAC-Hilfeseite zum Business Content. Bevor eigene Schnittstellen entwickelt werden, ist eine vorhandene Schnittstelle zu bevorzugen. Gerade wenn es um die Integration von Hierarchien geht, sind hier komplizierte Logiken bereits abgebildet. Für einfache Felderweiterungen (z.B. eigene Z-Felder an der Kostenstelle) können die Schnittstellen erweitert werden.

Schlussendlich sollte auch eine Möglichkeit geschaffen werden, die Plandaten in der Tabelle ACDOCP zu prüfen und zu berichten. Dazu stehen wieder Standard SAP Fiori Apps zur Verfügung, die je nach Stand des S/4HANA Systems unterschiedliche App Nummern und Einrichtungsaufwand bedeuten. Zu den üblicherweise genutzten Fiori Apps gehören unter anderem:

• Finanzplandaten Upload
• Finanzplandaten Löschen
• Finanzplandaten Kopieren
• Finanzplandaten erfassen
• Kostenstellen Plan/Ist Vergleich

Weiter werden die folgenden Transferprogramme in S/4HANA benötigt, wenn Daten aus den klassischen Tabellen genutzt werden sollen:

• R_FINS_PLAN_TRANS_CO_ERP_2_S4H
• R_FINS_PLAN_TRANS_CO_S4H_2_ERP
• R_FINS_PLAN_TRANS_ACTY_S4H_ERP
• R_FINS_PLAN_TRANS_ACTY_ERP_S4H
• weitere beginnend mit “R_FINS_PLAN_TRANS_”

Diese stehen ab S/4HANA Version 2022 (eingeschränkt auch in 2021) zur Verfügung. Für die Integration der Abschreibungen aus der AfA Simulation steht ebenfalls ein Mechanismus zur Verfügung.

Zu guter Letzt ist mindestens eine Plankategorie in der ACDOCP für die Plandaten notwendig. Zu beachten ist, dass die neue Welt an dieser Stelle in S/4HANA in Kategorien und nicht mehr in Versionen denkt.

Planung in der SAC

Die beiden erstgenannten Szenarien sind einfache Szenarien. Die Plandaten werden in der SAC erfasst und anschließend an S/4HANA weitergereicht. Dabei kommen die SAC-Funktionalitäten zum Einsatz, um z.B. Geschäftslogiken und Prüfungen zu implementieren. Der Planungsprozess kann Zielgerecht gestallten werden, ohne andere Funktionalitäten zu stören, wie das bei einer Entwicklung direkt im S/4HANA der Fall wäre.

Um die Daten aus der SAC in das S/4HANA zu transferieren, stehen verschiedene Standard-Schnittstellen im S/4 zur Verfügung, sofern die S/4HANA Version ausreichend aktuell ist. Je nachdem, ob es sich um Leistungstarife oder Budgets handelt, wird ein anderes Interface verwendet. Der Transfer wird wie ein Import Job eingerichtet und anschließend ein Zielumfang für die Export-Methode „Löschen & Ersetzen“ ausgewählt. Der Zielumfang bestimmt, welche Daten in S/4HANA vor dem eigentlichen SAC Plandaten Import gelöscht werden. Wird beispielsweise „Fiskalisches Jahr + Kostenstelle“ ausgewählt, werden alle Kombinationen aus Fiskalischem Jahr und Kostenstelle, die in den Export Daten vorkommen, in S/4HANA gelöscht und durch die SAC Plandaten ersetzt. Wird das Sachkonto als Dimension im Zielumfang hinzugefügt, werden nur die Sachkonten in den Kombinationen gelöscht, die aus der SAC transferiert werden. Sachkonten, die im SAC-Export nicht vorkommen, bleiben in S/4HANA dann unberührt. Die richtige Einstellung ist davon abhängig, was erreicht werden soll.

Es kann viele Gründe geben, warum die Daten aus der SAC in S/4HANA geschrieben werden müssen. Ob nun ein S/4HANA Reporting stattfindet oder ein BW die Daten aus der ACDOCP extrahiert, um z.B. historische Reporte zu befüllen. Ein häufiger Grund ist, dass die Daten von der ACDOCP in das klassische Controlling geladen werden, um die dort vorhandenen und eingerichteten CO Funktionen zu nutzen. Das kann z.B. eine Kostenumlage sein oder die Ableitung der Personalnebenkosten. Es macht nicht immer Sinn, diese Funktionen direkt in die SAC zu übertragen, vor allem nicht bei kurzer Projektlaufzeit oder knappen Budgets. Müssen die Ergebnisse dieser Umlagen und Ableitungen nun aber wieder zurück in die SAC, dann sind wir schnell in einem Hybriden Szenario, in dem es vor allem auf die richtige Gestaltung des integrierten Datenflusses ankommt. Im Folgenden wird das Szenario 3 als Hybrides Szenario beschrieben und auf die üblichen Fallstricke eingegangen.

Architektur eines Hybriden Szenarios

In der Liste der oben erwähnten Szenarien hat das dritte Szenario die höchste Komplexität. Das liegt daran, dass die Plandaten an 2 unterschiedlichen Stellen ins System eingegeben werden. Im Folgenden habe ich einmal eine mögliche Struktur erstellt:

Der Ablauf wäre wie folgt:

1. Planeingabe in SAC (oben) und KP06 (unten) durch verschiedene Personengruppen
2. Kopie der S/4HANA Plandaten aus den klassischen Tabellen in die ACDOCP durch IT (ein Kopierjob pro geplantes fiskalisches Jahr)
3. Import der Plandaten in die SAC
4. Konsolidierung der Plandaten in der SAC
5. Export der Plandaten in S/4HANA
6. Kopie der SAC-Plandaten aus der ACDOCP in die klassischen Tabellen durch IT (ein Kopierjob pro geplantes fiskalisches Jahr)

Dieses Vorgehen hat an einigen Stellen Schwachpunkte. Zunächst einmal kann jede Ausführung eines der Jobs nur ein fiskalisches Jahr kopieren. In der Regel werden in der SAC jedoch mehrere Jahre geplant. Im Fiori Umfeld stehen verschiedene Fiori Apps zur Verfügung, um Plandaten zu löschen, aus einer CSV/XLSX Datei zu importieren oder direkt einzugeben. Daten aus der SAC können nur mit dem Modus „Löschen und Ersetzen“ mit einem definierten Scope in die ACDOCP importiert werden. Der Scope bestimmt dabei, welche Daten gelöscht werden. Geben wir z.B. Buchungskreis und Kostenstelle an, werden alle Kombinationen in S/4HANA gelöscht, die im SAC-Export enthalten sind. Was aber passiert mit einer Kostenstelle, die in der ACDOCP bereits enthalten ist, aber im Quellenumfang des Exportes aus der SAC nicht? Diese bleibt in der ACDOP unberührt! So kann es vorkommen, dass ein „Gesamt-Reporting“ in S/4HANA andere Werte zeigt, als in der SAC geplant wurden (inkonsistente Reports!). Um dieses Problem zu umgehen, wurde in unserem Projekt eine eigene Plankategorie erzeugt, die zuerst komplett gelöscht und anschließen aus beiden Richtungen neu beladen wird.

Mit einem der Transferprogramme können die Daten in die klassischen Tabellen kopiert werden. Das kann der Fall sein, wenn man z.B. die alten Allokationsregeln weiterverwenden möchte, oder ein Gesamt-Reporting über die klassischen Tabellen notwendig ist. Dabei werden die Zieltabellen (COSP usw.) aber nicht gelöscht, sondern lediglich die im Transfer vorhandenen Werte überschrieben. Das führt spätestens dann zu Problemen, wenn Planwerte (in der SAC) wieder gelöscht werden (z.B. weil die falsche Kostenart verwenden wurde). Da dieser Datensatz dann nicht mehr im SAC Quellenumfang vorhanden ist, bleibt er in der Zieltabelle stehen. Es muss also zuerst die (klassische) Zieltabelle gelöscht werden, oder es dürfen keine Planwerte in der SAC aus der Planung gelöscht werden. Stattdessen können Planwerte auf „0“ gesetzt werden. Dadurch bleibt die Kombination im Quellenumfang enthalten und der Wert wird im Ziel (klassische Tabelle) auf „0“ gesetzt. Man muss allerdings bedenken, dass beim „Löschen und Ersetzen“ alle Planwerte gelöscht werden, also auch Werte, die beim letzten Transfer in die SAC noch nicht erfasst waren. Hier muss unbedingt auf den Prozess geachtet werden. Entweder muss die Eingabe im ERP gesperrt werden, solange die Daten ihre „Rundreise“ noch nicht abgeschlossen haben, oder es muss eine Version in der klassischen Welt angelegt werden, die erst vollständig gelöscht und anschließend aus ACDOCP und den klassischen beladen wird. Dann muss allerdings korrekt gefiltert werden, da einige Daten schon in der ACDOCP vorhanden sind.

Leider sind ein weiterer Schwachpunkt die Filtermöglichkeiten der Transferjobs. Obwohl die SAP GUI hier 4 Filtermöglichkeiten anbietet, funktioniert ausschließlich der „Include Filter“! Wenn nun ein Teil der Daten durch die KP06 und ein anderer Teil der Daten durch die Fiori/SAC geplant werden, muss beim Transferieren der Daten auf den korrekten Include Filter geachtet werden. Ansonsten besteht die Gefahr, dass Daten kopiert (und somit überschrieben!) werden, die nicht kopiert werden sollen. In einem unserer Projekte wurden einige Kostenarten und Buchungskreise über die SAC und wieder andere über KP06 geplant. Durch die Menge der Kostenstellen (>1.000) und Buchungskreise (>30) war die Erstellung dieser Filter sehr aufwendig und musste ständig angepasst werden. Außerdem gibt es KEINEN technischen Fehler (Dump), wenn ein Filter falsch verwendet wird. Dadurch fällt erst einmal gar nicht auf, dass der Filter ignoriert wird. Es handelt sich hier um ein in einer SAP-Note dokumentiertes Verhalten der Transferprogramme.

Obwohl es umfangreiche Trainings gab, haben trotzdem einige Planer ihre Daten nicht an der richtigen Stelle erfasst (SAC oder KP06), wodurch das Problem noch mehr verschärft wurde. Um ein Überschreiben der Daten zu vermeiden, können mehrere Plankategorien in der ACDOCP angelegt werden. So bleiben die originären Eingabewerte erhalten.

Im Bild oben wird das Problem nun sehr schnell deutlich. Je nachdem, an welcher Stelle das Gesamt-Reporting stattfindet, müssen die Daten trotzdem zusammenkopiert werden. Zu beachten ist auch, dass sowohl die SAC-Export Jobs also auch die Transferprogramme in S/4HANA die Abhängigkeit von Sachkonten zu Buchungskreisen berücksichtigen. Dabei verzeiht die SAC die Fehler im Export in S/4HANA genauso wenig, wie die Transferprogramme. In der KP06 kann man üblicherweise alle möglichen Kombinationen von Sachkonten/Kostenarten und Buchungskreisen erfassen. Bei der Erfassung findet selten eine Prüfung statt, ob das Sachkonto bzw. die Kostenart auch im Buchungskreis der geplanten Kostenstelle vorhanden ist.

Werden die Daten aus den klassischen Tabellen nun vom Transferprogramm in die ACDOCP geschrieben, gibt es einen technischen Fehler und der Transfer wird komplett abgebrochen, wenn die beplante Kostenart nicht für den entsprechenden Buchungskreis gültig ist. Innerhalb der SAC selbst gibt es keine Standardprüfung, welche Sachkonten/Kostenarten für welche Buchungskreise gültig sind. Das lässt sich aber über geschickte Programmierung im SAC Application Designer lösen und somit Exportprobleme vermeiden. Ebenso lassen sich mit einer App auch Regeln für Sachkonten und Leistungsarten umsetzen. Eine einfache Steuerungstabelle erlaubt es dem zentralen CO Team Leistungsarten für bestimmte Kostenstellen und Sachkonten freizugeben und zu sperren, ohne dafür in S/4HANA absteigen zu müssen. Der Transfer der Leistungsarten bringt leider ähnliche Herausforderungen mit sich, wie der Transfer der Kosten.

Fazit und Empfehlung

Wie wir in den Projekten gesehen haben, ist es wichtig von Anfang an einen klaren Planungsprozess anzustreben und den Datenfluss dementsprechend zu konstruieren. Die Eingabe der Plandaten an mehreren Stellen (KP06, SAC, …) macht die Konstruktion deutlich komplizierter und erhöht die Gefahr das Plandaten überschrieben werden. Als Best Practice hat sich herausgestellt, dass die Eingabe der Plandaten sowohl in SAC als auch S/4HANA in einer eigenen „Inputschicht“ (Version, Kategorie) stattfindet und das Kopieren/Transferieren/Konsolidieren über eigene Schichten geschieht.

Durch eine Vermeidung von unterschiedlichen „Eingabestellen“ kann die Komplexität weiter vereinfacht werden. Die gleichzeitige Verwendung von klassischen Eingabemöglichkeiten über KP06 als auch die Planung direkt im Fiori sollten vermieden werden, wenn die SAC zum Einsatz kommt. Die SAC bietet durch die Script-Möglichkeiten des Application Designer und Data Actions gute Möglichkeiten Prüfungen auf die eingegebenen Daten anzuwenden und Falscheingaben zu vermeiden.

Die SAC unterstützt mehrere Hierarchien für die gleiche Dimension. Durch die Verwendung von verschiedenen Hierarchien der Sachkonten/Kostenarten können unterschiedliche Sichten auf die gleichen Sachkonten erzeugt werden. So lassen sich Hierarchien sehr gut als „natürliche Filter“ für die Dateneingabe verwenden und die Darstellung von Reports und Eingabemasken passend gestalten.

Bei einer S/4HANA Einführung sollte unbedingt geprüft werden, ob die S/4 HANA Funktionalitäten für den Planungsprozess ausreichen. Werden z.B. die neuen Allokationsfunktionen des S/4HANA nicht genutzt, dann kann die SAC diese Aufgabe direkt übernehmen. Die klassischen Allokationsregeln sollten auf Grund der oben beschriebenen Herausforderungen beim Datenfluss vermieden werden, sofern es keinen guten Grund gibt, die neuen Funktionen nicht zu nutzen.

Schlussendlich ist eine Verwendung der klassischen Planung in Verbindung mit der SAC möglich, erfordert aber eine gut durchdachte Konstruktion des Datenflusses, sowie eine gute Steuerung des Planungsprozesses. So lässt sich ein „Big Bang“ vermeiden und ausgewählte Funktionen der klassischen SAP CO Kostenstellenplanung weiternutzen, bis die neuen Funktionen ausgereift sind.