SAP-S/4HANA-Einführung: Darauf kommt es an (2024)

Im Optimalfall beinhaltet das „Common Template“ neben den Gruppenanforderungen auch die Anforderungen aller Business Units der Gruppe. In der Praxis zeigt sich jedoch, dass aufgrund historisch gewachsener BU- oder Landeshoheiten in Bezug auf die ERP-Strategie nicht immer die flächendeckende, uneingeschränkte Bereitschaft besteht, einen gemeinsamen Template-Ansatz mit allen Konsequenzen zu verfolgen. Darüber hinaus kann es vorkommen, dass in den einzelnen BUs gänzlich andere ERP-Lösungen ausgewählt werden. Weitere Beispiele zeigen, dass sich BUs und die Gruppe zwar auf einige grundlegende Harmonisierungen und Standardisierungen wie gemeinsame Designprinzipien, Stammdaten, Strukturen und Prozesse einigen, jedoch kein „Common Template“ im eigentlichen Sinne entwickeln, sondern eigenständige divisionale Templates.

Hinsichtlich der Freiheitsgrade innerhalb der – durch heterogene Steuerungsansätze geprägten – BUs bietet ein solcher Ansatz natürlich Vorteile. Oftmals langwierige Harmonisierungsdiskussionen können abgekürzt oder vermieden werden. Um die definierten Harmonisierungen und Standardisierungen aufrechtzuerhalten und eine „Verwässerung“ der divisionalen Templates zu vermeiden, ist eine solide, übergeordnete Governance notwendig. Ebenfalls erwähnenswert ist, dass divisionale Templates in der Regel zu einem höheren Aufwand bei der technischen und fachlichen Integration führen (zum Beispiel über ein SAP Business Warehouse [BW/4HANA] oder ein SAP Central Finance [CFIN]), wenn eine Erfüllung der gruppenweiten Steuerungs- und Reporting-Anforderungen erreicht werden muss. Auch dürfte der Maintenance-Aufwand höher ausfallen als bei Nutzung eines „Common Templates“.

Unabhängig von der gewählten Template-Strategie zeigt sich jedoch immer, dass dem Steuerungsmodell im Rahmen der ERP-Transformation eine entscheidende Rolle zukommt. Es empfiehlt sich daher, das Steuerungsmodell des Unternehmens in die Betrachtung einzubeziehen –entweder bereits in einem vorgelagerten Schritt oder spätestens parallel zur Definition der Finanzprozesse. Dies kommt der Planbarkeit von Projektverlauf und Zielerreichung zugute.

Die Bedeutung des Steuerungsmodells für konzeptionelle Entscheidungen im ERP-System

„An unserem Steuerungsmodell möchten wir erst einmal nichts ändern. Dies ist nicht Bestandteil des Projektumfangs und wird gegebenenfalls im Rahmen der Ablösung unserer EPM-Systeme nochmals betrachtet.“ Dieser oder ähnliche Sätze sind im Rahmen von ERP-Projekten häufig zu hören. Der Impuls, das ERP-Transformationsprojekt auf diese Weise in Bezug auf Umfang und Kosten eingrenzen zu wollen, ist durchaus nachvollziehbar – hätte doch eine Änderung des Steuerungs- und des Datenmodells gegebenenfalls Folgen für eine Vielzahl von Vor- und Folgesystemen. Dabei wird gleichzeitig aber häufig unterschätzt, welche Auswirkungen die gruppenweiten und geschäftsmodellspezifischen Steuerungsanforderungen auf die Ausgestaltung der Finanzprozesse in SAP S/4HANA haben und wie insbesondere eine fehlende Harmonisierung der Steuerungsmodelle einen „Common ERP Template“-Ansatz behindern oder teilweise verhindern kann.

Was bedeutet Harmonisierung und wie kann sie gelingen?

