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 (www.juergen-noe-consulting.de). 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: https://de.espresso-tutorials.com/business_intelligence_0159.php

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. Modultests
  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. Modultests:

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

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
SAP BusinessObjects Mobile

Run better – und zwar überall mit SAP BusinessObjects Mobile

Fachabteilungen erwarten heute eine ständige Verfügbarkeit ihrer Daten, Berichte und Dashboards. Ihre Mitarbeiter möchten nicht an den Schreibtisch gefesselt sein, sondern überall und jederzeit auch auf ihren Mobiltelefonen und Tablets darauf zugreifen können.

Mit SAP BusinessObjects Mobile und der SAP BusinessObjects BI Plattform lässt sich diese Anforderung optimal umsetzen.

Dabei gilt es aber zu beachten, dass es große Unterschiede zwischen der Benutzerinteraktion mit einem mobilen Dashboard und der Arbeit am Laptop oder Desktop gibt – durch die kleineren Bildschirme auf Mobilgeräten bleibt auch weniger Platz für Visualisierungen, Filter, Schaltflächen und alle anderen Komponenten.

Bereitstellung eines WebI Reports in der SAP BusinessObjects Mobile App

In diesem Artikel möchten wir uns mit der Möglichkeit der Bereitstellung eines WebI Reports in der SAP BusinessObjects Mobile App befassen. Hierbei handelt es sich um die bevorzugte Option, da mit der App ganz bequem und sicher eine Verbindung mit der BI-Plattform hergestellt werden kann, um anschließend WebI Reports, Design-Studio-Anwendungen sowie weitere BI-Dokumente wie Crystal Reports oder SAP-Lumira-Dokumente abrufen zu können. Ein weiterer wichtiger Faktor ist die Unterstützung von Lumira 2.0, was mit der neuesten Version 6.6 von SAP Business Objects Mobile für iOS hinzugekommen ist.

iOs Android

Zwar profitieren iOS-Anwender gegenüber der Android-Version aktuell von einem geringfügig größeren Funktionsumfang sowie von einigen technischen Neuerungen, grundsätzlich bilden aber beide Versionen die Mehrzahl der Anforderungen von Unternehmensanwendern zuverlässig ab.

Unten sehen Sie einen WebI Report in der Desktop-Ansicht. Am Ende dieses Artikels zeigen wir Ihnen dann als Ergebnis den gleichen Bericht in der mobilen Darstellung (Abb. 1.1).

WebI ReportAbb. 1.1

Natürlich erfordert die Entwicklung einer verlässlichen und optimierten Mobilanwendung eine andere Herangehensweise als zum Beispiel die Entwicklung eines Dashboards zur Anzeige auf Desktop-Computern. Dennoch lassen sich diese Schritte auch auf die Bereitstellung in SAP BusinessObjects Mobile anwenden.

Ihre App in vier Schritten

>> Bitte beachten Sie: Um diese App nutzen zu können, muss sie von Anwendern der SAP BusinessObjects Business Intelligence Plattform heruntergeladen werden, deren IT-Abteilung die Nutzung von mobilen Diensten bereits aktiviert hat.

  1. Laden Sie die SAP BusinessObjects Mobile App aus dem Apple Store bzw. von Google Play herunter.
  2. Konfigurieren Sie in der App die Verbindung zu Ihrem BO-Server.

Für die nächsten Schritte gehen wir davon aus, dass Sie die App bereits auf Ihrem Telefon installiert haben. Als nächstes gilt es nun, die Verbindung zum BO-Server zu konfigurieren (Abb. 1.2).

Neue Verbindung zum BO Server

Abb. 1.2

Da unser Ziel die BI Plattform ist, wählen wir als Verbindungstyp BOE aus. Um den CMS-Namen zu ermitteln, melden wir uns bei der Central Management Console ein. Unter Server – Serverliste finden wir den Central Management Server mit dem Hostnamen (Abb. 1.3).

Central Management Console

Abb. 1.3

  1. Stellen Sie die gewünschte App bzw. den gewünschten Bericht über das BO-Launchpad bereit.

Im nächsten Schritt erfolgt zunächst die Anmeldung beim BO-Launchpad. Für den Zugriff auf den Ordner „Kategorien“ benötigen wir Administratorrechte. In diesem Ordner finden wir alle Anwendungen und Berichte, die aktuell für die mobile Nutzung verfügbar sind (Abb. 2.1).

BI Launchpad

Abb. 2.1

Wir rufen unsere Ordner auf und wählen per Rechtsklick den Bericht aus, den wir bereitstellen möchten. In dem Kontextmenü, das jetzt erscheint, klicken Sie auf „Kategorien“ (Abb. 2.2).

Kategorien

Abb. 2.2

Ein neues Fenster wird angezeigt. Klicken Sie auf „Öffentliche Kategorien“ – „Mobil“ und speichern Sie Ihre Auswahl (Abb. 2.3).

Öffentliche Kategorien - Mobil

Abb. 2.3

  1. Wenn wir jetzt unsere mobile Anwendung aufrufen, wird der bereitgestellte Bericht angezeigt (Abb. 2.4).

Bericht

Abb. 2.4

Zu welchem Ergebnis führen diese Schritte?

Das Ergebnis ist ein Bericht, der jederzeit und überall über Ihr Mobilgerät aufgerufen werden kann. Dabei kann die Anzeige auch im Querformat erfolgen (Abb. 3).

Ergebnis

