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

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
Neuerungen und Weiterentwicklungen mit ABAP ab NetWeaver 7.4

Weiterentwicklungen in ABAP – diese Neuerungen gibt es ab NetWeaver 7.40

ABAP wird einfacher, direkter und benutzerfreundlicher

Hallo zusammen,

heute werden wir mal wieder sehr technisch: Wir beschäftigen uns mit Neuerungen in ABAP. Nicht nur die Applikationen und Tools der SAP entwickeln sich weiter. Nein, auch an der SAP-eigenen Programmiersprache wird ständig weiter gearbeitet.

Wir werden euch in der nächsten Zeit häufiger Einblicke über die Sprache, die neuen Tools, Test-Möglichkeiten und vor allem den Einsatz im Umfeld von SAP BW und HANA geben.

Heute beginnen wir mit einigen Neuerungen, die sich in den letzten Jahren in ABAP ergeben haben. Da diese Änderungen immer vom jeweiligen System-Stand abhängen, kann es sein, dass sie für einige unter euch noch sehr neu, für andere bereits Jahre alt und für die nächsten noch nicht einmal verfügbar sind.

Rückblick auf NetWeaver 7.40

Mit dem NetWeaver-Release 7.40 gab es einige sehr interessante Neuerungen bzw. Veränderungen innerhalb von ABAP, die durchaus Einfluss auf die tägliche Arbeit eines Entwicklers haben können. Horst Keller von der SAP hat dazu hier einen sehr guten Artikel veröffentlicht.

ABAP 7.40 ist seit 2013 verfügbar. Seit diesem Zeitpunkt gab es über die verschiedenen Support-Packages noch weitere Anpassungen. Obwohl wir jetzt das Jahr 2017 schreiben, ist es für viele unserer Kunden noch neu oder erst jetzt verfügbar, da die Sprache mit dem jeweiligen NetWeaver-Release einhergeht.

Wir selbst hatten mittlerweile aber das Vergnügen bei einigen Kunden mit dieser Version und höheren (ABAP 7.5 ist ebenfalls verfügbar) zu arbeiten. Wie immer kostet es den einen oder anderen Entwickler Überwindung, die neuen Themen zu verwenden, da sie es eben anders gewohnt sind und es sicher mehr als einen Weg nach Rom gibt.

Zwei konkrete Beispiele für die Neuerungen in ABAP

Aber gehen wir ins Detail. Hier ein paar Beispiele, wie sich die Arbeit mit der Sprache ABAP verändert hat:

Für mich eine der angenehmsten Änderungen ist die INLINE DECLARATION. Wie man es auch aus einigen anderen Sprachen kennt, kann man nun durch solch eine Syntax direkt im Befehl die benötigten Datenelemente deklarieren.

Hier als Beispiel:

Vor 7.4 sah es so aus:

Data: WA type line_of_itab.

Loop at itab into wa.

Endloop.

 

Ab 7.4:

Loop at itab into DATA(WA).

endloop

 

Das Ergebnis besteht nicht nur darin, dass eine Zeile Quellcode eingespart wird, vielmehr findet dadurch auch eine implizite Typisierung statt. Diese Art der Deklaration funktioniert übrigens auch für Field-Symbols und andere Objekte.

Ein weiteres Beispiel für nützliche Anpassung ist der Value Operator:

Vor 7.4:

DATA itab TYPE t_itab.

DATA wa LIKE LINE OF itab.

 

wa-col1 = 1.

wa-col2 = 2.

APPEND wa TO itab.

wa-col1 = 3.

wa-col2 = 4.

APPEND wa TO itab.

 

meth( itab ).

 

Ab 7.5:

DATA(itab) = VALUE t_itab(

( col1 = 1 col2 = 2 )

( col1 = 3 col2 = 4 ) ).

meth( VALUE t_itab(

( col1 = 1 col2 = 2 )

( col1 = 3 col2 = 4 ) ) ).

 

Auch das ist eine Neuerung, durch die unnötige Zeilen und auch Befehle gespart werden können und in meinen Augen den Quellcode auch lesbarer machen.

