Lessons Learned besser nutzbar machen

Nach dem Projekt ist vor dem Projekt – Lessons Learned besser nutzbar machen

Im Rahmen von Lessons Learned werden positive wie auch negative Erkenntnisse aus Projekten schriftlich festgehalten, um das gewonnene Wissen dadurch zu einem für zukünftige Projekte nutzbaren Erfahrungswert zu machen.

Typische Fragestellungen sind:

  • Haben wir aus unseren früheren Erfahrungen überhaupt gelernt?
  • Haben wir die Erfahrungen kritisch reflektiert und daraus die richtigen Schlüsse abgeleitet?

Oftmals werden Lessons Learned Workshops am Ende des Projektes durchgeführt. Daran ist grundsätzlich nichts auszusetzen, jedoch werden während des Projektes gewonnene Erkenntnis möglicherweise vergessen und nicht mehr erfasst.

Empfehlenswert ist, Lessons Learned nach jeder abgeschlossenen Phase durchzuführen, um viele der (kleineren) Erfahrungen im weiteren Projektverlauf nutzen zu können. Auch sollten diese besprochen und Maßnahmen abgeleitet werden.

Oftmals verschwinden Lessons Learned Dokumente in der Schublade und können für nachfolgende Projekte nicht mehr genutzt werden. Damit analoge oder auch neue Projektvorhaben von bereits durchgeführten Projekten profitieren können, haben wir die Lessons Learned Dokumente für alle Projektmanager und Consultants unseres Unternehmens zugänglich gemacht und zentral abgelegt.

Leassons Learned anhand eines Upgrade Projektes

Lessons Learned anhand eines Upgrade Projekts

Außerdem sollte nicht nur nach negativen Erfahrungen gesucht werden. Auch aus unseren Erfolgen können wir viel lernen und deren Faktoren sollten wir auf keinen Fall aus dem Blick verlieren.

Vielmehr sollten auch Erfolge eingehend nachvollzogen und dokumentiert werden, um das perfekte Vorgehen jederzeit reproduzieren zu können.

Und auch wenn ein Lessons Learned Prozess einen zusätzlichen Zeitaufwand bedeutet, lohnt es sich: denn die Zeit, die man zur Behebung wiederkehrender Fehler verschwendet, ist viel größer.

Wir bei Inspiricon legen sehr viel Wert auf die Dokumentation und die Umsetzung von Lessons Learned in den unterschiedlichen Projektphasen. Gerne unterstützen wir auch Sie mit diesem Vorgehen und begleiten Ihr Projektvorhaben zu einem erfolgreichen Abschluss.

Autor dieses Beitrags
Thomas Dietl Project Management
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Projektmanagement

Projektmanagement – warum der Grundstein schon vor Projektbeginn gelegt werden sollte

Unterschiedliche, in den vergangenen Jahren, durchgeführte Studien zeigen auf, dass eine Vielzahl von IT-Projekten scheitert oder nur teilweise erfolgreich abgeschlossen wird .

Projekte werden viel zu spät fertig gestellt oder das Budget wird weit überzogen. Und wenn tatsächlich Budget und Zeitplan gehalten werden, dann ist man oft unerwünschte Kompromisse eingegangen, über die man sich später noch täglich in seinen Unternehmensprozessen ärgern wird. Dies verwundert sehr, zumal sich das Thema „Projektmanagement“ mittlerweile zu einem zentral anerkannten Erfolgsfaktor für Projekte entwickelt hat.

Wir wollen daher in diesem Artikel sowohl die unterschiedlichen Projektmanagement-Methoden beleuchten als auch die wesentlichen Faktoren und Voraussetzungen die notwendig sind, um IT-Projekte erfolgreich umsetzen zu können.

Oftmals wird der Nutzen eines Projektmanagements bei (kleinen und mittelständischen) Unternehmen unterschätzt!

Projekt ist nicht gleich Projekt

Jedes Projekt hat seine Eigenarten und speziellen Erfordernisse. Projekte sollten nicht isoliert betrachtet werden, sie sind immer in ein Projektumfeld eingebettet und stehen mit diesem in Wechselwirkung. Einflüsse aus diesem Umfeld können starke Auswirkungen auf das Projekt haben. Lassen Sie uns nachfolgend erst einmal die verschiedenen Arten des Projektmanagements näher betrachten.

Arten des Projektmanagements im IT-Umfeld

1. „Traditionelles“ Projektmanagement

Charakteristisch hierfür ist eine durch Meilensteine getrennte Abfolge der Projektphasen in Initiierung, Planung, Überwachung, Steuerung und Projektabschluss. Zur Ablaufplanung wird i.d.R. die Netzplantechnik als Methode angewandt. Termine, Kosten, Ressourceneinsatz und Ergebnisse werden bereits zu Beginn des Projekts weitestgehend festlegt. Diese planungsorientierte Methode findet vor allem bei Projekten Verwendung, die zu einem bestimmten Termin abgeschlossen werden müssen. Änderungen zum Plan werden über Change Requests abgewickelt.

Traditionelles Projektmanagement

2. Agiles Projektmanagement

Hier wird versucht, die Projektdurchführung flexibel gegenüber Änderungen im Umfeld und auch beim Leistungsumfang zu gestalten. Dies erfolgt überwiegend mit Hilfe von kurzen, aneinander gereihten Planungs- und Durchführungszyklen sog. „Sprints“. Eine genaue Spezifikation des Produkts erfolgt erst während des Projekts. Es gibt strenge Budgetvorgaben. Charakteristisch für diese Vorgehen ist, dass man sich sehr stark auf das (Teil-)Ergebnis und die Akzeptanz durch die Anwender fokussiert. Das Managen und Steuern von agilen Projekten und Prozessen ist sehr dynamisch und flexibel, um Änderungsanträge vom Anwender schnell umsetzen zu können.

Agiles Projektmanagement

Das Beste aus zwei Welten

In der Praxis zeigt sich oft ein Mix aus traditionellem und agilem Vorgehen – besser bekannt als hybrider Projektmanagement-Ansatz. Dabei bildet das traditionelle Vorgehensmodell den organisatorischen Rahmen, wobei die Produktentwicklung nach agilen Prinzipien erfolgt. Welches ist aber nun die geeignete Art der Durchführung für Ihr Projekt?

Welche Methodik passt zu meinem Projekt?

Auswahl der Methode:

Ob nun agil oder traditionell – für jedes Projekt muss das geeignete Verfahren gefunden werden, abhängig von den jeweiligen Rahmenbedingungen. Festhalten lässt sich, dass erfolgreiche Projekte, je nach gewählter Methode, immer termin- und budgettreu sind.

Es gibt keine „Erfolgs-Schablone“ für gelingendes Projektmanagement!

Die gute Nachricht ist: Projektmanagement basiert nicht auf Schablonendenken, es gibt nicht DIE passende erfolgreiche PM-Schablone für jedes Projekt und ist zudem nicht auf eine gewisse Unternehmens- oder Projektgrößen fixiert. Vielmehr lässt es sich flexibel auf die Bedürfnisse des Unternehmens sowie an die Projektstruktur anpassen. Das optimal passende Projektmanagement-Konzept wird i.d.R. für das Unternehmen individuell entwickelt und derart zugeschnitten, damit es zum Projekt und den Zielsetzungen passt.

Lohnt es sich denn für Ihr Unternehmen, ein derartiges Konzept zu entwickeln?

In Projektmanagement zu investieren lohnt sich langfristig!

Zunächst bedeutet Projektmanagement einen erhöhten Planungsaufwand zu Projektbeginn, der sich aber letztendlich am Projektende durch Kosten- und Zeitersparnis auszahlt. Diese Investition zu Beginn des Projektes sorgt im Projektverlauf für einen reibungsloseren Ablauf und bringt eine Reihe von Vorteilen mit sich:

  • Gemeinsames Verständnis aller Beteiligten in Bezug auf das Projekt(ziel?)
  • Reduzierung der Projektkosten
  • Reduzierung des Zeitbedarfs
  • Verbesserte Einhaltung von Terminen, Meilensteinen, usw.
  • Frühzeitiges Erkennen von Planabweichungen und Einleitung von Gegenmaßnahmen
  • Verbesserte Zusammenarbeit der Teammitglieder / Projektbeteiligten
  • Termingerechte Zielerreichung

Damit Projekte evtl. nicht schon vor dem Start zum Scheitern verurteilt sind und sich die erhöhte Investition in die Planung und Steuerung auch auszahlt, sollten Sie den Projektmanager schon vor Beginn des Projekts mit seiner Arbeit starten lassen.

Den Projektmanager (PM) frühzeitig ins Boot holen zahlt sich aus!

Im Wesentlichen ist der PM für die erfolgreiche Planung, Durchführung und Kontrolle sowie für den Abschluss eines Projektes verantwortlich. Des Weiteren gewährleistet er ein strukturiertes Vorgehen von Beginn an. Bei vielen Gesprächen mit PM-Kollegen zeigte sich, dass sich die größten Herausforderungen während des Managements des Projekts in unterschiedlichen Projekten häufig ähneln und oft auf eine zu späte Einbindung des PMs zurückführen lassen. Daher empfiehlt es sich – gerade vor dem eigentlichen Projektbeginn – den Projektmanager frühzeitig mit ins Boot zu holen, um im Vorfeld die potenziellen Gefahren für ein Scheitern zu minimieren. Der PM kann dabei bei folgenden Themen unterstützen:

  • eine sauberen Auftragsklärung, d.h. Festlegung des Auftragsumfangs/Ziels
  • ein gutes Projekt-Setup
  • der Definition von messbaren Zielen und Abnahmekriterien
  • der Förderung eines gemeinsamen Verständnisses für das Projekt

Wesentliche Aufgaben des PM 

  • Klärung der Projektziels und des Auftrags
  • Entwerfen des Projektstrukturplans
  • Schätzen von Aufwänden
  • Erstellen des Terminplans
  • Koordination und Steuerung von Projektabläufen
  • Führung und Organisation der Projektmitglieder
  • Kalkulation von Kosten
  • Risikobewertung und Budgetierung
  • Planung, Umsetzung und Kontrolle
  • Übernahme der Projektkommunikation

