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
Active Directory Implementatierung für SAP Fiori

Active Directory Implementierung für SAP Fiori

Hallo und herzlich willkommen zum vierten Teil der Tutorialreihe „SAP Fiori Customization Samples“.  In diesem Video werden wir zeigen, wie man eine benutzerdefinierte Fiori-Kachel für das Fiori Launchpad erstellen kann.

Diese Kachel werden verwendet für die intuitive Anzeige dynamischer Daten, um Informationen auf einen Blick zu liefern, sobald man das Fiori Launchpad öffnet.  Dies ist das erste Video eines zweiteiligen Tutorials und konzentriert sich auf den strukturellen Teil des Prozesses.

Wir werfen zunächst einen kurzen Blick auf die Schritte, denen wir als nächstes folgen werden.

Voraussetzungen

Zuerst werden wir bestimmte Dateien aus dem SAPUI5-Framework sammeln, die uns als Grundlage für die benutzerdefinierte Kachel dienen werden.

Der zweite Schritt besteht darin, die Dateien so anzupassen, dass sie dem gewünschten Ergebnis entsprechen. Anschließend registrieren wir die Application als CHIP und nehmen sie in die Fiori Launchpad Designer-Komponente auf. Gegen Ende dieses Videos werden wir versuchen, die neue Kachel dem Launchpad hinzuzufügen.

Für dieses Tutorial gehen wir davon aus, dass Du Administratorzugriff auf das SAP-System hast, da Du eine SAP-Standardkomponente ändern musst. Außerdem gehen wir davon aus, dass die SAP WebIDE-Landschaft eingerichtet und in Betrieb ist, da wir sie für die Entwicklung und das Deployment verwenden werden. Es können auch andere Methoden eingesetzt werden, wie z.B. das manuelle Hochladen oder die Verwendung der Eclipse-IDE, aber diese Vorgehenweisen werden in diesem Tutorial nicht behandelt.

Leitfaden

Zunächst loggen wir uns in das zu modifizierende SAP-System ein und starten die Transaktion für den Fiori Designer. Dies geschieht über den Transaktionscode /ui2/flpd_CUST.

Sobald der Designer geladen ist, öffnen wir die Entwicklerkonsole mit der F12 Taste und navigieren zur Registerkarte Netzwerk.

Am Ende der URL muss man die Extension sap-ui-debug=true hinzufügen, um damit die UI5-Engine dazu zu bringen, alle Dateien zu laden. Dank der Magie der Videobearbeitung müssen wir hier jetzt nicht die Ladezeit abwarten, aber, das sei gesagt, die Wartezeit ist ziemlich lang.

Nun, da die Dateien geladen wurden, müssen wir sie nach dem Wort „Dynamic“ filtern. Es sollten dann noch drei Dateien in der Liste erscheinen. Speichere den Inhalt der Dateien in einem temporären Ordner mit Deinem bevorzugten Texteditor.

Nachdem Du diese drei Dateien gespeichert hast, klicke auf eine Kachel und warte, bis der nächste Stapel von Dateien komplett geladen ist. Nun solltest Du nach dem Wort „Konfiguration“ filtern und den Speichervorgang für die Dateien configuration.view.xml und configuiration-dbg.controller.js wiederholen.

Nachdem wir die Dateien gespeichert haben, müssen wir ein SAP WebIDE-Projekt anlegen.

Bitte öffne dazu die WebIDE ab und erstelle ein neues Projekt basierend auf der Vorlage. Wähle SAPUI5 Application und gebe die erforderlichen Felder ein. Dies wird das Projekt sein, an dem wir arbeiten werden.

Als Nächstes müssen wir die unnötigen Dateien löschen und die Dateien importieren, die wir zuvor gespeichert haben. Man kann sie als Stapel hochladen, wenn man sie als eine .zip-Datei speichert.

Erstelle einen neuen Ordner innerhalb des Webapp-Ordners und benenne ihn myKpiTile. In diesen Ordner werden wir sowohl die Ansichten als auch die Steuerungsdateien verschieben.

Benenne die App als app._launcher-Datei in kpiLaunchar_dynamic.chip.xml um und bearbeite sie, um den Ansichtspfad und den Namen der benutzerdefinierten Kachel zu ändern.