Mit SAP BusinessObjects Mobile können auch Push-Benachrichtigungen eingerichtet werden, über die Mobilanwender auch dann benachrichtigt werden können, wenn keine aktive Benutzersitzung läuft oder die mobile Anwendung gerade nicht ausgeführt wird. Um diese Funktion zu aktivieren, müssen die Einstellungen sowohl server- als auch clientseitig entsprechend angepasst werden (Abb. 4).

Push Benachrichtigungen

Abb. 4, Quelle: YouTube

Fazit und Ausblick

Der große Vorteil hier liegt darin, jederzeit fundierte und damit intelligentere Entscheidungen treffen zu können. Und zwar auf Grundlage von maßgeschneiderten und personalisierten Informationen, die überall bereitstehen – egal ob im Vorstandszimmer, beim Kunden vor Ort oder in der Produktionshalle – und auch ohne zusätzlichen Schulungsbedarf analysiert werden können.

Mit SAP BusinessObjects Mobile können Sie ohne Wartezeit sofort auf Business Intelligence-Berichte, Kennzahlen und Echtzeitinformationen zugreifen. Es gibt natürlich noch viele weitere Aspekte, die es im Zusammenhang mit SAP BusinessObjects Mobile und der richtigen Herangehensweise bei der Entwicklung von mobilen Anwendungen zu besprechen gilt, und wir werden uns diesen Themen in einem unserer nächsten Artikel widmen.

Autor dieses Beitrags
Cristian Moldovan Junior Consultant SAP BI
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
So erhöhen Sie mit SAP Fiori Ihre Benutzerproduktivität und Automatisierung

So erhöhen Sie mit SAP Fiori Ihre Benutzerproduktivität und Automatisierung

Sie kennen die „alten“ SAP-Oberflächen? Diese sehen nicht gerade ansprechend aus, wenn wir ehrlich sind. Das ändert sich jedoch grundlegend mit SAP Fiori!

Schluss mit komplizierten Workflows, Schluss mit langweiligen Designs,
Schluss mit der unnötigen Verschwendung von Ressourcen!

SAP Fiori stellt ein User Interface für alle Aufgaben zur Verfügung: Mit den browser-basierten SAP Fiori Apps lassen sich Aufgaben rollenbasiert und prozessbezogen in einer einzigen Benutzeroberfläche erledigen – und zwar über alle Devices hinweg.

SAP Fiori bildet damit die Schnittstelle von Effizienz und Design.

Der wesentliche Vorteil für Sie von SAP Fiori – abgesehen vom verbesserten Aussehen und der damit einhergehenden erhöhten Benutzerakzeptanz – ist die effektivere Nutzung von Ressourcen. Mit genauen Kenntnissen über das Nutzerverhalten Ihrer Mitarbeiter, können Sie die Apps so gestalten, dass sie die Arbeitsprozesse mit einer idealen User Experience optimal unterstützen.

Das bedeutet für Sie:

  • beschleunigte Prozesse
  • effektive Kostensenkung
  • Zugriff auf alle wichtigen Unternehmensprozesse von jedem Ort und jedem Gerät.

Zum Beispiel können Self Service Workflows, Abwesenheitsanträge, Zeiterfassung oder Bestellungen durchgeführt werden, die direkt in SAP Fiori angelegt und auch dort genehmigt werden.

Sie möchten sich detaillierter mit SAP Fiori auseinandersetzen und mehr über seine Funktionsweise lernen? Da haben wir etwas für Sie!

Webinar SAP Fiori Crashkurs in 30 Minuten

Schauen Sie sich die Aufzeichnung unseres Webinars vom 28. Juni 2017 an: SAP Fiori Crashkurs in 30 Minuten.

Darin zeigen wir Ihnen, wie Sie eine Fiori App für Live-Reporting auf SAP BW erstellen können. Erfahren Sie außerdem, wie SAP Fiori Sie noch unterstützen kann:

  • Vereinfachung von Prozessen und Workflows
  • Fehlerminimierung
  • optimale Nutzung Ihrer Ressourcen – denn SAP Fiori steht Ihnen bereits mit Ihrer SAP-Lizenz zur Verfügung
  • Individualisierung von Prozessen: Sie können alle SAP Fiori Apps Ihrem CI anpassen
  • Vereinfachung und Automatisierung Ihrer täglichen Aufgaben
  • last but not least: es ist einfach zu bedienen, macht Spaß und sieht auch noch gut aus!

>> Hier können Sie die Aufzeichnung anfordern.

In 7 Schritten zu Ihrer ersten SAP Fiori App

In diesem Leitfaden beschreiben wir Ihnen ausführlich und Schritt für Schritt, wie Sie selbst eine SAP Fiori App zur Datenvisualisierung erstellen können – und zwar in nur einer Stunde!

SAP Fiori repräsentiert ein neues personalisiertes, reaktionsschnelles und einfaches Benutzererlebnis über verschiedene Endgeräte hinweg. Für unsere Kunden stellt SAP Fiori die moderne, hochperformante und benutzerfreundliche Schnittstelle zu einem komplexen BI dar – BI meets Fiori.

>> Klicken Sie hier, um den Leitfaden anzufordern.

Das Beste kommt zum Schluss

In diesem Info-Video finden Sie komprimiert die wichtigsten Infos zu SAP Fiori. >> Hier geht’s zum Video!

Oder Sie lesen alles bequem in unserem E-Book nach – >> hier geht es zum Download.

Inspiricon-E-Book-SAP-Fiori

Sie haben weitere Fragen zu SAP Fiori? Kontaktieren Sie mich gerne direkt – ich freue mich auf Ihren Anruf, E-Mail oder SMS!