An dieser Stelle bedarf es einer Erläuterung des Harmonisierungsbegriffs. Er ist nicht gleichzusetzen mit einer kompletten Vereinheitlichung der individuellen Steueranforderungen, da diese, insbesondere bei stark abweichenden Geschäftsmodellen, durchaus Sinn ergeben. Zudem würde der Versuch einer Vereinheitlichung auch nur schwer zu einer Einigung führen. Vielmehr ist mit Harmonisierung gemeint, die verschiedenen Anforderungen der Gruppe und ihrer Business Units genau zu analysieren, um eine zukünftige gemeinsame Management-P&L (P&L = Profit & Loss, also Gewinn- und Verlustrechnung) und wesentliche Steuerungs-KPIs samt dimensionaler Aufrisse (zum Beispiel Produkt, Kunde, Region) für eine global integrierte Steuerungssicht abzuleiten.

Als erreichenswertes Ziel erscheint es, mit dem „Common Template“ eine umfassende Transparenz der finanziellen Performance sowohl auf globaler als auch auf divisionaler Ebene herzustellen, die aktuelle gesetzliche Rechnungslegungs- und Reporting-Pflichten beinhaltet, aber auch die Verantwortlichkeit des Managements für den jeweiligen Wertbeitrag spiegelt. Gleichzeitig muss das Template dem Anspruch genügen, das Business optimal bei der operativen Steuerung zu unterstützen. Dieses Ziel rückt in die Ferne, wenn Daten einzelner Managementaggregate und einzelner Legal-Einheiten nicht in der benötigten Form zusammengefasst werden können. Diese Aggregation wird benötigt, um aus dem Template heraus alle Steuerungs- und Reporting-Anforderungen bedienen zu können und ein gesamtheitliches, überleitbares Bild der Gruppe entlang aller Steuerungsdimensionen zu bekommen. Eine fehlende Harmonisierung erschwert zudem die Anpassung von Stammdaten und Strukturen in SAP S/4HANA.

Die Zeilenstruktur der Management-P&L

Die Management-P&L ist ein wesentlicher Kern des Steuerungsmodells, da sie zentrale Steuerungs-KPIs enthält und so eine Performance-Messung und ­Incentivierung verschiedener Managementebenen im Konzern ermöglicht. Während aus einer rein externen Reporting-Sicht zwischen dem klassischen Gesamtkostenverfahren und dem Umsatzkostenverfahren unterschieden wird und die Detailanforderungen eher gering sind, spiegeln sich in der Management-P&L vielfältige Aspekte. Diese sind stark durch die Branche beziehungsweise das Geschäftsmodell sowie durch die Unternehmensstrategie und die daraus abgeleiteten Steuerungsanforderungen geprägt.

Während beispielsweise im Bereich Industrial Products mehrstufige Deckungsbeitragsschemata mit Aufteilung nach fixen und variablen Kostenblöcken sowie die Darstellung von Standardkosten und Produktionsabweichungen nicht unüblich sind, liegt beispielsweise der Fokus bei Retailern häufig eher auf einer funktionalen P&L mit Kennzahlen zur Steuerung der Top und Bottom Line.

Die Entscheidung über die Zeilenstruktur der Management-P&L oder einer integrierten „Common P&L“, die sowohl die Anforderungen des internen als auch des externen Berichtswesens abdeckt, stellt die Weichen für Anforderungen an SAP S/4HANA. Da der Kontenplan in SAP klassischerweise nach dem Gesamtkostenverfahren strukturiert ist, bedingt die Anforderung zur Ableitung einer funktionalen beziehungsweise Umsatzkostenverfahren-P&L die Nutzung sogenannter Funktionsbereiche. Zusätzlich ist die Abbildung eines mehrstufigen Deckungsbeitragsschemas, beispielsweise im Rahmen der Nutzung von SAP CO-PA oder Margin Analysis, über Kontenstrukturen möglich.

Das Thema Kontenplan: Warum es bedacht werden sollte

