Infrastruktur MAG 1304

Wenn der Wirtschaftsprüfer zweimal kommt

2013

Mit dem Solution Manager 7.1 hat SAP etliche Innovationen bereitgestellt, die nun darauf warten, entdeckt zu werden. Die neuen Features helfen IT-Verantwortlichen unter anderem auch im Change-Management-Prozess. Die neue Downgrade Protection hilft, Inkonsistenzen durch Überholer zu vermeiden.

Nahezu jedem größeren SAP-Bestandskunden ist der Besuch des Wirtschaftsprüfers ein Graus. Der regelmäßige, jährliche Check sieht vor, dass aus der Importqueue des Produktivsystems wahllos eine kleine zweistellige Anzahl von Transportaufträgen bestimmt wird, für die es gilt, die Anforderungsdokumentation, die Testabnahme sowie die Freigabe für die Produktivsetzung aufzutreiben.

Einige Unternehmen meistern diese hehre Aufgabe dadurch, dass in E-Mail-Postfächern versucht wird, nach Dokumentation zu fahnden. Meist deckt der Wirtschaftsprüfer dann doch das eine oder andere sogenannte „Finding“ auf und bittet um eine Behebung bis zum nächsten Prüfungstermin.

Neben dem Thema Nachvollziehbarkeit von Änderungen hat ein Change Management im Solution Manager natürlich noch viel mehr Vorteile zu bieten: eine stringente und lückenlose Dokumentation aller am System durchgeführten Änderungen, die nicht nur für Wirtschaftsprüfer relevant ist, sondern auch für die eigene IT-Abteilung von unschätzbarem Wert sein kann.


 

Darüber hinaus können IT-Verantwortliche wertvolle Kennzahlen aus dem Change Management gewinnen und die Planungssicherheit von Releases, Änderungen sowie Upgrades massiv verbessern.

Incident Management

Ein Change Management setzt stets auf ein Incident Management auf. Änderungen können zwar dadurch erforderlich sein, dass neue Geschäftsprozesse definiert werden, in vielen Fällen liegt aber einer Änderung eine Störung in Form eines Incidents vor.

Dieser sollte sinnvollerweise in einem unternehmensinternen Service Desk erfasst werden. Ob nun hierfür der Solution Manager geeignet ist oder nicht, hängt von den internen Gegebenheiten ab.

Schnittstellen erlauben eine Integration in bestehende Service-Desk-Werkzeuge, allerdings gilt hier die Devise: Je intensiver die Form der Integration, umso kostspieliger wird auch der Betrieb und das initiale Implementierungsprojekt.

Die neuen Weboberflächen haben auch beim Service Desk Einzug gehalten, sodass nun das Incident Management ohne Bedenken unternehmensweit eingeführt werden kann.

IT-Verantwortliche hatten in der Vergangenheit noch Bedenken, Non- SAP-Anwender mit einer spezifischen und altbackenen ABAP-Oberfläche und der Bedienung einer SAPGui zu beglücken.

Dies ist nun mit den neuen Oberflächen nicht mehr notwendig, da sich das Incident Management von anderen kommerziellen Werkzeugen im Bedienkomfort kaum unterscheidet.

Problemmanagement

Neu im Release 7.1 hinzugekommen ist das Problemmanagement. Ganz gemäß ITIL wird aus einem Incident normalerweise nicht sofort eine Änderung, sondern zunächst ein Problem. Erst aus einem Problem kann dann eine Änderung, ein sogenannter Change, erstellt werden.

Das Problemmanagement hat aber nicht nur die Aufgabe, Incidents durchzuschleusen, sondern auch strukturelle Probleme zu identifizieren und anzupassen, bevor sich die Fehler und Meldungen durch Endbenutzer häufen.

Viele Kunden aus dem Mittelstand sind bereits damit beschäftigt, das Incident und Change Management im Unternehmen auszuprägen und zu leben, und werden das Problemmanagement zunächst hinten anstellen.

Change Management

Das Change Management im Solution Manager unterscheidet bei Änderungen zwischen normalen und dringenden Korrekturen. Beide Vorgangsarten werden in ein Projekt eingebettet und damit verknüpft.