Autor dieses Beitrags
Andrei Vlad CEO Inspiricon SRL
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
Neuerungen in SAP BO Information Design Tool 4.2

Welche Neuerungen bringt das SAP BusinessObjects Information Design Tool 4.2?

Heute kommen wir zum letzten Artikel in unserer Serie zu den neuen Funktionen von SAP BusinessObjects 4.2!

Die folgenden neuen Funktionen und Erweiterungen finden sich in diesem Release des Information Design Tools:

Mengen und Mengenfilter

Die Unterstützung von BI-Mengen ist die wohl wichtigste Erweiterung für das Information Design Tool in SAP BI 4.2.

In dieser neuen Version können Entwickler Mengen erstellen, die als vordefinierte Filter für komplexe Abfragen in Web Intelligence dienen. Eine Menge ist eine Struktur aus mehreren Listen mit Werten für aktive Dimensionen in der Business-Schicht und basiert auf einem Universum (UNX). Diese Mengen können die Definition von Kalendern enthalten, so bei zeitbasierten Mengen, deren Inhalt sich mit der Zeit verändert. Entwickler können Mengen im CMS-Repository veröffentlichen. Diese sind dann als Mengenfilter verfügbar, wenn das dazugehörige Universum als Datenquelle im Abfrageeditor verwendet wird. Mengen werden im Data Warehouse zusammen mit den Produktionsdaten gespeichert, um ein schnelles Filtern zu ermöglichen.

BI-Mengen eignen sich zum Abfragen von Daten über Mengenlogik und -Operatoren anstelle von SQL.

Universen

Entwickler können ab sofort in nur einem Schritt einzelne oder eine Gruppe mehrerer .UNV-Universen in das .UNX-Universum-Format konvertieren. Auch verknüpfte .UNV-Universen können ab sofort unter Beibehaltung der Links zu allen zentralen Universen in .UNX-Universen konvertiert werden. Darüber hinaus ist es nun auch möglich, dass ein einziges Universum bei Bedarf alle zentralen Universen enthält.

Sie können ab sofort die Funktion Big Numbers auf .UNX-Universum-Ebene verwenden und die Aktivierung per Bericht vermeiden. Bei Big Numbers handelt es sich um eine neue Hohe-Genauigkeit-Eigenschaft für den bestehenden numerischen Datentyp, die auf einem Formatierungsstandard für dezimale Gleitpunktzahlen basiert und es Entwicklern erlaubt, numerische Objekte zu definieren, die mit höherer Genauigkeit, zwischen 15 und 40 Stellen, konsumiert werden sollen.

Verknüpfte Universen

Das Information Design Tool kann verknüpfte Universen konvertieren, die mit dem Universe Design Tool erstellt wurden. Das Dialogfeld für die Konvertierung wurde von Grund auf überarbeitet, so dass jetzt mehrere Universen gleichzeitig konvertiert und neue Konvertierungsoptionen vorgeschlagen werden können.

Ab sofort können Entwickler ein Universum mit einem oder mehreren zentralen Universen im Repository verknüpfen. Änderungen am zentralen Universum werden automatisch auf die gemeinsam genutzten Komponenten in den verknüpften Universen übertragen. Durch die Verwendung verknüpfter Universen können Entwickler so Komponenten in vordefinierten und bereits getesteten Universen als Ausgangspunkt für die schnelle Erstellung neuer Universen nutzen.

Der Prozess für die Erstellung eines verknüpften Universums wurde überarbeitet. Entwickler müssen nun mit einem bereits bestehenden Universum beginnen und auf dieser Grundlage ein verknüpftes Universum erstellen. Nach der Erstellung können durch den Entwickler Tabellen zu dem neuen Universum hinzugefügt werden, die ihre Daten aus dem ursprünglichen Universum beziehen. Änderungen an dem ursprünglichen Universum werden in dem neuen verknüpften Universum automatisch nachgezogen. Das verknüpfte Universum übernimmt sowohl die Datengrundlage als auch die Business-Schicht des ursprünglichen Universums.

SQL-Erweiterung

Der neue SQL-Parameter NO_NULL_YIELDS_IN_SUBQUERY wurde zur Liste der SQL-Generierungsparameter hinzugefügt. Wird der Parameter auf YES gesetzt, werden SQL-Skripte generiert, um sicherzustellen, dass Felder mit Nicht-NULL-Werten in auf Unterabfragen basierenden Filtern berücksichtigt werden. Der Standardwert ist NO.

Festlegen von Zusammenfassungseinstellungen für die Datengrundlagenansicht

Für Datengrundlagen mit mehreren Sichten können Sie im Editor ab sofort eine benutzerdefinierte Ansicht anstelle der standardmäßigen Masteransicht öffnen. So sparen Entwickler bei der Arbeit mit Teilmengen der Datengrundlage Zeit und sind nicht gezwungen, den gesamten Inhalt der Masteransicht anzuzeigen. Der neu verfügbare Reiter Zusammenfassung liefert ab sofort eine Übersicht der Ansichten. Ihre farbliche Hinterlegung liefert dabei einen Hinweis auf die jeweilige Ladezeit. Anhand dieser Informationen können Entwickler eine Ansicht auswählen, die schneller geladen wird als die Masteransicht, die alle verfügbaren Ansichten anzeigt.

Erstellen eines Business Layers direkt auf Grundlage einer BEx Query

