Clustering avec ChaRM

Einige IT-Verantwortliche haben sich in der Vergangenheit damit beschäftigt, das Change Request Management einzuführen. Das Credo, das ich hier immer predige, heißt: Eine Anforderung einer Fachabteilung wird über einen Änderungsantrag genehmigt und führt dann zu einem oder mehreren Changes.

In dieser Aussage steckt bereits die erste Frage:

Warum eigentlich mehrere Changes?

Es ist ja nun so, dass der Solution Manager auch im Change Request Management mehrere Vorgangsarten beherrscht. Unter einer Vorgangsart versteht man im Wesentlichen ein Konstrukt aus einem Workflow, einer Definition des Change-Formulars, also der Oberfläche und insbesondere bei Changes im SAP- Umfeld natürlich auch mit dem Anschluss an das Transportwesen.

Kein anderes Change-Management- Werkzeug stellt diese Verknüpfung des Workflows mit der Importmechanik über die STMS so gut dar und verfügt über die gleichen Funktionen wie der Solution Manager.

Hierfür wurden die Vorgangsarten „Normale Änderung“ und „Dringende Änderung“ geschaffen. Nun ist es natürlich so, dass gerade komplexe Anforderungen nicht nur Änderungen in einer SAP-Umgebung, sondern auch in anderen Systemumgebungen erfordern.

Auch hierfür ermöglicht es der Solution Manager, einen Workflow zu definieren und diesen zu nutzen. Der Anschluss an das Transportwesen ist hier natürlich nicht vorhanden und auch gar nicht notwendig.

Über diese Konstruktion lassen sich z. B. auch Änderungen abbilden, die Anpassungen in einer SAP-Schnittstelle sowie auf einer Web-Oberfläche erfordern. Die Anpassungen auf der Web-Oberfläche würde man klassisch als „Non-SAP“-Change darstellen.

Dieses Konzept funktioniert sehr gut, da immer der Änderungsantrag die Klammer zwischen den einzelnen Changes bildet. Somit ist sichergestellt, dass auch die Koordination der unterschiedlichen Änderungen vollzogen werden kann.

Ohne einen Änderungsantrag kann genau diese Klammerung und erforderliche Abstimmung im Änderungsprozess nur sehr mühsam über Zusatzfelder auf dem Formular geschehen.

Die Thematik, dass ein Kunde über einen Change mit Transportanschluss mehrere Systemlinien versorgen will, hat SAP bereits in der Version 7.1 mit SP10 bereitgestellt. Genau diese Komponente nennt sich Cluster.

So kann ein sogenannter Cluster aus einer BW- und einer ERP-Landschaft gebildet werden. Über diesen Cluster können dann Changes verwaltet werden, die Änderungen in beiden Landschaften erfolgen. So ist sichergestellt, dass nicht händisch über mehrere Transportlandschaften Änderungen verwaltet und koordiniert werden müssen.

In Solution Manager 7.1 war diese Technik noch etwas in den Kinderschuhen. Die Cluster mussten immer identisch sein. Wer also eine ERP-Landschaft mit drei Systemen besitzt, benötigte auch drei Business- Warehouse-Systeme, um diese Logik zu vollziehen. Mit dem Solution Manager 7.2 hat sich dies geändert und es sind auch „unebene“ Cluster möglich.

Das Ganze hat sich auf den Folien immer so gut angehört, dass ich diese Funktionsweise immer bei Kunden vertreten habe. Gewundert habe ich mich immer, dass es im Internet, insbesondere im SDN nur wenige Diskussionen zu diesem Thema gab.

Seit dem letzten Implementieren ist mir auch klar, warum: Was SAP hier verschweigt, ist, dass die „Dringende Änderung“, die ja die meisten Kunden ausschließlich im Einsatz haben, diese Funktion gar nicht nutzen kann.

SAP hat diese Cluster-Funktionalität nur für die „Normale Korrektur“ implementiert und lässt damit insbesondere die Anwender außen vor, die keine releaseorientierte Entwicklung durchführen. Selbst Kunden mit einer releaseorientierten Entwicklung sind bestraft: Alle Changes innerhalb des Releases beherrschen den Cluster.

Alle anderen Changes vom Typ „Dringende Änderung“ nicht. Hier ist also massives Umdenken gefragt.

Leider war das so schlecht dokumentiert, dass auch ich hier in die Falle getappt bin. Der Weg aus dieser Sackgasse hat bedeutet, dass wir mittels Enhancement Spots und ein paar kleinerer Modifikationen die Cluster-Kollektion auch für „Dringende Änderungen“ aktiviert haben.

Ich hoffe, SAP hat hier ein Einsehen und handelt zeitnah. Wenn wir es als Beratungshaus schaffen, dieses Feature über Anpassungen einzuschalten, sollte das SAP ja erst recht gelingen.