{"id":65380,"date":"2019-06-10T11:48:00","date_gmt":"2019-06-10T11:48:00","guid":{"rendered":"https:\/\/kepner-tregoe.com\/blogs\/developing-a-risk-mitigation-discipline-in-it-change-management-part-1\/"},"modified":"2026-06-04T13:05:13","modified_gmt":"2026-06-04T13:05:13","slug":"developing-a-risk-mitigation-discipline-in-it-change-management-part-1","status":"publish","type":"post","link":"https:\/\/kepner-tregoe.com\/de\/blogs\/developing-a-risk-mitigation-discipline-in-it-change-management-part-1\/","title":{"rendered":"Entwicklung einer Disziplin zur Risikominderung im IT-Change-Management (Teil 1)"},"content":{"rendered":"\n

Dies ist der erste von zwei Beitr\u00e4gen zum Thema Risikominderung. <\/p>\n\n

Der Change-Management-Prozess in IT-Organisationen verfolgt zwei Hauptziele: die Wirksamkeit der Implementierung von \u00c4nderungen zu maximieren und das Risiko f\u00fcr das Unternehmen zu steuern. IT-Organisationen haben sich im Allgemeinen an einen dokumentierten Change-Prozess gehalten und sich dabei meist auf die Prozess-Compliance konzentriert, anstatt konsequent dar\u00fcber nachzudenken, Risiken dort, wo sie erforderlich sind, vorherzusehen und zu mindern. <\/p>\n\n

IT-Teams erstellen und setzen diese Prozesse nach Frameworks wie ITIL\u00ae durch. Die Governance, die sich aus diesem Ansatz ergibt, hat Organisationen sehr reaktiv gemacht. Traditionelle Prozesse sind f\u00fcr das heutige Ma\u00df an Ver\u00e4nderung und Innovation zu langsam. <\/p>\n\n

Das war in Ordnung, als die Geschwindigkeit des Wandels noch geringer war. Ein Change Advisory Board (CAB) konnte sich einmal pro Woche oder sogar einmal im Monat treffen und diese \u00c4nderungen in den Griff bekommen. Aber die Ver\u00e4nderungsrate, sowohl extern (getrieben durch den Wettbewerb) als auch intern (getrieben durch Innovationsm\u00f6glichkeiten), hat sich so stark beschleunigt, dass dieser Rhythmus nicht mehr funktioniert. <\/p>\n\n

Infolgedessen werden wichtige \u00c4nderungen auf Eis gelegt, weil die IT und das Unternehmen nicht mehr Schritt halten k\u00f6nnen. Das Management erkennt nun die Bedeutung der Gesch\u00e4ftsrisiken, die diese \u00c4nderungen mit sich bringen k\u00f6nnen. \u00c4nderungsantr\u00e4ge bleiben im \u00dcberpr\u00fcfungsprozess stecken, bis die Risiken verstanden sind. Zunehmend versp\u00fcrt das Unternehmen die Notwendigkeit, diese \u00c4nderungen dennoch vorzunehmen, um Wettbewerbsbedrohungen zu begegnen und Chancen zu nutzen, sieht aber seine \u00fcberlastete IT-Funktion eher als Hindernis denn als Verb\u00fcndeten. Gesch\u00e4ftsleute beginnen nach Wegen zu suchen, die IT zu umgehen, anstatt mit ihr zusammenzuarbeiten. <\/p>\n\n

Deshalb wird in Zeiten von Agile der traditionelle CAB-Ansatz in Frage gestellt. Neue Management-Philosophien wie DevOps haben beschleunigte Ver\u00e4nderungen und Innovationen gebracht, indem sie die mit jedem neuen Release verbundenen Risiken in viel kleinere Schritte zerlegt haben, indem der Umfang der Releases drastisch reduziert wurde. Dies verringert die Auswirkungen auf das Unternehmen, falls etwas schief geht \u2013 was unweigerlich passieren wird. <\/p>\n\n

In diesem neuen Umfeld ist es f\u00fcr IT-Organisationen wichtig, Risiken anhand von drei verschiedenen Dimensionen zu bewerten:<\/p>\n\n