Steuerungsinstrument oder Pflichtaufgabe?

Feature | 9. August 2006 von admin 0

Konsolidierungslösung der SAP

Konsolidierungslösung der SAP

Die Namensgebung legt es nahe: In der Konzernkonsolidierung wird ein Unternehmen mit allen verbundenen Tochtergesellschaften und Beteiligungen als eine „konsolidierte“ Einheit dargestellt. Diesem Konzernabschluss kommt eine immer größere Bedeutung zu. Lange Zeit wurde er im Rahmen der Gesetzgebung oder steuerlicher Vorschriften als Pflichtaufgabe betrachtet (legaler Konzernabschluss). Doch heute rückt er darüber hinaus auch immer mehr als Instrument der Unternehmenssteuerung oder als Informationslieferant des Managements in den Mittelpunkt des Interesses (Management- oder Controlling-Abschluss). Mehr und mehr Konzerne entschließen sich daher, ein einheitliches Konsolidierungssystem einzuführen. Denn entweder ist die bestehende Lösung den gestiegenen Anforderungen an das interne und externe Reporting nicht mehr gewachsen, oder ein einheitliches, konzernweites Reporting ist zum wichtigen Bestandteil der IT-Strategie avanciert.

Integration von Management- und legalem Abschluss

Matrix-Konsolidierung mit SAP SEM BCS

Matrix-Konsolidierung mit SAP SEM BCS

Früher ließen sich die legalen Einheiten eines Konzerns, etwa die Produktions- oder Vertriebsgesellschaften, meist einem bestimmten Unternehmensbereich eindeutig zuordnen. In zunehmendem Maße sind heute bestehende, neu erworbene oder neu gegründete legale Einheiten mehreren Unternehmensbereichen zugehörig (Matrix-Organisation). Die Frage nach der Integration von Management- und legaler Konsolidierung ist daher zum einen eng verknüpft mit der Matrix-Organisation.
Die Anforderungen an die legale Konsolidierung betreffen zum anderen immer häufiger auch Bereiche, die in der Vergangenheit durch das Konzerncontrolling und die Managementkonsolidierung abgedeckt wurden. Hierzu zählen beispielsweise die Segmentberichterstattung oder die Ermittlung von Unternehmenswerten bei der Neuregelung der Goodwill-Bilanzierung nach IFRS 3.1. Aus diesem Grund liegt der Gedanke nahe, die verschiedenen Abschlüsse in einem integrierten Prozess abzuwickeln.

SAP SEM BCS: Mehr Flexibilität erfordert mehr Planung

SAP SEM BCS: Mehr Flexibilität erfordert mehr Planung

Die Implementierung eines vollständig integrierten Konsolidierungsprozesses mit Management- und legalem Abschluss hat einerseits enormen Einfluss auf die Planung des Projekts. Andererseits hat die Entscheidung Auswirkungen auf die künftige Arbeitsweise der in der Konzernzentrale beteiligten Abteilungen. Beispielsweise wird die Managementkonsolidierung oft als Aufgabe des Controllings verstanden und ist demnach auch dort zu finden. Die legale Konsolidierung hingegen ist im Rechnungswesen angesiedelt. Bei einer vollständigen Integration der beiden Abschlussprozesse macht es daher unter Umständen auch Sinn, die beiden Abteilungen organisatorisch zusammenzulegen. Das jedoch erfordert eine genaue Planung.

Releases von SAP SEM BCS

Releases von SAP SEM BCS

Neben solchen organisatorischen Fragen muss auch die Datenlogistik geklärt sein, also die Übermittlung von Informationen aus dezentralen Meldeeinheiten in die Konzernzentrale. Ist es diesen Einheiten überhaupt möglich, Informationen für den legalen Abschluss und die Management-Sicht in einer Datenmeldung unterzubringen? Verfügen die Einheiten über die jeweils notwendigen Informationen? Können diese der Konzernzentrale annähernd gleichzeitig zugespielt werden, damit sich der integrierte Abschluss nicht verzögert?

Dezentraler oder zentraler Konsolidierungsprozess?