Ein schlechter Start eines Projekts kann nicht nur den Erfolg Ihres IT-Projekts gefährden. Unter Umständen – bei entsprechender Budget-Größe des Projekts kann eine unprofessionelle Umsetzung eines Projektvorhabens auch den Unternehmenserfolg gefährden!

Der optimale Einsatz von Projektmanagement minimiert die Risiken, die ein Projekt stören können. So können Chancen genutzt, Projektziele qualitativ erreicht und auch der Unternehmenserfolg sichergestellt werden.

Wir helfen Ihnen mit unserer Expertise im Projektmanagement!

Unsere Projektmanager besitzen das notwendige methodische Handwerkszeug sowie Know-how und Erfahrungen aus vielen erfolgreich durchgeführten Projekten für die Abwicklung Ihres Projektvorhabens. Bei Inspiricon kommen sowohl gelebte Projektmanagement- und Führungskompetenz als auch bewährte und erprobte Methoden und Tools im Projektprozess zum Einsatz.

Wenden Sie sich unverbindlich an unseren Ansprechpartner!

Autor dieses Beitrags
Thomas Dietl Project Management
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de

Die Geschichte des SAP BW

Hallo zusammen,

im Rahmen unserer BW/4HANA-Aktivitäten sind wir in die Archive gestiegen und haben versucht die Geschichte das SAP BW darzustellen. Herausgekommen ist diese Infografik von den Anfängen des BW 1.2 bis heute.

Wir haben den Weg nicht nur recherchiert, sondern wir sind den ganzen Weg gegangen. Gerne unterhalten wir uns mit Euch über die Entwicklung des SAP BW und über die aktuellsten Migrations-Strategien!

Geschichte des SAP BW

Autor dieses Beitrags
Jörg Waldenmayer Lead Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
inspiricon_performance-optimierung-sap-bw-ladevorgaenge

Performance-Optimierung von SAP BW Ladevorgängen durch Verwendung mehrdimensionaler interner Tabellen

Es kann bei der Beladung von Datenzielen in SAP BW zu langen Laufzeiten kommen, wenn große Datenmengen z.B. in Endroutinen prozessiert werden müssen. Unter Umständen treten Performanceprobleme erst einige Zeit nach Produktivstart bei wachsenden Datenvolumina auf, die zum Zeitpunkt der Entwicklung und in der Testphase so nicht zur Verfügung standen. In solchen Fällen ist es immer mit Risiken verbunden, wenn an einer produktiven Applikation Performanceoptimierungen vorgenommen werden müssen. Der nachfolgend beschriebene Lösungsansatz beschreibt eine Möglichkeit, die Verarbeitung größerer Datenmengen unter gewissen Voraussetzungen deutlich zu beschleunigen, ohne dass Änderungen an der ursprünglich implementierten Logik bzw. Verarbeitung vorgenommen werden müssen.

Aus der Praxis

Ein typisches Beispiel aus der Praxis ist die Ermittlung offener Lieferantenbestellungen. In einem unserer Kundenprojekte war gefordert, für offene Lieferantenbestellungen auf Positionsebene die Einteilungen sowie die Lieferantenbestätigungen und zugehörigen Wareneingänge zu verarbeiten und diese Informationen in Berichten zur Verfügung zu stellen. Ein großer Teil der Verarbeitungslogik war in der Endroutine einer Transformation implementiert, in welcher die Bestellpositionen verarbeiten wurden.

Mit Hilfe von Lookup Tabellen wurden die Einteilungen sowie die Lieferantenbestätigungen und Wareneingänge nachgelesen.  Diese Tabellen waren als Standard Tabellen definiert. Bei der Verarbeitung dieser Tabelleneinträge erfolgten die Berechnung der offenen, bestätigten und unbestätigten Bestellmengen sowie die Verrechnung von Wareneingängen bei Teilbelieferungen. Die Verarbeitung dieser Lookup Tabellen erfolgte in geschachtelten Loops im Rahmen eines Loops über das RESULT_PACKAGE. Da sowohl das RESULT_PACKAGE als auch die Lookup Tabellen mehrere zehntausend Datensätze enthielten, war die Gesamtperformance der Verarbeitung entsprechend gering.

Die Abfrage der Lookup Tabellen erfolgte über komplexe WHERE Klauseln innerhalb mehrerer verschachtelter LOOP – ENDLOOP Schleifen. Tabellen vom TYP HASHED TABLE konnten deshalb nicht ohne weiteres verwendet werden.

Für ca. 400.000 Bestellpositionen betrug die Gesamtlaufzeit der Verarbeitung ca. 90 Minuten.

Die Verwendung sortierter Tabellen führte zu nur zu geringfügigen Verbesserungen der Performance.

Dazu ein Beispiel aus der Verarbeitung:

1_inspiricon_sortierte-tabellen

Das Laufzeitproblem konnte mit Hilfe mehrdimensionaler interner Tabellen gelöst werden. Man definiert dabei eine HASH Tabelle deren Schlüssel mit „TABLE KEY“ performant gelesen werden kann. Im vorliegenden Fall bestand der Schlüssel aus der Nummer des Einkaufsbeleges und der Belegposition. Neben dem Schlüssel enthält die Tabelle an der Stelle eines weiteren Feldes eine zusätzliche interne Tabelle, welche derjenigen aus Abbildung 1 entspricht (it_eemmo06).

2_inspiricon-mehrdimensionale-interne-tabelle

Vorbereitung der Daten

Die Befüllung der ursprünglichen internen Tabelle bleibt unverändert und findet vor dem Loop über die RESULT_PACKAGE statt:

3_inspiricon-result-package

Im Anschluss werden die Daten in die HASH Tabelle übertragen und die ursprüngliche Tabelle gelöscht:

4_inspiricon-hash-tabelle

Verarbeitung der Daten

In der folgenden Verarbeitung wird die Originaltabelle für die Verarbeitung nur noch mit den aktuell benötigten Datensätzen befüllt:

5_inspiricon-datenverarbeitung

Die Verarbeitung der Originaltabelle bleibt unverändert:

6_inspiricon_verarbeitung-originaltabelle

Sie enthält jetzt nur noch diejenigen Datensätze, welche für den aktuellen Verarbeitungsschritt benötigt werden. Im vorliegenden Beispiel sind das die Einteilungen, Wareneingänge sowie die Lieferantenbestätigungen. Da die interne Tabelle nur noch sehr wenige Datensätze enthält, ist die Verarbeitung im Loop entsprechend performant.

Was bringt diese Lösung?

Ein Vorteil dieser Lösung besteht darin, dass an den bereits vorhandenen internen Tabellen und der verwendeten Logik in den WHERE Klauseln keinerlei Änderungen vorgenommen werden müssen. Der Aufwand für den Aufbau der HASH Tabelle fällt für die Gesamtlaufzeit kaum ins Gewicht. Die Lösung kann mit geringem Risiko zur Optimierung der Laufzeit bestehender Applikationen verwendet werden, da der Kern der Verarbeitungslogik unverändert bleibt und lediglich die Datenbereitstellung optimiert.

Das beschriebene Vorgehen empfiehlt sich also beispielsweise bei Applikationen, die schon sich schon seit längerer Zeit im Produktivbetrieb befinden und wegen wachsender Datenmengen an Laufzeitgrenzen stoßen.

Im oben erwähnten Beispiel, der Verarbeitung von Einkaufsbelegen, konnte die Gesamtlaufzeit der Verarbeitung von ca. 90 Minuten auf ca. 15 Minuten reduziert werden.

Quellenangabe der Bilder: Inspiricon AG

Autor dieses Beitrags
Oskar Glaser Lead Consultant BI Reporting
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de

 

Klassische DataStore Objekte

Klassische DataStore-Objekte vs. Advanced DataStore-Objekte

Mit SAP BW/4HANA gab es auf Architekturebene viele Änderungen, so zum Beispiel bei der Datenmodellierung.

In diesem Artikel beschäftigen wir uns mit den verschiedenen Funktionen und Möglichkeiten von ADSOs und zeigen dir zudem, wie sie dir dabei helfen können, verschiedene Aufgaben in deiner SAP BW-Umgebung zu optimieren.

Werfen wir aber zuerst einen Blick auf die klassischen DSOs und ihre Funktionen. Danach zeige ich dir noch die Unterschiede zwischen klassischen DSOs und den neu eingeführten ADSOs.

DSO (DataStore Object)

Was ist ein DSO?

Ein DSO ist eine zweidimensionale Speichereinheit, in der hauptsächlich Transaktionsdaten oder Stammdaten mit niedrigster Granularität gespeichert werden. Die Daten werden also mit einem hohen Detailgrad gespeichert.

DSO-Typen

Beim Anlegen eines DSOs musst du zunächst den Typ auswählen:

dso

Wenn wir ein DSO anlegen, legt das System standardmäßig eine System ID über die Option „Erzeugung von SIDs bei Aktivierung“ fest, die du in den Bearbeitungseinstellungen eines DSOs findest. Wird diese Option aktiviert, prüft das System die SID-Werte für alle Merkmale im DSO. Falls es keinen SID-Wert für ein Merkmal gibt, generiert das System die SID. Durch die Erzeugung der SIDs bei Aktivierung wird die Laufzeitperformance der Abfrage verbessert, da die SIDs nicht zur Laufzeit der Abfrage generiert werden müssen. SID-Werte werden grundsätzlich in der SID-Tabelle eines InfoObjects gespeichert. Über die SID wird auf die Attribute und Texte eines Stammdaten-InfoObjects zugegriffen. Die SID-Tabelle ist über den char key mit den dazugehörigen Stammdatentabellen verbunden.

In der folgenden Tabelle findest du eine Übersicht über die Eigenschaften der verschiedenen DSO-Typen und Architekturen:

table DSO types

ADSO (Advanced DataStore Object)

Das Advanced DSO ist in der Lage, all diese Objekte zu ersetzen.

 BW4HANA Modeling Objects