ABAP vereinfacht vieles

Als weiteres Beispiel für Vereinfachung ist die Durchsetzung von LHS = RHS. Sprich Befehle wie Move A to B werden obsolet. Vielmehr sagt man einfach B = A und ist fertig. Der große Vorteil hiervon ist, dass diese Zuweisungen auch verkettet und in Funktions- bzw. Methodenaufrufen verwendet werden können.

Weitere Veränderungen machen sich ebenfalls in deutlich lesbarerem Code bemerkbar:

result = class=>do_something(EXPORTING p1 = … p2 = … IMPORTING p3 = … p4 = … CHANGING p5 = … p6 = … ).

ABAP bewegt sich hier gefühlt immer weiter in Richtung JAVA und anderen Sprachen, die es erlauben, Methoden-Aufrufe auch mit komplexeren Parametern In-Line zu übergeben. Mit 7.4 funktioniert das jetzt auch bei Exporting- und Changing-Parametern – vorher war das nur mit Importing-Parametern möglich.

Drei neue Befehle für Transformationen

Drei neue Befehle, die ich persönlich vor allem in Transformationen gerne verwende, sind folgende:

DATA(lin) = lines( itab).

DATA(idx) = line_index( itab[ … ] ).

IF line_exists( itab[ … ] ).

ENDIF.

 

Diese Befehle vereinfachen das Prüfen von Tabellen. Sie geben die Anzahl der Lines, den Index einer Bedingung sowie das Ergebnis einer Prüfung zurück. Mit allen Werten kann direkt weiter gearbeitet werden. Vor 7.4 mussten diese Werte-Prüfungen immer erst mit READ-Befehlen ermittelt werden. Diese Befehle konnten nicht verkettet werden. Das hatte zur Folge, dass mit Hilfsvariablen und ähnlichen Konstrukten gearbeitet wurde, was den Code nur bedingt lesbarer gemacht hat.

Ihr habt Interesse an ABAP oder braucht einen Spezialisten in diesem Bereich? Wenn ihr Fragen oder Anmerkungen habt, schreibt mir gerne eine E-Mail an joerg.waldenmayer@inspiricon.de.

Autor dieses Beitrags
Jörg Waldenmayer Team Lead Technology
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Inspiricon SAP-HANA planning application kit 1030x665

Neues von den SAP Planungstools

Heute geht es mal wieder um die Planung. Was ist vom neuen HANA Planning Application Kit zu erwarten und was sind die Unterschiede und Vorteile, wenn man es mit herkömmlichen Standard-Planungsprogrammen vergleicht? Bevor wir diese Frage beantworten, lasst uns zunächst näher auf die Bedeutung von Planung eingehen.

Warum ist Planung so wichtig?

Unternehmen können ihre Entscheidungsfindungen durch eine ordentliche Planung wesentlich verbessern. Mit aktuellen und vergangenen Daten sowie voraussagenden Analysen können sie ihre Ziele für die Zukunft festlegen und steuern. Der Vergleich zwischen aktuellen Daten und Plandaten hilft den Planungsprozess zu verbessern.

Überblick über die SAP BI Planungstools

Wer ordentlich planen möchte, muss in der Lage sein, Daten manuell in ein System einzutragen (eingabebereite Queries). Diese Möglichkeit kann auf verschiedenen Wegen mit zahlreichen Tools erreicht werden, sowohl im BI- als auch im transaktionalen System.

Was Planungstools von einfachen Datenerfassungsfunktionalitäten unterscheidet, ist offensichtlich: Planungstools ermöglichen die Analyse von Daten und die Generierung komplexer Szenarien. Dies kann mit verschiedenen Planungsfunktionen erreicht werden. Diese reichen von simplen Vorgängen wie einfügen, löschen, kopieren und Währungsumrechnung bis hin zu umfassenderen benutzerdefinierten Funktionen. Im Folgenden findet ihr eine Übersicht der SAP BI Planungstools:

Inspiricon Evolution von BI Planung

Inspiricon Evolution von BI Planung