Über BICS-Zugriff können Entwickler eine Business-Schicht direkt auf Grundlage einer BEx Query erstellen und die Business-Schicht als Universum veröffentlichen, das für Web Intelligence verfügbar ist. Verglichen mit dem direkten Zugriff auf eine BEx Query hat das Erstellen eines Universums auf Grundlage einer BEx Query den großen Vorteil, dass Entwickler die Query-Dimensionen, Kennzahlen und Hierarchien in der Business-Schicht organisieren und benutzerdefiniert anpassen können.  Zwar können Entwickler bestimmte Komponenten der Business-Schicht bearbeiten, die Datengrundlage wird jedoch automatisch auf der Basis der Abfrage erstellt und ist schreibgeschützt.

Sie interessieren sich dafür, wie man ein Universum erstellt? Auch hierbei können wir Ihnen weiterhelfen: lesen Sie diesen Blogartikel, dort erklären wir Schritt für Schritt, wie man ein Universum kreiert.

Autor dieses Beitrags
Veronika Aleksandrova SAP BI Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de

 

WebI 4.2 mit neuen Funktionen

SAP BusinessObjects Web Intelligence 4.2 mit neuen Funktionen

In dieser Woche setzen wir unsere kleine Artikelserie zum Thema BI 4.2 fort. Heute beschäftigen wir uns mit SAP BusinessObjects Web Intelligence 4.2 und seinen neuen Funktionen. Legen wir also gleich los.

Heute möchte ich Ihnen einen Überblick über die neuen Funktionen verschaffen.

SAP BusinessObjects Web Intelligence 4.2 umfasst eine Reihe neuer Funktionen: Freigeben von Elementen, paralleles Regenerieren von Abfragen, Kommentare, Geokarten und visuelle Erweiterungen, direkter Zugriff auf HANA-Sichten und HANA-Online.

Freigabe von Elementen

Bei freigegebenen Elementen handelt es sich um Berichtsteile, die im CMS-Repository abliegen und durch andere Benutzer oder in anderen Dokumenten mehrfach wiederverwendet werden können. Entwickler können Berichtselemente auf einer zentralen Plattform in einem öffentlichen Ordner speichern. Freigegebene Elemente enthalten alle erforderlichen Metadaten: Berichtsteile, die entsprechende Datenquelle, Datenprovider, Variablen und Formatierung. So können Benutzer häufig verwendete Logos, Tabellen und Visualisierungen bequem und schnell in ihre Berichte importieren.

Paralleles Regenerieren von Abfragen

Die Funktion zum parallelen Regenerieren von Datenprovidern unterstützt ab sofort auch BEx-Abfragen. Zudem sind in der Central Management Console und im Information-Design-Tool neue Einstellungen hinzugekommen, über die Sie die Feinabstimmung paralleler Abfragen auf Verbindungsebene vornehmen können. Dadurch können Sie die maximale Anzahl parallel regenerierter Abfragen pro Dokument für OLAP-, BEx- oder relationale Verbindungen verwalten. Darüber hinaus können Sie festlegen, ob die parallele Abfrageverarbeitung auch bei zeitgesteuerten Vorgängen erfolgen soll.

Kommentare

BI-Kommentar ist derzeit für die Web-Intelligence-Anwendung verfügbar. Benutzer, die Web-Intelligence-Berichte verwenden, können nun die Funktion BI-Kommentar für die Zusammenarbeit verwenden.

Geokarten und visuelle Erweiterungen

Ab sofort können Sie unter Verwendung von Esri Maps oder Google Maps optisch ansprechende und aufschlussreiche Dashboards erstellen. So kann ab sofort jede Karte mit einer URL zur Kombination von Geodaten und unseren eigenen Daten verwendet werden. Die Karten in Web Intelligence sind nicht mehr länger nur der mobilen Anwendung vorbehalten. Ab sofort können Entwickler sie überall in Web Intelligence erstellen oder anzeigen, egal ob sie Desktop, Browser oder Mobilgerät verwenden. Diese Funktion umfasst zudem eine Geocoder-Engine. Mit dieser Engine können Entwickler mit ihrem bestehenden Datensatz beliebige Dimensionen für Städte, Bundesländer/Staaten und Ländern geokodieren.

Direkter Zugriff auf SAP-HANA-Sichten

Ab sofort können Entwickler direkt auf eine SAP-HANA-Informationssicht zugreifen, ohne vorher ein Universum erstellt zu haben. Darüber hinaus können sie Abfragen auf Basis von HANA-Sichten erstellen und profitieren von der Geschwindigkeit und Leistungsfähigkeit von HANA.

SAP-HANA-Online

Der SAP-HANA-Online-Modus ermöglicht es Ihnen, Web-Intelligence-Dokumente auf der Grundlage von aktiven Daten zu erstellen und sich so die Leistungsfähigkeit von SAP HANA zu Nutze machen. Im SAP-HANA-Online-Modus werden sämtliche Web-Intelligence-Berechnungen wie die Aggregation von Werten und das Filtern von Elementen an HANA delegiert. Dies ermöglicht schnellere Interaktionen zwischen Web Intelligence und HANA, was wiederum für mehr Geschwindigkeit bei der Regenerierung von Daten sorgt.

Diese Funktion richtet sich vor allem an Business-Analysten, die große Datenmengen in HANA analysieren. Sie können ab sofort mit Echtzeitdaten arbeiten und profitieren von besseren Interaktionen mit Web Intelligence. Berichtsdesigner profitieren außerdem von der Benutzerfreundlichkeit des SAP-HANA-Online-Modus, wodurch sich die Erstellung von Dokumenten einfacher als je zuvor gestaltet. Berichtsdesigner können nun Abfrageeditoren und Universen umgehen.