Bevor wir ein ADSO anlegen, müssen wir wissen, dass es 3 Haupttabellen umfasst:

  • Inbound Table
    • Tabelle der Aktivierungs-Queue bei klassischen DSOs
    • Nicht komprimierte Faktentabelle eines nicht-SAP-HANA-optimierten InfoCubes
    • Alle Sätze werden mit einem technischen Schlüssel gespeichert.
  • Tabelle der aktiven Daten
    • Enthält ebenso wie beim klassischen DSO die aktuellen Werte nach Aktivierung. Der Schlüssel der Tabelle ist der DSO-Schlüssel (auf Schlüssel werden wir noch näher eingehen).
    • Komprimierte Faktentabelle eines nicht-SAP-HANA-optimierten InfoCubes.
  • Change Log
    • Entspricht dem eines klassischen DSO.
    • Speichert die Unterschiede zwischen dem Inbound Table und der Tabelle der aktiven Daten.
    • Wird für die Delta-Erstellung benötigt.

Wichtige Schritte beim Anlegen eines ADSO

  • Ein ADSO wird in den BWMT in Eclipse wie jedes andere neue Objekt angelegt (in BW 7.5 besteht die Möglichkeit, auch weiterhin die klassischen Objekte im SAP GUI anzulegen, wohingegen in BW4/HANA nur noch die neuen Objekte in den BWMT angelegt werden können).
  • Auf der Registerkarte „General“ kannst du die Aktivierungseinstellungen und weitere Eigenschaften festlegen. Zunächst muss hier eine Beschreibung angegeben werden. Im Anschluss können wir unter „Model Template“ eine Vorlage auswählen. Dabei kann sich ein ADSO wie je eines der 4 Objekte im klassischen BW verhalten.

template

Acquisition-Schicht

In dieser Schicht lassen sich Objekte für die „schreiboptimierten“ Anwendungsfälle klassischer DSOs anlegen. Sie besteht aus 3 Schichten:

  1. Data-Acquisition-Schicht
    • Entspricht einer Persistent Staging Area (PSA) und dient als Eingangsablage im BW für Daten aus den Quellsystemen.
    • Keine Verwendung der aktiven Tabelle, daher ist eine Aktivierung nicht erforderlich.
    • Requests werden in die Inbound Table geladen und daraus extrahiert.
    • Alle Sätze in der Inbound Table enthalten eine Request-TSN, Datenpaket und Datensatznummer.
    • Auf die Inbound Table (ehemals Tabelle der neuen Daten / Aktivierungs-Queue) wird zum Ausführen einer BEx Query und zur Extraktion zugegriffen.
    • Daten werden nicht aggregiert.
  2. Corporate Memory mit Schwerpunkt auf Kompression
    • Requests werden auch weiterhin in die Inbound Table geladen.
    • Auf Detail-Level nicht mehr benötigte alte Requests können in die Tabelle der aktiven Daten komprimiert werden.
    • Um Speicherplatz zu sparen wird beim CM Compression ADSO auf eine Change-Log-Tabelle verzichtet, es gibt nur eine Inbound Table und eine Tabelle der aktiven Daten.
    • Wird ein Laderequests aktiviert, werden die Daten in die aktive Tabelle geladen und aus der Inbound Table gelöscht.
    • Gibt es 2 Sätze mit dem gleichen Schlüssel, überschreibt BW/4HANA alle Merkmale des Satzes mit denen des zuletzt geladenen Satzes.
  3. Corporate Memory mit Schwerpunkt auf Reporting
    • Der Unterschied zwischen dieser Vorlage und der Vorlage für die „Corporate Memory mit Schwerpunkt auf Kompression“ liegt darin, dass die Daten aus der Inbound Tabelle nicht gelöscht werden. Die Daten bleiben also in der Inbound Table, um zu verhindern, dass technische Informationen verloren gehen.
    • Die Vorlage für CM mit Schwerpunkt auf Reporting verfügt jedoch über keinen Change Log.
    • Ein weiterer Unterschied liegt darin, dass die Daten nicht aus der aktiven Tabelle, sondern aus der Inbound Table extrahiert werden.
    • Da die Daten nach der Aktivierung in der Inbound Table verbleiben, sind diese ADSOs sehr gut geeignet, wenn du zwar Daten speichern möchtest, durch den Wegfall des Change Log aber Speicherplatz eingespart werden soll.

Propagation-Schicht

  • Bildet die Grundlage für die weitere Verteilung und Weiterverwendung der Daten.
  • Entspricht einem Standard-DataStore-Objekt (klassisch).
  • Requests werden auch in die Inbound Table geladen.
  • Für das Reporting muss der Benutzer die geladenen Requests aktivieren.
  • Die Daten werden dann in die Tabelle der aktiven Daten übertragen und das Delta wird im Change Log gespeichert.
  • Das Change Log wird auch für den Rollback bereits aktivierter Requests genutzt.

Reporting-Schicht

  • Dient der Ausführung von Queries zur Analyse.
  • Entspricht einem Standard-InfoCube.
  • Die Inbound Table entspricht der F-Tabelle und die Tabelle der aktiven Daten der E-Tabelle.
  • Es gibt keinen Change Log. Ohne die Change-Log-Tabelle kann der Deltaprozess nicht erfolgen.
  • Nach der Aktivierung ist die Inbound Table leer.
  • Das Reporting erfolgt auf einer Union der beiden Tabellen Inbound Table und aktive Tabelle.

Planungs-Schicht

Sie ist in 2 weitere Schichten aufgeteilt:

  1. Planning on Direct Update
    • Die Daten werden automatisch in die aktive Tabelle geladen, eine Aktivierung ist also nicht erforderlich.
    • Es gibt keinen Change Log und keine Inbound Table.
    • Das Befüllen der aktiven Tabelle kann über eine API erfolgen.
    • Bei diesem ADSO-Typ können Daten können auch über den Datentransferprozess (DTP) geladen werden.
    • Es steht nur die Option Überschreiben zur Verfügung. Keine Summation von Kennzahlen wie beim Planning on Cube-like ADSO.
  2. Planning on Cube-like
    • Es gibt eine Inbound Table und eine aktive Tabelle.
    • Alle Merkmalsfelder sind in der aktiven Tabelle als Schlüsselfelder markiert, was eine Voraussetzung für die Planungseignung ist.
    • Es steht nur die Option Summation zur Verfügung.

Der Prozess der für HANA hoch-optimierten SID-Erzeugung

Zum Zwecke der Leistungsoptimierung ist es in BW/4HANA möglich, Kennzeichen sowohl auf InfoProvider-Ebene als auch einzeln für jedes Merkmal des DSOs zu setzen. Die Prüfung der Datenintegrität erfolgt dann nur für das ausgewählte Merkmal.

InfoObjects/Felder

Als neue Funktion ist es jetzt auch möglich, Felder mit einfachen Datentypen anstelle von InfoObjects zu verwenden. Wähle dazu die Registerkarte „Details“ aus und klicke auf „Add Field“. Unter „Identify with:“ kannst du über das Auswahlmenü festlegen, ob du für die Definition ein InfoObject oder ein Feld verwenden möchtest.

infoObject

In BW kann der Benutzer entscheiden, ob die Modellierung mit InfoObjects oder Feldern erfolgen soll. Das Modellieren von InfoObjects bedeutet zwar einen zusätzlichen Aufwand, andererseits bieten InfoObjects aber auch viele Vorteile. Bevor du dich also für eine dieser Modellierungsoptionen entscheidest, solltest du die jeweiligen Vor- und Nachteile genauesten abwägen.

Im Folgenden gehe ich daher ein wenig auf eben diese Vor- und Nachteile beim Modellieren mit Feldern ein:

Die Vorteile von Feldern

  • Wenn Felder in der Query enthalten sind, kann diese schlüsselbasiert in SAP HANA verarbeitet werden.
  • Wenn kleinere Datenvolumen verarbeitet werden, kann durch die Verwendung von Feldern die Flexibilität und Reichweite des Data Warehouse erhöht werden.

Die Nachteile von Feldern

  • Die Services der InfoObjects (so zum Beispiel Attribute und Hierarchien) stehen für Felder nicht zur Verfügung.
  • Die Gültigkeitsmerkmale bei DataStore-Objekten (advanced) mit Bestandskennzahlen müssen InfoObjects sein.
  • Die InfoObject-Attribute müssen InfoObjects sein.
  • Eine feldbasierte Kennzahl kann keine Ausnahmeaggregation haben.
  • Planungs-Queries auf DataStore-Objekten (advanced) werden mit Feldern nur lesend unterstützt.
  • Wenn Felder in der Query verwendet werden, können die InfoProvider nur sequentiell gelesen werden.
  • In der Query auf einem CompositeProvider werden nicht alle Datentypen für Felder unterstützt (z. B. dürfen Felder nicht länger als 20 Zeichen sein).

Definition von Schlüsseln für ein ADSO

  • In dieser Registerkarte wählen wir auch aus, welche Felder für die Schlüssel unseres ADSO verwendet werden. Klicke zur Definition eines Schlüssels auf „Manage Keys“.

fields adso

Schlüsselfelder

Es gibt 2 Schlüsseltypen: Primärschlüssel und Fremdschlüssel.

Die Vorteile von Schlüsselfeldern:

  • Eindeutige Identifikation eines Satzes in einer Tabelle.
  • Schlüsselfelder können nicht NULL sein.
  • Dient der Verbindung zweier Tabellen.
  • Hauptzweck eines Fremdschlüssels ist die Datenvalidierung.
  • Stammdatennachlesen: Durch die Verwendung des Wertes des Eingabefelds als Schlüssel kannst du das zu einem angegebenen Merkmal zugehörige Attribut des Merkmals auslesen.
  • Auslesen aus dem Advanced DataStore: Durch die Verwendung des/der Werte(s) des Eingabefelds als (geklammerter) Schlüssel, kannst du die Datenfelder eines angegebenen Advanced DataStore-Objekts (ADSO) auslesen.
  • Du möchtest auf jeden Fall vermeiden, dass BW/4HANA für 2 Sätze mit dem gleichen Schlüssel alle Merkmale des Satzes mit denen des zuletzt geladenen Satzes überschreibt.

Die Nachteile beim Verzicht auf Schlüsselfelder:

  • Sätze werden nicht eindeutig identifiziert => so besteht die Möglichkeit doppelter Sätze.
  • Die Performance wird beeinträchtigt.