Neben der logischen Klammer von Änderungen erfüllt das Projekt auch eine weitere, wesentliche Funktion. Über den Status des Projekts („In Entwicklung“, „Test“, „Produktiv“) wird gesteuert, wann und in welche Systemlandschaft die normalen Korrekturen importiert werden.

Die wahre Stärke des Solution Managers liegt in der nahtlosen Integration des Transportwesens mit dem Änderungswesen. Ein Transportauftrag kann nur noch dann angelegt werden, wenn hierfür ein genehmigtes Änderungsdokument vorliegt.

Der Import von Transportaufträgen wird über die damit verknüpfte normale oder dringende Korrektur vorgenommen. E-Mails von Entwicklern an SAP-Basisverantwortliche mit dem Hinweis, einen Transport einzuspielen, gehören damit der Vergangenheit an.

Im Vergleich zur Vorgängerversion 7.0 hat SAP hier eine Menge weiterentwickelt. Die wohl wesentlichste und auffälligste Änderung stellt das neue webfähige Frontend dar. Der Anwender kann nun besser die Ansicht einer Änderung konfigurieren und findet sich besser zurecht als in der früheren, altbackenen CRM-Oberfläche.

Darüber hinaus wurden auch an zahlreichen Stellen Business Add-ins implementiert, die es Kunden ermöglichen, das Change Management an die eigenen Bedürfnisse anzupassen. Ein klassisches Beispiel ist die Vergabe von Transportauftragsbezeichnungen.

Eine gängige Anforderung ist stets, dass die Bezeichnung nicht vom Anwender geändert werden kann, sondern durch eine definierte Nomenklatur vom System vorgegeben wird. Durch ein neues, von SAP geschaffenes Business Add-in lässt sich diese Anforderung schnell und einfach umsetzen.

Die Angst vor Überholern

Ein jeder SAP-Basis-Verantwortlicher kennt das leidige Problem: Importfehler aufgrund fehlender, abhängiger Transporte. Brisant wird die Situation dann, wenn sich in der Importqueue mehr als tausend Transportaufträge ansammeln, die auf die Produktivsetzung warten.

Meist wird dann jedoch nicht aus Konsistenzgründen die gesamte Queue mit dem bekannten großen Lkw importiert. Vielmehr werden einzelne Transportaufträge vorab als sogenannte Überholer importiert.

Wird ein älterer Transportauftrag eines Tages produktiv gesetzt, so kann es dazu kommen, dass funktionierendes Coding zurückgesetzt wird, oder, noch schlimmer, Tabellenanpassungen rückgängig gemacht werden.

Die sogenannte Downgrade Protection des Solution Managers warnt IT-Verantwortliche vor dem Import vor solchen kritischen Situationen. Das funktioniert dadurch, dass die klassische Sperrverwaltung von Workbench-Objekten erweitert wurde. Der Solution Manager weiß zu jeder Zeit, welche Version eines Transportobjekts aktuell in welchem System importiert ist.

Q Partners Grafik

Q-Partners begleitet Kunden unter anderem bei der Implementierung von Change- und Release-
Managementprozessen im Solution Manager.

Die Qual des Release Managements

Die meisten mittelständischen Kunden haben oft Probleme, ihre Fachabteilungen in Richtung von Firmenreleases oder zumindest vierteljährlichen SAP-Releases zu disziplinieren.

Oft entstehen Anforderungen spontan und sollen umso schneller umgesetzt werden. Eine Planung und Bereitstellung von Funktionalitäten zu definierten Terminen verstehen IT-Verantwortliche oftmals als zu starr.

Die normale Korrektur wird daher nur selten eingesetzt, meist nutzen Kunden ausschließlich das Instrument der dringenden Korrektur. Die dringende Korrektur erlaubt zu jedem Zeitpunkt einen Transport in das Produktivsystem und bietet daher die gewünschte Flexibilität im Gegensatz zur Release-orientierten Funktionsweise der normalen Korrektur.