BPS (Business Planning and Simulation)

Anders als bei der Integrierten Planung ist dieses Tool nicht vollständig in das SAP BI-System eingebunden. Einige Funktionen laufen teilweise immer noch auf BPS (z. B. die Kostenstellenkürzung).

Weitere Eigenschaften von BPS:

  • Ebenen der Planung, Planungsfunktionen und Sequenzen werden mit der Transaktion BPS0 erzeugt.
  • Mit BPS0 werden auch manuelle Eintrittslayouts, Filter und Variablen angelegt und nicht mit BEx-Abfragen, Filtern oder Variablen verbunden.
  • Das Frontend ist nicht in den BI-Tools integriert. Stattdessen muss man ein Web-Interface in BPS_WB schaffen.

SAP BI Integrated Planning

Diese Lösung ist vollständig in das SAP BI-System integriert. In der Data Warehouse Workbench werden Datenprovider festgelegt. Mit dem BEx Query Designer werden eingabebereite Queries erzeugt. Alle anderen planungsspezifischen Funktionalitäten wie Planungsfunktionen, Planungsabläufe, Datensegmente und charakteristische Merkmale werden im Planning Modeller definiert. Dieser kann vollständig in eine SAP HANA Datenbank migriert werden, mit dem Vorteil eines verbesserten Lesezugriffs (In-Memory).

Weitere Eigenschaften von SAP BI Integrated Planning:

  • Manuelle Einträge werden direkt im BEx Query Designer erzeugt. Variablen und Filter korrespondieren mit BEx-Variablen und -Filtern.
  • Planungsfunktionen, Sequenzen, Datensegmente, kennzeichnende Zusammenhänge usw. werden in der Transaktion RSPLAN erzeugt.
  • Eine Migration auf die SAP HANA Datenbank ist ohne Anpassungen möglich. Dies führt zu einer schnelleren Reaktionsgeschwindigkeit – davon profitiert auch die Benutzerfreundlichkeit. Die Daten werden nun in einer In-Memory Datenbank gespeichert. Nichtsdestotrotz werden Aggregationen und Kalkulationen weiterhin auf der Anwendungsebene ausgeführt.

SAP Planning Application Kit on HANA

Dieses Tool ist derzeit das Neueste aus dem Bereich Planung. Das Planung-Tool ist im Gegensatz zur obigen Lösung auf In-Memory optimiert. Die Applikation der Business Logik wird von der Applikations-Ebene auf die In-Memory Datenbank verschoben. Dadurch reduziert sich die Datenzirkulation und führt zu einer deutlichen Leistungsverbesserung.

Weitere Eigenschaften des Planning Application Kit on HANA:

  • BW-IP benötigt keine Veränderungen, um mit HANA zu arbeiten. Damit von einer verbesserten Reaktionsgeschwindigkeit profitiert werden kann, müssen die Planungsfunktionen jedoch zuvor migriert werden.
  • Die Ausführung von Kalkulationen In-Memory wird mit dem Planning Application Kit ermöglicht. SAP notes1637199 erklärt die Schritte zur Aktivierung des Kits.
  • Die meisten Planungsfunktionen sind bereits im Planning Application Kit vorhanden (Kopieren, Löschen usw.).
  • Es ist immer noch so, dass nicht alle Planungsfunktionen In-Memory ausgeführt werden können, insbesondere Planungsfunktionen, die auf ABAP exit basieren. Um diese Funktionen In-Memory auszuführen, muss ein SQL-Skript geschrieben werden.
  • Um eine Planungsfunktion zu generieren, die auf einem SQL-Skript basiert, muss ein Funktionstyp geschaffen werden, der auf der ABAP Klasse beruht. Das SQL-Skript wird dann von der Methode Execute abgerufen.
Planung alt/neu

Planung alt/neu

Zusammenfassend kann man sagen, dass mit dem neuen HANA Planungs Kit die gleichen Planungsfunktionen erreicht werden können, die im Standard IP verfügbar sind. Allerdings mit einer grundlegend verbesserten Geschwindigkeit, da eine In Memory-Datenbank genutzt wird.