Die Vorteile des Einsatzes von ADSOs anstelle von klassischen DSOs:

  • Vereinfachung von Objekttypen
    • Kann sich wie 4 Objekte im klassischen BW verhalten.
  • Flexibilität bei der Datenmodellierung
    • Modellierung deines ADSOs über die Einstellungen der Reporting-Schicht.
  • Performance beim Datenladen und der Aktivierung ist HANA-optimiert, da es sich bei ADSOs um native HANA-Objekte handelt.

Quellenangabe der Bilder: SAP SE, Inspiricon AG

Autor dieses Beitrags
Roxana Hategan Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
inspiricon unterschiede sap bw und bw4hana

Die Unterschiede in der Datenmodellierung mit SAP BW und SAP BW/4HANA

Wir studieren die Vergangenheit, um die Gegenwart zu verstehen.“  – William Lund

Aktuell häufen sich die Fragen unserer Kunden zum Thema BW 7.5 und BW4/HANA. Grund genug für uns hier eine Serie von Blogartikeln zu starten, um diese Themen zu beleuchten. Wir beginnen damit, die Entwicklung des SAP BW zu beleuchten und schauen uns anschließend an, welche Themen-Bereiche wir in den nächsten Wochen näher untersuchen.

In diesem Artikel steht SAP BW für die Vergangenheit und SAP BW/4HANA für die Zukunft der Datenmodellierung.

Die meisten Unternehmen und auch die Anwender sind sich immer noch nicht im Klaren darüber, wo genau die Unterschiede zwischen SAP BW (der alte Modellierungsansatz) und SAP BW/4HANA liegen. Mit diesem Artikel möchten wir die Dinge ins rechte Licht rücken und klare Antworten liefern.

Eine kurze Geschichte von SAP BW

Kurze Geschichte des SAP BW

 

Wo liegen die Unterschiede zwischen SAP BW und SAP BW/4HANA?

Eines der Hauptziele der SAP liegt in der Vereinfachung des Systems. Dementsprechend werden Objekte und Prozesse zusammengefasst und die Anzahl der Schritte reduziert.

a) Modellierungsobjekte

Ein schneller Vergleich der Modellierungsobjekte in der klassischen SAP-BW-Anwendung und der Objekte in SAP BW/4HANA machen vielleicht am ehesten deutlich, in welchem Ausmaß die Modellierung vereinfacht wurde.

sap_classic-sap-bw_sap-bw4hana_objects

Wir werden euch in den folgenden Artikeln die neuen Provider vorstellen, angefangen mit den ADSOs.

b) Datenflüsse

Der zentrale Einstiegspunt für die Datenmodellierung in SAP BW/4HANA ist der Datenfluss. Hier wird definiert, welche Objekte und Prozesse zur Übertragung der Daten von der Quelle an SAP BW/4HANA sowie zur Bereinigung, Konsolidierung und Integration der Daten benötigt werden, damit diese für Analyse- und Reporting-Zwecke zur Verfügung stehen. SAP BW∕4HANA setzt auf eine neue integrierte Schichtenarchitektur (Layered Scalable Architecture – LSA++).

Das klassische SAP BW verwendet LSA, die Vorgängerverion von LSA++. Diese Schicht ist restriktiver und bietet weniger Flexibilität im Umgang mit den Daten.

vergleich sap bw und bw4hana

 

Durch den Einsatz von LSA++ wird vor allem die Anzahl der Persistenzschichten reduziert. Das hat zwei Effekte:

  1. Zum einen wird dadurch die Performance der Datenverarbeitung erhöht: man muss weniger speichern und aktivieren und spart so Zeit!
  2. Und zum anderen wird dadurch das Datenvolumen reduziert. Wurde früher durch den gewollten Einsatz von Redundanzen im BW-System die Lese-Performance optimiert und Speicherplatz nicht als kritischer Faktor gesehen, so ändert sich das durch den Einsatz von HANA grundlegend. Hauptspeicher ist teurer, sowohl in der Hardware verglichen mit Festplattenspeicher, als auch in der Lizenzierung, da HANA nach Hauptspeicher lizenziert wird. Außerdem wird das System durch weniger „physische“ Schichten auch flexibler in der Ausgestaltung.

c) Quellsysteme

Auch im Bereich der Quellsysteme treibt die SAP den Ansatz der Vereinfachung voran.

SAP BW∕4HANA bietet flexible Möglichkeiten zur Integration von Daten aus verschiedensten Quellen. Die Daten können aus dem Quellsystemen extrahiert und umgewandelt und in das SAP-BW-System geladen werden. Es ist aber auch möglich, zu Analyse- und Reporting-Zwecken direkt auf die Daten im Quellsystem zuzugreifen, ohne diese im Enterprise Data Warehouse physisch ablegen zu müssen.

sap-bw4hana-simplified-source-systems

  1. SAP-HANA-Quellsystem
    • diese Konnektivität lässt sich für alle anderen Datenbanken nutzen (z. B. Teradata, Sybase IQ, Sybase ASE).
  2. SAP Operational Data Provisioning (ODP)
    • dient als Datendrehscheibe für alle Daten, die über externe Quellen in das BW-System einfließen
    • wird ausschließlich mit SAP Landscape Transformation (SLT), SAP ERP Extractor (SAP Business Suite), HANA Views und SAP BW eingesetzt

Das neue ODP-Konzept mit seiner wesentlich schnelleren Datenextraktion macht die PSA überflüssig.

Mit diesen beiden Verbindungstypen können Daten durch Real-Time-Replikation oder direkten Zugriff im Batch-Modus verfügbar gemacht werden.

Die HANA-Views werden nach Aktivierung der Objekte (z. B. ADSO, Composite Provider) automatisch in der SAP-HANA-Datenbank generiert.

d)  Leistung

Durch den Einsatz von HANA kann die Geschwindigkeit der Datenverarbeitung, wie unter LSA++ schon beschrieben, gesteigert werden. Ging es bei den Datenflüssen noch um eine schlankere Architektur, gibt es natürlich auch handfeste technische Performance-Gewinne:

Neben dem klassischen SAP BW bietet SAP BW/4HANA zudem In-Memory-Data-Warehousing:

  • Keine Aggregate oder Rollup-Prozesse
  • Keine performance-spezifischen Objekte
  • Weniger Indizes
  • Schnelleres Laden und Verarbeiten von Daten
  • Ebenfalls in diese Richtung geht die Möglichkeit Transformationen direkt auf die Datenbank zu verlagern, die SAP spricht hierbei von Push-Down. Diese Leistungssteigerung in SAP BW/4HANA wird durch einen Algorithmus-Pushdown sichergestellt:

sap-bw4hana_algorithm-push-down

Auch auf dieses Thema werden wir in einem der folgenden Artikel im Detail eingehen.

Quellenangabe der Bilder: SAP SE, Inspiricon AG

Autor dieses Beitrags
Roxana Hategan Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
SAP BusinessObjects

SAP BusinessObjects – so wählst du das richtige Client-Tool aus

Stellst Du Dir auch die Frage, welches BusinessObjects Tool Deinen Anforderungen am meisten genügt? In diesem Beitrag möchten wir das Thema grob anreißen und Dir einige Tipps mit auf den Weg geben.

SAP BusinessObjects Front-End Palette

In den letzten Jahren hat SAP ihre BusinessObjects Front-End Palette sehr stark vereinfacht – wie man dem folgenden Schaubild entnehmen kann:

Abb. 1: SAP BusinessObjects Front-End Palette

Die Auswahl des richtigen Werkzeugs ist mittlerweile um einiges einfacher geworden. So gibt es die Wahl zwischen drei Kategorien:

  1. Data Discovery & Applications
  2. Office Integration
  3. Reporting

Diese unterscheiden sich grob anhand der Ausprägung an Interaktivität, Standardisierung und Visualisierung.

Was aber alle drei Kategorien miteinander verbindet, ist die gegebene Interoperabilität, sodass die erstellten Inhalte unter den einzelnen Tools weiterverwendet werden können. Das wären beispielsweise:

  • Lumira 2.0 Discovery Dateien (ehem. Lumira 1.x), welche in Lumira 2.0 Designer (ehem. Design Studio 1.x) mit zusätzlichen Scripts ergänzt werden können.
  • Oder in umgekehrter Reihenfolge die Verwendung von Designer Applikationen in Discovery u.a. für die Erstellung von Story Boards.
  • Das Aufrufen von parametrisierten Crystal Reports oder Web Intelligence Berichten aus den jeweiligen Tools ist weiterhin möglich und findet auch vielfach Verwendung.
  • u.a.

Nichtsdestotrotz fragen sich die Mitarbeiter in den Fachabteilungen und das Management in den Unternehmen, welches Front-End Tool für Ihre Auswertungen und Analysen am besten geeignet ist.

Dabei gibt es insbesondere zwei Situationen, in denen die Frage nach dem richtigen Tool beantwortet werden muss:

  1. Wenn die bisher produktiv eingesetzten Frontend-Tools bestimmte neue Anforderungen nicht mehr abdecken können und deshalb die verbleibenden SAP BusinessObjects-Tools dafür geprüft werden
  2. Wenn in einem Unternehmen SAP BusinessObjects komplett neu eingeführt wird

Werden an dieser Stelle nicht die passenden Tools ausgewählt, kann dies nicht nur zu geringerer Akzeptanz bei den Endnutzern, sondern meist auch zu längeren Implementierungszeiten führen. Der richtigen Toolauswahl fällt somit ein hoher Stellenwert zu.

Phasen der Auswahl

Der Auswahlprozess durchläuft im Idealfall verschiedene Phasen. In folgender Grafiksind diese veranschaulicht:

inspiricon-auswahlphasen-client-tool

Abb. 2: Phasen der Toolauswahl

Grob zusammengefasst:
Es muss zum einen geklärt werden, wer der eigentliche Konsument der Berichte/Applikationen ist. Ein Manager hat meist deutlich andere Anforderungen an Inhalte und Darstellung wie z.B. ein Business Analyst und ist meist mehr an aggregierten, statischen und visuell anspruchsvolleren Daten interessiert. Darüber hinaus hat ein Manager weniger Zeit die Daten im Detail zu analysieren und will Berichte oft vorberechnet und automatisiert mit einer Zusammenfassung erhalten.

