Die Überschrift hat Sie vielleicht etwas überrascht?
Bis jetzt sind Sie davon ausgegangen, dass mit der Einführung des Universal Journals das Prinzip der Single-Source-of-Truth umgesetzt ist und dass Ihr Leben als Controller dadurch leichter und vor allem interessanter wird? Vorbei die Zeiten, in denen Sie einen Großteil Ihrer Arbeitszeit für die Suche nach den Ursachen von Ergebnisdifferenzen und Datenschiefständen vergeuden mussten.
Stattdessen wollten Sie sich nach der erfolgreichen Einführung von SAP S/4HANA intensiv mit der Erstellung aussagekräftiger Analysen und der Interpretation der monatlichen Ergebniszahlen beschäftigen? Sie wollten dem Management ein verbessertes Informationsangebot bereitstellen, damit relevante Entscheidungen schneller und auf der Grundlage verlässlicher Zahlen getroffen werden können? Sie haben sich auch schon ausreichend informiert über die Möglichkeiten zur Erstellung eigener Abfrage und Reports mit KPIs?
Ihre Hoffnungen sind berechtigt und die Realisierung Ihrer Ziele ist auch keineswegs gefährdet. Es gibt lediglich kleinere Stolperfallen, die Ihre Freude an der neuen „Reporting-Welt“ kurzzeitig etwas trüben könnten. Dieser Beitrag wird Ihnen zeigen, worauf Sie beim Aufbau der neuen „Reporting-Welt“ achten müssen. Das Augenmerk ist dabei auf die Möglichkeiten im Fiori Launchpad gerichtet. Zweifelsohne eröffnet sich mit SAP SAC ein riesiges Spektrum an Möglichkeiten. Gegenüber dem Angebot für das Reporting im R/3 ist das Angebot im Fiori Launchpad bereits eine enorme Verbesserung.
Wie kommt es zur Entstehung der Stolperfallen? Vereinfacht gesagt geht es darum, dass eine einheitliche Datenquelle durch unterschiedliche Datenzugriffe zu unterschiedlichen Ergebniszahlen führen wird.
Wie kann ein einheitlicher Datenzugriff sichergestellt werden? Zur Beantwortung dieser Frage muss man sich etwas genauer mit dem Universal Journal beschäftigen. In der R/3-Welt gab es bei jedem Geschäftsvorfall mehrere Belege und diese Belege wurden in unterschiedlichen Tabellen gespeichert. In SAP S/4HANA wird auf die Vielzahl der Belege und Tabellen verzichtet: Ein Geschäftsvorfall erzeugt einen Beleg im Universal Journal, und alle FI- und CO-Auswertungen nutzen die Belege in dieser Tabelle.
Anhand eines einfachen Beispiels möchte ich Ihnen das Problem beim Datenzugriff verdeutlichen: Die Gehaltsbuchung für einen Vertriebsmitarbeiter wird unter Verwendung des Sachkontos für Gehälter auf die Vertriebs-Kostenstelle des Mitarbeiters gebucht. Aus der Sicht der Deckungsbeitragsrechnung muss der Betrag in der Berichtszeile „Vertriebskosten“ ausgewiesen werden. Für die Definition der Berichtszeile könnte ein Funktionsbereich oder eine Kostenstellengruppe genutzt werden, aber beide Varianten sind mit größerem Aufwand verbunden, der nicht unbedingt durch einen höheren Nutzen gerechtfertigt wird.
Die einfachste Lösung, die auch den von SAP ausgelieferten Standard-Apps zugrunde liegt, besteht in der Verwendung einer Bilanz-/GuV-Struktur für den Zeilenaufbau des Deckungsbeitragsberichts. Die Besonderheit der für diesen Bericht genutzten Bilanz-/GuV-Struktur besteht darin, dass dem Knoten „Vertriebskosten“ lediglich das Sachkonto zugeordnet wird, das für die Abrechnung der Kostenstelle verwendet wird. Auf den Beleg für die Gehaltsbuchung auf der Kostenstelle wird damit nicht zugegriffen. Dies war auch im R/3 so, denn der Datenzugriff für die Erstellung eines Deckungsbeitragsberichts erfolgte nur auf die Tabelle mit den CO-PA-Daten, und diese Tabelle enthielt nur den Abrechnungsbeleg der Kostenstelle.
Die Bilanz-/GuV-Struktur ist der erste wichtige Baustein für einen einheitlichen Datenzugriff auf das Universal Journal und für die Erstellung zeilenbasierter Berichte. Diese Berichte werden Sie zukünftig mit Hilfe der App „Benutzerdefinierte analytische Abfragen“ (Query) erstellen. Wenn Sie sich bereits etwas mit den Möglichkeiten zur Berichtserstellung im Fiori Launchpad beschäftigt haben, dann wissen Sie, dass man jetzt auch ohne großen Aufwand kennzahlenbasierte Diagramme erstellen kann (App „KPIs und Berichte verwalten“).
In der Zukunft werden kennzahlenbasierte Diagramme voraussichtlich eine größere Bedeutung bekommen als die zeilenbasierten Berichte, da der Entscheidungsträger mit einem Blick die für ihn relevanten Informationen erfassen kann. Umso wichtiger ist es deshalb, dass diese Diagramme nicht nur optisch ansprechend sind, sondern auch verlässliche Informationen liefern (bei dem Diagramm in der ersten Abbildung ist dies leider nicht gelungen).
Für die Erstellung der Diagramme benötigen Sie Kennzahlen. Diese Kennzahlen werden durch die zuvor erstellten analytischen Abfragen bereitgestellt. Dabei gibt es mehrere Varianten, und genau dadurch entsteht die Gefahr, dass in den Diagrammen unterschiedliche Werte für dieselbe Kennzahl ausgewiesen werden. Sie können beispielsweise die Kennzahl „Bruttoumsatz“ als Summe der Konten 8010, 8020 und 8030 definieren. Da Sie bereits auf die zentrale Bedeutung der Bilanz-/GuV-Struktur hingewiesen wurden, würden Sie so eine Formel sicherlich nicht anlegen. Stattdessen würden Sie nach Möglichkeiten zum Zugriff auf die Bilanz-/GuV-Struktur suchen. Leider werden Sie nicht fündig. Ein direkter Zugriff auf die Bilanz-/GuV-Struktur ist nicht möglich. Der Zugriff auf die Bilanz-/GuV-Struktur erfolgt über semantische Tags. Die semantischen Tags werden zuerst mit den Knoten der Bilanz-/GuV-Struktur verknüpft und anschließend können Sie in Ihrer analytischen Abfrage beliebige Kennzahlen durch Zugriff auf diese semantischen Tags definieren.
Damit alle zeilenbasierten Berichte und alle kennzahlenbasierte Diagramme identische Werte liefern, sollten Sie für Ihr Deckungsbeitragsschema nur eine einzige Bilanz-/GuV-Struktur verwenden und diese Bilanz-/GuV-Struktur mit den relevanten semantischen Tags versorgen. Damit haben Sie einen einheitlichen Datenzugriff auf die einheitliche Datenquelle sichergestellt und werden dauerhaft viel Freude mit der neuen Reporting-Welt (und den Entscheidungsträgern) haben.