In vielen SAP-S/4HANA-Transformationsprojekten wird das Thema Kontenplan grundsätzlich stark unterschätzt. Häufig ist die einzige gemeinsame Basis der Konzernkontenplan, auf den die einzelnen operativen Kontenpläne über ein sogenanntes Mapping geschlüsselt sind. Ein harmonisierter operativer Kontenplan auf Konzernebene ist häufig nicht gegeben, teilweise nicht einmal auf BU-Ebene. Folglich müssen zunächst sämtliche existierenden operativen Kontenpläne analysiert werden, um einen gemeinsamen Aufsatz für das Template zu schaffen. Bei der Analyse sollte ein Fokus auf Konten liegen, die in SAP nun nicht mehr benötigt werden, da sie beispielsweise aufgrund der Ledger-Lösung oder der Verfügbarkeit anderer Dimensionen beziehungsweise Kontierungsobjekte (zum Beispiel Trading Partner, Steuercodes, Funktionsbereiche, Profit Center) nicht mehr relevant sind.

Zudem ist insbesondere auch bei den Primärkosten kritisch zu hinterfragen, welche Konten über die buchhalterischen Minimalanforderungen hinaus für weitere Analysezwecke genutzt werden und ob diese zukünftig im Kontext der globalen, divisionalen oder operativen Steuerung noch erforderlich sind. Auch Sekundärkosten, die seit SAP S/4HANA als echte Konten in den Kontenplan gewandert sind, müssen betrachtet und im Rahmen des Aufsatzes der Gemeinkostenrechnung diskutiert werden.

Eine Standardisierung über die gesamte Gruppe kann in einem großen und sehr heterogenen Konzern nur schwer „nebenbei“ im Rahmen einer SAP-S/4HANA-Einführung bewältigt werden, sodass diese Aufgabe optimalerweise bereits in einem separaten Vorprojekt angegangen werden sollte. Ist dies nicht gewünscht, kann sich unter Umständen eine Standardisierung im Rahmen des S/4-Projekts nur auf bestimmte Kontenbereiche oder Hierarchieebenen des Kontenplans beschränken, wenn der zeitliche Projektverlauf nicht dahin gehend angepasst wird. In diesem Fall müssen gegebenenfalls entsprechende Freiheitsgrade innerhalb der Business Units beziehungsweise landesspezifische Freiheitsgrade akzeptiert werden.

Die Standardisierung der Funktionsbereiche

Ebenso sieht es bei der Standardisierung der Funktionsbereiche aus. Dies sind Kontierungsobjekte, die es ermöglichen, die betrieblichen Aufwendungen gemäß den Anforderungen des Umsatzkostenverfahrens nach Funktionen (zum Beispiel Fertigung, Verwaltung, Vertrieb etc.) zu gliedern. Funktionsbereiche können in den Stammdaten verschiedener Objekte, darunter Kostenstellen, Aufträge, PSP-Elemente, aber auch Sachkonten, hinterlegt werden.

Der Funktionsbereich wird bei primären und sekundären Buchungen nach festen Regeln abgeleitet und im gemeinsamen Beleg („Universal Journal“) in SAP S/4HANA mitgeführt. Auch hier ist eine Vorabanalyse des Status quo essenziell, der gegen die Anforderungen der Management-P&L geprüft werden sollte. Darüber hinausgehende Anforderungen sollten kritisch hinterfragt werden, da diese eigentlich keine bestehende Steuerungsrelevanz besitzen dürften. Bei Funktionsbereichen, die sich direkt über Konten ableiten, ergibt sich unter Umständen die zusätzliche Herausforderung, dass ein und dasselbe Konto bei unterschiedlichen Legal-Einheiten mit verschiedenen Funktionsbereichen verknüpft ist. Auch diese Sachverhalte sind im Rahmen der Ausgestaltung des Kontenplans zu analysieren und abzustimmen.