Im nächsten Schritt werden verschiedene Use Cases definiert, die für die grundsätzlich unterschiedlichen Anforderungen an den Einsatz der Tools verstanden werden können. Die letzte Phase dient der Bewertung und Beobachtung der Werkzeuge im produktiven Betrieb.

Auswahlmethoden

Die oben genannten Anforderungen werden gesammelt und können anschließend in einen Entscheidungsbaum überführt werden. So ein Entscheidungsbaum könnte beispielsweise wie folgt aussehen:

inspiricon-auswahlmethoden-toolauswahl

Abb. 3: Entscheidungsbaum bei der Toolauswahl

Diese Methode hilft bei wenigen klaren sich gut unterscheidbaren Anforderungen – und bei wenigen Endanwendern. Ist die Anzahl der Nutzer und damit meist die der Nutzeranforderungen deutlich größer und vielfältiger, bietet sich das Verfahren an, mittels geführten standardisierten Nutzerbefragungen (Interviews) den Anforderungskatalog zu erarbeiten. Das könnte folgendermaßen aussehen:

  • Berichte und Analysen sollen im Browser oder Microsoft Office verfügbar sein
  • Nutzer sollen Ad-hoc neue Berechnungen erstellen / hinzufügen können
  • Nutzer sollen mit Hierarchien arbeiten können
  • Nutzer sollen mit Standard SAP BEx-Query Strukturen arbeiten können
  • Berichte und Analysen sollen sowohl online als auch offline genutzt werden können
  • Berichte und Analysen sollen per E-Mail versendet werden können
  • Nutzer sollen die Daten filtern können
  • Nutzer sollen selbst eigene Berichte erstellen oder bestehende anpassen können
  • Navigation innerhalb der Berichte soll möglich sein
  • Drill-Down Funktionalität soll ermöglicht werden
  • Berichte und Analysen sollen hoch formatiert sein
  • Informationen in den Berichten müssen hoch aggregiert sein
  • Berichte und Analysen müssen hohe visuelle Standards erfüllen
  • usw.

Nach der möglichst vollständigen Erfassung aller relevanten Anforderungen, werden diese gegen die Funktionen der unterschiedlichen SAP BusinessObjects-Tools abgeglichen. Dabei werden durch das Tool erfüllbare Anforderungen grün und nicht umsetzbare rot markiert.

Nachfolgend wird dies beispielhaft anhand Crystal Reports verdeutlicht:

  • Berichte und Analysen sollen im Browser oder Microsoft Office verfügbar sein
  • Nutzer sollen Ad-hoc neue Berechnungen erstellen / hinzufügen können
  • Nutzer sollen mit Hierarchien arbeiten können
  • Nutzer sollen mit Standard BEx-Query Strukturen arbeiten können
  • Berichte und Analysen sollen sowohl online als auch offline genutzt werden können
  • Berichte und Analysen sollen per E-Mail versendet werden können
  • Nutzer sollen die Daten filtern können
  • Nutzer sollen selbst eigene Berichte erstellen oder bestehende anpassen können
  • Navigation innerhalb der Berichte soll möglich sein
  • Drill-Down Funktionalität soll ermöglicht werden
  • Berichte und Analysen sollen hoch formatiert sein
  • Informationen in den Berichten müssen hoch aggregiert sein
  • Berichte und Analysen müssen hohe visuelle Standards erfüllen

Nachdem die Anforderungsprüfung für jedes der Tools durchgeführt wurde, kann anschließend das Tool mit den meisten grün markierten Anforderungen bestimmt werden.

Ein derartiger Anforderungskatalog kann noch weiter beliebig komplex z.B. pro Abteilung oder Nutzerkreis  verfeinert werden, sodass am Ende für jede spezifische Zielgruppe innerhalb des Unternehmens die passendsten Tools zur Verfügung stehen.

Oft wird dieses Verfahren – bei umfangreicherem Einsatz – in Form einer Funktionsmatrix (z.B. in MS Excel) abgebildet. Das schafft zu Beginn höhere Aufwände bei der Erstellung, stellt aber bei häufiger Verwendung ein standardisiertes und probates Mittel dar, mit hoher Wahrscheinlichkeit das richtige Tool auszuwählen, das die meisten Anforderungen abdeckt.

Fazit

Ungeachtet dessen, für welche Auswahlmethode man sich entscheidet, wird es am Ende selten eine 100%ige Übereinstimmung mit allen Anforderungen geben – die „eierlegende Wollmilchsau“ wird sich am Ende auch hier nicht finden. Ein guter Mix aus den verschiedenen SAP BusinessObjects-Tools ist auch durchaus wünschenswert, um auch die Stärken der einzelnen Tools bestmöglich auszuschöpfen.

Die vorgestellten Methoden dienen als beispielhafte Denkanstöße und sind nur grobe Verfahrensweisen. Im Detail kann eine kundenindividuelle detaillierte Analyse und Gegenüberstellung der Anforderungen in hohem Maße zur richtigen Auswahl des Tools führen.

Bist Du interessiert an einer Vertiefung des Themas oder benötigst Du eine individuelle Analyse, dann kontaktiere uns. Wir werden Dich gerne dabei unterstützen.

Autor dieses Beitrags
Artur Witzke Senior Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Wer braucht schon SAP Vora?!

Wer braucht schon SAP Vora?!

Für was benötige ich überhaupt SAP Vora?

SAP Vora bietet die Möglichkeit, strukturierte und semi-strukturierte Daten innerhalb eines existierenden Hadoop-Clusters über eine moderne Oberfläche auszuwerten und diese untereinander sowie mit Daten aus SAP HANA zu kombinieren.

Es handelt sich hierbei technisch gesehen um eine Erweiterung des Apache Spark Execution Framework, das sich schon seit Längerem in der Hadoop-Welt etabliert hat.

SAP Vora realisiert somit eine verteilte In-Memory Abfrage-Engine für strukturierte und semi-strukturierte Daten in einem Hadoop-Cluster.

Wie kann ich SAP Vora nutzen?

Es gibt mehrere Optionen, wie ihr SAP Vora einsetzen könnt; natürlich empfiehlt SAP bevorzugt die Nutzung in der Cloud – entsprechend der eigenen Cloud-Strategie:

On-Premise:

Cloud-basiert:

  • Nutzung der für SAP Partner kostenfreien Developer Edition über Amazon Web Services (AWS) oder SAP Cloud Appliance Library (SAP CAL)
  • Nutzung der kostenpflichtigen Production Edition über AWS
  • Als Service über SAP Big Data Services
  • Über das Bring Your Own License (BYOL) -Modell (SAP Cloud Platform, AWS)

Die SAP Vora Developer Edition über AWS verfügt über die volle Funktionalität und mit ein paar wenigen Klicks wird die Umgebung entsprechend den vorher für die eigenen Bedürfnisse ermittelten Parametern konfiguriert.

Der zugrundeliegende vorhandene Hadoop-Cluster ist eine Hortonworks-Distribution (HDP) mit den entsprechenden Tools/Software wie Spark, Ambari, Zeppelin, usw. und verfügt über maximal 4 Knoten.

Die von SAP über die SAP Cloud Appliance Library (CAL) angebotene Variante kommt in Form einer vorkonfigurierten Appliance daher mit sehr ähnlicher Funktionalität wie die bei der AWS. Sie macht vor allem dann Sinn, wenn man bereits SAP CAL nutzt.

Die produktive Edition unterscheidet sich nur in der nach oben möglichen Skalierbarkeit des Clusters und natürlich durch die Kosten.

Wie funktioniert SAP Vora?

Nach der Entscheidung für ein Deployment-Modell (On-Premise oder Cloud) geht es – je nach Wahl – an die Installation und Konfiguration.

Die Installation erfolgt in drei Schritten:

  1. Festlegung der benötigten Anzahl Knoten für Vora im Hadoop-Cluster in Abhängigkeit von
    • Anforderungen an die Verfügbarkeit
    • Anforderungen an das Sizing (CPU, Disk vs. RAM, Control Nodes vs. Compute Nodes, unterschiedliches Sizing für jede spezifische Spark-Engine, usw.)
    • Erwartetes Datenwachstum
  2. Deployment des SAP Vora Manager Services auf den benötigten Cluster-Knoten
  3. Konfigurieren und Starten der SAP Vora Services auf den Cluster-Knoten mit Hilfe des SAP Vora Manager User Interfaces

Nach erfolgreicher Installation und Konfiguration in einem Hadoop-Cluster (Distributionen HDP, Cloudera und MapR werden unterstützt) könnt ihr SAP Vora nutzen. Neben dem bereits oben erwähnten SAP Vora Manager für eher administrative Aufgaben, stehen die sogenannten SAP Vora Tools als die zentrale GUI für den Endanwender zur Verfügung.

Folgende Tools werden in der GUI angeboten:

  • Data Browser: Inhalte von Tabellen und Views anschauen
  • SQL Editor: SQL-Statements erstellen und ausführen
  • Modeler: Tabellen und Views erstellen und ändern
  • User Management: Anwender-Konten und Zugriffe auf die SAP Vora Tools managen

Mit Hilfe der SAP Vora Tools kann der Endanwender die im Hadoop-Cluster befindlichen Daten, die sich in Struktur und Datentyp unterscheiden, auswerten. Nachfolgend sind die Auswertungsmöglichkeiten detaillierter beschrieben.

Was kann ich mit SAP Vora auswerten?

Mit Vora habt ihr die Möglichkeit JSON-Dokumente auszuwerten, Zeitreihen- und Graphen-Analysen durchzuführen sowie via SQL auch klassisch relational strukturierte Daten zu analysieren.

Dabei nutzt Vora für jede Art der unterschiedlichen Analysen eine spezifische Spark-Engine mit entsprechender Optimierung in der Verarbeitung.

Der „Doc Store“ – NoSQL-Analysen von semi-strukturierten JSON-Dokumenten

Mit der Version 1.3 hat SAP den sogenannten „Doc Store“ eingeführt, mit dem veränderte Dokumente als schemalose Tabellen gespeichert werden können und somit eine horizontale Skalierung (scale-out) und eine flexible Handhabung bei den Dokument-Feldern (Löschen, Hinzufügen) ermöglicht wird.

