SolMan 7.2 SP3 is now general available!

  1. Der SAP Solution Manager 7.2 SP3 ist seit 15.08.2016 frei verfügbar (general availability). Der Ramp-up ist beendet!
  2. Die Wartung für den SAP Solution Manager 7.2 endet laut PAM am 31.12.2025. Damit hält sich der SAP Solution Manager nun endlich ebenfalls an die allgemeine Wartungszusage der SAP SE.
  3. Der SAP Solution Manager 7.2 basiert auf SAP Netweaver 7.4. Die Wartung für SAP Netweaver 7.4 endet am 31.12.2020. (Klingt komisch. Ist aber so. 😉

Verweise:

SAP Solution Manager 7.2 jetzt verfügbar!

Die ersten Schulungen und Bücher zum neuen SAP Solution Manager 7.2 sind jetzt verfügbar. Das Release selbst wird in wenigen Wochen ebenfalls da sein.

Werden Sie jetzt aktiv und beginnen noch heute mit den Vorbereitungen. Die Zeit ist knapp und der Mehrwert für Ihr Unternehmen hoch.

Ich verate Ihnen hier, wie Sie sich am besten vorbereiten und damit ganz entspannt in das neue SAP Solution Manager 7.2 Zeitalter starten können.


  1. Die erste offizielle SAP-Schulung zum neuen Release steht nun bereit. Thematisiert wird hier die wichtigste Neuerung im SAP Solution Manager 7.2 sowie die kritischste Aktivität beim Upgrade von 7.1 auf 7.2. Starten wird die Schulung im September 2016 – zeitgleich mit der generellen Verfügbarkeit des SAP Solution Manager 7.2. Anmeldungen für diese quasi-obligatorische Schulung sind ab sofort möglich‎‎.‎

    WSMCAT Content Aktivierung und Process Management für SAP Solution Manager 7.2
  2. Das erste Buch zum SAP Solution Manager 7.2 ist bereits verfügbar. Mehrere weitere SAP-Press-Publikationen zum neuen Release stehen schon im Regal und warten auf die finale Freigabe Ende September. Bestellungen bzw. Vorbestellungen für diese quasi-obligatorischen Publikationen sind bereits möglich.‎

    SAP Solution Manager for SAP S/4HANA

    SAP Solution Manager für SAP S/4HANA

    Upgrading to SAP Solution Manager 7.2‎
  3. Der SAP Solution Manager 7.2 SP2 befindet sich seit April im Ramp-up und ist dort für alle Ramp-up-Kunden und -Partner verfügbar. Das darauf folgende Support Package 3 wird dann für alle SAP-Kunden voraussichtlich ab September 2016 ‎verfügbar sein.

    SAP Solution Manager 7.2 Help‎

Die genannten Schulungen und Publikationen bilden den idealen zeitlichen und inhaltlichen Startpunkt für den 7.2-Upgrade, den wir alle im Zeitraum Herbst 2016 bis Sommer 2017 starten werden – weil wir es wollen, können, dürfen und müssen.


Wir wollen upgraden, weil wir die neuen Features richtig toll finden und dringend benötigten!‎

Wir können upgraden, weil wir uns u.a. durch Lesen der Bücher und Teilnahme an den Schulungen / Workshops bestens vorbereitet haben!

Wir dürfen upgraden, sobald SAP SE den SAP Solution Manager 7.2 allgemein verfügbar macht‎!

Wir müssen upgraden, weil der aktuelle SAP Solution Manager 7.1 am 31.12.2017 abgeschaltet wird!

SAP Solution Manager ‎7.2 Change Request Management Upgrade Leitfaden (ChaRM 7.2 Upgrade Guide)

Der SAP Solution Manager 7.2 ist aktuell im Ramp-Up und in Kürze generell verfügbar. SAP-Kunden haben dann ein Jahr Zeit um ihren SAP Solution Manager 7.1 zu upgraden, da die Wartung für das Release 7.1 im Dezember 2017 enden wird.

Ich habe nun alle mir bekannten manuellen Upgrade-Aktivitäten für ChaRM 7.2 zusammengetragen und möchte mein Wissen und meine Erfahrungen gern mit Ihnen teilen und diskutieren.

Bitte nutzen Sie diesen Leitfaden als Ergänzung zu SOLMAN_SETUP und allen anderen offiziellen Upgrade-Dokumenten.

Ich wünsche Ihnen viel Spaß beim Lesen, Nachdenken und Umsetzen. Wenn Sie Fragen haben, den einen oder anderen Punkt diskutieren möchten oder Fehler bzw. Lücken entdecken, dann melden Sie sich bitte bei mir, damit ich diesen Blog-Beitrag kontinuierlich optimieren und vervollständigen kann. Im Namen aller anderen SAP-Kunden danke ich Ihnen vielmals für Ihre Mithilfe!


The IT Service Management and Change Management processes have been enhanced with many new functionalities. And the good message is, that we kept all existing frameworks and features from the release 7.1. The upgrade for customers for ITSM and CHARM processes will have a low impact on existing solutions but the new features will bring additional values. (SCN: SAP Solution Manager Wiki -> ITSM and ChaRM in SAP Solution Manager 7.2)

Laut SAP SE ist der Umstieg von SAP Solution Manager 7.1 zu 7.2 aus Sicht von ITSM und ChaRM ganz leicht‎. Alles klappt wie zuvor. Lediglich die neuen Features müssen bei Bedarf konfiguriert und aktiviert werden.

Keine Migration?

Genau!

Irgendeine Voraussetzung?

Voraussetzung: Wir müssen komplett im Standard sein, ohne Ausnahme. Das gilt neben Entwicklung auch für Stammdaten, Berechtigungen, Customizing und UI-Konfiguration.

Sind wir nicht.

Na dann‎: Willkommen im Klub!

Und nun?

Nun müssen wir eben doch (manuell) migrieren.

Customizing:

  • Einige Customizingeinstellungen (z.B. Downgrade-Protection, Importstrategie / Statusabhängiger Import, Kopiersteuerung, …) müssen korrigiert / überführt werden, da hier inkompatible Änderungen‎ vorgenommen wurden.

UI-Konfiguration:

  • Einige Felder (z.B. Projekt-ID) müssen entfernt und andere Felder (z.B. Change-Control-Landschaft und Branch) hinzugefügt werden.
  • Der Zuordnungsblock für die Lösungsdokumentation muss eingeblendet werden.
  • Im Gegenzug müssen die Zuordnungsblöcke für Projekte, Lösungen und Dokumente entfernt werden.
  • Die Benutzerrolle SOLMANPRO wurde angepasst. Einige Customizingeinträge wurden entfernt andere sind hinzugekommen. Falls eine kundeneigene Version erstellt wurde sind die Änderungen manuell abzugleichen.

Personalisierung:

  • Vorhandene Web-UI-Personalisierungen sind zu prüfen und ggf. mittels Transaktion WCF_CC abzugleichen, da diese nun möglicherweise inkompatibel zu geänderten UI-Konfigurationen sind. Ohne diese Korrektur sind für einige Anwender die neuen Felder / Zuordnungsblöcke ggf. nicht eingeblendet.
  • Da die Reportinganwendung /TMWFLOW/REPORTINGN in das Administrations-Cockpit überführt wurde, sind ggf. erstellte anwenderspezifische oder -übergreifende Selektions- und ALV-Varianten in die neue Fiori-Anwendung zu übertragen.
  • Das gleiche gilt auch für die anderen obsoleten Administrations- und Reporting-Anwendungen.

Berechtigungen:

  • Die Berechtigungsrollen müssen angepasst angepasst werden, da neue Vorgangsarten für Änderungszyklen und neue Berechtigungsobjekte für die neue Lösungsdokumentation eingeführt wurden.

Jobs:

  • Da im Zuge des Upgrades alle Änderungszyklen und Aufgabenpläne geschlossen und neu angelegt werden, müssen alle eingeplanten Aufgabenplanaufgaben (z.B. Importe) neu eingeplant werden.
  • Da der Report für untertägige Importe und die Reports für die Verteilung von Dringenden Transporten abgeschafft wurden, müssen die entsprechenden Aufgabenplanaufgaben genutzt und als Jobs eingeplant werden.

Stammdaten:

  • Logische Komponentengruppen und Change-Control-Landschaften müssen definiert werden.
  • Geschäftsprozesse müssen mittels Content-Aktivierung in die Lösungsdokumentation übernommen werden.
  • ‎Projekte müssen bei Bedarf nach ITPPM überführt werden.

Bewegungsdaten:

  • A‎uf die Problematik für Alt-Vorgänge mit Projekten, welche nicht Teil der Content-Aktivierung sind, bin ich in einem anderen Beitrag bereits eingegangen. Demnach werden ‎alte Vorgänge nach dem Upgrade ggf. unvollständig im SAP Web Client UI angezeigt, da die Zuordnung der Projekte, Lösungen, Geschäftsprozesse und Dokumente im Web UI nicht mehr sichtbar sein wird.

Entwicklung:

  • Es gibt keine Projekte mehr, dafür logische Komponentengruppen, Branches und Change-Control-Landschaften.
  • Die Findung des Änderungszyklus pro Change-Control-Landschaft ist nicht mehr eindeutig, da nun auch die Zuordnung eines Changes zu zukünftigen Zyklen möglich ist.
  • Der Aufgabenplan wird für den Folgeänderungszyklus wiederverwendet. Die Zuordnung zwischen Änderungszyklus und Aufgabenplan ist folglich nicht mehr eineindeutig.
  • Änderungsdokumente „Dringende Änderung“, „Normale Änderung“ und „Administrative Änderung“ sind wahlweise auch ohne Aufgabenplan/Transportaufträge nutzbar.
  • Ein Änderungsantrag ist mit einem Änderungszyklus verknüpft. Bisher galt galt das nur für Änderungsdokumente.
  • Der Vorgänger eines Änderungsdokumentes kann neben dem Änderungsantrag auch ein IT-Requirement sein.
  • Die SMSY wird abgeschafft (Funktionsbausteine und Tabellen werden nicht mehr synchronisiert/unterstützt). Zum Lesen von RFC-Destinationen und Systeminformationen ist die API der LMDB zu nutzen. Zum Beispiel ist deshalb ab sofort der Funktionsbaustein /TMWFLOW/GET_RFC anstelle von /TMWFLOW/GET_RFC_DEST zu nutzen. Achtung: Der obsolete Funktionsbaustein existiert weiterhin, liefert aber stets eine Exception.
  • Grundlegende Tabellen wurden ersetzt: Transportaufträge werden nun in der Tabelle /TMWFLOW/TRORD_N statt bisher /TMWFLOW/TRORDHC gehalten. Transportstatusinformationen werden nun in der Tabelle /TMWFLOW/TRACK_N statt bisher /TMWFLOW/TRACK + /TMWFLOW/TRORDEC gehalten. Retrofitinformationen werden nun in der Tabelle /TMWFLOW/RFITCT statt bisher /TMWFLOW/RFITC gehalten. Folglich sind alle kundeneigenen Anwendungen mit direkten Tabellenzugriffen (i.R. Select-Zugriffe in Reportinganwendungen) anzupassen. Achtung: Die alten Tabellen existieren weiterhin und erzeugen folglich keinen Syntaxfehler.

Um es kurz zu machen: Alle Kundeentwicklungen müssen getestet und sehr wahrscheinlich angepasst werden.

Modifikationen und Erweiterungen:

  • Im Rahmen des Upgrades sind Dictionary-Modifikationen, Quellcode-Modifikationen und Erweiterungen abzugleichen (SPDD, SPAU, SPAU_ENH).
  • Zusätzlich sind auch WebUI-Erweiterungen (Repository + HTML) und WebUI-Konfigurationen abzugleichen (WCF_CC, WCF_RT_COMP).
  • Die bei Web-UI-Erweiterungen aufgebaute Klassenvererbungshiercharchie für die Controller-Klassen ist zu prüfen und anzupassen, da SAP SE ggf. die Kontrollerklassen für Windows, Views oder Kontextknoten ausgetauscht oder inkompatibel geändert hat.

Ist die Liste vollständig?

Nein.

Die genannte Punkte sind nur die „Big Rocks“‎. Im Detail wird es viele weiteren Punkte geben. Beispiel: Wenn es neue Vorgangsarten für die Änderungszyklen gibt, dann hat dies neben CRM_ORD_PR (Vorgangssichtbarkeit/-änderbarkeit) auch Auswirkungen auf B_USERSTAT (Statuswechsel) und CRM_TXT_ID (Textsichtbarkeit/-pflege). Wenn es einen neuen Zuordnungsblock „Lösungsdokumentation“ gibt, dann hat der auch „Statusabhängige Drucktasten“, welche entsprechend zu konfigurieren sind. Und wenn dem so ist, dann muss auch das Berechtigungsobjekt SM_FIELD entsprechend ausgeprägt werden.

Gibt es von SAP SE einen Upgrade-Leitfaden?

Ja: SUM + SOLMAN_SETUP.

Enthält der auch die hier beschriebenen manuellen Migrationstätigkeiten?

Nein.

Gibt es noch andere offizielle Hilfsmittel?

Ja…bitte schauen Sie zusätzlich auch auf folgenden Seiten vorbei:

SAP Solution Manager 7.2 – Noch gar nicht da und schon veraltet

Beobachtung: Seit 20.01.2016 ist das Enhancement Package 4 für SAP CRM 7.0 offiziell verfügbar. Das SAP CRM 7.04 wird bis Ende 2025 supported. Es ist davon auszugehen, dass es bis dahin noch einige weitere Enhancement Packages geben wird. Aktuell gibt es ungefähr aller zwei Jahre ein neues Enhancement Package für SAP CRM 7.0.

Schlussfolgerung: Gemäß aktueller SAP-Philosophie werden ab 20.01.2016 neue Funktionen und Funktionsverbesserungen nur noch in Form von Feature Packages für SAP CRM 7.04 ausgeliefert. Zukünftige Support Packages für Enhancement Package 1, 2 und 3 werden bis auf wenige Ausnahmen ausschließlich Fehlerbeseitigungen enthalten.


Beobachtung: Der SAP Solution Manager 7.2 ist aktuell noch im Ramp-Up und wird spätestens zum Jahresende 2016 offiziell verfügbar sein. Kunden haben dann genau ein Jahr Zeit für einen Releasewechsel von 7.1 nach 7.2, bevor Support und Wartung des aktuellen SAP Solution Manager 7.1 zum Jahresende 2017 eingestellt wird. Der SAP Solution Manager 7.2 basiert auf SAP CRM 7.03 und nicht auf dem aktuellen 7.04.

Schlussfolgerung: Folglich wird das passieren, was in der Vergangenheit immer wieder ‎für Unmut bei den Anwendern gesorgt hat: Der SAP Solution Manager 7.2 ist veraltet, verschläft aktuelle Trends, wir müssen sehr lange auf neue Funktionen oder Funktionsverbesserungen warten und der nächste Releasewechsel wird erneut viele Verbesserungen aber eben auch hohen Implementierungs- und Schulungsaufwand mit sich bringen.


Überraschung: Solange brauchen wir auf SAP Solution Manager 7.3 (oder 7.5 wegen NW 7.50? oder 8.0 weil großer Sprung?) allerdings gar nicht warten. Denn Support und ‎Wartung für SAP Solution Manager 7.2 wird nach aktueller Planung bereits Ende 2020 wieder eingestellt werden. Ursache hierfür ist der Java Stack.

Weiterführende Informationen:
Product Availability Matrix: SAP Solution Manager 7.2
Product Availability Matrix: SAP CRM 7.04
SAP Note: 1648480 – Maintenance for SAP Business Suite 7 Software
SCN: Product Release Strategy Webcast Notes – All About Feature Packages

SAP Solution Manager 7.2 Requirements Management

Das Requirements Management im SAP Solution Manager 7.2 ist nicht durchdacht, nicht ausgereift und folglich für die produktive Nutzung nicht geeignet. (Persönliche Einschätzung von Peter Weigel vom 24.05.2016)

Warum das? Das erfahren Sie hier:

Change Requests sind Anträge für Änderungen Ihrer Business- und IT-Lösung. Solche Änderungsanträge werden nach ITIL niemals direkt angelegt sondern entstehen immer aus einer Störung, einem Problem, einem Service Request oder einem Requirement.

Mit Requirements können Anforderungen erfasst, verwaltet, Abhängigkeiten definiert und ausgewertet werden. Die konkrete Implementierung ist nicht Gegenstand des Requirements Managements, kann aber durch Erzeugung eines Änderungsantrages getriggert werden. Mit den Change Requests werden konkrete technische Lösungen implementiert (und validiert). Da die implementierten technischen Lösungen letztendlich die eingangs formulierten Geschäftsanforderungen befriedigen müssen, dienen die Requirements gemäß V-Modell als wesentliche Grundlage für die Durchführung von Integrations- und Abnahmetests.

SAP Solution Manager 7.1:

Eine solche Requirements Management Funktionalität fehlte im SAP Solution Manager 7.1. Da nicht jeder Kunde Änderungsanträge zur Verwaltung von Anforderungen missbrauchen wollte (Kleine Lösung) aber auch nicht jeder Kunde in ein vollumfängliches Requirements Management von HP ALM/QC investieren möchte (Große Lösung), wurde von SAP Consulting ein Requirements Management Add-on entwickelt, das genau die Lücke schließt (Mittelgroße Lösung).

SAP Solution Manager 7.2:

Im SAP Solution Manager 7.2 ist ein Requirements Management nun enthalten. Folglich ist das Add-on von SAP Consulting nicht mehr erforderlich. Sollte man meinen. Doch weit gefehlt. Während das Add-on durchdacht, ausgereift, ITIL-konform und mit vielen Zusatzfunktionalitäten ausgestattet wurde, ist die SAP Solution Manager 7.2 Lösung einfach nur sch…. „schön“ :-).