Aus der Notwendigkeit zur Trennung von Standardkosten und Produktionsabweichungen ergeben sich weitreichende Anforderungen – sowohl was die technische Umsetzung in SAP S/4HANA als auch was die konzeptionelle Ausgestaltung angeht. Lokale Standardkosten für alle Materialien müssen auf konsistente Weise mit einem gemeinsamen Detaillierungsgrad berechnet werden, damit sie als Standardkosten der verkauften Produkte in der lokalen GuV verwendet und auch auf BU- und Gruppenebene aggregiert werden können. Varianzen als Abweichungen zwischen Ist- und Standard-(Soll-)Kosten müssen transparent und auf ihren jeweiligen Ursprung zurückführbar sein, um die Steuerung der Produktionsfunktion auf lokaler und globaler Ebene zu unterstützen. Dazu gehört ein klarer, standardisierter Analysepfad von den P&L-Zeilen ausgehend bis hin zu den zugrunde liegenden Wertströmen, Geschäftsprozessen und gebuchten Belegen. Auch sollte die periodische Bewertung der produzierten Vorräte zu Ist-Kosten auf eine konforme und effiziente Weise unterstützt werden. Falls das Steuerungsmodell sogar auf die Berechnung einer durchgerechneten Marge abzielt („World COGS“), dann ergeben sich weitere umfangreiche Anforderungen an die konzeptionelle Ausgestaltung und gruppenweite Standardisierung, die vom Umfang her nicht zu unterschätzen sind.

Der dimensionale Aufriss der Management-P&L

Neben der Zeilenstruktur ist eine Management-P&L vor allem dadurch gekennzeichnet, dass bestimmte KPIs oder Kosteninformationen für Steuerungs- und Analysezwecke auf verschiedene Dimensionen heruntergebrochen werden müssen. Beispielsweise ist für den Konzern nicht nur der Umsatz auf Gruppenebene relevant, sondern auch ein Aufriss nach Business Units, Regionen oder Legal-Einheiten erforderlich. Bei der regionalen Perspektive kommt meist noch die Zusatzanforderung einer Unterscheidung in eine „Country of Origin“-Sicht (Umsatz des Landes, in dem die meldende Legal-Einheit sitzt) und eine „Country of Destination“-Sicht (bezieht sich in der Regel auf das Land, in dem der Endkunde sitzt). Darüber hinaus existieren meist weitere geschäftsfeldspezifische Steuerungsanforderungen mit weiter gehenden Analysenotwendigkeiten wie beispielsweise Details nach Produkt(-Gruppe), Kunden(-Gruppe) etc.

Aus all diesen Anforderungen ergeben sich weitere konzeptionelle Leitplanken für das S/4-System. SAP bietet hier – und zwar nicht erst seit der Einführung von SAP S/4HANA – eine Vielzahl von Möglichkeiten, diese Zusatzdimensionen abzubilden, ohne dafür weitere Konten anlegen und den Kontenplan überfrachten zu müssen. Bereits bei der Dimension „Business Unit“ stellt sich oftmals die Herausforderung, dass nicht alle Legal-Einheiten eins zu eins einer Ausprägung dieser Dimension zugeordnet werden können. Hier wird üblicherweise von „Zebra“-Einheiten gesprochen, die dadurch gekennzeichnet sind, dass sie mehrere Divisionen „streifen“, also in ihnen aktiv sind. Folglich kann die managementorientierte Perspektive in Abgrenzung zur Legal-Perspektive nur über eine Kombination aus Legal-Einheit und einer weiteren Dimension (in der Regel dem „Profit Center“) berichtet werden. Gerade beim Thema „Profit Center“ gehen die geschäftsfeldspezifischen Anforderungen häufig stark auseinander, da Profit Center je nach Geschäftsmodell unterschiedliche Funktionen haben können. Über die Profit-Center-Hierarchie können beispielsweise Business-Unit- oder Business-Line-Strukturen und Produktgruppen (bis hinunter zum einzelnen Produkt) abgebildet werden. Alternativ können hierüber aber auch regionale Sichten weiter untergliedert werden, bis hin zur Niederlassung. Die dadurch entstehende Komplexität verleitet zu einer Depriorisierung der Harmonisierung und somit dazu, weitreichende divisionale und lokale Freiheitsgrade einzuräumen.

Die Basisharmonisierung: ein Kompromiss?