Nachdem ihr in Vora einen Document Store (=Collection) auf Basis von im Cluster existierenden JSON-Dokumenten erstellt habt, wird darauf basierend ein View erstellt, den man auch mit den bekannten JSON-Expressions erweitern kann. Dieser wird dann im Vora-eigenen Doc Store gespeichert und kann im Tabellen- als auch JSON-Format bearbeitet werden.

Zeitreihenanalyse – Ausnutzung effizienter Kompression und Daten-Verteilung

Die Spark-Engine, die für die Zeitreihenanalyse zur Verfügung steht, kann ihre Stärken vor allem dann ausspielen, wenn die zugrundeliegenden Daten über möglichst viele Cluster-Knoten verteilt sind und effizient komprimiert werden können.

Auf Basis von im Cluster vorliegenden Zeitreihen-Daten wird innerhalb Vora eine „Zeitreihen-Tabelle“ erstellt, für die es eine eindeutige Spalte mit Zeitperioden (=Range Type) geben muss. Neben weiteren Optionen können Eigenschaften zur Äquidistanz und zusätzliche Komprimierungs-Parameter eingeben werden.

Um Zeitreihendaten auswerten zu können, müsst ihr noch eine View erstellen, den man mit spezifischen Table Functions (z.B. Cross/Auto Correlation) erweitern kann.

Es lassen sich dann für Zeitreihen entsprechende Analysen wie Regression, Binning, Sampling, Similarity, usw. durchführen.

Real-time Graphen-Analyse – Auswertung sehr großer Graphen

Vora verfügt über eine eigene In-Memory Graphen-Datenbank, die insbesondere die Analyse großer Graphen in real-time unterstützt. Die Modellierung der Graphen im grafischen Metadaten-Viewer wird entsprechend durch einen Pfad-Expression-Editor unterstützt.

Die Abfragen auf die Graphen dürfen durchaus – aufgrund der In-Memory-Engine – sehr komplex werden und die Visualisierung der Graphen zeigt sich State-of-the-Art.

Die Engine für die Graphen-Analyse bietet sich insbesondere im Bereich des Supply Chain Managements an oder zur Darstellung von umfangreichen Organisations- oder Projekt-Hierarchien oder Geschäfts-Netzwerken.

Relational Engine – Verwendung von SQL zur Auswertung von Relationen

Nicht zuletzt bietet Vora auch die Möglichkeit mit Hilfe von SQL strukturierte Daten im Cluster in Form von relationalen spaltenbasierten Tabellen abzubilden und abzufragen. Dabei werden auch hier die Daten im Memory komprimiert.

Für relationale Daten, die nicht im Arbeitsspeicher liegen müssen, bietet Vora die Disk Engine an. Diese legt die Daten in einer Datei auf dem lokalen Knoten ab, auf dem die Engine läuft. Analog dem Dynamic Tiering bei HANA, können auch hier die spaltenbasierten relationalen Disk- mit den In-Memory-Tabellen problemlos gejoint werden.

Auch noch erwähnenswert

  • SAP HANA-Tabellen können in Vora – nach erfolgter Registrierung im Repository – zusammen mit den dort erstellen Views und Tabellen zusammen verwendet werden. Von Vora aus können Daten auch in SAP HANA geschrieben werden.
  • Erstellung von Level- und Parent-Child-Hierarchien und gemeinsame Verwendung mit Fakten-Tabellen wird unterstützt.
  • Währungsumrechnung (Standard oder ERP) kann in Tabellen und Views verwendet werden.
  • Für jede Engine respektive für die in Vora erstellten spezifischen Datenstrukturen gibt es spezielle Funktionen und Typen für die Partitionierung, mit denen diese im Cluster optimal verteilt bzw. partitioniert werden (Hash, Block, Range).

Welche Datenquellen und -formate werden aktuell unterstützt?

Mit SAP Vora Tools können folgende Dateien in Vora verarbeitet werden:

  • .CSV
  • .ORC
  • .PARQUET
  • .JSON
  • .JSG

Neben dem Standard-Datentyp HDFS sowie den Typen ORC und PARQUET (Option (format „orc“ / format „parquet“)) können folgende weitere im „Create Table“-Statement in Vora geladen werden:

  • Amazon S3 (Option (storagebackend „s3“))
  • Swift Object (Option (storagebackend „swift“))

Fazit und Ausblick

SAP Vora spielt seine Stärken natürlich insbesondere im Zusammenhang mit SAP HANA aus: so kann man relationale Daten aus HANA mit semi-strukturierten Daten aus dem Hadoop-Cluster zusammen auswerten. Des Weiteren findet ihr in Vora verschiedene Auswertungs-Möglichkeiten (Graphen, Dokumente, usw.) in einem Tool vereint, die man sonst in jeweils verschiedenen Tools (oder nur mit verschiedenen Datenbanken) der Hadoop-Distributoren oder Drittanbietern findet.

Zukünftig plant SAP für Vora für alle Engines das Transaktionskonzept (ACID) zu unterstützen, um eine konsistente Datenhaltung zu verbessern. Für dieses Jahr 2018 ist ein erster Support für Insert-/Update-/Delete-Statements geplant. Vorgesehen ist darüber hinaus auch die Unterstützung für SQL-Pass-thru von SAP HANA zu SAP Vora.

Für Freunde des SAP BW noch interessant: über 2018 hinaus ist die Unterstützung von DSOs geplant.

Wenn ihr SAP Partner seid, könnt ihr einfach mit der kostenfreien Developer Edition starten, um in die Materie einzusteigen – dort könnt ihr euch in Ruhe mit der Konfiguration und der Nutzung vertraut machen.

Oder fragt uns – wir helfen gerne!

Autor dieses Beitrags
Andreas Keller Associate Partner
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de

So gelingt der Einstieg in den Query Designer in Eclipse

Es freut uns sehr, dass wir euch heute unseren ersten Gastautor vorstellen dürfen: Jürgen Noe. Er ist Geschäftsführer der Jürgen Noe Consulting UG (haftungsbeschränkt) in Mannheim. Jürgen ist Autor verschiedender Bücher aus der SAP-Welt. Sein Artikel – so wie sein neues Buch – dreht sich um den Query Designer in Eclipse. Vielen Dank nochmals an ihn und euch viel Spaß bei der Lektüre!

 

Mit der Einführung von SAP BW 7.4 kam neben der HANA Unterstützung auch eine stille Revolution in der Oberfläche hinzu. War bis zu diesem SAP BW Release die SAP GUI die einzige unterstützte Softwareentwicklungsumgebung (SEU), setzte das Hasso-Plattner-Institut bei der Entwicklung der HANA Datenbank von vornherein auf Eclipse als SEU. Damit sind jetzt zwei Entwicklungsumgebungen für Entwickler von SAP Applikationen relevant. So ist zum Beispiel für die Entwicklung der HANA Datenbankobjekte das HANA Studio relevant. Für klassische ABAP-Applikationen war weiterhin die SAP GUI notwendig.

Doch SAP hielt eine weitere Überraschung parat: Neben der reinen Unterstützung der HANA Plattform kamen mit der Zeit weitere Tools für die Entwicklung und das Customizing von Applikation auf HANA in Eclipse hinzu.

Ein Tool hieraus sind die sogenannten BW Modelling Tools, kurz auch BW-MT. Diese erlauben es, das typische BW Customizing komplett in Eclipse zu vollziehen. Das Anlegen von InfoProvidern, des kompletten Extraktions-Transformation-Lade-Prozesses (ETL) ist komplett in den BW-MT möglich.

Damit war es nur logisch, das zentrale Tool zum Anlegen von BW Queries ebenfalls in den Modelling Tools nachzubauen. Mit den neueren Releases von SAP BW ab Version 7.4 aufwärts, wird der gute alte Query Designer als Stand-Alone-Applikation im Rahmen der Business Explorer- Suite (BEx) damit obsolet.

Schnelleinstieg in den Query Designer in Eclipse

Vor diesem Hintergrund habe ich die neuen Funktionalitäten des Query Designers in Eclipse daher in dem Buch „Schnelleinstieg in den Query Designer in Eclipse“, erschienen im September 2017 im Verlag Espresso Tutorials, beschrieben.

Query Designer Cover

 

Den Link zum Buch findet ihr hier:

Das Buch möchte ich euch in den nächsten Abschnitten kurz vorstellen:

Das Buch beginnt mit allgemeinen Grundlagen über SAP BW und Eclipse im Allgemeinen. Im Abschnitt zu Eclipse erkläre ich kurz den Aufbau von Eclipse sowie zentrale Begriffe wie Plug-In, View und Perspektiven. Erfahrene Eclipse-Anwender können dies Kapitel auch überspringen.

Im dritten Kapitel erfolgt eine Kurzübersicht zu den BW Modelling Tools. Hier erkläre ich, wie ihr klassische Transaktionen, wie die Data Warehouse Workbench in Eclipse aufrufen, wie ihr einen Datenfluss anlegt und gehe auf zentrale Views ein, wie die Project Explorer- und die InfoProvider-View.

Da der Project Explorer in Eclipse von zentraler Bedeutung ist, zeige ich detailliert, wie ihr ein neues Projekt anlegt und damit arbeitet. Anschließend erkläre ich, wie ihr im Project Explorer in die InfoProvider-View, die in der folgenden Abbildung 1 dargestellt ist, navigieren könnt:

Infoprovider view

Abbildung.0.1 Infoprovider View

In dieser View könnt ihr globale, wiederverwendbare Objekte, wie eingeschränkte und berechnete Kennzahlen, Strukturen, Filter, aber auch Variablen anlegen. Diese sind unterhalb des Ordners Reusable Components in Abbildung 1 zu finden.

Wie genau die einzelnen wiederverwendbaren Elemente anzulegen sind, welche Einstellungen es gibt und wie sich diese auswirken, beschreibe ich im Detail im Kapitel 4 des Buches mit zahlreichen Screenshots. Die Möglichkeit der zentralen Anlage von wiederverwendbaren Komponenten ist für mich ein Grund, warum sich der Umstieg von der  alten BEX Version auf den neuen Query Designer in Eclipse lohnt. Vorbei sind die Zeiten, in denen Sie sich mühsam durch mehrere Fenster im BEx-Query-Designer klicken mussten, um zum Beispiel eine Formelvariable anzulegen. Die Navigation und Benutzerfreundlichkeit wurde aus meiner Sicht hier entscheidend verbessert.