Sollten Sie noch weitere Fragen zu diesen Themen haben, stehe ich Ihnen gerne zur Verfügung!

 

Autor dieses Beitrags
Veronika Aleksandrova SAP BI Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de

Cognos-Migration

Wie Unternehmen mit einer standardisierten SAP-Lösung konzernweit Prozesse harmonisieren und Vergleichbarkeit gewährleisten können

Hallo,

heute stellen wir euch ein weiteres Projekt aus unserem Portfolio vor. Diesmal geht es um die Migration einer bestehenden Cognos Reporting Lösung auf SAP BW on HANA mit SAP BusinessObjects als Frontend.

Der Kunde, den wir hierbei unterstützt haben, ist in der Herstellung und im Vertrieb elektronischer Bauelemente aktiv. Er ist Teil eines globalen Konzerns und die verschiedenen Tochterunternehmen des Konzerns nutzten unterschiedlichste ERP- und Business Intelligence-Lösungen. Im Rahmen des weiteren Wachstums und des Anstiegs der Komplexität stießen die Funktionalität der selbstprogrammierten ERP-Lösung sowie das Reporting an ihre Grenzen.

DAS PROJEKT

Inspiricon löste basierend auf einer neu eingeführten standardisierten SAP ERP-Lösung mit SAP BW die existierende Cognos Reportinglösung ab.

Zu dieser Entscheidung trugen mehrere Gründe bei:

  • Die Weiterentwicklung der zum Großteil kundenindividuellen und selbstentwickelten Reporting-Lösungen war teuer und zeitaufwändig.
  • Es bestand ein hoher Wartungs- und Pflegeaufwand.
  • Innerhalb des Konzerns waren Bedeutung und Inhalt von KPI’s nicht konsistent. Als Folge waren eine Vergleichbarkeit der Prozesse und Ergebnisse der Tochtergesellschaften nicht gegeben.
  • Es existierten viele Schnittstellen zu anderen Systemen, was hohe Kosten sowie eine hohe Fehleranfälligkeit implizierte. Besonders die Berichterstattung an den Mutterkonzern war aufwändig. Sie wurde über weitere Schnittstellen abgewickelt, da das Berichtswesen durch eine – individuelle – zusätzlich aufgesetzte Cognos-Reporting-Lösung ausschließlich auf Kunden abgestimmt war.
  • Das interne Wissen über die existierende Lösung beschränkte sich auf wenige Köpfe im Unternehmen. Es bestand daher ein hohes Verlustrisiko an technischem Know-How, sollte ein Wissensträger ausscheiden.

DIE LÖSUNG

Da SAP-Produkte bereits von einer anderen Tochtergesellschaft verwendet wurden, war die neue ERP-Lösung schon systemseitig vorhanden.

Jedoch wurde nicht nur das ERP-System erneuert, sondern auch im Bereich BI sollte eine Evolution stattfinden. Der Konzern setzte auf eine SAP-Lösung. Somit löste SAP Business Warehouse on HANA die bisherige Cognos-Reporting-Lösung ab.

Gestartet wurde das Projekt mit Release SAP 7.4 on HANA. Während des Projektes erfolgte die Migration auf SAP 7.5 on HANA. Auch in diesem Fall wurde SAP BW bereits von einer Tochtergesellschaft verwendet und war also bereits vorhanden.

Frontendseitig entschied man sich ebenfalls für Produkte aus der SAP BusinessObjects Familie. Aus diesen Umstellungen sollten folgende Änderungen und Vorteile resultieren:

  • Datenmodelle werden durch die Standardisierung für alle Töchter des Konzerns nutzbar. Dies ermöglicht einen kostenoptimalen Support von den weltweit verteilten Service Centern.
  • Alle KPI’s werden vereinheitlicht, um eine Vergleichbarkeit zu garantieren.
  • Für Nutzer der Cognos-Lösung wird die Umstellung durch eine Like-to-Like Migration erleichtert.
  • Überflüssige Schnittstellen fallen weg.
  • Informationen fließen innerhalb der gesamten Wertschöpfungskette besser und schneller.
  • Die Reaktionsfähigkeit zur Unternehmenssteuerung wird erhöht. Dies bringt auch eine Steigerung der Wettbewerbsfähigkeit mit sich.

Unsere Lösung bestand aus Web Intelligence Reports auf Basis SAP BW on HANA mit standardisierter Datenversorgung aus dem operativen SAP ERP. Im folgenden Schaubild seht ihr den skizzierten Projektverlauf:

Skizzierter Projektverlauf

Durch den Wechsel der ERP- und BI-Systeme konnte unser Kunde seine Geschäftstätigkeit verbessern. Auf der einen Seite können die User nun schneller auf Berichte und Daten zugreifen, was die Entscheidungsfindung erheblich verkürzt. Auf der anderen Seite können die Berichte nun teilweise vom User selbst angepasst werden (Self-Service BI). Nicht zu vernachlässigen ist der enorme Sicherheitsgewinn durch die zentrale Steuerung von Zugangsberechtigungen. Abschließend konnten Lizenzkosten zum Vorteil der Wirtschaftlichkeit des Kunden reduziert werden.

Eine Einführung und Standardisierung der SAP ERP- und BI-Lösung ist mit hohen finanziellen Aufwänden verbunden. Diese konnten wir durch den Einsatz von Mitarbeitern aus unserem Nearshoring-Standort in Cluj-Napoca, Rumänien, erheblich reduzieren. In den Hochphasen des Projektes waren bis zu 6 Kollegen aus Cluj-Napoca eingebunden. Die Koordination erfolgte über tägliche kurze Meetings, in denen das Team remote mit Bild und Ton zugeschaltet war.