Wie eingangs erwähnt führt jedoch eine gänzlich fehlende Harmonisierung dazu, dass eine Aggregation, Analyse und Vergleichbarkeit auf Gruppenebene nicht mehr ohne weiteres möglich ist und vielfältige Mappings und Überleitungen eingeführt werden müssen. Ein sinnvoller Mittelweg kann darin bestehen, zumindest hinsichtlich der Gesamtstruktur und Nomenklatur, zum Beispiel der Profit-Center-Hierarchie, eine gewisse Basisharmonisierung herbeizuführen. Selbst wenn diese aus BU-Sicht für unterschiedliche Zwecke genutzt wird, können die Informationen durch klare Vorgaben besser berichtet und analysiert werden.

An dieser Stelle soll auch das Thema Kostenstellen nicht unerwähnt bleiben. Die Kostenstellenrechnung benötigt eine Untergliederung in einzelne Kostenstellen als Verantwortungsbereiche für die dort anfallenden Kostenarten. Dabei orientiert sich diese Untergliederung in der Regel an der Aufbauorganisation des Unternehmens und wird durch vielfältige Faktoren wie Branche, betriebliche Gegebenheiten, Kostenverrechnungsverfahren, Datenschutz und nicht zuletzt von Steuerungsaspekten beeinflusst. Dabei stellt sich grundsätzlich die Frage, was auf welcher Ebene über die Kostenstellen gesteuert werden soll und welche strukturellen Vorgaben an Kostenstellenhierarchien und Kostenstellen erforderlich sind, um eine spätere Aggregation und Analyse zu ermöglichen.

Auch hier ist in größeren Konzernen mit mehreren Geschäftsmodellen eine Abstimmung und Harmonisierung nicht ohne größeren Aufwand möglich, da die bislang verwendeten Kostenstellen – aus unterschiedlichen Gründen und größtenteils historisch gewachsen – bisher keiner einheitlichen Logik folgen. Zudem gibt es im Berichtswesen meist vielfältige Mappings und Überleitungsrechnungen, die für die Aggregation und Analyse genutzt werden. Um jedoch auf Gruppen- und BU-Ebene zu erreichen, dass Kosten und Performance-KPIs in bestimmten Verantwortungsbereichen (zum Beispiel Produktion, Supply Chain, IT, Einkauf) übergeordnet transparent sind, führt an einer Harmonisierung der Kostenstellenstrukturen in der Regel kein Weg vorbei. Je heterogener die Geschäftsmodelle, desto größer ist die damit verbundene Herausforderung der Harmonisierung. Auch wenn eine komplette Standardisierung der Kostenstellen in den wenigsten Fällen möglich und sinnvoll ist, ist eine weitestgehende Harmonisierung der Kostenstellenhierarchien bis auf eine gewisse Hierarchieebene absolut zu empfehlen. Zudem sollten auch klare Vorgaben hinsichtlich der Vergabe der Kostenstellennummern erfolgen. Durch die so geschaffenen Gesetzmäßigkeiten in der Nomenklatur werden Logiken und Ableitungen möglich. Hieraus ergeben sich enorme Vorteile für das Reporting und die Analyse. Ebenso kann die Komplexität durch den Wegfall entsprechender Mappings reduziert werden.

Bilanzielle Steuerungskennzahlen

Neben der Management-P&L stehen, je nach Branche, auch weitere bilanzielle Steuerungskennzahlen im Fokus des Managements. Hierzu gehören beispielsweise Kennzahlen aus den Bereichen Working Capital und Anlagevermögen. Auch bei diesen Kennzahlen reicht es in der Regel nicht aus, eine reine Gruppen- oder Legal-Einheiten-Sicht zu betrachten, sondern es werden weitere Details und Aufrisse benötigt. Zudem haben viele Unternehmen die Anforderung, die Bilanz in Managementsichten aufzuteilen, um eine Management- oder Matrixkonsolidierung zu unterstützen. Im Gegensatz zur P&L besteht im Bereich der Bilanz jedoch die Herausforderung, dass die entsprechenden bilanziellen Buchungspositionen nicht ohne weiteres eine Aufteilung in relevante Berichtsdimensionen beinhalten.