Ebenso wichtig ist die Ausgestaltung des Konsolidierungsprozesses im Hinblick auf die Aufgabenteilung im Konzern. In heterogenen Konzernlandschaften sind oftmals einzelne Abteilungen für die Konsolidierung eines Unternehmensbereichs zuständig. Bei dieser Vorgehensweise münden letztendlich mehrere, dezentrale Konsolidierungsprozesse in einen neuen, zentralen Prozess.
Von Vorteil ist hierbei, dass die Verantwortlichkeiten klar abgegrenzt sind und die jeweilige Teilkonzernkonsolidierung unter Umständen spezifische Anforderungen abdeckt, ohne den Gesamtprozess zu beeinflussen – beispielsweise die Verarbeitung zusätzlicher Managementinformationen über Vertriebskanäle oder Produkte. Nur die von der Zentrale geforderten und notwendigen Informationen werden weitergegeben.
Ein Nachteil dieser Vorgehensweise liegt in den Schnittstellen für die Weitergabe der Informationen an die Konzernzentrale. Sie sind zusätzliche Fehlerquellen und verursachen mit Implementierung und Wartung einen Zusatzaufwand. Außerdem gewährleistet die Konsolidierung in Teilen keine vollständige Transparenz über den gesamten Prozess und über alle Verarbeitungsschritte – schließlich geben die meldenden Einheiten bereits aggregierte Ergebnisse weiter. Das erschwert Korrektur und Verständnis des Konzernergebnisses.
An einem einheitlichen, konzernweiten Konsolidierungsprozess hingegen sind alle meldenden Einheiten direkt beteiligt. Die Schnittstellenproblematik entfällt, die Transparenz bleibt gewährleistet. Allerdings müssen bei der Gestaltung eines einheitlichen Prozesses auch die vielfältigen Anforderungen der dezentralen Einheiten berücksichtigt werden. Es besteht die Gefahr, einen sehr komplexen Prozess zu entwickeln. Hierdurch wiederum steigen die Prozesskosten, insbesondere aufgrund des Bedien-, Schulungs- und Pflegeaufwands.
In beiden Fällen steht und fällt die Konsolidierung mit der Verfügbarkeit und Qualität der Daten. Der wichtige Punkt „Datengewinnung“ sollte daher ebenfalls lange vor der Implementierung einer Konsolidierungslösung geklärt sein. Idealerweise wird bereits in der Anforderungsanalyse die mögliche Auswirkung auf die Performance mit bewertet. So lässt sich schon frühzeitig steuernd eingreifen, wenn zum Beispiel komplexe Anforderungen – meist aus der Managementkonsolidierung – abgebildet werden sollen.

Wege zur Konsolidierung

Konsolidierungslösungen lassen sich im Prinzip nach drei verschiedenen Ansätzen implementieren. Beim klassischen Wasserfallprinzip folgt der Anforderungsaufnahme und -analyse das Business-Konzept, die Realisierung, Test, Produktionsvorbereitung und schließlich der Produktivstart. Der Nachteil: Der Anwender befasst sich bei diesem Ansatz meist erst nach dem Produktivstart eingehend mit der Lösung, zu spät für Know-how-Transfer und Fehlerkorrekturen.
Der zweite Ansatz ist mehr von fachlichen Anforderungen getrieben. Beim Nachfahren von Konzernabschlüssen auf Basis übernommener Altdaten sollen Zahlen für Vorperioden- und Vorjahresvergleiche in das Berichtswesen übernommen werden. Die entsprechenden Mitarbeiter sind gezwungen, sehr früh produktiv mit der neuen Lösung zu arbeiten. Auf einem vorkonfigurierten Prototyp werden jeweils nur die Funktionen weiter ausgeprägt, die für die betreffende historische Periode relevant ist. Die restlichen Funktionen werden während der Implementierung „zugeschaltet“.
Der dritte Ansatz eignet sich insbesondere für die Umsetzung mehrerer dezentraler Konsolidierungsprozesse. Zunächst wird ein Konsolidierungstemplate aufgebaut, das als Vorlage für die Teilkonzernsysteme dient. Die Teilkonzerne prägen dieses Template gemäß ihrer spezifischen Anforderungen aus, ohne die Schnittstellen oder Grundanforderungen des Mutterkonzerns zu ändern. Bei dieser Vorgehensweise ist der Aufwand für die Zentrale begrenzt, allerdings hängt der Projekterfolg stark von den dezentralen Einheiten und der Kommunikation mit diesen ab.
Das „Wasserfallprinzip“ ist gewissermaßen der klassische Weg und wird dem zufolge auch am häufigsten gewählt. Dem gegenüber ist der zweite Ansatz insbesondere dann zu empfehlen, wenn die Altdaten bereits während der Implementierung einer neuen Lösung in geeigneter Qualität vorliegen, etwa bei einem Releasewechsel. Der dritte Ansatz empfiehlt sich, wenn die Teilkonzernen im Rahmen der IT-Strategie des Gesamtunternehmens mit der Implementierung individuelle Anforderungen umsetzen dürfen und dadurch einen Mehrwert für sich schaffen.

Wolfgang Schütte-Felsche

Wolfgang Schütte-Felsche

Michael Gardumi

Michael Gardumi

Tags: , ,

Leave a Reply