Setzte den View-Namen auf mykpitile.myTile.view.js und den Titel der Kachel auf „mydynamictile“ und die Beschreibung wird vom Tutorial erstellt.

Nun müssen wir die Ansicht und den Controller umbenennen, damit sie dem neuen Namen, den wir ausgewählt haben, zu entsprechen. Daher werden wir die Ansicht in myTile.view.js umbenennen und der Controller wird myTile.controller.js sein.

Benenne auch den Konfigurations-Controller um und lösche die Debug-Registerkarte im Namen weg.

Wir müssen den Namensraum und den Namen der Ansicht auch in den aktuellen Dateien aktualisieren. Dies kann mit der Such- und Ersetzungsfunktion durch Drücken von Strg+f geschehen. Damit ändern wir den vorherigen Namensraum zu unserem aktuellen Pfad, also myKpiTile und den Namen der View zu myTile. Dies muss auch in der Steuerungsdatei geändert werden und kann auf die gleiche Weise erfolgen.

Um die Anwendung als CHIP zu registrieren, muss man sie als BSP-Applikation im SAP-System bereitstellen. Wie man hier sehen kann, hatte ich einige Probleme bei der Bereitstellung der Anwendung, weil ich vergessen habe, einige unnötige Dateien zu löschen. Achte darauf, dass Du nur die Dateien speicherst, die Du im Projekt benötigst, sonst stürzt es während des Deployments ab.

Wir wechseln nun zur Transaktion se80, um zu überprüfen, ob die Anwendung erfolgreich bereitgestellt wurde. Nachdem wir sichergestellt haben, dass die Bereitstellung erfolgreich war, können wir mit der Registrierung als CHIP fortfahren. Dies geschieht mit dem Transaktionscode /ui2/chip.

Gebe einen Namen ein und erstelle den CHIP. Gebe die URL der BSP-Applikation, den Anzeigenamen und die Beschreibung ein. Da es sich um einen CHIP und nicht um eine normale UI5-Anwendung handelt, vergiss nicht, den Pfad zu kpilauncer_dynamic.chip.xml anzugeben.

Nachdem der CHIP erfolgreich registriert wurde, kannst Du nun fortfahren und den neuen CHIP in die Fiori Launchpad-Designerkomponente aufnehmen. Dies kann durch den Aufruf des CUSTOMIZE_COMPONENT aus dem Transaktionscode se80 oder durch Folgen der in der Beschreibung angegebenen URL geschehen.

Man muss über Administratorrechte verfügen, um die Standardkomponente zu ändern. Wir passen die Komponente chip_catalog_config an und die Konfigurations-ID lautet Fiori Launchpad Katalog.

Wie man sieht, gibt es hier bereits benutzerdefinierte Kacheln, die ich in der Vergangenheit erstellt habe. Hier müssen wir also einen neuen Wert hinzufügen. Sei vorsichtig, da der Wert des Parameters genau einem der vorherigen Einträge entsprechen muss. Wir fügen x-SAP-ui2 hinzu.

Lasst uns noch einmal den Namen des CHIPs überprüfen, den wir erstellt haben, Z_mytuttile. Achtung, es gibt dort keine Leerzeichen. Jetzt können wir es speichern, einem Transport zuordnen und es wird dem System hinzugefügt.

Kehren wir zurück zum Fiori Launchpad-Designer, und versuchen, eine neue Kachel hinzuzufügen. Wie man sieht, ist meine benutzerdefinierte Kachel: mYtutorial TILE nun als Option zum Hinzufügen vorhanden. Leider gibt es in diesem Moment noch nichts anderes als die standardmäßige dynamische Kachel, aber das werden wir im zweiten Teil dieses Tutorials ändern.

Kurze Zusammenfassung

Wir hoffen, dass dieser erste Teil des Tutorials hilfreich für Dich war. Wenn Du Fragen dazu hast, zögere nicht, uns zu kontaktieren. Wir werden sie Dir gerne beantworten. Verpasse auch nicht den nächsten Teil, damit Du Dir einen Überblick über den kompletten Prozess verschaffen kannst!

