Author Archive: Oliver Wahrstötter

Hat irgendwer Zeit unsere alten Listen S4 tauglich zu machen

Hat irgendwer Zeit unsere alten Listen S/4 tauglich zu machen

Posted on by

Mitten in der S/4HANA Einführung kommen die Anforderungen aus dem Fachbereich. „Wir brauchen aber die Lagerstandsauswertung XY nach VKORG unbedingt auch. Ohne der können wir nicht arbeiten.“
Verständlich, denn die Mitarbeiter beschäftigen sich jetzt intensiv mit dem neuen System und versuchen ihre bestehenden Prozesse nachzuspielen.

Aber da fehlt jetzt was.
Klar, die bestehenden Auswertungen und Listen, die in jedem alten R/3 System vorhanden sind. Ohne sie wird der weitere Prozess schwierig.

Aber das Projekt ist bereits in vollem Gange, die Aufwände sind budgetiert und die Ressourcen eingeteilt. Klar, man will immerhin rechtzeitig fertig werden.

Und der Druck wird größer. Auch wenn man im neuen System vielleicht eine andere Herangehensweise an die Prozesse hat, die Leute aus dem Fachbereich wollen dennoch eine gewisse Stabilität. Vielleicht wird man einige dieser Listen im Laufe der Zeit wieder los – vielleicht aber auch nicht. Jedenfalls jetzt – kurz vor GoLive – wo alle nervös sind und die Lage angespannt ist, ist der falsche Zeitpunkt dafür. Also werden die wichtigsten dieser Reports in die neue Fiori Oberfläche übertragen.

Aber wer kennt sich genau aus, wie der Report funktioniert? Wie die Daten gelesen werden? 3000 Zeilen Spaghetti Code aus dem Jahre 1998 wollen auch erst einmal neu gebaut werden.

Genau hier hilft unser Rapid Report Generator.

  • Mit etwas Customizing wird der Report einfach in eine moderne Fiori Applikation verwandelt.
  • Die Logik der Datenbeschaffung bleibt im Report. Der Selektionsbildschirm und die Ergebnisliste werden transformiert.
  • Die Navigation in Business Objekte kann auch durch Fiori Links ersetzt werden.
  • Auch der „Warenausgang“ kann gebucht werden. Sowie beliebige andere Aktionen können ausgeführt werden.

UI38 (so war unser interner Arbeitstitel) kann aber noch viel mehr. Sie haben eine zentrale Stelle, um auch neue Reports anzulegen. Egal ob CDS View basiert, oder in Methoden ausprogrammiert, mit simplem Customizing bekommen Sie diese schnell und einfach in Ihr Fiori Launchpad. Die Arbeit des Rapid Report Generators ist also mit der Einführung noch nicht zu Ende. Im Gegenteil, er ist das zentrale Tool, um Informationen aus dem ERP System schnell an die gesamte Belegschaft zu übermitteln!

Fazit

Unserer Erfahrung nach gibt es diese absolut notwendigen Reports in jedem Unternehmen. Mal sind es 7, mal 100 Listen. Das ist von Unternehmen zu Unternehmen unterschiedlich. Mit dem Rapid Report Generator bekommen Sie diese, unabhängig von der Anzahl, in kürzester Zeit in die Fiori Oberfläche. Somit sparen Sie jede Menge Zeit und kostbare Nerven bei der Integration und können sich um die wesentlichen Dinge kümmern!

Typische Support Anfragen in SAP Systemen

Typische Support Anfragen in SAP® Systemen

Posted on by

und wie das SQL Cockpit uns das Leben vereinfachen kann

Wer kennt das nicht. Die Systeme sind aufgesetzt und eingestellt, die Erweiterungen programmiert und die Schnittstellen laufen. Die Tests waren erfolgreich und das SAP System wurde produktiv gesetzt. Dennoch kommen immer wieder Supportanfragen herein. 

Das kann natürlich verschiedenste Gründe haben. Nehmen wir mal an, dass die Entwicklungen sehr sauber waren, das System gründlich getestet wurde und wenig es kaum neue Anforderungen gibt, die umgesetzt werden, gibt. Unrealistisch? Wahrscheinlich! Aber das es in einem agilen Umfeld mit laufenden Erweiterungen an den Systemen zu Fehlern kommt, ist irgendwie nachvollziehbar. Da ist ja immer alles in Bewegung. 

