Business & IT – Change Impact will gemanaged sein
28.03.08 by Peter Helfenstein
Bestehende IT-Systeme decken heute die Business-Prozesse praktisch vollständig ab. Mehrheitlich kommt dabei Paketsoftware strategisch zum Einsatz. Neuentwicklungen von ganzen Business-Systemen sind eigentlich eher die Ausnahme. Die moderne Anwendungsentwicklung arbeitet in solch einem Umfeld anders: Sie ist nicht mehr Build-Centric, sondern Change-Centric, siehe auch Punkt #4 im Blog-Beitrag von Niel Roberston, CTO von ALM Anbieter Newmerix.
War früher bei Projekten das Bauen von neuen Systemen in erster Linie kreative, innovative Herausforderung, geht es heute vielmehr darum eine mehr oder weniger grosse Zahl von kleinen und grossen Changes an bestehenden Systemen und Customizings vorzunehmen. Die Systeme selbst sind gebaut, im Einsatz, zum Teil mit mehreren technischen und produktiven Instanzen und oft komplex miteinander verknüpft und lokal angepasst. Dies auf jeder Ebene, von der kleinsten Programmkomponente oder einzelnen Customizing-Einstellungen, über einzelne Business-Funktionen bis hin zu ganzen Geschäftsprozessen.
Kommt hinzu, dass heutige Systeme aus immer mehr aus mehrfach benutzten Komponenten bestehen. Serviceorientierte Architekturen erlauben Business Prozesse und funktionale Komponenten sauber zu trennen. Ein „guter Design“ erlaubt, Services relativ gut vor negativen Auswirkungen von Änderungen in Teilbereichen schützen. Doch neue Abhängigkeiten werden mit einer solchen Wiederverwendung auf jeden Fall geschaffen. Funktionale Komponenten werden von verschiedensten Business-Prozessen genutzt. Änderungen an einem einzelne Geschäftsprozess oder einer Geschäftsfunktion können an verschiedensten Stellen im System Konsequenzen haben.
Auch Systemkonsolidierungen tragen das ihre bei. Um Hardware und Softwarekosten einzusparen, werden Business Prozesse und funktionale Komponenten regional oder global auf einem System zusammengefasst. Änderungen aufgrund lokaler Bedürfnisse müssen somit immer im Kontext des gesamten konsolidierten Systems betrachtet werden.
Dies hat zur Folge, dass diese Komplexität für Änderungen verstanden werden muss, will man nicht böse Überraschungen erleben. Die Erfahrung zeigt, dass es im wesentlichen gilt, drei plus zwei Arten von Folgen am System zu verstehen und zu kontrollieren.
Ebenfalls sollte betrachtet werden, wieviel neue Komplexität im System mit der Änderung geschaffen wird. Ein nicht mehr wartbares System ist leider allzu schnell geschaffen.
Letztendlich sollte auch noch der Impact der Komplexität des Systems für die vorzunehmenden Änderungen beurteilt werden. Möglicherweise zeigt die Analyse des Systems, dass eine an sich einfache Änderung wegen zu hoher Systemkomplexität gar nicht in Angriff genommen werden sollte.
Im übrigen kann mittels geeigneter Massnahmen und Projekte, beispielsweise einem entsprechenden Systemdesign oder mit Schutzmassnahmen für Komponenten wie Firmentemplates präventiv ein Systemumfeld geschaffen werden, das Auswirkungen von Änderungen reduziert oder ungewollte Änderungen erkennt und nicht einfach zulässt.
IT Impact Analyse und IT Environment Protection werden so zu Schlüsseldisziplinen der Systementwicklung. Für Paketsoftwarelösungen gibt es erste gute Ansätze, diese Aufgabenstellungen richtig anzugehen. Informatikorganisationen, bei welchen Impact Analyse und Environment Protection konsequent in die IT Change Prozesse integriert sind, findet man jedoch noch selten. Stattdessen treiben die Firmen über den gesamten Application Lifecycle hinweg noch viel unnötigen Aufwand und bezahlen einen hohen Preis: Projekte werden zu komplex und geraten ausser Kontrolle, Abhängigkeiten werden nicht erkannt, Tests somit nicht durchgeführt und Fehler erst im Betrieb gefunden.
Konsequentes Impact Management, also Business & IT Change Impact Analyse und Environment Protection erlangen zentrale Bedeutung. Der Einsatz von umfassenden, eingekauften oder selbst entwickelten Softwaresystemen verändert die Optik beim Bau von Systemen – jeder neue Bedarf wird in erster Linie zu einer Änderung des bestehenden Systems!
Service Architekturen und Business Process Management erlauben Wiederverwendung, gleichzeitig steigen damit potentiell die Auswirkungen von Änderungen.
Change Impact Management bestehend aus Impact Analyse und Environment Protection konsequent in die Systementwicklungs-Methodik integriert und werkzeugunterstützt erlaubt, dass Systeme trotz hoher Komplexität über die Lebenszeit hinweg mit adäquatem Aufwand verändern lassen und sich die Komplexität nicht mit jeder Veränderung unnötig erhöht.
Der Nutzen von wirkungsvoller Impact Analyse und Environment Protection kann sehr gross sein. Paketsoftwareinstallationen und Systeme mit Service Architektur können mit vernünftigem Aufwand bei hoher Qualität weiterentwickelt werden. Die Systeme bleiben für Business und IT flexibler und mit kürzerer Reaktionszeit anpassbar. Sie können so viel länger im Einsatz stehen, ohne wegen zu hoher Komplexität frühzeitig wieder abgelöst werden zu müssen.

06.05.08 um 3:56 pm
[...] müssten sich an ihre sich schnell verändernde Umwelt anpassen und sich selbst immer schneller verändern. Klar. Aber sind die Umwelten von Unternehmen nicht [...]
13.05.08 um 2:25 pm
[...] Impact-Analyse Im wesentlichen werden drei Arten von Auswirkungsanalyse mit der beteo Impact-Sanduhr [...]
07.07.08 um 9:22 am
[...] Risikobewertungen ermöglichen, [...]
02.10.08 um 2:54 pm
[...] UCMDB ein Monitoring-System aufgesetzt werden, welches realtime alle System-Ausfälle anhand der Impact-Analyse-Funktion von UCMDB aufzeichnen, detailliert darstellen kann, sowie Auswertungen erlaubt. Ein anderer [...]
28.10.08 um 8:39 am
[...] SAP den BPCA überhaupt ankündigt, zeigt welch Stellenwert SAP der Auswirkungsanalyse zuordnet. Die Impact Analyse ist ein Thema, über welches wir auf beteo Blog bereits diverse [...]