Revolution oder Evolution?
Gemeinsam mit dem mittelständischen Chemieunternehmen Zschimmer & Schwarz hat Consolut eine Migration durchgeführt, um die Neuerungen, die simple Finance schon heute bietet, zu eruieren.
Die Möglichkeit, eine Migration auf einem Kundensystem fernab jeglicher „Laborbedingungen“ durchzuführen, stellte Ansporn und Herausforderung dar. Der Fokus seitens Zschimmer & Schwarz lag vornehmlich auf schnelleren und verbesserten Berichtsmöglichkeiten und zusätzlich auf vereinfachten Zugriffen auf die Datenbanktabellen, um Schnittstellen in einer heterogenen Systemlandschaft effizienter gestalten zu können.
Kind braucht Namen
Im Juni 2015 war es so so weit. Als Testsystem kam ein Hana (SAP ERP 6 EHP 7 sFin 1503) zum Einsatz, welches als Kopie des Produktivsystems erstellt wurde. Parallel dazu wurde ein entsprechendes Non-Hana System (SAP ERP 6 EHP 7, Windows) für vergleichende Tests aufgebaut.
Hier fiel uns zum ersten Mal auf, was später zur Gewissheit wurde: Produktnamen und Bezeichnung von Releaseständen werden von der SAP in kurzen Intervallen geändert. Gab es anfänglich noch die Begriffe Smart Financials und Simple Finance, so war im Juni stets von sFin die Rede.
Aus „SAP Simple Finance add-on 2.0 for SAP Business Suite powered by SAP Hana“ wurde kurzerhand „SAP Simple Finance, on-premise edition 1503“. Unterschieden sich die Releasestände anfänglich noch durch eine klassische aufsteigende Nummerierung, so entschied sich SAP in diesem Sommer dazu, mit Jahr und Monat der Auslieferung (z. B. 1503 = März 2015) das Release zu kennzeichnen.
Analog gilt dies auch für die Support Packages. Aus SAP-Sicht handelte es sich somit um eine Migration mit Release „SAP Simple Finance, on-premise edition 1503, SPS 1505“.
Den Kern der Änderungen im sFin bilden die Änderungen in den Tabellenstrukturen im Bereich des FI/CO. Gab es bisher im SAP ERP Tabellen für Einzelposten und Salden in den Modulen Hauptbuch, Anlagenbuchhaltung, Debitoren, Kreditoren und Controlling, so tritt an deren Stelle eine neue zentrale Tabelle (ACDOCA, neuerdings als „universal Journal“ bezeichnet).
In diese Tabelle sollen entsprechend alle Buchungen aus diesen Bereichen zentral zusammengeführt werden. Finanzbuchhaltung und Controlling werden in der Datenbank vereinigt. Soweit die Theorie. SAP verbindet dieses neuartige Konzept mit der Zusicherung, dass die Stabilität aller Anwendungsprogramme erhalten bleibt.
Dies wird dadurch sichergestellt, dass nach dem neuen Konzept auf einige nicht mehr benötigte Tabellen (z. B. BSID, BSAD, COSP) über sogenannte Kompatibilitätsviews weiter zugegriffen werden kann. Die Anwendungsprogramme nutzen somit weiterhin die altbekannten Tabellen bzw. Views.
Der Abruf der tatsächlichen Daten erfolgt jedoch über neue Views, streng genommen aus der neuen Tabelle ACDOCA. Damit gelingt es SAP, ein neues Tabellenkonzept umzusetzen, ohne dabei massive Änderungen in den Anwendungsprogrammen durchführen zu müssen.
Die Auswirkung dieser Vorgehensweise auf die Performance führt zu einigen überraschenden Ergebnissen. Nicht alle Tabellen werden jedoch durch Kompatibilitätsviews ersetzt. So bleiben z. B. die BSEG und die COEP weiterhin bestehen und werden parallel zur ACDOCA gefüllt. Informationen werden somit bewusst redundant gehalten.
Kinderkrankheiten
Vor dem Eintritt in die schöne neue Welt des „simple Finance“ hat SAP ein Cockpit zur Migration der Daten gesetzt. Dies ist übersichtlich gehalten, und wer schon einmal eine Migration ins neue Hauptbuch oder Ähnliches durchgeführt hat, wird sich hier schnell zurechtfinden.
Über eine Reihe von Schritten sollen die Daten aus den bisherigen Einzelposten- und Saldentabellen in die neue universelle Tabelle ACDOCA überführt werden. Da gibt es am Rande ein bisschen Customizing, und jedem Migrationsschritt folgt mindestens ein weiteres Prüfprogramm.
So ließe sich eine Migration vermutlich in wenigen Stunden durchführen, wenn es nicht irgendwann zu Fehlernachrichten in den Prüfprogrammen käme. Hier entpuppt sich die Anlagenbuchhaltung als Unruhestifter.
Das ist nicht verwunderlich, weil Vorgänge in der Anlagebuchhaltung bedingt durch ihre Laufzeit in mehrere Geschäftsjahre ausstrahlen. Eine Customizingänderung aus dem vergangenen Jahrzehnt kann bei einer Prüfung aus heutiger Sicht durchaus als fehlerhaft erscheinen, obwohl sich die Anwendungsprogramme in all den Jahren nicht daran gestört haben.
Erschwerend kommt hinzu, dass die Datenhaltung in der Anlagebuchhaltung allgemein etwas komplexer ist als in der Hauptbuchhaltung oder im Controlling. An dieser Stelle ging es im Projekt ohne eine OSS-Meldung bei SAP nicht mehr weiter.
Die Unterstützung aus Walldorf führte zunächst zum Einspielen von gefühlt mehr als hundert Hinweisen, deren Freigabedatum zumeist nahe am Tagesdatum lag. Es war mittlerweile August und unsere Annahme, dass ein Programmstand aus dem Mai des gleichen Jahres eine hinreichende Grundlage für die Migration darstellt, erwies sich als Trugschluss.
So hilfsbereit der SAP-Support in der Bearbeitung war, aus seiner Sicht verfügten wir über einen hoffnungslos veralteten Programmstand. In weiteren Gesprächen kristallisierte sich heraus, dass die Migrationsprogramme der Anlagebuchhaltung in unserem Support Package über einige konzeptionelle Mängel verfügten, die erst im nächsten Support Package behoben seien.
SAP half uns schließlich, alle Klippen zu umschiffen und die Migration erfolgreich abzuschließen. Dies wurde mit der Aussage verbunden, dass diese Fehler mittlerweile behoben seien. Es spricht vieles dafür, dass dem so ist.
Nachdem wir dieses Etappenziel erreicht hatten, galt unser Interesse den Neuerungen in der Anwendung. Eine wichtige Erkenntnis lautet: Es gibt praktisch keine Änderungen in der SAPGUI. Hier wird SAP von ihrer intelligenten Strategie eingeholt.
Da die Neukonzeption keine Anpassung der Anwendungsprogramme verlangt, gibt es augenblicklich auch keinen Zusatznutzen. Wie sieht es hingegen mit den vielfach umworbenen Fiori-Apps aus? Hier bleibt unser Fazit aus mehreren Gründen unentschlossen.
Die Anzahl der Fiori-Apps ist gegenwärtig noch begrenzt und weicht teilweise nur geringfügig durch eine Reduktion der Selektionsmöglichkeiten von der SAPGUI ab. In den einschlägigen Videoportalen und Präsentationen präsentiert SAP allzu häufig die gleichen speziellen Prozesse, wodurch sich der Eindruck verfestigt, dass der Zusatznutzen von Fiori augenblicklich noch überschaubar ist.
Optisch stellen Fiori-Apps sicherlich einen Fortschritt dar. Vieles erscheint im Augenblick jedoch nicht durchgängig und weckt Assoziationen an eine Weiterentwicklung der allseits bekannten Enjoy-Transaktionen. Es sei hinzugefügt, dass einige Veröffentlichungen den Anschein erwecken, dass in naher Zukunft Funktion und Anzahl der verfügbaren Fiori-Apps deutlich steigen wird.
Alle Beteiligten hatten natürlich große Erwartungen an die Performance des Hana-Systems. Um eine Vergleichbarkeit zu ermöglichen, wurde das Produktivsystem von Zschimmer & Schwarz (System i) auf eine Windows VM und eine Hana VM mit identischer Hardware kopiert. Der Performance-Vergleich wurde auf SQL-Ebene durchgeführt (siehe Tabelle).
Test #1 und Test #4 zeigen die Stärke des Hana-Systems. In beiden Fällen ist eine deutliche Steigerung der Performance beim Tabellenzugriff zu beobachten. Die Abfrage aus Test #4 ist im Großen und Ganzen vergleichbar mit Test #3.
Überraschend waren die Ergebnisse der Tests #3 und #4. Der auf Hana notwendige Zugriff über den Kompatibilitätsview reduziert die Geschwindigkeit des Lesezugriffs deutlich, sodass Hana hier im Vergleich sogar langsamer als die anderen beiden Systeme ist.
Wir weisen darauf hin, dass die für Hana verwendete Hardware nicht von SAP zertifiziert war. Es ist zu erwarten, dass mit einer zertifizierten (und damit leistungsfähigeren) Hana die Zugriffszeiten auf die Tabellen BSID und BSAD im Bereich SAP ERP auf Windows liegen würde.
Bis zu diesem Zeitpunkt wollte sich bei uns noch keine rechte Freude über unsere bisherigen Ergebnisse einstellen. Zuletzt befassten wir uns mit der Möglichkeit des „realtime reporting“ mit Hana. Eine Möglichkeit besteht in der Nutzung von Hana Live.
SAP liefert Hana Live Content für sFin aus. Damit ist es möglich, mit SAP-BI-Tools (z. B. BO Analysis for Office oder BO Design Studio) direkt auf die Daten der Tabelle ACDOCA zuzugreifen.
Die zweite Möglichkeit stellt die Nutzung eines „embedded BW“ im Hana-System dar. Hierzu wird ein zusätzlicher BW-Mandant im Hana-System angelegt. Auch dort stellt SAP Content zur Verfügung, mit deren Hilfe in Echtzeit auf die sFin-Stamm- und -Bewegungsdaten zugegriffen werden kann.
Da der Datenzugriff über virtuelle InfoCubes erfolgt, können Berichte einfach und sehr schnell mit Standard-SAP-BI-Tools erstellt werden. In beiden Fällen ist kein Laden von Daten notwendig. Die Belege stehen sofort nach der Buchung dem Berichtswesen zur Verfügung. Die Performance des Zugriffs auf die Daten war in beiden Möglichkeiten sehr schnell.
Revolution und Evolution
SAP hat im FICO mit sFin ein zukunftsweisendes Tabellendesign eingeführt. Die Migrationsprogramme waren zum Zeitpunkt unseres Projektes noch fehlerbehaftet. Diese Fehler sollten aber mit einem aktuellen Support Package Level größtenteils behoben sein.
Der Nutzen der Fiori-Apps ist derzeit noch überschaubar. Hier besteht in den nächsten Jahren noch Potenzial. Das Beste kam zum Schluss. Die Möglichkeiten des Echtzeitreportings sind aus unserer Sicht augenblicklich das stärkste Argument für eine Migration nach sFin.
Aus Sicht von Zschimmer & Schwarz ergibt sich augenblicklich ein Mehrwert vor allem für SAP-Kunden, deren komplette ERP-Landschaft unter SAP läuft. Diesen Vorteil kann man bei hybriden Systemen noch nicht erkennen.
Zschimmer & Schwarz entschied sich daher, die weitere Entwicklung abzuwarten und gegebenenfalls zu einem späteren Zeitpunkt den dann verfügbaren Softwarestand nochmals neu zu bewerten. Vielleicht ergeben sich dann genügend Mehrwerte, um gegebenenfalls den Wechsel durchzuführen.