Wie am Anfang des Beitrags erwähnt, ist dieses Video der vierte Teil der Tutorialreihe SAP Fiori Customization Samples.

Der erste Teil zeigt Dir, wie Du ein SAP Fiori Launchpad auf der SAP Cloud-Plattform erstellst und Apps auf dem Fiori Launchpad hinzufügst.

Der zweite Teil erklärt Dir, wie Du Dein Fiori Launchpad für Dich anpassen kannst.

Der dritte Teil veranschaulicht, wie sich ein Single Sign-On zwischen einem Fiori Launchpad, das auf einem BW-System bereitgestellt wird, und SAP Business Objects konfigurieren lässt.

 

Autor dieses Beitrags
Andrei Ghiura Associate
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@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

 

Maschinelles-Lernen-mit-SAP-HANA-und-SAP-Fiori

Machine Learning mit SAP HANA und SAP Fiori

Was ist maschinelles Lernen und warum ist es so wichtig?

Auf jeden Fall ist es heute in aller Munde. Wir sollten also zunächst einmal klären, warum genau alle Welt so interessiert daran ist.

Der Grund, warum maschinelles Lernen in aller Munde ist, ist die Tatsache, dass es uns in vielen Bereichen gewaltige Fortschritte bringt. Es erlaubt Computern, bestimmte Aufgaben nicht nur auszuführen, sondern die zugrunde liegenden Regeln für die Ausführung dieser Aufgaben im Vorfeld überhaupt erst zu erlernen (also basierend auf historischen Daten aus Erfahrungen zu lernen).

Beispiele

Ein gutes Beispiel ist das Gesundheitswesen. Hier werden Algorithmen für das maschinelle Lernen bereits erfolgreich eingesetzt, um die Anzeichen für ein Reihe schwerer Krankheiten wie zum Beispiel Brustkrebs frühestmöglich zu erkennen und so das Risiko für Patienten zu senken.

Im Finanzwesen kommen Lernalgorithmen zum Einsatz, um Betrugsversuchen auf die Spur zu kommen und Geldwäsche zu bekämpfen. Derartige Algorithmen können Abermillionen von Transaktionen analysieren und dabei verdächtige Muster erkennen und offenlegen.

Im Bereich der Online-Sicherheit werden Algorithmen für das maschinelle Lernen eingesetzt, um verdächtiges Verhalten zu beobachten und Datenschutzverletzungen zu erkennen.

Und nicht zuletzt ist maschinelles Lernen schon längst Teil unseres Alltags. Egal, ob wir mit Siri auf unseren Apple-Geräten oder mit Alexa über unseren Echo kommunizieren, in den sozialen Netzwerken unterwegs sind oder uns von Google Maps leiten lassen, den Kern all dieser Systeme bilden maschinelle Lernalgorithmen.

Auch im Tagesgeschäft vieler Unternehmen sorgen diese Algorithmen für die Automatisierung grundlegender Aufgaben, die früher von Hand verrichtet wurden, so zum Beispiel bei der Prüfung von Rechnungen auf Duplikate, Bestellungen und vielem mehr. …

Im Bereich Business Intelligence nimmt maschinelles Lernen als Bestandteil von Predictive-Analytics-Verfahren ebenfalls ein wichtige Rolle ein und ermöglicht es Mitarbeiten, bestimmte Ergebnisse zu prognostizieren. So können im Vertrieb zum Beispiel Vorhersagen zu Verkaufszahlen getroffen werden und Führungskräfte können verschiedene Prognosen zu den möglichen Auswirkungen von Entscheidungen auswerten und so ihre Entscheidungsfindung unterstützen.

Aber wie funktioniert es?

Machen wir einen kleinen Test:

  • 2 → 4
  • 3 → 9
  • 5 → 25
  • 6 → ?

Die richtige Antwort ist natürlich 36. Und der Grund, warum du das wusstet, ist die Tatsache, dass du ein Muster erkannt hast. Und genau so arbeiten auch maschinelle Lernalgorithmen. Sie werden anhand von Beispieldaten trainiert und lernen auf diesem Wege, Muster zu erkennen und diese Muster den richtigen Reaktionen zuzuordnen (aus Erfahrung lernen). Nach Abschluss des Trainings können wir den Algorithmus mit neuen Daten füttern und erhalten (hoffentlich) die richtige Antwort auf unsere Abfrage.

