SAP-Auswertungen selbst bauen: QuickViewer, SAP Query und die Grenze
Die meisten Listenanforderungen brauchen keine Entwicklung, sondern eine halbe Stunde am richtigen Werkzeug. Manche brauchen sie wirklich, und die willst du vorher erkennen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Jede Liste wird zum Ticket, und jedes Ticket zum Programm
Der Weg ist in vielen Häusern immer derselbe. Jemand aus dem Fachbereich braucht eine Übersicht, die es in dieser Form nicht gibt. Er meldet das an die Anwendungsbetreuung, die schreibt eine Anforderung, die Anforderung landet in der Entwicklung, dort wird ein Report gebaut, abgenommen und transportiert. Sechs Wochen später gibt es eine Liste, die inzwischen anders aussehen sollte, weil sich in der Zwischenzeit die Frage verschoben hat. Und weil das Programm nun existiert, wird es gepflegt, auch wenn es nach einem Jahr niemand mehr aufruft.
Der Aufwand entsteht nicht durch die Auswertung, sondern durch den Weg dorthin. Ein erheblicher Teil dieser Anforderungen sind Listen über einen Bestand: offene Bestellungen mit Lieferant und Termin, Materialien ohne Bewegung seit einem Datum, Kunden einer Region mit ihrem Zahlungsziel. Das sind Selektionen über wenige Tabellen mit einer Verknüpfung, und dafür gibt es Werkzeuge, die genau dafür gebaut wurden und keine Programmierung verlangen.
Der umgekehrte Fehler kostet ähnlich viel. Wenn jeder im Fachbereich sich seine Listen selbst baut und niemand aufschreibt, welche davon zu welchem Zweck existiert, entsteht innerhalb von zwei Jahren ein Bestand aus Hunderten Auswertungen, die nebeneinander leben, sich widersprechen und deren Autoren teilweise gar nicht mehr im Haus sind. Der Punkt ist deshalb nicht, ob der Fachbereich selbst bauen darf, sondern wo die Grenze zwischen einem schnellen Blick und einer dauerhaften Auswertung verläuft.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Ablauf von der Anforderung bis zur fertigen Auswertung
Sechs Stationen, die in dieser Reihenfolge durchlaufen werden. Wer die zweite überspringt, baut regelmäßig etwas, das es schon gibt, und wer die vierte überspringt, hat nach einem Jahr fünfzig Listen ohne Besitzer.
- 1
Die Frage vollständig aufschreiben
Eine Anforderung beginnt fast immer mit dem Satz, dass jemand mal eine Liste bräuchte. Halte fest, welche Objekte gemeint sind, über welchen Zeitraum, mit welcher Einschränkung, wie oft die Auswertung gebraucht wird und wer das Ergebnis anschließend bekommt. Die letzte Angabe ist die wichtigste, denn sie entscheidet zwischen einem persönlichen Blick und einem Bericht, für den jemand geradesteht.
Geschafft, wenn: Ein Satz, aus dem hervorgeht, welche Daten betroffen sind und ob die Auswertung einmalig gebraucht wird oder dauerhaft.
- 2
Prüfen, ob es die Auswertung längst gibt
In SAP S/4HANA liegt für viele Standardfragen bereits eine App oder ein Bericht bereit, dazu kommt der Bestand an Queries, den euer Haus über die Jahre aufgebaut hat. Suche zuerst dort, und zwar mit dem fachlichen Begriff, nicht mit einem technischen Namen. Diese Prüfung dauert selten mehr als zwanzig Minuten und beendet einen erheblichen Teil aller Anforderungen an dieser Stelle.
Geschafft, wenn: Entweder ein Verweis auf eine vorhandene Auswertung oder die begründete Feststellung, dass es sie nicht gibt.
- 3
Mit dem QuickViewer den ersten Wurf bauen
Der QuickViewer erzeugt mandantenabhängige Berichte ohne ABAP-Programmierung. Als Datenquelle dienen eine Tabelle, ein View oder ein Tabellen-Join, ein InfoSet ist dafür nicht zwingend nötig. Du wählst die Listenfelder für die Ausgabe und die Selektionsfelder für die Einschränkung, sicherst und führst aus. Für die Ausführung braucht ein Benutzer Berechtigung für SQ01 oder SQVI, und daran scheitert der erste Versuch überraschend häufig.
Geschafft, wenn: Eine lauffähige Liste mit den richtigen Feldern, gebaut in einer knappen Stunde und ohne Beteiligung der Entwicklung.
- 4
Aus dem QuickView eine SAP Query machen
QuickViews sind benutzerabhängig, jeder führt nur seine eigenen aus. Genau das ist die Sollbruchstelle, an der viele Häuser stattdessen ein Ticket schreiben. Der vorgesehene Weg ist ein anderer: Aus einem QuickView lässt sich eine SAP Query erzeugen, und damit steht die Auswertung einem größeren Kreis zur Verfügung. Dabei bekommt sie ein InfoSet als Datengrundlage und eine Benutzergruppe, über die geregelt ist, wer sie sehen und ändern darf.
Geschafft, wenn: Eine Auswertung mit Namen, Beschreibung, Benutzergruppe und einer Person, die für sie zuständig ist.
- 5
Für Zeitvergleiche und Verdichtung das Werkzeug wechseln
Sobald Perioden verglichen, Werte über Hierarchien verdichtet oder Kennzahlen über längere Zeiträume beobachtet werden sollen, ist der Punkt erreicht, an dem eine Query im Data Warehouse die passendere Antwort ist. Geht es dagegen um ein festes Layout, das gedruckt, versendet oder als Dokument abgelegt wird, übernimmt ein Berichtswerkzeug wie Crystal Reports, das genau dafür gebaut ist und die Daten aus dem System bezieht.
Geschafft, wenn: Eine Zuordnung der Anforderung zu einem Werkzeug, die sich begründen lässt, statt einer Query, die immer weiter aufgeblasen wird.
- 6
Die Grenze zur Entwicklung sauber ziehen
Wenn die Auswertung rechnen muss, Fallunterscheidungen über verschiedene Belegarten braucht, Daten umschlüsselt oder Zwischenergebnisse speichert, endet der Bereich der Werkzeuge ohne Programmierung. Dann ist Entwicklung dran, und zwar von Anfang an mit einem Blick auf die Datenmenge: Die Zahl der Treffer und das übertragene Datenvolumen klein zu halten, ist die erste Regel für jeden Datenbankzugriff, und sie entscheidet später über die Laufzeit.
Geschafft, wenn: Eine bewusste Entscheidung für ein Entwicklungsvorhaben statt eines Tabellen-Joins, den nach einem Jahr niemand mehr entwirren kann.
Vier Stufen, und die Frage entscheidet, auf welcher du landest
- 01 Eine Liste für dich allein, einmalig: der QuickViewer ist in einer halben Stunde fertig.
- 02 Dieselbe Liste für eine Abteilung: aus dem QuickView wird eine SAP Query mit Benutzergruppe.
- 03 Zeitreihen, Perioden und Verdichtung: dafür ist eine Query im Data Warehouse gebaut.
- 04 Ein Bericht, der ausgegeben und verteilt wird: dort übernimmt ein Berichtswerkzeug mit Layout.
- 05 Rechnende Logik über mehrere Belegarten: das ist Entwicklung, und das darf man auch sagen.
Danach weißt du bei jeder Anforderung, welches Werkzeug dran ist
Die Werkzeuge unterscheiden sich weniger in dem, was sie technisch können, als in der Frage, für wen das Ergebnis gedacht ist und wie lange es leben soll. Diese sechs Punkte sind die Entscheidungsgrundlage, und sie kosten in der Anwendung jeweils Minuten, nicht Tage.
Die Frage vollständig aufschreiben
Halte fest, welche Objekte gemeint sind, welcher Zeitraum gilt, welche Einschränkung nötig ist, wie oft die Auswertung gebraucht wird und was mit dem Ergebnis geschieht. Erst wenn diese fünf Angaben stehen, lässt sich sagen, ob es um eine einmalige Liste oder um einen dauerhaften Bericht geht.
Zwischen einmalig und dauerhaft trennen
Ein einmaliger Blick darf schnell und schmutzig sein, ein dauerhafter Bericht braucht einen Besitzer, einen Namen und eine Beschreibung. Diese eine Unterscheidung verhindert beides: das Ticket für eine Frage von zehn Minuten und den Wildwuchs aus Hunderten Listen ohne Herkunft.
Mit dem QuickViewer anfangen
Er erzeugt mandantenabhängige Berichte ohne ABAP-Programmierung, mit einer Tabelle, einem View oder einem Tabellen-Join als Datenquelle. Für den ersten Wurf ist das der schnellste Weg, und du siehst nach einer halben Stunde, ob die Frage überhaupt beantwortbar ist.
Für den geteilten Gebrauch zur SAP Query wechseln
QuickViews sind benutzerabhängig, jeder kann nur seine eigenen ausführen. Sollen mehrere Leute dieselbe Auswertung nutzen, erzeugst du daraus eine SAP Query. Damit bekommt sie eine Benutzergruppe, einen Namen und einen Platz, an dem andere sie finden.
Bei Zeitvergleichen das Berichtswerkzeug nehmen
Sobald es um Perioden, Vergleiche zum Vorjahr, Hierarchien oder verdichtete Kennzahlen geht, ist die Query am Ende. Dann ist eine Query im Data Warehouse oder ein Berichtswerkzeug mit eigenem Layout der richtige Schritt, nicht der zwanzigste Anlauf mit einem Tabellen-Join.
Die Grenze zur Entwicklung bewusst überschreiten
Rechnende Logik, Umschlüsselungen, Fallunterscheidungen über mehrere Belegarten: Das ist Entwicklung, und dort gehört es hin. Wichtig ist nur, dass diese Entscheidung ausgesprochen wird, statt sie als immer größeren Join zu tarnen, den niemand mehr versteht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was der QuickViewer leistet und wo er aufhört
Der QuickViewer ist bewusst schlicht gebaut. Er erzeugt mandantenabhängige Berichte ohne ABAP-Programmierung, und als Datenquelle genügt eine Tabelle, ein View oder ein Tabellen-Join. Ein InfoSet ist nicht zwingend nötig, die Daten können unmittelbar aus der gewählten Quelle gelesen werden. Man wählt die Felder für die Ausgabe, die Felder für die Einschränkung, sichert das Ergebnis und führt es aus. Für die Ausführung braucht der Benutzer Berechtigung für SQ01 oder SQVI.
Die entscheidende Eigenschaft ist zugleich die größte Einschränkung: QuickViews sind benutzerabhängig. Jeder kann nur die eigenen ausführen, es gibt keine Weitergabe an Kollegen und keine gemeinsame Pflege. Für einen schnellen Blick ist das genau richtig, weil niemand um Erlaubnis fragen muss und nichts kaputtgehen kann. Für eine Auswertung, die jeden Monatsanfang von vier Leuten gebraucht wird, ist es das falsche Werkzeug, und das merkt man erst, wenn der erste Kollege danach fragt.
In der Praxis lohnt sich deshalb eine einfache Hausregel: Der QuickViewer ist der Skizzenblock. Was dort entsteht und sich als dauerhaft nützlich erweist, wird in eine SAP Query überführt und bekommt damit einen Besitzer. Was dort entsteht und einmal gebraucht wird, bleibt liegen und stört niemanden. Diese Regel ist deshalb wirksam, weil sie den ersten Schritt nicht behindert, sondern nur den zweiten verlangt.
SAP Query: derselbe Baukasten, aber für mehrere Leute
Der Übergang ist ausdrücklich vorgesehen. Wenn du QuickViews einem größeren Kreis zugänglich machen willst, kannst du daraus SAP Queries erzeugen. Damit ändert sich weniger an der Auswertung selbst als an ihrer Umgebung: Sie liegt jetzt auf einem InfoSet, das die Datengrundlage beschreibt, und in einer Benutzergruppe, über die geregelt ist, wer sie sehen und wer sie ändern darf. Aus einer persönlichen Liste wird ein Gegenstand, den man einem Nachfolger übergeben kann.
Der InfoSet ist dabei der Teil, der Sorgfalt verlangt. Er legt fest, welche Tabellen und Verknüpfungen zur Verfügung stehen und welche Felder daraus überhaupt sichtbar werden. Ein gut geschnittener InfoSet für den Einkauf oder für den Vertrieb erspart über Jahre Dutzende von Einzelaufbauten, weil sich daraus verschiedene Auswertungen bedienen lassen. Ein InfoSet, in dem jemand einfach alles zusammengehängt hat, wird dagegen zur Quelle langsamer Abfragen und falscher Zahlen aus doppelt gezählten Zeilen.
Für den Betrieb bedeutet das eine kleine, aber notwendige Ordnung. Benutzergruppen entlang der Fachbereiche, ein Namensschema, aus dem hervorgeht, worum es geht, und eine kurze Beschreibung in der Query selbst. Das kostet je Auswertung zwei Minuten und ist der Unterschied zwischen einem gepflegten Bestand und einer Sammlung von Namen wie ZTEST3, bei denen niemand mehr weiß, ob sie noch stimmen.
Warum Auswertungen im Rechnungswesen heute anders aussehen
Wer aus einem klassischen ERP kommt, hat gelernt, für unterschiedliche Fragen unterschiedliche Quellen anzuzapfen. In SAP S/4HANA hat sich das geändert. Das Universal Journal in der Tabelle ACDOCA ist der gemeinsame Belegspeicher für das Rechnungswesen, interne und externe Sicht lesen aus derselben Quelle, und das verbindende Element ist das Konto. Die früheren Summensätze in Hauptbuch, Controlling, Material Ledger, Anlagenbuchhaltung, Kreditoren- und Debitorenbuchhaltung sind ebenso entfallen wie die Indextabellen, die bestimmte Selektionen beschleunigen sollten.
Für Auswertungen hat das zwei Folgen. Die angenehme: Abstimmungsdifferenzen zwischen internen und externen Zahlen, die früher aus verschiedenen Quellen stammten, entfallen an dieser Stelle. Die unangenehme: Jede Auswertung, die aus dem Altsystem übernommen wurde und auf eine der entfallenen Summen- oder Indextabellen zugreift, geht nicht mehr auf oder läuft gar nicht mehr. Das ist einer der Punkte, an denen Bestandsauswertungen nach einem Umstieg systematisch durchgesehen werden müssen.
Wenn Ergebnisrechnung im Spiel ist, kommt eine weitere Besonderheit dazu. Das Universal Journal enthält Spalten für die Standardmerkmale und für die zusätzlichen Merkmale des Ergebnisbereichs, insgesamt bis zu sechzig Merkmale einschließlich der festen. Das ist eine großzügige, aber eben endliche Zahl, und sie ist der Grund, warum die Frage, welche Merkmale wirklich gebraucht werden, in ein Konzept gehört und nicht in eine Sammlung von Einzelwünschen.
Wann ein Berichtswerkzeug übernimmt
Es gibt drei Anzeichen, an denen sich zuverlässig erkennen lässt, dass eine Query nicht mehr das richtige Werkzeug ist. Das erste sind Perioden: Sobald ein Vergleich zum Vormonat, zum Vorjahr oder über einen längeren Zeitraum gefragt ist, arbeitest du gegen die Bauart einer Query an. Das zweite sind Hierarchien und Verdichtungen, also die Frage nach Summen über Ebenen. Das dritte ist ein festes Layout, das gedruckt, versendet oder abgelegt werden muss und dabei jedes Mal gleich aussehen soll.
Für die ersten beiden ist eine Query im Data Warehouse gebaut. Dort werden Kennzahlen und Merkmale getrennt modelliert, Zeitbezüge sind Teil des Modells und nicht ein Feld unter vielen, und Verdichtungen kommen aus der Struktur statt aus einer Nachbearbeitung. Für den dritten Fall ist ein Berichtswerkzeug wie Crystal Reports zuständig, das aus denselben Daten ein Dokument mit festem Aufbau erzeugt, mit Seitenumbrüchen, Gruppenwechseln und einem Layout, das man dem Kunden schicken kann.
Zwischen den Werkzeugen zu wechseln, ist kein Scheitern, sondern der eigentliche Punkt. Der Fehler, der wirklich weh tut, ist der Verzicht auf den Wechsel: eine Query, die über Monate um Hilfsfelder, Zusatz-Joins und nachgelagerte Tabellenkalkulationen erweitert wird, bis sie eine halbe Stunde läuft und drei Leute wissen, wie man sie richtig liest.
Die Grenze zur Entwicklung, und was danach zählt
Entwicklung wird gebraucht, sobald die Auswertung rechnet, umschlüsselt, Fälle unterscheidet oder Zwischenstände speichert. Das ist keine Niederlage für den Fachbereich, sondern eine saubere Zuständigkeit. Wichtig ist, dass der Wechsel ausgesprochen wird, denn die typische Verfallsform ist ein Tabellen-Join, der Schritt für Schritt um weitere Tabellen ergänzt wird, bis er fachlich falsche Zahlen liefert, weil eine Verknüpfung Zeilen vervielfacht.
Ist die Entscheidung gefallen, verschiebt sich die wichtigste Frage auf die Datenmenge. Die Leistung eines Programms hängt ganz wesentlich an der Effizienz seiner Datenbankzugriffe, und die beiden Grundregeln lauten: die Zahl der gelesenen Zeilen klein halten und die übertragene Datenmenge klein halten. Überflüssige Zeilen sollten gar nicht erst zur Anwendung transportiert und dort ausgewertet werden. Wer das beim Entwurf berücksichtigt, spart sich die spätere Suche nach der Stelle, an der die Laufzeit entsteht.
Und es lohnt sich, an dieser Stelle über die Lebensdauer nachzudenken. Eine Auswertung, die als Programm entsteht, gehört ab dann zum Bestand, wird bei jedem Upgrade angefasst und muss zu dem passen, was ihr euch zum Umgang mit Erweiterungen vorgenommen habt. Genau deshalb ist die Frage, ob eine Query gereicht hätte, keine Bequemlichkeit, sondern eine Frage danach, wie viel Software ihr in fünf Jahren pflegen wollt.
Dazu passende Kurse
Wer Listen bisher als Anforderung weitergegeben hat, kommt mit SAP-Kurse zu Query und Berichtswerkzeugen in wenigen Tagen an den Punkt, die meisten davon selbst zu bauen.
Weil eine Auswertung fast immer in einer Tabellenkalkulation weiterlebt, gehören Excel-Kurse für die Weiterverarbeitung der Ergebnisse in dieselbe Planung wie das Bauen der Query selbst.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Was ist der Unterschied zwischen QuickViewer und SAP Query?
Braucht man dafür Berechtigungen, und welche?
Können wir alle Auswertungen aus dem Altsystem einfach übernehmen?
Ab wann lohnt sich ein Data Warehouse statt einer Query?
Sollen Fachbereiche selbst Auswertungen bauen dürfen?
Passt thematisch dazu
Viele Ergebnisse landen ohnehin in einer Tabellenkalkulation, und wer dort aus der exportierten Liste eine Auswertung aufbauen will, braucht vorher eine Liste ohne Zwischensummen und ohne verbundene Zellen.
Sobald mehrere Bereiche dieselbe Kennzahl unterschiedlich rechnen, hilft keine weitere Query mehr, sondern erst die Rolle, die aus vorhandenen Daten ein tragfähiges Modell baut .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Erst das Werkzeug wählen, dann bauen
Bei cmt baust du Query, InfoSet und Bericht an echten Daten auf und siehst dabei genau die Stelle, an der ein Tabellen-Join anfängt, falsche Zahlen zu liefern.