Lest mehr zum Thema Planung und SAP HANA in unserem Blog.

Euch ist vielleicht aufgefallen, dass wir BPC noch nicht erwähnt haben – dies wird Thema eines nächsten Beitrags sein. Bis dahin!

 

Autorin dieses Beitrags
Gabriela López de Haro Senior BI Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de
Inspiricon SAP BW Upgrade 7.4

Mit den Inspiricon Best Practices zum Erfolg: Erfolgreiches Upgrade SAP BW 7.3 zu 7.4 bei einem weltweit tätigen Pharma-Konzern

In unserem heutigen Blog-Beitrag stellen wir euch ein Upgrade-Projekt vor. Es handelte sich um ein SAP BW Upgrade 7.3 zu 7.4, das in den Jahren 2015 – 2016 realisiert wurde.

Die Anforderungen des Kunden an die Inspiricon waren:

  • Releasewechsel auf SAP BW
  • Steigerung der Systemstabilität
  • Integration von HANA-optimierten Datenmodellen

Eine Zusammenfassung der Vorgehensweise findet ihr auch unter folgendem Link: http://inspiricon.de/wp-content/uploads/2017/02/Inspiricon_Upgrade-SAP-BW-7.4.pdf

Unsere Ausgangsposition

Unser Kunde war vor dem Upgrade auf dem Releasestand SAP BW 7.3 mit unterschiedlichen Service Packages. Ein Upgrade auf die Version 7.4 war erforderlich um

  • die Systemperformance zu erhöhen
  • Mobile Reportings und Applikationen mit Fiori zu entwickeln
  • die SAP Systeme auf dem aktuellsten Stand zu halten (Einspielen der letzten SAP-Hinweise)

Die Herausforderung für Inspiricon

Da unser Kunde global agiert, hat unser Projekt-Team eine sehr heterogene IT-Landschaft vorgefunden. Das bestehende Reporting ist weltweit im Einsatz. Das bedeutet, dass das BI System auf Konzern-Ebene eine Möglichkeit schafft, die Daten weltweit zu verarbeiten, um ein einheitliches Berichtswesen zu gewährleisten.

Konkret waren im Projekt folgende Herausforderungen vom Inspiricon-Team zu lösen:

  • Angeschlossene Systeme und damit verbundene Abhängigkeiten mussten berücksichtigt werden
  • Die bestehende Landschaft ist sehr komplex
  • Während des Releasewechsels liefen viele Projekte parallel auf dem zu upgradenden System. Organisatorisch bedeutete dies, dass der Informationsaustausch zwischen unterschiedlichen Projekten abgestimmt und zeitnah in allen Zeitzonen erfolgen muss.
  • Keine Unterbrechung des laufenden Betriebs („geräuschloses Upgrade“)
  • Testmanagement: Laufende Abdeckung von allen vorhandenen Systemfunktionalitäten

Das Projektteam bestand aus bis zu 20 Personen, davon zwei Nearshoring Ressourcen (BI-IT). Das Inspiricon Nearshoring-Team bereicherte mit seiner langjährigen Erfahrung und Qualitätsansprüchen das Onsite-Team auch durch einen signifikanten Kostenvorteil. Mehr zum Thema Nearshoring gibt es hier.

Inspiricon Projektansatz

Inspiricon Projektansatz

Erfolgreicher Projektabschluss

Ende Mai 2016 war das Go-Live, gefolgt von einer intensiven Hyper Care Phase über 3 Wochen. Während dieser Zeit begleitete unser Inspiricon-Team den Kunden, bis das System wie gewünscht performant und stabil lief.

Durch den Releasewechsel ist unser Kunde nun in der Lage, die neuesten HANA-Objekte in vollem Umfang zu nutzen und von deren Performancevorteil zu profitieren. Die Kundenanforderungen wurden also umfassend erfüllt – Folgeprojekte sind bereits beauftragt.

Inspiricon Best Practices