Aber was sind die häufigsten Gründe für Fehlertickets abseits vom typischen Projektgeschäft? Mir fallen da spontan 2 Gründe ein. 

  1. Verständnisfragen. Gerade, wenn User Transaktionen selten aufrufen, kann es zu Fragen wie „Was muss ich hier eingeben? Warum bekomme ich da einen Fehler?“ . Das kann man meist mit guten Schulungsunterlagen in den Griff bekommen.
  2. seltene Datenkonstellationen. Da kommt auf einmal ein Kunde vom Typ X, aus dem Land Y und der VKORG Z daher. Und da funktioniert dann die Partnerfindung im Beleg plötzlich nicht. Der Grund kann sein, dass diese seltene Kombination beim Test nie abgefragt wurde. Solche Datenkonstellationen können entweder durch Benutzer eingegeben worden sein, aber auch durch Programme verursacht worden sein (zB durch eine Migration oder Schnittstelle)

Wie löst man nun diese Fälle von Datenproblemen?

Im ersten Schritt schaut man sich wohl den Beleg, die Stammdaten des Partners und dann vielleicht auch das Customizing an. Über die regulären Transaktionen im SAP System. Wann man dann gleich draufkommt, super! Fall gelöst.

Aber meistens kommt man da nicht weiter. Vor allem im Second und Third Level Support ist man eher im Programm Code und auf der Datenbank unterwegs um Fehler zu finden und auch um abzuprüfen, ob es auch mehrere ähnlich gelagerte Fälle gibt. Und genau da lässt einen das SAP System meist ordentlich im Stich.

Der übliche Weg führt einen dann in die SE16 (wer den Transaktionscode nicht kennt: da geht es zur Einzeltabellenansicht). Dort sucht man dann nach dem entsprechenden Datensatz und hantelt sich dann langsam von Tabelle zu Tabelle. Mit dem Umweg über das Notepad oder Excel, in dem man die Daten copy&paste zwischen lagert. Das ist mühsam und aufwendig. Aber noch schlimmer: ich muss beim nächsten Mal die gleichen Schritte nochmal machen. Und ganz ehrlich, bei SAP geht es um Daten. Daten, die in einer Datenbank abgelegt sind. Und seit Anbeginn (das sind auf R/2 bezogen 42 und auf R/3 gerechnet 30 Jahre) gibt es keine vernünftige Lösung, damit diese Daten schnell, flexibel und vA auch sicher durchforstet werden können.

Ein klassisches Beispiel sind wohl Inkonsistenzen bei Adressen. Wohl auch, weil die meisten SAP Berater und Kollegen den Teil der SAP Welt auch gut kennen. Geschäftspartner werden fast überall verwendet. Um Adressen zu Geschäftspartnern zu analysieren muss man zuerst vom BP Stamm (BUT000) über den Adresslink (BUT020) zu den Adressen (ADRC) springen.

Also Tabelle – Excel – Selektionsschirm – Tabelle – Excel – Selektionsschirm – Tabelle. Schon ist man am Ziel. Aber dann kommt man drauf, dass es um Personen geht und dort auch das Feld PERSNR mitspielt. Also wieder alles von vorne…

Und jetzt kommt das SQL Cockpit ins Spiel. Hier kann ich mir die Tabellen alle gleichzeitig anschauen und verknüpfen. Da sehe ich das Problem dann auch einen Blick. Und was noch besser ist, einmal ausgeführt, bleibt die Abfrage in meiner Historie bestehen und ich kann sie jederzeit wieder ausführen. Beim ersten Problem bin ich mit dem SQL Cockpit vielleicht nur geringfügig schneller als „von Hand“, aber beim zweiten Mal spar ich schon 90% der Zeit. Und wenn es dann doch öfters auftritt, dann speichere ich diese Abfragen zusätzlich ab und stelle sie sogar meinen Kollegen zur Verfügung.

Am nächsten Tag einfach das Statement von gestern genommen:

und irgendwann nach dem 3,4 Mal (ok, bei mir wahrscheinlich nach dem 20. Mal – ich bewundere die Kollegen die so strukturiert sind) wird das ganze abgespeichert damit es auch die Kollegen nutzen können:

Ich nutze das SQL Cockpit seit 10 Jahren bei meinen Kunden. Und es ist aus meiner täglichen Arbeit nicht mehr weg zu denken. Manche Kunden nutzen es noch nicht, da muss ich dann auch immer über die SE16 arbeiten 🙁

Zählt doch mal, wie oft ihr täglich die SE16 nutzt. Wenn ihr in eurem Unternehmen auf weniger als 10 Abfragen pro Tag kommt (wohlgemerkt im gesamten Unternehmen, nicht pro User!), dann ist das SQL Cockpit für euch wahrscheinlich nicht geeignet. Sobald ihr mehr Abfragen macht, dann wird es sehr nützlich sein!.

