REALTECH ChangePilot 1.0 (Stand 2/2009)
Einleitung In Zeiten von Globalisierung und schnellem Wandel ist es für Unternehmen entscheidend sich schnell an neue Situationen anzupassen. Die Agilität wird dabei immer mehr davon bestimmt, wie effizient sich neue Anforderungen, die sich aus dem operativen Geschäft ergeben, in der IT umsetzen lassen. Notwendiges Know-how oder Ressourcen können in vielen Fällen eingekauft werden, doch IT Prozesse müssen in einer Organisation fest verankert sein. Ein wesentlicher Bestandteil dieser IT Prozesse ist das Change und Release Management. Dadurch wird gesteuert auf welchen Weg funktionale Anforderungen, die im Business entstehen, in der IT von der Entwicklung über die Stufen Qualitätssicherung und Abnahme ins Produktivsystem gelangen. Wesentlich ist dabei, dass derartige Prozesse definiert, dokumentiert und gelebt werden. Auf diese Weise wird der Betrieb komplexer IT Landschaften unterstützt, so dass die Qualität der Softwareentwicklung immer auf einem fest definierten Niveau erfolgt, Fehler vermieden und die Dienstleistungserbringung wiederholt werden kann. Nur dadurch kann sichergestellt werden, dass die Anforderungen, die aus dem Business entstehen bewertet und je nach Nutzen priorisiert und effizient umgesetzt werden. Vor diesem Hintergrund ist Change und Release Management ein integraler Bestandteil der IT Governance. Es genügt nicht, sich auf die Bereitstellung von Systemen zu fokussieren und Überlegungen zum Betrieb der Lösung bis zum Go-Live zu vernachlässigen. Ein effizienter Change und Releasemanagement Prozess beeinflusst in hohem Masse die Agilität eines Unternehmens und kann somit zu einem entscheidenden Wettbewerbsvorteil werden. Die ASAP Roadmap wurde von SAP als Vorgehensmodell für die erfolgreiche Umsetzung von SAP Einführungsprojekten definiert. Kürzlich wurde dieses Vorgehensmodell vom Active Global Support der SAP um die Run SAP Methodik erweitert. Dieses Vorgehensmodell definiert die erforderlichen Schritte und Prozesse, die zum erfolgreichen und effizienten Betrieb einer SAP Landschaft notwendig sind. Ein wesentlicher Bestandteil ist in dieser Roadmap dem Thema Change Management gewidmet. Abbildung 1: RunSAP Roadmap Copyright REALTECH 2009 Seite 2 von 10
In der Vergangenheit wurden oftmals Transportaufträge einzeln in verschiedene Systeme eingebracht, eine Bündelung von Transportaufträgen zu Change Requests existierte nicht und erhöhte den Aufwand. Besonders hoher Verwaltungs- und Administrationsaufwand ist vor allem dann gegeben, wenn eine Kundenanforderung zu Änderungen auf verschiedenen Systemlandschaften (z.b. ERP, BI, CRM) führt. Die entstehenden Transportaufträge müssen dann oftmals in der richtigen Reihenfolge und synchronisiert in die verschiedenen Systeme eingebracht werden, was zu einem hohen Kommunikationsaufwand führt. Die von SAP propagierte Lösung, der SAP Solution Manager mit der Komponente ChaRM ist für derartige Anforderungen kaum gerüstet, da das Change Management zunächst nur SAP Systeme berücksichtigt. Change und Releasemanagement muss jedoch als ein team- und systemübergreifendes Thema verstanden werden, welches im gesamten Unternehmen verankert ist. Aus Sicht eines CIO ist es vor allem wichtig, unternehmensweite Standards für Softwareänderungen definieren zu können und diese Standards für jede Entwicklung tool unterstützt abbilden zu können. Diese Maßnahme ist beispielsweise auch im Capability Maturity Modell Integration (CMMI) vorgesehen. Ein Reifegrad vom CMMI Level 3 kann nur dann erteilt werden, wenn das Standardprozessframework in allen Geschäftseinheiten eingehalten wird, ein einzelnes Softwareentwicklungsteam kann dadurch nicht CMMI Stufe 3 zertifiziert werden. Betrachtet man die Aufwände für IT-Budgets in der Vergangenheit mit heute, so stellt man fest, dass immer weniger Kosten für Hardware und Software und wesentlich mehr in die Organisation investiert werden muss. Compiler, Entwicklungsumgebungen und arbeitsbegleitende Software sind inzwischen zur Commodity geworden. Die wesentlichen Kosten für Softwareerstellung und Wartung komplexer IT-Systeme spiegeln sich im personellen Aufwand wieder. Die IT-Budgets sind im Zuge der Finanzkrise an vielen Stellen noch weiter gesunken und gestrichen worden. In einigen Studien geben CIOs an, dass eine weitere Kürzung ohne Verringerung geforderten Servicequalität oder Verringerung der IT- Systeme nicht mehr möglich ist. Einsparungen sind hier meist jedoch noch möglich, wenn die Prozesse und die Organisation effizienter gestaltet werden. Dabei sollte jede IT-Abteilung sich fragen, ob sie die mögliche oder tatsächlich benötigte Leistung liefert und wie die Serviceanforderungen erhoben und bewertet werden. Auch die Frage, ob der Aufwand angemessen ist und Kostenstruktur und Kostentreiber bekannt sind, ist wesentlich für eine Optimierung. Insbesondere im Zusammenhang mit Change und Release Management ist es unabdingbar zu hinterfragen, wo am falschen Ende gespart wird und was die Minderqualität von IT-Services kostet. Die Erhebung solcher Daten für das Thema Softwarechangemanagement kann nur dann sinnvoll und genau durchgeführt werden, wenn ein Werkzeug zum Change und Releasemanagement eingesetzt wird. Copyright REALTECH 2009 Seite 3 von 10
Abbildung 2: IT-Budgets im Zeitverlauf Dadurch besteht dann auch die Möglichkeit, mit Softwareunterstützung strategisches IT- Service Management zu betreiben und die korrekte Ausrichtung der IT mit Hilfe von Balanced Scorecards stets zu überprüfen. Eine Software, die Change und Release Management unterstützt, muss in der Lage sein, verbindliche Prozesse zu unterstützen und Compliance sofern für das einzelne Unternehmen notwendig zu erzwingen. ChangePilot ist eine Change und Releasemanagement Lösung für komplexe IT Landschaften, die sich nahtlos in existierende Toollandschaften integriert. Die serviceorientierte Architektur der Software ermöglicht eine schnelle Anbindung externer Werkzeuge wie z.b. Service Desk oder Configuration Management Werkzeuge. Projektleiter definieren in ChangePilot ihre Projekte und steuern bzw. überwachen den Projekterfolg mittels des integrierten Management Dashboards. Dadurch könnten Verzögerungen im Projektverlauf frühzeitig erkannt werden und Gegenmaßnahmen ergriffen werden. Change Manager nutzen ChangePilot um Change Requests zu erfassen oder zu klassifizieren und Komponenten zuzuordnen. Die Verknüpfung des Change Requests mit einem konkreten Release und die Genehmigung des Change Requests wird üblicherweise auch vom Change Manager übernommen. Eine grafische Oberfläche zur Definition und Änderung der in ChangePilot definierten Change Prozesse erleichtert die Anpassung an neue gesetzliche oder organisatorische Vorgaben. Release Manager planen in ChangePilot Releases, wobei jeder Change Request einem Release zugeordnet werden muss. Releases können verschiedene Typisierungen besitzen (z.b. Projektrelease, Wartungsrelease) und werden mit einer Releasenummer versehen. Die Copyright REALTECH 2009 Seite 4 von 10
Bildung von Releasehierarchien ist möglich, um beispielsweise komplexe Bäume mit einem Basisrelease und darauf aufbauenden Releases zu modellieren. Der Releasemanager stellt diese Releasehierarchie zusammen, definiert ggf. verschiedene Releasetypen und legt Prozesse für diese Releasetypen fest. Die Daten der einzelnen Releases (z.b. Testbeginn, Code-Freeze, Feature-Freeze) werden in einem Releasekalender festgelegt. In der SAPGui Oberfläche des ChangePilot verknüpft ein ABAP Entwickler den Transportauftrag mit dem ihm zugewiesenen Change Request. Darüber hinaus hat der Entwickler eine Übersicht aller, ihm zugeordneten Change Requests und des damit verbundenen Releases. Über eine Suchfunktion ist der Softwareentwickler in der Lage, Change Requests zu lokalisieren. Je nach Berechtungsmodell kann es möglich sein, nur nach eigenen Change Requests zu suchen oder alle Change Requests zu durchsuchen. Aktivitäten an Change Requests (z.b. Markierung des Change Requests als abgeschlossen) werden auch über diese Oberfläche vorgenommen. Diese Nutzung der Oberfläche im SAPGui schließt auch SAP Berater ein, die Customizing durchführen und dadurch Änderungen erzeugen, die ebenfalls mit einem Change Request verknüpft sein müssen. Softwareentwickler für SAP Java Technologien (Process Infrastructure, Java, Enterprise Service Repository) nutzen hierfür die Weboberfläche des ChangePilot. Abbildung 3: ChangePilot Die Abbildung zeigt die Integrationsmöglichkeiten des ChangePilot in existierende Systemlandschaften. Der Solution Manager Service Desk kann als Incident und Problem Management Lösung genutzt werden, mittels derer Changes in ChangePilot angelegt werden. ChangePilot kann jederzeit den aktuellen Bearbeitungsstatus des Change Requests in das Ticket im Service Desk zurückspiegeln. Eine Integration von non-sap Entwicklungen ist mittels verschiedener Configuration Management Tools möglich. Configuration Management Tools versionieren die Softwarestände von non-sap Entwicklungen, so dass Copyright REALTECH 2009 Seite 5 von 10
die daraus entstehenden Source-Artefakte mit einem Change Request in ChangePilot verbunden werden können. ChangePilot verfügt über eine intelligente Delivery Logik, die die Livesetzung von Releases oder Changes erlaubt. In Abhängigkeit des Importergebnisses kann der weitere Workflow gesteuert werden. Change Management Die ChangePilot Einstiegsseite für Benutzer stellt das Dashboard dar. Dieses kann je nach Rollenzugehörigkeit frei definiert werden. Die einzelnen Elemente können frei konfiguriert und auf dem Dashboard in Form von Mashups gestaltet werden. Abbildung 4: Dashboard Der Change Management Reiter ist die Ansicht, in der Change Requests bearbeitet, angelegt und Aktivitäten vervollständigt werden. Change Manager definieren mittels der Konfigurationsoberfläche verschiedene Change Request Typen, die jeweils Releasetypen zugeordnet werden können. Jeder Change Request Typ kann dabei benutzerdefinierte Attribute und auch einen eigenen Workflow besitzen. Der Workflow wird mittels des grafischen Workfloweditors einfach definiert. In der Auslieferung sind bereits Bausteine für Testintegration, Belieferung und Benachrichtigungen erhalten. Mittels einer Expertensicht können auch auf einfache Weise Webserviceaufrufe an externe Softwarewerkzeuge konfiguriert werden. Alle Workflows werden versioniert und werden erst nach einem Genehmigungsverfahren freigeschaltet. Dies erlaubt es, dass Copyright REALTECH 2009 Seite 6 von 10
Änderungen am Softwareentwicklungsprozess erst durch das Change Advisory Board genehmigt werden müssen, bevor diese Änderungen auch tatsächlich erfolgen und auf das System durchschlagen. Eine neue Workflowversion gilt dabei ausschließlich für neue Change Requests, bereits bestehende werden jeweils in der Version, mit der der Change Request angelegt wurde gesteuert. Die ausgelieferten Standardbausteine, die für die Konfiguration des Workflows verwendet werden können, werden mit den folgenden Produktreleases erweitert. Abbildung 5: Grafischer Workfloweditor Release Management ChangePilot ermöglicht Releasemanagern die Definition und Terminierung von Releases im Kalender. Dabei ist es möglich, verschiedene Releasetypen zu definieren und auch die Beziehungen von Releases in Releasehierarchien abzubilden. Die Definition erlaubt eine Festlegung, welche Change Request Typen einem Releasetyp hinzugeordnet werden können. Ebenso wie Change Requests unterliegen Releases einem Workflow, der mittels des grafischen Editors festgelegt werden kann. Auch hier existiert ein Approvalworkflow, so dass Änderungen an der Releasedefinition zunächst durch das Change Advisory Board (CAB) genehmigt werden müssen, bevor diese Änderung dann für neu erstellte Releases herangezogen wird. Die Definition von Systembelieferungen und Systemen bzw. Mandanten erfolgt immer auf der Releasedefinition. Eine Belieferung von SAP Systemen sollte auch immer auf Basis eines Releases zu einem terminierten Datum erfolgen, es ist jedoch auch möglich einzelne Change Requests in ein System einzuspielen. In diesem Fall sind jedoch die Zielsysteme und Belieferungen auch vom dem Change Request zugeordneten Release abhängig. Copyright REALTECH 2009 Seite 7 von 10
Delivery Management Die Belieferung von SAP Systemen kann mittels einer STMS Integration oder über den TransportManager erfolgen. Im Falle der TransportManager Integration wird dieser remote durch die Definition der Change und Release Prozesse aus ChangePilot heraus konfiguriert. Belieferungen, Importe und Approvals finden auf Ebene des ChangePilot statt, so dass SAP Basisberater, die bisher den TransportManager genutzt haben nun aus ChangePilot heraus den Import von Releases oder Changes steuern. Die bekannte Kollisionsprüfung kann in den Workflow integriert werden, so dass beispielsweise Releases erst dann produktiv gesetzt werden können, wenn keine Kollisionen auftreten. Abbildung 6: Change Management Vorteile von ChangePilot Definition von verbindlichen Entwicklungsprozessen (IT-Governance und IT-Alignment) Einhaltung von Compliancevorgaben bei Systemänderungen Effizientes Management von IT Landschaften Einfaches Reporting des Projektstands Auswertung von Änderungen für strategisches IT Service Management Management von Key Performance Indikators (KPI) Support für IT-Service Provider Copyright REALTECH 2009 Seite 8 von 10
Architektur REALTECH ChangePilot ist eine Change und Release Management Lösung für komplexe SAP Landschaften, die sich nahtlos in die bestehende Enterprise-IT integriert. Die Lösung besteht aus mehreren Komponenten. Abbildung 7: ChangePilot Architektur Das Zentralsystem steuert die Datenhaltung, Weboberfläche und die Kernprozesse. Die Frontend Komponenten dienen der Nutzung des REALTECH ChangePilot aus der SAPGUI heraus. Das Zentralsystem wird als AddOn auf einem Java fähigen Webserver (ab EJB 2.0) installiert. Üblicherweise handelt es sich hierbei um den Java Stack des SAP Solution Manager 7.0, es kann jedoch auch jeder andere EJB-fähige Webserver verwendet werden. Für das Deployment auf dem WebAS Java Stack wird ein Software Deployment Archive (SDA) ausgeliefert, das mittels des SAP Software Deployment Managers (SDM) einfach installiert werden kann. Die Frontend Komponenten werden als AddOn im SAP System installiert. Die Installation wird durch den Import mehrerer Transportdateien durchgeführt. Die Verteilung der verschiedenen Transporte wird in der gesamten Systemlandschaft durchgeführt und ist vom Systemaufbau abhängig. Copyright REALTECH 2009 Seite 9 von 10
Weitere Informationen zu unseren Softwareprodukten unter: www.realtech.com REALTECH system consulting GmbH Industriestr. 39c 69190 Walldorf Germany Tel +49.6227.837.571 Fax +49.6227.837.9571 customer-services-addons@realtech.com http://www.realtech.com Copyright REALTECH 2009 Seite 10 von 10