Aus einem erfolgreichen Projekt können wir viel lernen. Daher wurden aus dem Upgrade-Projekt Vorgehensweisen für weitere Projekte entwickelt. Diese Best Practices enthalten folgendes und werden auf andere Projekte übertragen:

  1. Der Upgrade Prozess (Test-Konzept, Upgrade des Projektzeitplanes)
  2. Upgrade des fachlichen Plans (Pre-Upgrade, Checklisten für das Upgrade und das Post-Upgrade)
  3. Ressourcen-Matrix (Projekt-Organigramm, Rollen und Verantwortlichkeiten, Kommunikationsmatrix)
  4. Herausforderungen und Empfehlungen

Ergänzend zu diesem Blogbeitrag empfehlen wir euch die Lektüre unserer Best Practice „Inspiricon Best Practices im Einsatz“.

Ihr interessiert euch für das Thema SAP BW? Lest unter http://inspiricon.de/sap-bw-bo/  mehr dazu. Gerne könnt ihr uns auch direkt kontaktieren – euer Ansprechpartner rund um SAP BW ist Michael Schmer.

 

Autor dieses Beitrags
Istvan Boda SAP BI Consultant
Tel.: +49 (0) 7031 714 660 0
E-Mail: cluj@inspiricon.de
Inspiricon strategische operative Vertriebsplanung

So wird eine operative und strategische Vertriebsplanung konzipiert und eingeführt

Hallo zusammen,

nachdem in den letzten beiden Artikeln zum Thema Planung theoretische Grundlagen besprochen wurden, schauen wir uns heute ein ganz konkretes Beispiel an. An einem unserer Kunden aus dem Maschinen- und Anlagenbau zeigen wir, wie die operative und strategische Vertriebsplanung konzipiert und eingeführt wurde.

Ein paar Zahlen vorab: Bei unserem Kunden handelt es sich um ein Unternehmen das in 130 Ländern weltweit mit ca. 7.500 Mitarbeiter präsent ist und das einen Jahresumsatz von ca. 600 Mio. EUR hat.

Was bisher in der Planung geschah

Vor der Einführung eines standardisierten Planungsprozesses gab es eine „historisch gewachsene Lösung“ mit vielen unterschiedlichen Prozessen und Planungswerkzeugen. Ein synchronisierter Planungsprozess war nicht vorhanden. Es wurde daher mit sehr viel manuellem Aufwand versucht, in Excel die unterschiedlichen Planungen zu konsolidieren, um ein möglichst genaues Gesamtbild erzeugen zu können. Das galt sowohl für die strategische Planung mit einem Zeithorizont von 5 Jahren, als auch für den monatlich rollierenden Sales Forecast mit einem Zeithorizont über die kommenden 12 Monate.

Das blieb nicht ohne Folgen:

  • Die Planungsungenauigkeiten waren sehr groß zwischen dem was geplant wurde und der tatsächlichen Erreichung.
  • Die Sales Mitarbeiter wurden nicht an der Qualität ihrer abgegebenen Planung gemessen.
  • Das Ergebnis war ein manuell sehr aufwendiger, fehleranfälliger Planungsprozess.
  • Auf Basis der ungenauen Planzahlen wurden Produktionsentscheidungen abgeleitet.
  • Aufgrund der Ungenauigkeiten konnten die produzierten Produkte nicht wie geplant verkauft werden.
  • Erhöhte Lagerkosten sowie eine hohe Kapitalbindung waren die Folge.

Deshalb sollte ein standardisierter Planungsprozess den bestehenden Prozess ablösen.

Das Projekt wurde in mehreren Stufen durchgeführt – Stufe 1

In Stufe 1 wurde die strategische Vertriebsplanung angegangen. Diese wurde bei unserem Kunden als Mid Term Sales Planung (MTP-SP) bezeichnet. Sie umspannte einen Planungshorizont von 5 Jahren.

Nach Erstellung des Fach- und IT-Konzeptes konnte die technische Realisierung beginnen. Die Konzeptarbeit nahm einen Zeitraum von ca. einem halben Jahr ein. Der Planungsprozess für die strategische Vertriebsplanung wurde im gesamten Unternehmen in diesem Zusammenhang auch standardisiert.