SAP Hana® – das SQL Cockpit kann helfen

Posted on by

In den vergangenen Jahren gab es in der Software Architektur die Bestrebungen, alles zu abstrahieren. Die tatsächlichen Zugriffe auf die Datenbank wurden dadurch immer weiter in den Hintergrund gedrängt.

Das hatte den Vorteil, dass es für Entwickler leichter wurde, da die relevanten Daten schön in Objekten vorhanden waren. Auf der anderen Seite haben die Entwickler damit den Zugang zu den Daten aus den Augen verloren. Dies zeigt sich vor allem in performancekritischen Applikationen, da dort viele inperformante und oft auch zu viele unnötige Datenbankzugriffe vorhanden waren, und dies sehr schnell spürbar wurde.

SAP HANA verhilft mit seiner in Memory Technologie nun den Datenbankzugängen zu einer neuen Renaissance. Plötzlich sind SAP Berater gefordert, die Performance bereits an der Quelle (der Datenbank) zu optimieren.

Wenn man nun in einem HANA Implementierungsprojekt einen Prozess aus einem System (z.B. SAP ERP) in die in Memory Technologie verlagern möchte, dann muss man zunächst diesen Prozess und die relevanten Daten analysieren. Danach werden die Daten in das HANA System geladen und dort die Zugriffe optimiert. Für den ersten Teil (die Analyse) gibt es nur die üblichen SAP Standardmittel (die meisten Berater nehmen dann die SE16), um die Daten auszuwerten. Danach werden sie transferiert und im HANA System gibt es dann externe Tools (also schon von SAP, aber nicht innerhalb des SAP Systems, sondern als Plugin in der Java Entwicklungsumgebung Eclipse), um die SQL Zugriffe zu optimieren.

Genau bei diesen beiden Prozesschritten kann das Cadaxo SQL Cockpit aber wichtige Dienste leisten, um den Einführungsprozess wesentlich zu beschleunigen. Zuerst können die Daten bereits im Quellsystem mit SQL Syntax analysiert werden. Das ermöglicht bereits eine erste Abschätzung der Optimierungspotenziale. Und quasi als „Abfallprodukt“ sind für die SQL Optimierungen die Statements schon vorbereitet.

Der Medienbruch ist auch nicht zu unterschätzen. Für SAP Berater, die seit Jahren alle Tätigkeiten innerhalb eines Systems (SAP NetWeaver) durchführen konnten, und ohne externe Tools ausgekommen sind, ist es viel einfacher im SAP System die Daten zu analysieren, als zunächst ein externes Tool zu installieren, die Zugriffe (Security) auf das System einzurichten, um dann die Analysen durchzuführen. Auch die tiefe Integration (z..B. konsequente Vorwärtsnavigation) innerhalb eines SAP Systems verhilft einem Berater zu wesentlich schnelleren Ergebnissen, als dies durch externe Zugriffe möglich wäre.

Aus diesem Grund sind interne Applikationen externen vorzuziehen. Dies gilt zumindest bei SAP Systemen immer!  Somit wäre das SQL Cockpit (intern) für alle SAP HANA Projekte ein wesentlicher Beschleunigungsfaktor.

Ist SAPUI5® wirklich der große Wurf?

Posted on by

Ende der 90er, am Höhepunkt der ersten dot.com Blase, wurde SAP scharf ob ihrer nicht vorhandenen Webfähigkeiten kritisiert. Seitdem ist viel passiert und viele verschiedene Webtechnologien sind gekommen und auch wieder gegangen. Ich hatte immer das Gefühl, das SAP stets auf der Suche nach der richtigen Technologie, dem richtigen Vorgehen war.

 

Bei dieser Suche gab es für mich gab es drei Meilensteine. Der Internet Transaktion Server (ITS), der es ermöglicht hat jede beliebige SAP GUI Transaktion im Web darzustellen. Die Usability war natürlich grausam, aber noch heute ist es die schnellste und einfachste Methode bestehende Applikationen im Web verfügbar zu machen. Die meisten Kunden verwenden es zum Glück nur für selten genutzte Applikationen.

 

Business Server Pages (BSP). Entstanden als Freizeitprojekt einiger Walldorfer Entwickler, legte diese Technologie die Grundlage für den Web Application Server wie wir ihn heute kennen. Und viele andere SAP Webtechnologien rendern zu guter Letzt mittels BSP deren User Interface.

 

