SPP Blog

Wie schon in einem meiner früheren BLOGs angekündigt ist sie nun da, die neue Version, mit zahlreichen Verbesserungen. Hier ein Auszug aus den Release Notes: (mehr…)

Aufgrund zahlreicher Anfragen möchte ich hier ein paar Details der Upgrade Analyse mittels IntelliCorp’s LiveCompare auflisten. 

Analyse Vorgangsweise

Wir als SPP gestalten eine Upgrade Analyse als kleines Projekt, indem der Kunde bestimmte, klar definierte Reports erhält. Die typische Projektlaufzeit beträgt unter 2 Wochen. Der Aufwand unseres Beraters beträgt max. 4 Tage. Dazu kommen noch interne Aufwände beim Kunden im Umfang von 0,5 bis 3 Tagen.

Das “Projekt” gliedert sich in 3 Phasen:
Phase 1: Definition und Abklärung der Inhalte. Hier wird anhand von Beispiel-Reports und den Anforderungen des Kunden jeder einzelne Report mit seinen Inhalten und seinem Nutzen genau durchbesprochen bzw. definiert.
Phase 2: Durchführung der Analyse
Phase 3: Abschließende Präsentation und Diskussion der Ergebnisse mit der Projektleitung

Analyse Ergebnisse

Ich möchte vorab nochmals betonen, dass die Analysen gemacht werden können BEVOR der tatsächliche Put stattgefunden hat.
Die folgende Liste der Reports ist beispielshaft und wird im im konkreten Fall so gut wie immer an den Kunden angepasst, wie bereits oben erwähnt.

Verwendungsgrad Bericht
Nutzungsgradanalyse nach Applikationsbereichen, Transaktionen und Häufigkeit der Aufrufe.

Benutzte, obsolete Transaktionen
Dieser Report zeigt alle derzeit genutzten Transaktionen, die auf dem Zielrelease entweder nicht mehr existieren, oder seitens SAP als obsolet gekennzeichnet sind.

Unbenutzer Custom Code
Enthält eine Auflistung aller, von einem Endbenutzer ausführbare Eigenentwicklungen, also Transaktionen und Programme, die nicht genutzt wurden.

Genutzte Standard Transaktionen
Enthält alle genutzten Standardtransaktionen und zeigt die Veränderungen in deren Dynpros auf. Dies ist ein direkter Hinweis auf die zu erwartenden Veränderungen aus Enduser-Sicht bzw. Testsicht. Dynpros sind die Definitionen der Bildschirmmasken in der SAP-GUI.

User Location Analysis
Analyse der Nutzung basierend auf dem Standort des Benutzers. Einbezogen werden auch Daten wie Abteilung, Personal Bereich etc..

Impacted profiles and Authorazations
Dieser Bericht enthält eine Aufstellung aller benutzten Profile und liefert einen Vergleich der damit verbundenen Objekte im Ausgangs und im Zielsystem.

Customized and used Standard IDOCS
Analyse der verwendeten IDOCS um vorab festellen zu können, welche IDOCS nach dem Put entsprechend angespasst werden müssen.

Neue SAP-Transaktionen
Enthält alle neuen SAP-Transaktionen mit Beschreibung, Entwicklungsklassen und Modulzugehörigkeit.

RFC Function Calls
Die SAP Workload zeichnet neben der normalen Benutzerinteraktion auch Zugriffe von aussen via RFC auf. Diese Logs sind ein direkter Hinweis auf externe Schnittstellen. In diesem Report werden die aufgerufenen Funktionsbausteine zwischen den beiden Systemen verglichen.

Custom Code Impact
Der Custom Code Impact Report liefert alle relevanten Änderungen an den SAP-Standard Objekten, die in Eigenentwicklungne verwendet werden.

UNICODE Syntax Check
Liefert einen kompletten Syntax-Check der Eigentwicklungen ab. Die Arbeitsweise und das Ergebnis ist sehr ähnlich dem von UCCHECK, jedoch ist dieser Check auch möglich auf SAP Releases 46c abwärts (!), während UCCHECK erst nach dem Upgrade zur Verfügung steht. Dies ist ein unerlässlicher Report, wenn Sie auf einem SAP Release unter 4.7 sind und bei einem Upgrade gleichzeitig eine Unicode Konvertierung durchführen müssen (weil Sie beispielsweise MDMP im Einsatz haben).