Autor dieses Beitrags
Claudio Volk Vorstand
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Wie man Informationen mit SAP Fiori in Echtzeit auswerten und visualisieren kann

Wie man Informationen mit SAP Fiori in Echtzeit auswerten und visualisieren kann

Hallo,

heute stellen wir euch ein Kundenprojekt vor, bei dem es um die Einführung der Datenauswertung und -visualisierung in Echtzeit ging.
Lasst uns direkt in das Projekt einsteigen:

Unser Kunde

Die ERCO GmbH, ist ein international führender Spezialist für Architekturbeleuchtung mit LED-Technologie. Das Familienunternehmen ist in rund 55 Ländern mit etwa 1.000 Mitarbeitern vertreten.

Die Ausgangssituation

ERCO hat uns damit beauftragt, eine App zu entwickeln, die KPIs nicht nur anzeigen kann, sondern zudem den Anwendern auch die Möglichkeit bietet, die KPIs direkt zu kommentieren. Zum Beispiel für Soll-Ist-Vergleiche oder ähnliches. All diese Informationen zusammen genommen unterstützen die Vertriebssteuerung.

Die Anforderungen

Durch die Einführung einer SAP Fiori Applikation mit Anbindung eines SAP BW Systems sollte eine Optimierung des Informationsaustauschprozesses zwischen Vertriebsmitarbeitern und der Geschäftsführung erreicht werden.

Daraus ergaben sich folgende Projektanforderungen für uns:

  • Reports und Feedback-Möglichkeiten sollen für Vertriebsmitarbeiter einfacher zugänglich werden – inklusive mobiler Zugriffe.
  • Reports sollen in Echtzeit generiert werden.
  • Kommentare und Schätzungen von Vertriebsmitarbeitern sollen ebenfalls in Echtzeit erfasst und zentral abgespeichert werden.
  • Geschäftsführer sehen die konsolidierten Daten, sobald sie von den Vertriebsmitarbeitern erfasst wurden.

Das Projektziel

Wir hatten die Entwicklung einer mobilen App für das iPad vor Augen, die alle ca. 250 Außendienstmitarbeiter nutzen sollen, um ihre wichtigsten Vertriebskennzahlen stets im Blick zu haben. Übergeordnetes Ziel der mobilen App war es, den Außendienstmitarbeitern unabhängig von Zeit und Ort die Möglichkeit zu geben, sich über ihre aktuelle Vertriebsperformance zu informieren.

In der folgenden Grafik seht ihr – natürlich stark vereinfacht – die Projektschritte, die Veränderungen sowie Vorteile der SAP Fiori Applikation:

Inspiricon ERCO-Projekt

Am Ende stand ein mobiler, schlanker und vor allem sehr einfacher Prozess für das Monitoring und für die Anpassungen der Prognosen zur Verfügung. Mitglieder der Geschäftsführung und Vertriebsmitarbeiter haben damit immer die aktuellsten Daten zur Verfügung. Dies führt zu einer erheblichen Wertsteigerung der Daten. Das ist vor allem im Business Intelligence-Umfeld entscheidend, denn dort ist der Wert einer Information abhängig von ihrem Aktualitätsgrad.

Wir freuen uns, dass unser Kunde nach Einführung der SAP Fiori Applikation sehr zufrieden ist. So sagte Celina Berg, Projektleiterin der ERCO GmbH, nach Abschluss des Projektes:

„Inspiricon hat das Projekt professionell von Anfang bis Ende erfolgreich durchgeführt. Die Kommunikation war offen und direkt. Der Status des Projektes war jederzeit transparent. Unser Projektziel wurde in Time & Budget erreicht. Wir freuen uns, mit der Inspiricon auch in der Zukunft zusammen zu arbeiten.“

Auch wir sind gespannt auf weitere gemeinsame Projekte! Die Success Story zu diesem Projekt findet ihr auf unserer Webseite.

Wenn ihr mehr über SAP Fiori erfahren wollt, schaut doch mal in unserem Blog vorbei unter http://inspiricon.de/category/technologie/sap-fiori/

Autor dieses Beitrags
Gerald Iakobinyi-Pich Software Architect
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
Design Thinking

So findet ihr euren Weg zu Design Thinking

Was ist Design Thinking?

Beim Design Thinking steht der Mensch im Mittelpunkt.

„Design Thinking ist ein benutzerorientierter Innovationsansatz, der sich Anleihen bei der Arbeit von Designern nimmt, um menschliche Bedürfnisse, technische Möglichkeiten und die Voraussetzungen für unternehmerischen Erfolg optimal abzubilden.“
— Tim Brown, President und CEO, IDEO.

Das bedeutet, dass sich beim Design Thinking alles um die Benutzererfahrung dreht. Bei der Entwicklung von Produkten oder Projekten orientiert man sich an der Lösung und nicht am Problem. Ziel ist es, eine Lösung zu entwickeln, die auf die Bedürfnisse ihrer Nutzer ausgerichtet ist, anstatt sich allein auf die technische Herausforderung zu konzentrieren.

So wichtig das Design (Look & Feel) eines Produktes oder einer Lösung auch ist, ist es doch nur ein Puzzleteil, denn im Design Thinking kommen alle Aspekte zusammen: Look & Feel, Nutzung, Anwenderzufriedenheit und -nutzen.

