Mehr Leistungsfähigkeit mit Ihrer Analytics-Lösung
Mit Ihrer bestehenden Analytics-Lösung können Sie bereits typische Fragestellungen beantworten, wie
- Umschlagshäufigkeit und Bestandsreichweite für Artikel,
- Bestandsbewertung mit diversen Preisen,
- Simulation von Preisänderungen.
Können Sie diese Fragestellungen aber auch unter folgenden Randbedingungen beantworten:
- Berechnung auf maximal granularer Datenbasis?
- Zu beliebigen Stichtagen?
- Für alle Artikel und Betriebe gleichzeitig?
- Ohne Vorberechnung?
Mit dem Einsatz eines SAP HANA Datenbanksystems schaffen Sie die Grundlage für derartige Analysemöglichkeiten. Aber erst mit einer geschickten Nutzung der neu zur Verfügung gestellten technischen Möglichkeiten, lassen sich auch komplexe Analysen auf sehr großen Datenbeständen ohne Vorberechnung durchführen.
Das folgende Projektbeispiel veranschaulicht das Potential:
Wie aber lassen sich Lösungen mit SAP BW auf einem HANA Datenbanksystem erstellen, die eine derartige Leistungsfähigkeit aufweisen?
In meinem Blog „Next Level Analytics, Teil 1“ bin ich zunächst auf die Lösungsarchitektur eingegangen. In der Fortsetzung „Next Analytics, Teil 2“ habe ich dann ein vereinfachtes Design entwickelt.
In diesem Beitrag wollen wir uns mit der Datenmodellierung und der Erstellung von Calculation Views im HANA Studio bzw. Eclipse beschäftigen. Wenn Sie mit der Verwendung des HANA Studios bzw. Eclipse noch nicht vertraut sind, kann ich Ihnen diesen Blogbeitrag empfehlen: SAP HANA Studio für SAP BW Benutzer.
In dem vereinfachten Design soll es verschiedene aDSO Objekte zur Speicherung von
- Einkaufpreisen
- Verkaufspreisen
- Materialbewegungen
geben.
Beginnen wir mit den Einkaufspreisen, die wir ja zeitabhängig zu verschiedenen Artikeln und Lieferanten speichern wollen. Wir gehen davon aus, dass wir die verschiedenen Einkaufspreise aus einem Quellsystem extrahieren können, sie aber innerhalb unseres BW Systems nicht in weitere aDSO fortschreiben möchten. Unter diesen Randbedingungen entscheiden wir uns für ein aDSO mit folgenden Eigenschaften: Staging-aDSO, Reporting aktiviert.
Der Vorteil dieser Variante besteht darin, dass wir eine Datenbanktabelle für das Changelog einsparen, aber dennoch das aDSO in einen Composite Provider einbinden können. So kann den Anwendern z.B. eine Query zur Überprüfung der Preise angeboten werden.
Nun stehen wir vor der Frage, ob wir in unserem aDSO mit Feldern oder Info Objekten arbeiten wollen. Dazu sollten wir uns überlegen, was wir mit den Daten an dieser Stelle erreichen wollen: Sie dienen uns lediglich als Datenbasis für weitere Berechnungen. Brauchen wir dafür zusätzliche Texte oder Attribute? Nein, das wäre an dieser Stelle unnötiger Overhead. Aber wenn wir eine Query zur Überprüfung der Datenqualität anbieten wollen, brauchen unsere Anwender doch Texte und evtl. weitere Informationen. Ja, das können wir auch liefern, wenn wir die Felder aus unserem aDSO später im Composite Provider auf die zugehörigen Info Objekte assoziieren!
Aufgrund dieser Überlegungen entscheiden wir uns für ein feldbasiertes aDSO.
Über den Konditionstyp können unterschiedliche Einkaufspreise abgelegt werden, während die Mengeneinheit zusätzlich eine Unterscheidung nach Preisen pro Mengeneinheit ermöglicht. Jeder Einkaufspreis ist gültig zwischen den beiden Zeitpunkten „Gültig ab“ und „Gültig bis“ und in unterschiedlichen Währungen abgelegt werden.
Für die Verkaufspreise wollen wir zwei aDSO anlegen, weil diese auf zwei unterschiedlichen Organisationsebenen gepflegt werden: zum einen pro Verkaufsorganisation und Vertriebsweg und zum anderen zusätzlich pro Werk.
Auch hier können wir über den Konditionstyp unterschiedliche Verkaufspreise unterscheiden, die dann wiederum zwischen den beiden Zeitpunkten „Gültig ab“ und „Gültig bis“ gültig sind.
Die Berechnung von Materialbeständen soll hier nach einem vereinfachten Ansatz realisiert werden, in dem sich eine Bestandsmenge für einen Stichtag aus der Summe aller Zu- und Abgänge bis zu diesem Stichtag ergibt. Aufgrund dieser Vereinfachung entfallen bestimmte Aspekte wie die Berücksichtigung von Stützstellen, historische Bewegungen oder Komprimierungen.
Alle relevanten Materialbelege sollen in einem aDSO gespeichert werden, in dem Info Objekte verwendet werden. Die Modellierungseigenschaften für dieses aDSO entsprechen einem früheren Info Cube und sehen wie folgt aus:
Mit den hier verwendeten Info Objekten wird nur ein kleiner Teil aus den Informationen eines Materialbeleges abgebildet. Für die Veranschaulichung der weiteren Techniken reicht dies aber völlig aus und wir vermeiden unnötigen Ballast.
Im nächsten Teil der Next Level Analytics Serie werden wir in die Perspektive „SAP HANA Modeler“ wechseln, um dort den virtuellen Teil der Lösung zu definieren.