Interface Programs Impact
Zur Erstellung dieses Berichts werden alle Eigenentwicklungen nach „Call Transaction“ Aufrufen durchsucht. Der Parameter , die aufgerufene Transaktion, werde dann zwischen den beiden Systemen verglichen.

ABAP Impact
Dieser Scan enhält eine Reihe von ABAP Statements, die beim Upgrade von 46c und darunter nach 4.7 und darüber Probleme bereiten können.

BAPI
Aus dem ABAP Impact Scan-Ergebnis werden, zur Erstellung dieses Reports, alle „Call Function ‚BAPI*“ Fundstellen in diesem Report weiterverarbeitet. Die gefundenen und aufgerufenen BAPIs werden zwischen den 2 Systemen hinsichtlich ihres Codings verglichen.

16tes Jahrhundert. Ein einsamer Archäologe steht vor einem Feld. Wo soll er zu graben beginnen? Er hat noch ein paar Jahre, die ihm das Leben noch gelassen hat und er kennt China nur aus Erzählungen, kann also das Chinesenprinzip nicht anwenden. Er denk also nach, denkt nach, wo seiner Erfahrung nach die größte Chance auf „die Entdeckung“ begraben ist. Da, ein Baum, zum wachsen benötigt er Nährstoffe, darunter , oder nahe daran wird etwas zu finden sein. Ja, das sagt ihm seine Erfahrung.
Also beginnt er dort zu graben. Er findet etwas. Er findet ein kleines Haus einer verhältnismäßig armen Familie. Er ist enttäuscht und gräbt nicht weiter.
200 Jahre später wird dann mit den eigentlichen Ausgrabungen begonnen. Die Stadt gilt als die wichtigste Informationenquelle über das Leben in der Antike.

SAP

Wer mich kennt, kennt meinen zu Übertreibungen neigenden Stil. Wie läuft ein klassisches SAP-Projekt? Ein Release-Upgrade zum Beispiel. Doch nicht viel anders als beim glücklosen Archeologen. Am Anfang weiß man oft sehr wenig über das System. Alles ist verschüttet. Wie plant man nun den Release-Wechsel, auf Basis welcher Informationen werden Schätzungen abgegeben? Was passiert dann im Projekt? Wenn man Glück hat, dann besitzen die beteiligten Berater ausreichende Kenntnisse über das System und die darauf implementierten Prozesse. Wenn nicht, kommt es wie fast üblich, zu Projekt-Überschreitungen auf der Zeit- und auf der Budget-Achse. Dazu kommt meist noch ein massives Qualitätsproblem, da wichtige Phasen, nämlich das Testen und die Ausbildung der End-User zugunsten der Implementierung gekürzt werden. Dies wiederum beeinträchtigt die dritte Achse, nämlich die Akzeptanz.

Ausweg

Klassische SAP-Projekte wie Upgrades, werden nach dem Wasserfallmodell geplant. Jedoch wird ein wichtiger Aspekt, bzw. Schritt der Methode sträflich vernachlässigt. Die Anforderungsanalyse, auch Gap-Analyse genannt, oder anders ausgedrückt in der Frage „Was hat SAP am FÜR UNS relevanten Standard geändert?“. Eine relativ einfache Frage, die im SAP Umfeld, wenn man das Ziel verfolgt sie umfassend zu beantworten, schnell zur Anwendung des Chinesen-Prinzips führt.
Einzige Lösung ist also eine Automatisierung des „Problems“ der Analyse. Wie kommt man schnell zu der gewünschten Information, in möglichst hoher Qualität und möglichst umfänglich?
Es gibt hier viele Anbieter von Analyse Werkzeugen, beginnend bei SAP-Consulting über RBE bis hin zu IntelliCorp. Jedes dieser Werkzeuge hat einen ganz bestimmten Schwerpunkt und damit auch dort seine Stärken.

Die umfassendste Antwort am Markt hat zurzeit IntelliCorp. Deren Assessor Template for SAP-Upgrades bietet eine ganze Reihe von vollautomatisierten Analyse-Workflows. Damit ist es möglich binnen weniger Tage (im Schnitt 3) umfassendes Material zur detaillierten Planung des Upgrade-Projektes zu erhalten. Ganz nebenbei dient das Ergebnis dann auch schon als Arbeitsunterlage für das Implementierungsteam. Durch seine enorme Flexibilität lässt sich das Werkzeug für alle SAP-Ausprägungen anwenden. Das sind sämtliche Industrielösungen, die Einbindung der Software von Drittanbietern oder eigene Namespaces in der Workbench.