Folgende Hauptkritikpunkte habe ich identifiziert:

  1. Die Freigabe zur Implementierung im Business Requirement ist ein völlig überflüssiger Schritt, da der Fachbereich in der Regel bereits in die Genehmigung des Change Requests als CAB-Mitglied involviert ist (spezieller Schritt in der Approval Procedure)
  2. Das IT Requirements ist eine völlig überflüssige Alternative zum Change Request.
  3. Das Requirement Management wird von SAP SE völlig unnötig als eigenständiger Prozess positioniert, in Wahrheit ist das „Business Requirement“ eindeutig dem IT Service Management und das „IT Requirement“ eindeutig dem Change Request Management zuordenbar.
  4. Ansonsten sind natürlich geringfügige Unterschiede im Statusfluss erkennbar, die Bezeichnungen sind mal hier und mal da besser. Mal fehlt hier ein Zwischenstatus, mal dort.
  5. Die Detailfunktionen habe ich nicht im Detail prüfen können. Es scheint aber so, dass in der SAP Solution Manager 7.2 Lösung viele wesentliche Features (z.B. Zerlegen und Zusammenfassen von Requirements) fehlen. Auch scheinen durch Einführung des IT Requirements als Change-Request-Ersatz viele existierende ChaRM-Features verloren gegangen zu sein (z.B. Nutzung von Approval Management, Unterprozess „Scope Extension“.)
  6. Die Präsentationen von SAP SE sind nicht optimal. Wenn man nicht sehr genau aufpasst in welchem Prozess (Business Requirement oder IT Requirement) man sich gerade befindet und wenn man noch nicht ganz verstanden, wie die beiden Prozesse zusammenspielen (BR erzeugt ITR. ITR kommuniziert mit BR. BR kommuniziert mit ITR.), hat man keine Chance die Lösung zu verstehen.