Nun findet jedes Jahr im Zeitraum Juli bis August die MTP-SP für die kommenden 5 Jahre statt. Dabei planen sämtliche Vertriebsmitarbeiter, Markt- und Kundenbetreuer die Vertriebszahlen über die kommenden 5 Jahre. Pro Kunde, Land und Vertriebsmitarbeiter werden auf Hauptproduktgruppenebene Absatzmenge und Absatzpreise geplant.
Im ersten Planungsjahr sind die Zahlen monatsgenau zu erfassen, für die verbleibenden 4 Planungsjahre erfolgt die Eingabe nur auf Jahresebene. So ergibt sich nach mehreren Planungsiterationen ein Gesamtbild der Absatzplanung über die kommenden 5 Jahre.

Durch eine hinterlegte Ableitungsmatrix werden aus den Planzahlen Produktionsinformationen abgeleitet. Denn nicht alle Produkte des Unternehmens werden an allen Standorten produziert. Auf Basis dieser Planung können Kapazitätsaussagen abgeleitet werden und Entscheidung zu Kapazitätsverlagerung, Kürzungen oder Erweiterungen getroffen werden.

Die IT-Technische Realisierung erfolgte mit Hilfe von SAP Business Warehouse und dessen Planungslösung BI-IP (BI-Integrierte Planung). Die Realisierung der Stufe 1 dauerte ca. 6 Monate.

Stufe 2 – Konzeption und Einführung einer rollierenden Sales Forecast Planung

Nachdem Stufe 1 eingeführt war, widmete man sich der Stufe 2 – der Konzeption und Einführung einer rollierenden Sales Forecast Planung. Das methodische Vorgehen fand analog zur Stufe 1 statt. Es wurden die genauen fachlichen Anforderungen strukturiert, standardisiert und im Fachkonzept niedergeschrieben. Im Anschluss wurde die technische Umsetzung im IT-Konzept beschrieben, ehe die Realisierung erfolgen konnte.

Der „Rolling Sales Forecast“ findet monatlich statt, es werden immer die kommenden 12 Monate im Detail betrachtet. Die Vertriebsmitarbeiter planen weltweit ausschließlich die geplanten Absatzmengen. Im Gegensatz zu Stufe 1 findet diese Planung eine Granularitätsstufe niedriger statt, es wird auf Produktgruppenebene geplant. Die verbleibenden Planungsmerkmale sind analog zu Stufe 1. Auf Basis dieser Informationen lassen sich die genauen Bedarfe aus Vertriebssicht ableiten. Unter Berücksichtigung der aktuellen Lagerbestände lassen sich so genaue Produktionszahlen ableiten, die in die Grob- und Feinplanung der Produktion überführt werden. Zudem finden diese Zahlen Eingang in die anderen Planungen des Unternehmens, wie z.B. der Personal-, Finanz- und G&V Planung.

Mit spezifischen Planungsfunktionen, die im Rahmen des Projektes eingerichtet wurden, werden die Anwender bestmöglich systemseitig unterstützt. Zum Beispiel schreiben sich die eingegebenen Planzahlen von Periode 1 automatisch in Periode 2 fort, sodass die Vertriebsmitarbeiter nur die bekannten Änderungen in der Folgeperiode erfassen müssen. Dies war besonders benutzerfreundlich und sparte den Vertriebsmitarbeitern jede Menge Zeit bei der Eingabe, da sie sich nur auf die Änderungen zum Vormonat konzentrieren mussten.

Stufe 1 und Stufe 2 gehen Hand in Hand

Zusammenspiel_Strategische-Planung_und_Rollierender-Sales-Forecast

Zusammenspiel Strategische Planung und Rollierender Sales-Forecast