Natürlich sind diese Algorithmen auf die Bearbeitung von Problemen ausgelegt, die um ein Vielfaches komplexer sind als unser kleiner Test und zudem unzählige Eingabewerte erfordern. So stellen auch komplexe Aufgaben wie Bild- und Spracherkennung oder die Vorhersage möglicher Vertriebsergebnisse anhand von historischen Marktdaten kein Problem dar.

 Maschinelles Lernen mit SAP HANA und Fiori

Als viel diskutiertes Thema weckt maschinelles Lernen natürlich auch Neugier und Experimentierfreude und auch wir bilden da keine Ausnahme. Bei Inspiricon stellte sich vor allem die Frage, welchen Mehrwert dieser neue Trend in unseren angestammten Fachgebieten wie BI, SAP Fiori und SAP HANA entfalten könnte.

Dabei hat sich gezeigt, dass SAP HANA das maschinelle Lernen bereits heute schon sehr beachtlich unterstützt. Mit der SAP HANA Predictive Analytics Library ermöglicht SAP die Verwendung von maschinellen Lernalgorithmen und sogar den Aufbau von neuronalen Netzen. Nutzt man diese Stärken und verbindet sie mit SAP Fiori, lassen sich einige hochinteressante Anwendungen im Bereich der Predictive Analytics realisieren. So konnten wir beispielweise ein kleine Fiori-Anwendung für die Prognose von Verkaufszahlen in den einzelnen Filialen einer Supermarktkette erstellen. Die folgende Abbildung zeigt einen groben Überblick über die Architektur dieser Anwendung:

Architecture-Application-Machine-Learning

Die von uns entwickelte Fiori-Anwendung wäre vor allem für Führungskräfte interessant und würde es ihnen erlauben, innerhalb der Anwendung die Prognose bis zum Jahresende auszuwerten. Wir beschäftigen uns auch weiterhin mit diesem Szenario und arbeiten daran, es um zusätzliche Funktionen wie zum Beispiel “Was-wäre-wenn-Szenarien” zu erweitern, über die sich die Auswirkungen von Management- und Marketingentscheidungen (z. B. Werbeaktionen) auf die prognostizierten Verkaufszahlen untersuchen lassen:

Fiori-Predictive-Demo-Machine-Learning

Fazit

Maschinelles Lernen ist schon mit einem einfachen HANA-Backend möglich!

Zwar gibt es am Markt bereits umfassende und leistungsstarke Tools wie z. B. Tensorflow für neuronale Netzwerke oder SAP Predictive Analytics, aber ihr solltet unbedingt wissen, dass diese für einen Einstieg in das Thema nicht unbedingt zwingend erforderlich sind. Wie schon oben gesagt, erhaltet ihr mit SAP HANA schon alles, was ihr braucht. Und mit SAP Fiori lassen sich UI-Anwendungen realisieren, die das implementierte Szenario optimal unterstützen. Für die vorausgehende Analyse der Daten stehen euch leistungsstarke und zudem kostenlose Analysetools wie Python (Pandas) oder R zur Verfügung. Daraus kann sich ein durchaus sehr attraktiver Ansatz ergeben, der sich auch ohne zusätzliche Lizenz- oder Infrastrukturkosten umsetzen lässt und insbesondere für kleinere Probleme geeignet ist, die auch ohne intensive Datenverarbeitung auskommen.

Für welchen Ansatz ihr euch letzten Endes entscheidet, hängt ganz allein von dem jeweiligen Anwendungsfall ab und sollte vom Entwicklungsteam genau durchdacht sein. Ein wichtiger Faktor, der bei der Entscheidungsfindung nicht außer Acht gelassen werden darf, sind die Kosten, die durch Pflege und Lizenzen entstehen.

Quellenangabe der Bilder:  Inspiricon AG

Autor dieses Beitrags
Gerald Iakobinyi-Pich Solution Architect
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@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