Um hier einen Kompromiss zu schaffen, hat SAP das Konzept der Vorabkorrektur eingeführt. Normale Korrekturen können mittels eines separaten Genehmigungsworkflows vorab produktiv gesetzt werden, also vor dem eigentlichen Release-Termin.

Dadurch erhalten Change Manager und Entwicklungsleiter die notwendige Flexibilität, um ungeplante Änderungen kurzfristig bereitzustellen und nicht die Fachabteilung auf das nächste Release-Fenster zu verweisen.

In Summe ist die Verwendung von Releases in jedem Fall empfehlenswert, schon allein um auf ein konsistentes Testmanagement zu setzen. Werden Änderungen kontinuierlich in das Qualitätssicherungssystem transportiert und situativ produktiv gesetzt, so wird nie das getestet, was auch in das Produktivsystem importiert wird.

Besonders komplex wird das Change Management immer dann, wenn parallel zu einer Drei-Systemwartungs-Landschaft auch eine Projektlandschaft aufgebaut werden soll. Dies ist nur dann sinnvoll, wenn zu bestimmten Stichtagen zusätzliche Funktionalitäten bereitgestellt und die Wartung von der Projektentwicklung auch systemisch getrennt werden soll.

Ein konkretes Beispiel hierfür sind die Formatanpassungen, mit denen Energieversorger stets zum 1. April und 1. Oktober konfrontiert werden. Eine Fünf-System-Landschaft, wie sie mittlerweile von SAP empfohlen wird, erfordert auch eine Disziplin im Change Management.

Insbesondere müssen alle Änderungen, die in der Wartungslandschaft implementiert werden, auch in der Projektlandschaft nachgezogen werden. Dies kann natürlich auf manuelle Art geschehen, es dürfte allerdings nicht lange dauern, bis der eine oder andere Transportauftrag verloren geht und im schlimmsten Fall das neue Release dann inkonsistent produktiv gesetzt wird.

Retrofit ermöglicht als Komponente des Solution Managers, dass auf einem automatisierten Weg alle Anpassungen der Wartungslandschaft in die Projektlandschaft eingespielt werden.

Bei Customizing-Aufträgen erfolgt dies mittels BC-Sets, bei Workbench-Aufträgen wird das Coding mittels RFC-Verbindungen übertragen. Das Ganze funktioniert natürlich nur, wenn die betreffenden Tabelleneinträge beziehungsweise die Workbench-Artefakte auf der Projektlandschaft noch nicht verändert wurden.

Ist auf beiden Systemlandschaften eine Änderung erfolgt, so wird dem Benutzer ein Splitscreeneditor präsentiert und der Entwickler muss entscheiden, wie mit den Änderungen umgegangen werden soll.

Der Retrofit-Prozess wurde in der Version 7.1 des Solution Managers nochmals massiv verbessert und kann nun uneingeschränkt empfohlen werden. Ein manueller Abgleich in einer Fünf-System-Landschaft ist bei größeren Projekten nahezu unmöglich. Schade ist in diesem Zusammenhang, dass die Retrofit-Funktionalität nur Kunden mit SAP Enterprise Support zuteilwird.

Fazit

Mit dem Solution Manager 7.1 steht für das Change und Release Management ein professionelles Werkzeug zur Verfügung. Trotz alledem gilt es, den klassischen IT-Spruch „there is no silver bullet“ zu berücksichtigen.

Ein Werkzeug kann nie als Allheilmittel betrachtet werden. Die Definition von Change- und Release-Prozessen und die Anpassung der organisatorischen Abläufe ist zunächst wesentlich.

Q-Partners Consulting und Management begleitet Kunden unter anderem bei der Definition einer Roadmap, der Einführung von Prozessen und der Implementierung von Change- und Release-Managementprozessen im Solution Manager.

Zusätzlich zu den SAP-Standards stellt Q-Partners eigene Add-ons für das Change Management zur Verfügung, die die Arbeit mit dringenden und normalen Korrekturen vereinfachen und optimieren.

Über den Autor

Matthias Kneissl, Q-Partners

Geschäftsführer bei der Q-Partners Consulting und Management GmbH

Hinterlassen Sie einen Kommentar

AdvertDie Meinung 2