SAP bietet bereits seit dem Release ERP 6.0 die Möglichkeit der sogenannten Belegaufteilung („Document Split“), um Bilanzpositionen unter anderem nach Segmenten und „Profit Centers“ aufzuteilen. Es empfiehlt sich, die Anforderungen an die Belegaufteilung zielgerichtet aus dem Steuerungsmodell abzuleiten. Hierfür gibt es zwei wesentliche Gründe: Einerseits ist eine nachträgliche Aktivierung der Belegaufteilung nur über ein Migrationsszenario möglich, andererseits ist für die Umsetzung der Belegaufteilung eine saubere Analyse der Prozesse, Geschäftsvorfälle und Belege erforderlich. Da auch an dieser Stelle die Anforderungen der Gruppe und der einzelnen BUs voneinander abweichen können, ist eine vorherige Abstimmung im Rahmen der Diskussion des Steuerungskonzepts sinnvoll. Größere Freiheitsgrade auf BU-Ebene sind bei der Nutzung eines gemeinsamen SAP-Templates nicht oder nur bedingt möglich.

Die Konsolidierung: ein weiterer relevanter Steuerungsaspekt

Neben den bereits skizzierten Bereichen gibt es weitere Aspekte des Steuerungsmodells, die Auswirkungen auf die Ausgestaltung eines SAP-S/4HANA-Templates haben. Ein Beispiel hierfür ist die erforderliche Konsolidierungslogik. Bei Steuerungskennzahlen auf Konzernebene stellt sich nicht nur die Frage nach deren Berechnungslogik, sondern auch, ob diese konsolidiert oder unkonsolidiert gezeigt werden sollen. Beispielsweise muss geklärt werden, ob die Segmente „echt“, im Sinne eines eigenen Teilkonzerns, konsolidiert werden sollen oder ob lediglich eine Überleitung der aggregierten Segmentdaten auf die konsolidierte Gruppe erfolgen soll.

Während es im externen Rechnungswesen diverse Vorgaben zur Konsolidierung gibt, bestehen im Management Reporting hier sehr große Freiheitsgrade. Durch den sogenannten Management Approach im Rahmen der Segmentberichterstattung nach IFRS 8 können beide Berichtswelten jedoch nicht gänzlich unabhängig voneinander betrachtet werden. Zudem ergeben sich in der Überleitung des Management Reportings zum externen Reporting häufig diverse Probleme, insbesondere wenn Strukturen und Konsolidierungslogiken nicht sauber aufeinander abgestimmt sind. Dies betrifft insbesondere den Bereich der P&L. Unabhängig vom Grad der Harmonisierung des externen und internen Reportings ist für den Aufsatz von SAP S/4HANA wichtig, dass die Anforderungen an die Granularität der zu liefernden Daten bekannt sind. So ist für eine paarweise beziehungsweise zweiseitige Konsolidierung die Bereitstellung von Partnerinformationen erforderlich.

Die meldende Gesellschaft oder der meldende Buchungskreis in SAP S/4HANA muss für konsolidierungsrelevante Konten die Partnergesellschaft (Trading Partner) mitliefern, damit die Konsolidierung im entsprechenden System durchgeführt werden kann. Im Falle der „Zebra“-Gesellschaften und der Nutzung einer sogenannten Matrixkonsolidierung können sich diese Anforderungen sogar noch erhöhen, da hier die Pärchen nicht mehr auf Ebene von Legal-Einheiten gebildet werden können, sondern beispielsweise Profit Center und Partner Profit Center oder SAP Segment und Partner SAP Segment für die Konsolidierung herangezogen werden müssen.

Im Bereich der P&L sollte zudem darauf geachtet werden, dass im Rahmen von Umlagen und Verrechnungen teilweise Partnerinformationen verloren gehen können. Kommt zum Beispiel die Ergebnis- und Marktsegmentrechnung (SAP CO-PA/Margin Analysis) zum Einsatz, so werden im Rahmen von sogenannten CO-PA-Umlagen die Partnerinformationen nicht weitergegeben. Daher ist es empfehlenswert, bei der Umsetzung einer SAP-CO-PA-Lösung die entsprechenden Anforderungen und Datenstrukturen vorab zu analysieren. Gegebenenfalls muss ein Wechsel von einer zweiseitigen auf eine einseitige Konsolidierungslogik erfolgen oder die Umlagelogik in SAP S/4HANA überdacht werden.

