Die Kunst der kontrollierten Veränderung

Der Autor ist Gründer und Vorstand der VMS AG. Per aspera ad astra! Jeder CIO erfährt tagtäglich, dass auch in der IT die Götter vor den Erfolg den Schweiss gesetzt haben. Dass Systeme und Prozesse, je länger sie in Betrieb sind, an Komplexität zunehmen, ist gewissermassen ein Naturgesetz. Immer weitergehende Verfeinerungen werden Teil der Abläufe, Ausnahmesituationen fliessen in den Prozess ein. Der breite Einsatz von Standard-Software wie SAP scheint eher Teil denn Lösung des Problems. Jede Modifikation, Neuimplementierung oder Eigenentwicklung, jeder zusätzliche Nutzerkreis macht eine Anwendungs- und Systemlandschaft komplexer. Komplexität an sich, zum Beispiel durch vielfältige Schnittstellen zwischen Systemen, bereitet keine Probleme. Jedenfalls solange man Systeme stabil und unverändert lässt. In einem sehr dynamischen Umfeld ist Stabilität allerdings ein Wunschtraum. Denn ist das System einmal implementiert, belastet der Grad der gegenseitigen Abhängigkeiten jede Änderung. Wandeln sich die äusseren und inneren Rahmenbedingungen, führt das zwangsläufig zu neuen Anforderungen in den unterstützenden Systemen und Prozessen. Das Ergebnis zeigt sich dann in monate­langen Releasewechselprojekten oder in einer deutlichen Zurückhaltung der IT hinsichtlich der  spontanen Anforderungen des Business. Das wird dann von den Anwendern als Inflexibilität der IT wahrgenommen.

Änderungen an der IT – neudeutsch als Changes bezeichnet – sind vor diesem Hintergrund nicht per se verwerflich. Mitunter sind sie sogar unerlässlich, wenn eine Unternehmensstrategie umzusetzen ist oder die Schlagkraft einer Organisation erhöht werden soll. Zum Teil sind Changes vom Unternehmen selbst allerdings auch nicht beeinflussbar. Sie werden schlechterdings vorgeschrieben von der Produktpolitik der Hersteller. Man bedenke allein, welche massiven Auswirkungen auf die SAP-Landschaft der Wechsel von einem singulären ERP-System auf ein Bündel von Spezialanwendungen (ERP, Reporting, Data Warehousing, Kundenbeziehungsmanagement, Suppliermanagement, Integrations-Middleware/EAI etc.) bewirkt. Anstösse und Gelegenheiten für grössere und kleinere Changes gibt es folglich en masse. Es ist offensichtlich, dass der Komplexitätsgrad in dieser Hinsicht Aufwand, Kosten und letztlich auch die Zahl der Changes unmittelbar beeinflusst.

Abstrakt gesprochen wird Komplexität von der Zahl der beteiligten IT-Komponenten und der Menge von deren Verknüpfungen getrieben. Übersetzt in die Praxis heisst das z.B.: Mehrere Betriebssystemwelten sind komplexer als eine einheitliche. VMS hat das bereits 2007 exemplarisch an Untersuchungen zu SAP gezeigt. Der technische Betrieb von SAP in einer Ein-Betriebssystem-Umgebung für die gesamte IT liegt um 37 Prozent unter den Kosten bei Einsatz mehrerer unterschiedlicher Betriebssysteme. Gleiches gilt für den Mix von Anwendungsprogrammen, oder auch – in Zeiten der Cloud – den Einsatz mehrerer Virtualisierungsprodukte. Bereits der Betrieb eines Produkts in mehreren Releaseständen ist kostentreibend. Auch das gilt von Adobe bis VMware. Jede Änderung an einer einzelnen Komponente hat direkt oder indirekt Einfluss auf die übrigen Bestandteile einer Systemlandschaft. Oder vereinfacht ausgedrückt: Jeder Change zieht eine lange Schlange weiterer Folge-Changes nach sich. Der hier grob skizzierte Hintergrund verdeutlicht, dass Change Management weit mehr als die effiziente Ausführung von Änderungsprojekten umfasst. Zu den ersten Aufgaben des Change Management zählt natürlich eine sinnvolle Auswahl, Bündelung und Reihenfolge unter den Änderungswünschen, die mit vertretbarem Aufwand zu bewältigen sind. Es gilt auch abzuwägen, ob der Gewinn an Nutzen (z.B. für die Einführung einer weiteren Anwendung ausserhalb des Portfolios) eine Erhöhung des Komplexitätsgrades wert ist, für den später wieder ein hoher Folgepreis zu zahlen ist. Im Sinne einer nachhaltigen Lösung muss aber ein begleitender Prozess institutionalisiert werden, um den Komplexitätsgrad einer System- und Anwendungslandschaft zu überwachen und wo immer möglich zu reduzieren. Schliesslich ist die beste Änderung eine, die erst gar nicht anfällt.