Für mich ist SAPUI5 jetzt der dritte große Meilenstein. Was bringt mich dazu, das zu glauben? Um das zu begründen sollten wir zuerst schauen, was SAP aus den vergangenen User Interfaces gelernt hat. Mit BSP war SAP am Puls der Zeit. Man hatte eine ähnliche Technolgie wie Microsoft mit ASP (Application Server Pages) und Java mit JSP (Java Server Pages). Bei den Technologien und Ansätzen, die sich daraus entwickelt haben, sind vor allem Webdynpro und WebUI zu nennen. Dies sind keine Webrendering Technologien, sondern Konzepte und Frameworks, die Entwicklern die Programmierung von strukturierten Anwendungen erleichtern sollten. Leider hat SAP damals immer mehr sein eigenes Süppchen begonnen zu kochen, sodass man sich von den großen Strömungen entfernt hat. Insbesondere im Bereich der Usability und der Nutzbarkeit in verschiedensten Browsern und auf unterschiedlichsten Endgeräten, wurde der Anschluss verpasst.

 

Dann kam HTML5 und damit nicht nur eine neue Webtechnologie (mit HTML wie man es aus den Neunzigern kennt, hat HTML5 herzlich wenig zu tun) sondern auch ein neues Designparadigma, wie man am Besten für unterschiedlichste Endgeräte entwickeln sollte.

 

Es hat wohl ein Umdenken innerhalb der SAP stattgefunden, denn jetzt hat SAP plötzlich bekommen, alles richtig zu machen. Anstelle der Entwicklung einer ähnlichen Technologie setzt SAP nun genau auf HTML5 auf. Somit profitiert SAP sofort von allen Weiterentwicklungen des weltweiten Standards HTML5. Und SAPUI5 ist ja keine eigenständige Technologie, sondern eine zusätzliche API, die die Darstellung von Geschäftsprozessen und Daten im Web vereinfachen und verbessern soll.  Davon hat SAP sogar eine Open Source Version (OpenUI5) veröffentlicht.

 

Die richtige UI Strategie zu haben reicht aber nicht aus um festzustellen, ob diese sich auch durchsetzen wird. Denn oft waren die besten Produkte nicht die, die sich dann am Ende durchgesetzt haben. Was lässt mich also glauben, das SAPUI5 sich jetzt hier durchsetzen wird?

 

Es sind die vielen neuen Produkte, der SAP, die jetzt bereits auf diese Technologie setzen. SAP Fiori verwendet UI5 als Technologie um Prozesse aus den bestehenden Systemen einfach und übersichtlich web fähig zu machen. Es gibt schon über 400 verschiedene Apps der SAP und es ist kein Ende in Sicht.

 

SAP Cloud Systeme. Egal ob es die HANA Cloud Platform ist, auf welcher Entwickler mit SAPUI5 neue Applikationen bauen können, auch viele Cloud Standardlösungen der SAP (zB Cloud for Customer) setzen bereits auf der UI5 Technologie auf.

 

Das sind schon viele Zeichen, die die Wichtigkeit dieser UI Strategie erahnen lassen. Aber das größte Argument kommt noch. S4 HANA, DIE Zukunft der SAP, das System, das das erfolgreichste und am weitesten verbreitete Produkt der SAP Familie ablösen soll, das in die Fußstapfen von R/3 (Entschuldigung: SAP ERP) treten soll. Dieses Produkt setzt komplett auf SAPUI5 als Oberflächentechnologie.

 

Und damit ist für mich klar. Das ist keine weitere zusätzliche Oberfläche, die in bestimmten Szenarien und einigen Lösungen zum Einsatz kommt, sondern das wird alle anderen Oberflächen ablösen oder zu Nischenanwendungen degradieren. Und das finde ich gut. Es ist eine großartige Technologie, sie ist wunderbar mit Non-SAP Technologien kombinierbar. Egal ob es einmal sehr fancy sein soll, oder bestimmte Technologien in SAP Prozesse integriert werden können (zum Beispiel Image Recognition), als Entwickler kann man aus einem unendlichen Pool an Lösungen auswählen.

 

 

 

 

 

Consulting Portfolio

Posted on by

Consulting PortfolioUnsere Berater sind seit vielen vielen Jahren erfolgreich für unsere Kunden im Einsatz. Wir haben schon die unterschiedlichsten Technologien und SAP Anwendungen kommen und auch wieder gehen sehen.

Unser Vorteil ist, das wir uns nie auf einzelne Module oder Bereiche beschränkt haben. Unser Ziel war es immer die Prozesse End2End beraten und implementieren zu können. Das klassische „Das macht der Kollege vom Modul XY“ ist und fremd.

Weiter lesen→

SAP Fiori® in a nutshell

Posted on by