„Die meisten Menschen machen den Fehler zu denken, dass es bei Design nur darum geht, wie es aussieht. Die Leute denken, es ist nur Fassade – dass man den Designern einen Kasten in die Hand drückt und sagt: ‚Macht, dass es gut aussieht!‘. Das ist nicht unser Verständnis von Design. Design ist nicht nur, wie etwas aussieht. Design ist auch, wie etwas funktioniert.“
— Steve Jobs, Mitgründer und CEO, Apple Inc.

Warum ist Design Thinking wichtig?

Eine Bewertung des Design Management Instituts hat ergeben, dass designorientierte Unternehmen wie Apple, Coca-Cola, IBM oder Nike den S&P-500-Aktienindex in den vergangenen 10 Jahren um rund 228 % übertroffen haben (mehr unter dazu hier).

Design-zentrische Unernehmen

Aus der Untersuchung geht ganz klar hervor, dass Unternehmen, bei denen die Benutzererfahrung an erster Stelle steht, erfolgreicher sind. Dementsprechend kommt eine Konzentrierung auf das Kundenerlebnis auch den Aktionären zugute.

Wie wird beim Design Thinking vorgegangen?

Jeder einzelne Schritt in diesem Ansatz setzt tiefgreifende menschliche Interaktion und ein entsprechendes Verständnis voraus:

  1. Discovery – Beim ersten Schritt im Design-Thinking-Prozess geht es darum, ein empathisches Verstehen für das zu lösende Problem zu entwickeln. Engagieren Sie sich, sammeln Sie Wissen, beobachten Sie die Nutzer und versetzen Sie sich in ihre Lage, um ihre Erfahrungen und Motivationen besser zu verstehen. Stellen Sie sicher, dass Sie die zugrunde liegenden Probleme auch auf persönlicher Ebene ganz genau verstehen. Einfühlungsvermögen ist unerlässlich für diesen Prozess, da er ein Verständnis für die Nutzer und deren Bedürfnisse schaffen soll.
  2. Interpretation – Analysieren Sie die Beobachtungen, die Sie im ersten Schritt gemacht haben. Fassen Sie die in Schritt eins gesammelten Daten zusammen, um die Probleme zu definieren, die Sie und Ihr Team ermittelt haben.
  3. Ideation – Beginnen Sie mit der Ideenfindung. Gehen Sie dabei neue Wege und seien Sie innovativ. Es gibt verschiedene Verfahren zur Ideenbildung, die Denkanreize schaffen und neue Ideen hervorbringen können, so zum Beispiel Brain Storming, Collaborative Sketching oder Reverse Thinking. Versuchen Sie, neue Lösungen zu finden, sammeln Sie anfangs so viele Ideen wie möglich und verfeinern Sie sie im Laufe der Ideenbildung.
  4. Experimentation – Prototyp: Bauen Sie einen oder mehrere preisgünstige Prototypen und testen Sie sie. Dies ist ein iterativer Prozess, der der Validierung der Ideen dient. Geben Sie die Prototypen weiter, lassen Sie sie von Ihrem Team ausgiebig testen, stellen Sie aber auch sicher, auch Dritte zu beteiligen, so zum Beispiel zukünftige Nutzer. Hören Sie sich ihre Meinungen an und wiederholen Sie gegebenenfalls die Ideenfindung und
    -entwicklung.
  5. Evolution – Setzen Sie die besten Ideen um. Testen Sie das fertige Produkt, sammeln Sie Feedback und behalten Sie die Benutzererfahrung genauestens im Auge. Dabei werden unter Umständen Probleme und Aspekte zu Tage treten, die eine Weiterentwicklung des Produkts erforderlich machen. Sie müssen den Kontext der Produktnutzung verstehen, wie Menschen mit dem Produkt interagieren und wie sie zu ihm stehen. Setzen Sie dieses Wissen ein, um das Produkt zu verbessern.

SAP Fiori und Design Thinking

SAP Fiori ist SAPs Antwort auf die Anforderungen, die einer besseren Benutzererfahrung zugrunde liegen. Es fungiert als Designleitfaden und -standard für Unternehmensanwendungen. Es ist das neue Gesicht von SAP für alle Business User und stellt eine nahtlose Benutzererfahrung in den Mittelpunkt.

Die Anwendungen sehen nicht nur besser aus, mit SAP Fiori ist es zudem möglich, Unternehmensanwendungen praktisch auf jeder von den Endanwendern genutzten Plattform bereitzustellen, egal ob auf dem Desktop oder dem Mobilgerät.

Während SAP Fiori als Designleitfaden für die für Business User angestrebte Benutzererfahrung einer Anwendung dient, stellen die SAP UI5 Libraries die notwendigen Tools für eine schnelle und einfache Umsetzung von Anwendungen auf Desktops und Mobilgeräten nach Maßgabe der SAP-Fiori-Leitlinien zur Verfügung.

Aber das ist noch längst nicht alles. Sie sind nur ein Teil des Ökosystems, das SAP nach und nach aufbaut, um den Einsatz von Design-Thinking-Methoden zu vereinfachen. Tools wie SAP Web IDE und Tools für ein schnelles Prototyping wie zum Beispiel build treten in Erscheinung und werden fortlaufend verbessert, um Entwicklungsteams die optimalen Tools für ihren Design-Thinking-Prozess an die Hand zu geben.

Mit SAP Fiori und dem Ökosystem, das sich rundherum entwickelt, treibt SAP zudem nachdrücklich die Einführung der Design-Thinking-Methode voran, um die Geschäftsprozesse von Unternehmen zu optimieren.