Auch in einem zweiten Punkt stellen die BW-MT ihre volle Stärke dar: Nie war es so einfach, von einem Objekt zu einem anderen abspringen, es zu ändern und die Änderung sofort im Ausgangsobjekt zu sehen. Ein konkretes Beispiel: Ihr stellt fest, dass ihr eine weitere Kennzahl in der Query benötigt. In der alten Welt musstet ihr diese erst in der DataWarehouse Workbench (DWB) anlegen, im MultiProvider ergänzen und zuordnen, den Query Designer neu starten, damit er die Änderung mitbekam und dann konnte man die Kennzahl in die Query einfügen. Dieses lästige Hin-und Herspringen zwischen verschieden Tools und Transkationen entfällt komplett. Mit den BW-MT wechseln in Eclipse lediglich die Views! Ihr wechselt von der  Query Designer View zur Stammdaten-View, legt dort die Kennzahl an, fügt sie eurem Datenmodell im Multiprovider in der InfoProvider-View hinzu, speichert diese ab und wechselt zurück in die Query Designer View.

Alles parallel in einem Tool, in mehreren Fenstern nebeneinander!

Sofort ist die Änderung am MutliProvider in Eclipse sichtbar. Falls nicht, kurz auffrischen und schon ist die neue Kennzahl auch in der Query verfügbar. So einfach war es noch nie!

Die Queryeigenschaften im Detail

Jetzt fragt ihr euch bestimmt schon, wie sieht die View des Query Designers aus, mit der man Queries erstellen, ändern und löschen kann? Schauen wir dazu auf die folgende Abbildung 2:

Query Definition

Abbildung.0.2 Querydefinition (Filter)

Wie ihr seht, ist die Querydefinition über mehrere Reitere verteilt. Im Reiter Allgemeines (General) stellt man allgemeine Queryeigenschaften ein, wie Anzeigen wiederholender Schlüsselwerte und vieles mehr.

In Abbildung 2 seht ihr die Definition eines Queryfilters. Wie im BEx-Query Designer bleibt die prinzipielle Querystruktur mit Spalten Zeilen und freien Merkmalen erhalten. Diese Struktur definiert ihr im Reiter Sheet Definition. Gearbeitet wird prinzipiell mit dem Kontextmenü, über das ihr alle wichtigen Funktionen in der jeweiligen View erreicht.

Über den Reiter Conditions legt man Bedingungen an, wie etwa zeige mir alle Datensätze mit einem Umsatz größer 1 Mio. Euro.

In den Exceptions definiert man Ausnahmen. Ausnahmen erlauben es, Zeilen, Spalten oder auch nur einzelne Zellen farbig zu markieren und damit auf Ausreißer oder besondere Zustände hinzuweisen.

Gelungen finde ich den Reiter Dependency Structure, der aufzeigt, in welchen anderen Queries die verwendeten Variablen dieser Query noch verwendet werden.

Im Reiter Runtime Properties stellt ihr die Performance-Eigenschaften der Query ein, wie etwa Nutzen des Delta-Caches und viele weitere Eigenschaften, die wir aus der RSRT bereits kennen.

Was man genau in jedem einzelnen Reitern einstellen kann und wie sich diese Einstellungen auswirken, zeige ich anhand vieler Screenshots und Beispielen im Kapitel 5 des Buches.

Und wie sieht das Queryergebnis aus?

Nachdem ihr eure Query erstellt haben, möchtet ihr sie auch testen und ausführen. Mit den BW-MT erfolgt die Ausgabe des Queryergebnisses in einer eigenen View, hierzu Abbildung 3:

Queryergebnis

Abbildung.0.3: View für Queryergebnis

Ihr könnt im Queryergebnis frei navigieren, Filter setzen, Aufrisse hinzufügen, entfernen, so wie ihr es kennt. Auch hier findet ihr alles komplett in dieser View wieder, es ist kein installierter JAVA-Server für eine Webausgabe oder ein Wechsel zum BEX-Analyzer für eine Ausgabe in Excel mehr nötig!

Bei komplizierteren Queries benötigt ihr eventuell zwei Strukturen:
Im alten BEx Query Designer musstet ihr mit dem Zelleditor arbeiten. Im neuen Query Designer in Eclipse ist der Zelleditor rundum erneuert worden und verfügt nun über nützliche Funktionen wie Copy & Paste. Des Weiteren finden auch keine lästigen Roundtrips zum Server mehr statt, um die Eingabe zu prüfen, was das Arbeiten mit dem Zelleditor deutlich beschleunigt. Schaut euch den neuen Zelleditor auf Abbildung 4 an:

Zelleditor

Abbildung 0.4 Zelleditor

Zu guter Letzt: die Variablen

Was jetzt noch fehlt sind Variablen, die euch Dynamik in den Queries erlauben. Im sechsten Kapitel widme ich mich den Variablen und zeige, wie alle typischen Variablen anhand von Screenshots und mit einfachen Beispielen angelegt werden können.

Die Vorteile des neuen Query Designers in Eclipse:

  • Moderne, benutzerfreundliche und zukunftsfähige Oberfläche
  • Alle bestehende Funktionen des BEX Query Designer sind im neuen Query Designer in Eclipse enthalten
  • Nahtlose Integration der BW-Datenmodellierung in einem Tool

Als Fazit kann ich euch den Query Designer in Eclipse samt den BW-MT nur ans Herz legen. Das Erstellen und  Testen von ganzen BW Datenmodellen und Queries war noch nie so einfach. Damit stellt der Query Designer im Eclipse für mich einen wichtigen Schritt in die Zukunft dar!

Autor dieses Beitrags
Jürgen Noe Geschäftsführer der Jürgen Noe Consulting UG (haftungsbeschränkt)
Tel.: +49 (0) 621 72963337
E-Mail: juergen.noe@juergen-noe-consulting.de
5 Stufen einer erfolgreichen Test-Strategie bei BI-Implementierungen

Die fünf wesentlichen Stufen einer erfolgreichen Teststrategie für SAP-BI-Implementierungen

Wie wichtig sind Tests in SAP BI überhaupt?

Es wird den ein oder anderen geben, der die drei goldenen Regeln für erfolgreiche SAP-BI-Projekte noch nicht kennt. Sie lauten:

„Testen, testen und dann noch einmal testen!

Und jetzt mal ganz im Ernst: Eine erfolgreiche Teststrategie für jede SAP-BI-Implementierung umfasst genau genommen sogar fünf ganz wesentliche Schritte. Diese lassen sich wie folgt zusammenfassen:

  1. Unit Test
  2. Funktionstests
  3. Datenmigrations- und Integrationstests
  4. Performancetests
  5. User-Acceptance-Tests (UAT) & abschließende Freigabe

„Wenn Sie meinen, dass Tests zu teuer sind, sollten Sie sich darüber bewusst sein, was ein Auslassen dieser Tests kostet!“

Man hört diese Frage förmlich schon: „Was kosten mich denn diese ganzen Tests?!“

Es gibt immer wieder Kunden, die die Kosten für die erforderlichen Tests einer SAP-BI-Implementierung scheuen. Vielleicht verweisen sie darauf, dass die „Qualität“ eigentlich inbegriffen sein sollte – vorausgesetzt, das BI-Team hat bei der Entwicklung aller Berichtsobjekte gründlich gearbeitet.
Vielleicht wehren sie sich gegen eine Bereitstellung ihrer knappen Mittel für Testmaßnahmen und geben das Geld lieber für weitere Entwicklungen vor dem Go-live aus.
Und vielleicht stehen sie auch selbst unter Druck das „Maximum“ aus dem BI-Projektteam herauszuholen, solange es noch vor Ort ist – und all das sollte möglichst im festgelegten Projektumfang aus Zeit, Budget und Qualität liegen.

Und trotz all dieser Widerstände, die auf den ersten Blick für geringere Investitionen in Testläufe sprechen, zeichnet die Erfahrung aus SAP-BI-Projekten ein gegenteiliges Bild. Natürlich bedeutet die Entscheidung für gründlichere Tests auch erheblichen Mehraufwand, den es im Projektzeitplan frühzeitig zu berücksichtigen gilt – letztendlich können so aber in aller Regel auch die Gesamtkosten der Implementierung gesenkt werden.

Untersuchungen haben gezeigt, dass die tatsächlichen Kosten von Softwarefehlern abhängig vom Zeitpunkt ihrer Entdeckung exponentiell steigen können.

So gibt es zum Beispiel die 1-10-100-Regel:
Ein Fehler, der in der Entwicklungs- und anfänglichen Programmierungsphase noch 1 Euro kostet, kann während der Akzeptanztests schon 10 Euro und nach dem Go-live sage und schreibe 100 Euro kosten!

Unsere langjährige Erfahrung in BI-Projekten hat uns immer wieder gezeigt, dass Kosten gespart werden können, wenn Bugs bereits in den anfänglichen Testphasen entdeckt und behoben werden – je früher man also mit den Testläufen beginnt und je mehr Geld vorab in diese Tests investiert wird, desto mehr kann bei den Projektkosten sowohl kurz- als auch langfristig eingespart werden.

So mancher BI-Projektmanager schätzt das mögliche Einsparpotential auf das Zwei- bis Dreifache der Kosten! Und wenn sich die Projektverantwortlichen so noch nicht vom Wert zusätzlicher Tests überzeugen lassen, gilt es auch nicht zu vergessen, dass ebenso die Aufwände und der Druck direkt vor dem Go-live ganz erheblich reduziert werden können – ganz zu schweigen davon, dass so auch die Fachabteilungen beruhigt werden können –, wenn die anfängliche Konzentration auf die Tests allmählich Wirkung zeigt. Spätestens dann zeigt sich, dass sich diese Investition in die Qualität mehr als lohnen.

Testen oder Nichttesten, das ist hier (nicht) die Frage …

Da wir uns jetzt einig sind, dass Tests ein wesentlicher Bestandteil eines jeden SAP-BI-Projekts sind, stellen sich natürlich weitere Fragen:
Was genau muss wann, wie und wie oft getestet werden?

Grundsätzlich gilt: Je mehr man testet, desto geringer fallen die Gesamtentwicklungskosten aus.