Mein Tipp:

Warten Sie mit der Implementierung auf jeden Fall bis SAP SE das Business Requirement optimiert (1+4+5) und nahtlos mit dem Change Request statt dem IT Requirement verbunden hat (2). Nur dann macht die Einführung und Nutzung des Requirements Magements überhaupt Sinn. Falls Sie nicht warten können oder zusätzliche Features benötigen oder ganz allgemein eine sehr gute Lösung haben wollen, dann nehmen Sie lieber das SAP Solution Manager 7.1 Requirements Management Add-on, das es übrigens auch für bzw. im SAP Solution Manager 7.2 noch geben wird.

Statusfluss:

SAP Solution Manager 7.2 Business Requirement

  • Define
  • Submitted for Validation
  • Being Checked
  • Handed Over to IT (-> ITR. Define)
  • Committed by IT (<- ITR. Approved)
  • Committed (-> ITR. Submitted for Implementation)
  • Implemented (<- ITR. Implemented)
  • Completed (<-> ITR. Completed)
  • Postponed by IT (<-> ITR. Postponed)
  • Postponed
  • Rejected by IT (<-> ITR. Rejected)
  • Rejected

Diese Genehmigung „Committed by IT -> Committed“ durch den Fachbereich ist überflüssig, da der Fachbereich einen eigenen Schritt in der Approval Procedure des Change Requests besitzt und dort bereits genehmigt hat.