Wir haben uns in einem früheren Artikel bereits mit dem Mehrwert beschäftigt, den der Einsatz von Design Thinking und einer Konzentration auf die Benutzererfahrung für Unternehmen mit sich bringt. Zum Artikel geht es hier.

Bei Fragen rund um Design Thinking, SAP Fiori und UX stehe ich Ihen gerne zur Verfügung!

Autor dieses Beitrags
Gerald Iakobinyi-Pich Software Architect
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de

Ein Erfahrungsbericht zum Upgrade auf SAP BW 7.5 oder „Unverhofft kommt oft“

Hallo zusammen,

heute gibt es einen Erfahrungsbericht aus einem unserer letzten Kunden-Projekte. Es ist immer wieder spannend zu den ersten zu gehören, die mit neuen Releases, Support-Packages oder Tools arbeiten dürfen. Allerdings gibt es hierbei durchaus Tücken. Von einer solchen Überraschung handelt dieser Bericht.

Wir entwickelten im Rahmen einer Migration sehr viele Daten-Modelle basierend auf den „neuen“ Objekten ADSO (Advanced Datastore Objects) und Composite Provider, um diese als HANA-Views verfügbar zu machen und anschließend mit Native HANA-Mitteln weiterzuverarbeiten.

In diesem Beitrag konzentrieren wir uns auf ein Problem, welches beim Upgrade von SAP BW 7.4 auf BW 7.5 auftrat. Dieses Upgrade fand während unseres Projektes statt.

Wie gesagt unsere Datenmodelle basieren hier vor allem auf ADSOs. Diese ADSOs können so modelliert werden, dass sie sich wie ein Cube verhalten oder wie ein klassisches DSO. Sprich entweder sie haben einen dedizierten Schlüssel (Variante DSO) oder alle Merkmale bilden gemeinsam den Schlüssel (Cube).

Ein weiterer Unterschied zwischen einem Cube und einem DSO ist, wie die Einheiten von Kennzahlen verwendet werden:

Bei Cubes gehört die Einheit zur Kennzahl: sie werden bei Transformationen in einer Regel verarbeitet.

cube-regel

Bei DSOs sieht es etwas anders aus. Hier wird die Einheit als separates Feld behandelt (also in Transformationen in 2 Regeln).

DSO

DSO-Feld

Unter SAP BW 7.4 wurden alle ADSOs wie DSOs behandelt (zwei Regeln).

Wir staunten also nicht schlecht, als nach dem Upgrade die Transformationen zu allen ADSOs, die wie Cubes modelliert waren, nicht mehr funktionierten. Wir erhielten keine Fehlermeldungen, vielmehr kam es zu Verschiebung der Daten zwischen den Feldern. Es waren ja jetzt weniger Felder in der Zielstruktur. Als wir dann versuchten die Transformationen zu untersuchen, erhielten wir folgenden Fehler:

Transformation-Fehler

Wie erwähnt kam der Fehler nicht direkt und auch die Datentransferprozesse (DTPs) liefen teilweise „sauber“, also ohne Fehlermeldung. Die Transformationen selbst wurden als aktiv angezeigt. Die Fehlermeldung erschien immer nur dann, wenn die Transformation geöffnet wurde. War keine besondere Logik hinterlegt, wurde sogar, wenn man die Transformation im Änderungsmodus öffnete, als automatischer Vorschlag die fehlende Einheit zugewiesen.

Leider gab es zum damaligen Zeitpunkt keine Korrektur von der SAP! Uns blieb an dieser Stelle nichts anderes übrig, als die Fehler manuell zu korrigieren.

Kennt eine/r von euch das Problem? Gibt es mittlerweile eine Lösung der SAP?

Wir standen vor der Wahl alle ADSOs auf den Modus „Standard-DSO“ umzustellen und dann zu hoffen, dass die automatische Aktivierung die Transformationen wieder korrekt zuordnet.
Oder wir mussten alle Transformationen auf dem Testsystem anpassen.

Die Anpassung des ADSO-Modus war leider nicht möglich, da dies einen großen Einfluss auf unser Datenmodell gehabt hätte. Also hieß es Zähne zusammenbeißen und in einer Hau-Ruck-Aktion mit vereinten Kräften die Transformationen anzupassen. Leider gab es bei komplexeren Logiken größere Komplikationen, da die ungültigen Regeln gelöscht wurden (und die anderen Systeme aktuell nicht verfügbar waren). Wir konnten alle Probleme lösen und das Projekt mit vertretbarer Verzögerung in die nächste Phase bringen. Das ließ sich allerdings nur durch eine geschlossene Mannschaftsleistung erreichen, wie sie in solchen Projekten unerlässlich und für Inspiricon charakteristisch und selbstverständlich ist.

Unsere Erkenntnis in diesem Projekt war, dass neue Tools immer sehr, sehr spannend aber eben auch fehleranfällig sind. Wir versuchen deshalb neue Themen frühzeitig auf unseren internen Systemen zu testen (aktuell finden Versuche mit Predictive Analytics, Lumira 2.0 sowie SAP Leonardo statt).

Leider kann man nicht alles testen und bestimmte Dinge wie Upgrades oder Migrationen sind doch immer wieder sehr individuell. Wir berücksichtigen das in unseren Projekten, indem wir mit entsprechenden Puffern arbeiten und den Kunden über die Risiken und Chancen eines Upgrades aufklären. Gemeinsam entscheiden wir, welche Strategie für das aktuelle Projekt die Richtige ist.

Autor dieses Beitrags
Jörg Waldenmayer Team Lead Technology
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de