Eines gleich vorweg: auf dem UI Sektor tut sich was. Ich möchte Ihnen in einem kurzen Überblick den Aufbau, die wichtigsten Features und Einsatzmöglichkeiten des neuesten SAP UI Babys Fiori geben.

Was ist SAP Fiori?

SAP Fiori, oder SAP Fiori UX, ist SAPs neue „User Experience“, also quasi ein neues „Benutzererlebis“ und steht für neue, moderne Designprinzipien.

Es stellt die etwa 200 am häufigsten genutzten SAP-Funktionen auf einer neuen, intuitiven Benutzeroberfläche bereit, die man an seine persönlichen Wünsche anpassen kann.

Entwickelt wurde Fiori sowohl für Manager und als auch für Mitarbeiter.

Man kann verschiedene Tätigkeiten wie z. B. Self Service Workflows, Abwesenheitsanträge, Zeiterfassung oder Bestellungen durchführen, und diese dann direkt in Fiori anlegen und dort auch genehmigen.

Ganz egal, ob am PC, am Tablet oder am Smartphone, SAP Fiori läuft auf allen drei Gerätearten gleichermaßen gut. Somit hat man dieselbe User Experience (eben UX), also das Benutzererlebnis, auf allen drei Geräten.

Die Oberfläche basiert auf SAP UI5 und passt sich unterschiedlichen Bildschirmgrößen an.

SAP Fiori ist kostenlos.

Apps

SAP Fiori basiert auf Apps, die unterschiedliche Einsatzgebiete und auch technische Anforderungen haben.

Es gibt drei Arten von Apps:

Die Transactional Apps – wie der Name schon sagt, kann man mit ihnen Transaktionen durchführen, wie z. B. Urlaubsanträge von Mitarbeitern bearbeiten und diese genehmigen. Aufgrund der Perfomance wird empfohlen SAP HANA zu verwenden, allerdings laufen diese auch auf anderen Datenbanken.

Die Analytical Apps – das sind quasi Real Time Informationen aus der SAP Business Suite, also damit kann man sich seine Key Performance Indikatoren live anschauen. Diese Apps brauchen relativ viel Performance und laufen NUR auf SAP HANA.

Die Fact Sheets – diese zeigen Informationen an. Man kann von einem Fact Sheet zum nächsten browsen. Angezeigt werden verschiedene Inhalte und Informationen, die im Zuge der Business Operations relevant sind. Diese laufen auch NUR auf SAP HANA.

Weiters gibt es eine Wave 1 mit 25 Apps (aus den Bereichen: Human Ressources, Sales, Procurement) und eine Wave 2 mit 180 Apps (unter anderem aus dem Bereichen: Manufacturing, Finance, Supply, …)

Praktischer Nutzen

Stellen Sie sich vor, Sie stehen als Manager gerade in der Früh beim Bäcker, und es steht eine Liste von Freigaben für Aufträge an, und Sie können diese schnell und einfach auf Ihrem Handy erledigen. Im Büro angekommen legen Sie schnell ein paar Kundenaufträge an, und kurz darauf bei einem Meeting haben Sie auch schon wieder die wichtigsten Informationen auf einem Tablet zu den wichtigsten Lieferungen und Rechnungen schnell zur Hand. Einfach und praktisch mit SAP Fiori, damit können Sie praktisch an jedem Ort mit einer einheitlichen Benutzeroberfläche arbeiten. Diese passt sich, dank der Responsive-Design-Prinzipien, einfach an die Formfaktoren der verschiedenen Geräte an, und so haben Sie auf allen Plattformen die gleiche Benutzeroberfläche zur Verfügung.

Fazit: alles in allem ist es ein großer Gewinn an Benutzerfreundlichkeit und Performance.

Um in „SAP Fiori Style“ zu programmieren, muss man gewisse Guidelines beachten und in UI5 entwickeln.

UI5

SAP UI5 ist SAP’s Toolkit zum Bauen von Web Applikationen mit HTML5.

Es basiert auf Java Script.

Dafür gibt es ein eigenes SAPUI5 JavaScript Development Toolkit mit dem man auf HTML5 basierende Web Applikationen schreiben kann. D.h. es ist quasi ein Sammlung von libraries mit denen man Desktop und Mobile Applikationen schreiben kann, die in einem Internetbrowser laufen.

Es gibt eigene Development Guidelines, die beschreiben wie man damit Webseiten entwickeln kann.

Wie sieht so etwas aus?

Mit JSON:

Weitere Informationen zu Fiori finden Sie in den verschiedenen SAP Fiori Dokumentationen.

Viel Spaß beim Entdecken!