Stufe 1 und Stufe 2 wurden in der Art miteinander integriert, dass sich die Werte aus der MTP-SP in den „Rolling Sales Forecast“ vererben. Weitere Planungsfunktionen erleichtern den Anwendern die Planungsarbeit. Hier einige Beispiele:

  • Eingegebene Jahreswerte können auf Monate heruntergebrochen werden. Man kann dann die Monatswerte, z.B. nach saisonalen Einflüssen korrigieren und anschließend diese Zahlen wieder auf Jahreswerte aggregieren.
  • Verkaufsplanzahlen, die auf Hauptproduktgruppenebene geplant wurden, können auf Basis der letzten 24 Ist-Monate auf eine Ebene tiefer, sprich auf Produktgruppenebene heruntergebrochen werden.
  • Die Verteilung und der Absatz schwanken über das Jahr unterschiedlich stark in verschiedenen Regionen. Mit Hilfe von globalen und lokalen Verteilschlüsseln kann man unterschiedliche Regionen individuell bearbeiten.
  • Es wurden unterschiedliche Plausibilitätsprüfungen eingebaut, die das Ziel haben, automatisiert die Datenqualität zu verbessern. So wird zum Beispiel verprobt, ob der eingegebene Forecast mindestens genauso groß oder größer als der im System abrufbare Order Backlog ist. Wenn nicht, wird eine entsprechende Warnmeldung ausgegeben.

In den nächsten Artikeln zum Thema Planung werden wir einige dieser nützlichen Planungsfunktionen genauer beleuchten und vorstellen.

Nachdem beide Stufen produktiv gesetzt wurden, wurden über einen Zeitraum von einem Jahr Erfahrungen gesammelt. Dann wurde eine Optimierungsphase aufgesetzt, in der die Erfahrungen, Verbesserungsvorschläge und Wünsche der Endanwender Berücksichtigung fanden.

Die Projektziele wurden in vollem Umfang erreicht:

  • Die verschiedenen Planungselemente greifen ineinander, was zu einer Erhöhung der Planungsgenauigkeiten führt.
  • Der gesamte Planungsprozess läuft strukturierter ab. Es gibt einen Planungskalender.
  • Der manuelle Aufwand zur Eingabe und Verifikation der Planzahlen konnte drastisch reduziert werden.
  • Die Aufwandseinsparung im Bereich der Datensammlung, -aufbereitung und -plausibilisierung kann nun für verstärkte Analysetätigkeiten und damit für bessere Informationen genutzt werden.
  • Sowohl die Datenqualität als auch die Planungsgenauigkeit konnten deutlich gesteigert werden. Infolgedessen nahmen die Lagerbestände spürbar ab und die Kapitalbindung reduzierte sich.

Unser Inspiricon-Projektteam begleitete den Kunden während des gesamten Prozesses, von der Erarbeitung der fachlichen Planungsprozesse, über die Erstellung des IT-Konzeptes und der gesamten Realisierung mit SAP BI-IP.

Fragen? Anregungen? Lust auf eine Diskussion zum Thema? Meldet euch, wir freuen uns darauf.

Inspiricon Unternehmensplanung Steuerung

Unternehmensplanung – eine Einführung

Hallo zusammen,
bisher konntet ihr in unserem Blog viel über neue Themen wie Fiori usw. lesen – nun möchten wir euch auch ein wenig mehr über unsere Kernkompetenzen erzählen. Dazu gehört – ganz vorne mit dabei – die Unternehmensplanung (Enterprise Planning). Wir werden uns unter anderem mit folgenden Themen beschäftigen:

  • Was ist Unternehmensplanung?
  • Wozu braucht man das?
  • Auf was kommt es dabei an?
  • Welche Projekte hat die Inspiricon in diesem Umfeld bereits erfolgreich realisiert?

Heute beginnen wir mit einer allgemeinen Einführung:
Wikipedia sagt zu Planung: „Planung beschreibt die menschliche Fähigkeit zur gedanklichen Vorwegnahme von Handlungsschritten, die zur Erreichung eines Zieles notwendig scheinen. Dabei entsteht ein Plan, gemeinhin als eine zeitlich geordnete Menge von Daten.
Bei der Planung wird berücksichtigt, mit welchen Mitteln das Ziel erreicht werden kann, wie diese Mittel angewendet werden können, um das Ziel überhaupt zu erreichen (Vorgehensmodell), und wie man das Erreichte kontrollieren kann (Steuerung). Als Planungsergebnis erzeugen im Idealfall kurz-, mittel- oder langfristige Pläne Handlungssicherheit.“