Geht man beim Testen dann noch strukturiert vor, eröffnen sich weitere Vorteile. Hält man die Testergebnisse zum Beispiel fest und setzt sie in unmittelbaren Nutzen um, wird mit jeder Wiederholung von Testdurchläufen und Testphasen die Qualität des Endprodukts (eure BI-Berichte) gesteigert. Auf diese Weise stoßt ihr einen Prozess kontinuierlicher Verbesserung in eurem BI-Projekt an, der eurem SAP-BI-System auch lange nach Abschluss des ursprünglichen Implementierungsprojektes noch zugutekommt.

Was genau umfassen SAP-BI-Tests eigentlich – was gehört dazu?

Testläufe sind genau genommen regelmäßige „Qualitätsprüfungen“, also eine Gelegenheit, die Qualität einer Implementierung an festgelegten Punkten im Projektzeitplan und unter Berücksichtigung verschiedener Aspekte zu messen. Dabei sollte jeder Test durch Nachverfolgung und Dokumentation sowohl der SAP-BI-Testfälle als auch der Mängel in einem geeigneten Testtool unterstützt werden.
„HPQC” – HP ALM Quality Center ist ein häufig genutztes Testtool, aber natürlich gibt auch viele weitere Tools am Markt.

Wir bei Inspiricon wissen, dass jede Kundensituation einzigartig ist. Es gibt keine „Standardvorgehensweise“, die sich auf jedes beliebige Szenario anwenden lässt. Es gibt jedoch ein bewährtes Framework, das zur Strukturierung der Testaktivitäten eingesetzt werden kann. In unseren SAP-BI-Projekten konzentrieren wir unsere umfassenden Erfahrungen und unser Fachwissen aus vorausgegangenen Projekten, um auf die spezifischen Herausforderungen eingehen zu können. Darüber hinaus erarbeiten wir eine individualisierte Teststrategie und einen Testplan, um maximale Qualität für eure SAP-BI-Implementierung sicherzustellen und die Gesamtkosten möglichst gering zu halten.

Die folgenden Testaktivitäten haben nicht den Anspruch vollständig zu sein oder eine Standardvorgehensweise abzubilden. Sie dienen lediglich als Beispiel für einige der wichtigsten Qualitätsprüfungen, die im Rahmen unserer fünf wesentlichen Stufen von SAP-BI-Testläufen erfolgen können:

1. Unit Tests:

Gute Modultests liefern die Grundlage für alle weiteren Schritte. Diese ersten Tests umfassen eine gründliche Prüfung der Gestaltungsarbeit, gefolgt von einer schrittweisen Dokumentation der Daten auf ihrem Weg durch die verschiedenen Schichten eurer BI-Architektur, sowohl im persistenten als auch im nicht-persistenten Status.
Je größer die Zahl der erkannten und (einfacher) behobenen Bugs zu diesem Testzeitpunkt ausfällt, je größer sind die Einsparungen insgesamt!

  • Dokumentation und Freigabe der technischen Daten (dies kann zum Beispiel eine Beschreibung der Berichtsgestaltung und der Datenflüsse in Word, eine visuelle Übersicht in PowerPoint und eine Excel-Tabelle mit umfassenden Mappings des Datenmodells umfassen)
  • Treffen der Fachabteilung zur Freigabe der Berichtslayouts und -köpfe (schon bevor die Testdaten verfügbar sind)
  • Interne Tests durch den BI-Entwickler, einschließlich gründlicher Prüfung der Daten in jeder Stufe des Datenflusses und eines direkten Vergleiches der Quellsystemdaten, der SAP-BW-Daten und der Daten im endgültigen BI-Bericht

Wenn Du mehr über Codetests erfahren möchten, lese unsere Blog-Serie über das ABAP Unit Test Framework in Eclipse. Der erste theoretische Teil bietet Dir das notwendige Know-how, um Unit Test Cases für Deinen Code zu erstellen. Im zweiten Teil werden wir Dir das genaue Vorgehen dann in einem praktischen Beispiel demonstrieren.

2. Funktionstests:

Um die Funktion effektiv testen zu können, muss im Team das notwendige Fachwissen nicht nur bezüglich der fachlichen Anforderungen und der Prozesse im ERP-Quellsystem vorliegen, sondern auch in Hinblick auf das Datenmodell, die Datenflüsse, die Berichtsgestaltung in SAP BI und die Möglichkeiten, diese beiden Welten zu „überbrücken“ bzw. zu vereinen.

  • Tests zur Sicherung der Qualität (QA), vor allem durch interne BI-Projektverantwortliche mit eingehenden Kenntnissen des vorherigen Berichtssystems und der zugrunde liegenden Geschäftsprozesse
  • Dokumentation der Testfälle in Testsoftware wie zum Beispiel HPQC
  • Pre-UAT-Tests (Pre-User Acceptance Testing) auf Fachseite, einschließlich Mängelbehebung und erneuter Tests, umfassender Dokumentation und Nachverfolgung im Testtool, z. B. HPQC
  • Interne Tests durch das BI-Team, koordiniert durch die Entwicklungsleiter und Dokumentation in einer zentralen Statusliste bzw. einem „Katalog“ aller BI-Berichte

3. Datenmigrations- und Integrationstests:

An diesem Punkt erfolgt die Überprüfung der Datenmigration und der reibungslosen Integration mit dem/den Quellsystem(en). Datenflüsse, einschließlich InfoPackages, DTPs, Transformationen und letztendlich der Prozessketten, die das vollständige tägliche Laden der Daten automatisieren, müssen koordiniert und auf Vollständigkeit, Richtigkeit, korrekte Fehlerbehandlung und Stabilität geprüft werden. Und selbstverständlich müssen alle BI-Objekte, die ins Produktivsystem transportiert werden, vor dem Go-live geprüft werden!

  • Prüfung der Datenmigrationen
  • Prüfung vollständige Datenübernahme gegenüber Delta-Datenübernahme
  • Optimierung und Test der täglichen und periodischen Prozessketten
  • Konfiguration und Test der Meta-Ketten
  • Aktivierung und Prüfung der automatisierten BW-“Housekeeping“-/Bereinigungsaufgaben
  • Prüfung der transportierten BI-Objekte im Produktivsystem vor dem Go-live

4. Performancetests:

An dieser Stelle erfolgt eine gründliche Prüfung der Performance der Systemarchitektur sowie des System-Sizings. Die Aktualisierungszeiten und akzeptablen Performancewerte werden anhand der Anforderungen auf fachlicher Seite festgelegt, üblicherweise werden dabei als Vergleichswert die Performance-Benchmarks der vorausgegangenen Berichtssysteme zu Grunde gelegt.

Automatisierte Performance-Tests durch Drittanbieter-Software wie LoadRunner. Dabei werden unter anderem die folgenden Aspekte berücksichtigt:

  • Lastspitzen durch gleichzeitige Benutzer
  • Anfängliche Ladezeiten für Berichtsstruktur und Eingabeaufforderungen
  • Aktualisierungszeiten für Berichte mit Daten
  • Maximale durch Berichtsabfragen zurückgegebene Datenmengen
  • Speichervolumen für gespeicherte Berichte und Zeitpläne

5. User-Acceptance-Tests (UAT) und abschließende Freigabe:

Hier wird es erst richtig interessant, denn hier haben die Endanwender als eigentliche „Empfänger“ unseres finalen Produkts endlich auch Gelegenheit, ihre Berichte zu testen! Sie können die Qualität der Berichtergebnisse durch Durchführung von Testfällen für Daten- und Plausibilitätsprüfungen prüfen. Darüber hinaus können sie mögliche Mängel und Erweiterungen im Testtool protokollieren und erfolgte Fehlerbehebungen erneut prüfen. Bei der endgültigen Freigabe eines Berichts auf der Fachseite haben immer die Endanwender das letzte Wort.

  • Datenprüfung im UAT auf Fachseite, einschließlich einer weiteren Runde an Fehlerbehebungen und erneuter Tests
  • Plausibilitätsprüfung im UAT auf Fachseite zum Abgleich der ursprünglichen Berichte mit den migrierten/replizierten SAP-BI-Berichten in Hinblick auf Zweck, verfügbare Spalten und ungefähre Ergebnisse. Dies kann trotz der zunehmenden Unterschiede zwischen den beiden Datenbestände nützlich sein: „laufende“ Live-Daten aus dem Quellsystem gegenüber dem „Snapshot“ der ursprünglich migrierten Daten und den gesammelten Daten aus den Akzeptanztests.
  • Weitere Tests nach Abschluss des UAT und Validierung durch größer angelegte Testgruppen mit umfangreicherem Datenmaterial, so zum Beispiel mit zusätzlichen migrierten Daten und weiteren gesammelten Testdaten.
  • Finale Freigabe auf Fachseite durch „bestandene“ Testfälle im Testtool, z. B. HPQC.

Es soll noch einmal betont werden, dass es sich hierbei lediglich um einige Beispiele empfohlener Schritte in einer umfassenden Teststrategie für BI-Implementierungen handelt und dass diese in keiner Weise eine Standardherangehensweise darstellen sollen. Jedes Implementierungsprojekt ist einzigartig und es sollte daher auch für jeden Kunden eine eigene Teststrategie und ein eigener Plan entwickelt werden, der den spezifischen Anforderungen und SAP-BI-Szenarien gerecht wird.

Qualität ist Trumpf!

Zusammengefasst ist eine umfassende Teststrategie unterstützt durch wirksame Strukturierung, Nachverfolgung und Dokumentation in einem geeigneten Testtool die beste Investition zur Sicherstellung eines reibungslosen Go-lives für Endanwender und eines zukunftssicheren BI-Systems mit nachhaltig hoher Qualität!

Je mehr Zeit und Geld ihr von Anfang an für Testzwecke investieren, desto weniger Probleme werden auch beim Go-live auftreten – und desto geringer werden auch die Gesamtkosten für das SAP-BI-Projekt ausfallen!

Ihr benötigt Unterstützung bei der Entwicklung einer eigenen Teststrategie für SAP BI? Dann ruft mich heute noch an oder schreibt mir eine E-Mail!

Autor dieses Beitrags
Andrea Taylor Senior Consultant SAP BI
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de