SAP Solution Manager 7.2 IT Requirement

  • Define (<- BR. Handed Over to IT)
  • Submitted for Validation
  • Being Checked
  • Submitted for Approval
  • Approved (-> BR. Committed by IT)
  • Submitted for Implementation (<- BR. Committed)
  • Implement
  • Implemented (-> BR. Implemented)
  • Completed (<-> BR. Completed)
  • Postponed (<-> BR. Postponed by IT)
  • Rejected (<-> BR. Rejected by IT)

Die Statusbezeichnungen sind anders. Dennoch ist eindeutig erkennbar, dass der Prozess identisch zum Change Request ist.

SAP Solution Manager 7.1 Requirements Management Add-on

  • Submitted / Neu
  • To Check / Prüfung
  • Checked / Genehmigt
  • Released / Freigegeben
  • Ongoing Implementation / Implementierung
  • Implemented / Realisiert
  • Tested / Getestet
  • Confirmed / Abgenommen
  • Change Required / Überarbeitung
  • Deferred / Zurückgestellt
  • Reject / Abgelehnt

Über die Statusbezeichnungen kann man streiten. Der Prozess entspricht aber bis auf die zum Glück nicht vorhandene überflüssige Genehmigung dem Business Requirement.

SAP Solution Manager 7.1 Change Request

  • Created
  • Validation
  • Extend Scope
  • To be Approved
  • Approved
  • Being Implemented
  • Implemented
  • Confirmed
  • Rejected

Die Statusbezeichnungen sind anders. Dennoch ist eindeutig erkennbar, dass der Prozess identisch zum IT Requirement ist.

Fazit: Das Requirements Management im SAP Solution Manager 7.2 ist nicht durchdacht, nicht ausgereift und folglich für die produktive Nutzung nicht geeignet.

Disclaimer: Dieser Beitrag spiegelt meine persönliche und folglich subjektiv geprägte Meinung zum Thema SAP Solution Manager 7.2 Requirement(s) Management wider. SAP SE hat diesen Beitrag nicht geprüft, nicht kommentiert, nicht genehmigt und nicht dementiert. Dieser Beitrag stellt keiner Kauf- oder Nicht-Kauf-Empfehlung dar. Welche Lösung (S, M, L oder SM 7.2) für Sie die optimale Lösung ist, kann aus diesem Beitrag nicht abgeleitet werden. Hierfür ist eine ausführliche Anforderungsanalyse 🙂 notwendig.