Planung beschreibt also den Zielzustand, den man in einer gegebenen Zeit, mit gegebenen Mitteln erreichen möchte. Dabei können die Planungsobjekte und Ziele sehr vielschichtig sein.  Man kann Finanzen planen, Personal, Verkäufe, Produktion uvm.

Planung benötigt man, um richtig „Steuern“ zu können. Vergleichen kann man das am besten mit folgender Metapher: Du befindest dich irgendwo im Wald und hast eine Landkarte zur Hand. Die Landkarte ist allerdings recht nutzlos, solange du nicht genau zwei Dinge bestimmen kannst:

1. Wo befinde ich mich aktuell?
und
2. Wo möchte ich hin, was ist mein Zielpunkt auf der Landkarte?

Kannst du eine der beiden Fragen nicht beantworten, kommst du an einer x-beliebigen Stelle aus dem Wald heraus. Vermutlich aber nicht da, wo du eigentlich „hinsteuern“ wolltest.

Genau beim Thema „Steuern“ passiert also die eigentliche Arbeit, das Controlling. Hier arbeiten Manager und Controller zusammen. Während der Manager für das Erreichen der geplanten Ergebnisse verantwortlich ist, verantwortet der Controller die Transparenz der Zielerreichung und gibt dem Manager Handlungsempfehlungen für zu treffende Entscheidungen. Das Schaubild verdeutlicht die Aufgaben nochmals:

Manager / Controller

Aufgabenbereich Manager / Controller

Bildquelle: Internationaler Controllerverein

Hier kommt jetzt Business Intelligence (BI) ins Spiel. Hier genau liegt die Beratungskernkompetenz der Inspiricon – die Ermittlung und Fixierung der Zielvorgaben (Planung) und die Gegenüberstellung derselben zu dem tatsächlich erreichten Ist-Zustand zu betrachten, inklusive einer dazugehörigen Abweichungsanalyse. Wir unterstützen Planungsprozesse sowohl von fachlicher Seite, wie auch von technischer Seite, wenn es um die Integration von Daten und Informationen aus unterschiedlichen Quellen geht. Technisch haben wir uns dabei auf die Beratung der Business Intelligence Werkzeuge aus dem Hause SAP fokussiert (SAP Business Warehouse und Business Objects).

Wie die einzelnen Planungselemente verzahnt ineinandergreifen (Stichwort horizontale und vertikale Integration, dazu später mehr) und auf was es dabei ankommt, erfahrt ihr im nächsten Blog-Beitrag zum Thema Enterprise Planning.

Fragen? Anregungen? Lust auf eine Diskussion zum Thema? Meldet euch, wir freuen uns darauf.

Road 1030x772

Neues zu BW 7.5

Hallo zusammen,
kaum ist BW 7.4 bei den Kunden angekommen, geht die Reise auch schon weiter. In wenigen Tagen (23.11.2015) startet das Ramp-Up für BW 7.5!
Hier einige Highlights der neuen Version:
• Die Entwicklung der HANA-Objekte schreitet voran, das DSO wird weiter aufgewertet
• SAP BW / HANA goes Big Data
• Eclipse wird immer mehr zur Oberfläche Nummer 1
• Die gemeinsame Verarbeitung von Online (BW-Daten) und Offline Excel / Flatfiles wurde verbessert
• Neue / Verbesserte Möglichkeiten der Plannung in BI-IP und BPC

Roadmap SAP BW 7.5

Roadmap BW 7.5

Hier findet ihr weitere Details

Wir bleiben für euch dran und freuen uns, wenn Ihr Fragen oder Anmerkungen zu diesem und allen anderen Themen habt!
Euer Jörg Waldenmayer & Claudio Volk

 

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