Die Steuerung von Investitionsausgaben und Capital Expenditures

Als weiteres Beispiel ist die Steuerung von Investitionsausgaben beziehungsweise Capital Expenditures (CapEx). Die Anforderungen an eine CapEx-Steuerung können dabei auf BU-Ebene sehr unterschiedlich sein. Im Regelfall gibt es eine gemeinsame CapEx Guideline, die die Reporting-Strukturen inklusive der relevanten CapEx-Kategorien (zum Beispiel Growth, Efficiency, Replacement etc.) und Freigabestufen auf den unterschiedlichen Ebenen definieren. Zudem sollte es auch aus Steuerungsperspektive ein klares Verständnis dafür geben, auf welcher Ebene und nach welchen KPIs die CapEx-Steuerung erfolgen soll.

Beispielsweise kann auf Gruppenebene der Fokus auf einer reinen Finanzsteuerung mit Planung, Freigabe und Überwachung von CapEx-Budgets und dem Vergleich mit Ist-Werten liegen, wohingegen auf BU-Ebene die eigentliche CapEx-Steuerung im Sinne der Steuerung von Einzel-Investments und Ausgabephasen stattfindet. Alternativ kann die CapEx-Steuerung auch im Sinne einer Investment-Portfolio-Perspektive zentral auf Konzernebene erfolgen. Darüber hinaus gibt es vermehrt Ansätze, bei denen die CapEx-Steuerung mit Kennzahlen aus dem Bereich Nachhaltigkeit („Sustainability KPIs“) kombiniert wird. In Abhängigkeit von den Steuerungsanforderungen ergeben sich auch hier in SAP S/4HANA diverse Ausgestaltungsmöglichkeiten. Diese reichen von einer komplexen, integrierten und standardisierten Lösung unter Nutzung von SAP IM, MM, PS und PM bis hin zu einer eher einfacheren Lösung mit wenig Standardisierung über die Business Units hinweg.

Potenziale von SAP S/4HANA ausschöpfen

Um die Potenziale von SAP S/4HANA bestmöglich nutzen zu können, sollten sich Konzerne vorab und frühestmöglich mit der Harmonisierung von Prozessen und Strukturen beschäftigen. Je heterogener die im Konzern vorkommenden Geschäftsmodelle und je dezentraler deren historisch gewachsene Steuerungshoheit ausgeprägt ist, desto herausfordernder und zeitintensiver gestaltet sich eine solche Harmonisierung. Harmonisierungsherausforderungen ergeben sich insbesondere bei näherer Betrachtung der Werteflüsse, die auf den gegebenen Strukturen ablaufen.

Dem Steuerungsmodell auf BU-Ebene kommt dabei eine zentrale Rolle zu, da sich hieraus vielfältige Anforderungen und wesentliche Leitplanken für die Ausgestaltung von Strukturen und Prozessen in SAP S/4HANA ergeben. Hierzu gehören unter anderem Konten, Funktionsbereiche, Kostenstellen, Werteflüsse sowie Verrechnungs- und Konsolidierungslogiken. In vielen Projekten wird dieser wichtige Zusammenhang unterschätzt, was häufig zu langwierigen Diskussionen oder zu suboptimalen Entscheidungen während der Konzeptionsphase beziehungsweise in der Design- und Customizing-Phase führt. Geschäftsspezifische Freiheitsgrade einer Business Unit sind dabei wichtig und sinnvoll. Diese sollten jedoch bewusst und unter Abwägung der damit verbundenen – auch langfristigen – Konsequenzen (z. B. zusätzliche Aufwände für Mappings, Maintenance und Governance) getroffen und nicht als Abkürzung genutzt werden, um die für eine Harmonisierung erforderlichen Abstimmungen im Rahmen des Transformationsprojekts zu umgehen.