Die Beschränkung auf wenige Lieferanten, die Konsolidierung und Homogenisierung der Server- und Speicherressourcen, angefeuert durch Virtualisierung, sind beispielsweise ein trefflicher Pfad, fremdbestimmte Changes durch die Releasepolitik der Hersteller deutlich zu reduzieren. Auf Lösungsseite ist die Verwendung von Templates ein bewährtes Verfahren, um gleichartige Prozesse im Konzern auszurollen, auch ohne sich auf ein einziges zentrales System festzulegen. Im Sinne der Komplexitätskontrolle muss dazu aber auch ein striktes Controlling in Form eines Template-Monitoring eingeführt werden, um die Verselbstständigung der Komponenten zu verhindern.

Ein weiterer Ansatzpunkt, um die Zahl der Interaktionspunkte und damit der Changes dauerhaft zu reduzieren, ist das Thema Eigenentwicklungen. Gerade im Zusammenhang mit einem anstehenden Change und/oder Releasewechsel am ERP-System stellt sich stets die Frage nach einem gründlichen «Hausputz». Denn die Übernahme nicht mehr genutzter bzw. wenig nützlicher Eigenentwicklungen in die neue Version ist auch mit Blick auf künftige Änderungen ein erheblicher Kostenfaktor. Eine detaillierte Kenntnis des Ist-Zustands ist eine Grundvoraussetzung, um geeignete Ansatzpunkte zu identifizieren. Im praktischen Einsatz zeigt sich, dass nur eine detaillierte, präzise Vermessung der Systeme klar aufzeigt, welche Abhängigkeiten zwischen Funktionen, Eigenentwicklungen und Systemen vorherrschen und ob Nutzen und Nutzung das rechtfertigen. Auf dieser harten Datengrundlage lässt sich gut entscheiden, an welchen Stellen Bereinigungen sinnvoll sind. Sie sollte auch als feste Leistung in den betrieblichen Ablauf integ­riert werden, um die Entwicklung der System- und Anwendungslandschaft kontinuierlich zu überwachen. Denn allen Standardisierungsbemühungen zum Trotz führen Systeme sonst relativ schnell wieder ein Eigenleben, das über die Zeit zu erheblichen Abweichungen und damit neuer Komplexität führt. Neben der Planung ist an dieser Stelle eine Controlling-Instanz im Change Management essenziell, um zeitnah ordnend eingreifen und die Company Policy durchsetzen zu können.

Change Management bedeutet vor allem Management. Das heisst nichts weniger, als eine Balance zwischen Aufwand, Nutzen und Folgen der Änderungsanforderungen zu finden. Die hohe Kunst hierbei ist es, zwischen der Anforderung nach einheitlichen, homogenen Struk­turen und dem Anwenderwunsch nach neuer Funktionalität abzuwägen. Um diesen sicherlich nicht einfachen, konfliktfreien Prozess zu unterstützen, muss er aber aus abstrakten Höhen auf die Basis der Fakten zurückgeführt werden. Mit klaren Messungen zu Kosten und Folgewirkungen von Changes lässt sich die Balance zwischen zu viel Rigorosität und damit Unwillen auf Anwenderseite, und zu viel Freiheit und damit einem höheren Komplexitätsgrad und schlechteren Kostenstrukturen finden. Ein Schritt voran auf dem Weg zu den Sternen.