Change Request

Change Request begegnet Entscheidern in zwei Zusammenhängen, die im Gespräch leicht verschwimmen. Im Projekt ist er der förmliche Antrag, den vereinbarten Leistungsumfang, Termine oder den Preis zu ändern, etwa weil eine Schnittstelle fehlt oder eine Fachabteilung eine zusätzliche Funktion wünscht. Im laufenden IT-Betrieb ist er der Antrag, ein produktives System zu verändern: ein Update einspielen, eine Firewallregel anpassen, einen Server abschalten. In beiden Fällen enthält ein brauchbarer Change Request dieselben Bausteine: was geändert werden soll und warum, welche Systeme, Leistungen oder Vertragsteile betroffen sind, welche Risiken entstehen, was die Änderung kostet und wie lange sie dauert, und wer darüber entscheidet.

Im Betrieb orientieren sich viele Organisationen an ITIL 4. Dort gilt als Änderung jede Ergänzung, Anpassung oder Entfernung von etwas, das direkt oder indirekt Auswirkungen auf Services haben kann. Die zugehörige Praxis heißt in ITIL 4 Change Enablement, in älteren Ausgaben Change Management. Sie unterscheidet drei Typen: Standard-Changes sind vorab genehmigt, risikoarm und wiederholbar. Normale Changes durchlaufen eine Risikobewertung und eine Freigabe. Notfall-Changes werden beschleunigt umgesetzt, wenn ein größerer Störfall droht, und danach nachträglich überprüft.

Warum Change Requests Sache der Führung sind

In Projekten sind Change Requests der Ort, an dem sich Budget und Termine verschieben. Ein Festpreis deckt nur den vereinbarten Umfang ab. Jede Änderung danach wird verhandelt, und viele kleine Änderungen ergeben in Summe oft mehr Mehraufwand als eine große. Fehlt ein geregeltes Verfahren, entsteht Streit darüber, ob eine Leistung schon geschuldet war oder zusätzlich zu vergüten ist. Ein ausdrückliches Anordnungsrecht des Auftraggebers kennt das BGB im Bauvertragsrecht (§ 650b BGB). Für IT-Projekte gibt es keine vergleichbare Vorschrift; wie Änderungen beantragt, bewertet und vergütet werden, muss der Vertrag regeln.

Im Betrieb geht es weniger um Geld als um Stabilität und Nachweisbarkeit. Ungeplante oder schlecht abgestimmte Änderungen gehören zu den häufigen Ursachen von Störungen. Ein geordnetes Verfahren zeigt, wer eine Änderung beantragt, geprüft und freigegeben hat. Genau das fragen Wirtschaftsprüfer, Zertifizierer und Aufsichtsbehörden nach; die Norm ISO/IEC 20000-1 für IT-Service-Management verlangt ein Änderungsmanagement als festen Bestandteil.

Hinzu kommt ein Souveränitätsaspekt. Bei eigenen Systemen entscheidet das Unternehmen selbst über Änderungen. Bei Cloud- und SaaS-Diensten ändert der Anbieter seinen Dienst nach eigenem Plan: Funktionen fallen weg, Schnittstellen ändern sich, Datenstandorte verschieben sich. Ein Kunde kann dort keinen Change Request stellen, der den Anbieter bindet. Ihm bleiben vertraglich vereinbarte Ankündigungsfristen, Informationsrechte und im Zweifel der Ausstieg.

Wie ein Change Request in der Praxis abläuft

Der Ablauf ist in Projekt und Betrieb ähnlich. Jemand stellt den Antrag mit Begründung. Die zuständige Stelle bewertet Aufwand, Risiko und Wirkung auf andere Teile. Eine dafür benannte Instanz entscheidet: im Projekt meist der Lenkungskreis oder die Projektleitung, im Betrieb eine Change Authority, die je nach Risiko eine Person, ein Gremium oder ein automatisierter Freigabeschritt sein kann. Danach wird umgesetzt, getestet und dokumentiert, bei größeren Änderungen mit einer Rückschau.

Ein denkbares Szenario: Ein mittelständisches Unternehmen führt eine neue Unternehmenssoftware zum Festpreis ein. In der Testphase fällt dem Einkauf auf, dass ein mehrstufiger Freigabeprozess für Bestellungen fehlt. Der Dienstleister reicht einen Change Request mit zusätzlichem Aufwand und mehreren Wochen Verzug ein. Das Unternehmen hält die Funktion für selbstverständlich, der Dienstleister verweist auf die Leistungsbeschreibung, in der sie nicht steht. Weil der Vertrag kein Änderungsverfahren und keine Preisbasis für Änderungen vorsieht, zieht sich die Klärung über Wochen, und der Starttermin rückt. Eine präzise Leistungsbeschreibung und ein vorab vereinbartes Verfahren hätten den Streit auf eine Sachfrage reduziert.

Worauf es in Angeboten und Verträgen ankommt

• Geregeltes Verfahren: Form des Antrags, Fristen für Angebot und Entscheidung, und wer auf beiden Seiten Änderungen beauftragen darf.
• Preisbasis vorab: Tagessätze oder Preise für Änderungen schon im Hauptvertrag festlegen, nicht erst im Streitfall verhandeln.
• Folgen sichtbar machen: Jede Änderung mit ihren Auswirkungen auf Termine, Abnahme und Betriebskosten festhalten, nicht nur mit dem Einmalpreis.
• Schwelle für Kleinigkeiten: Ein begrenztes Kontingent für kleine Anpassungen spart Verwaltungsaufwand, braucht aber eine klare Obergrenze und regelmäßige Abrechnung.
• Änderungen des Anbieters: Bei Cloud- und SaaS-Diensten Ankündigungsfristen, Informationspflichten und ein Kündigungsrecht bei wesentlichen Änderungen vereinbaren.

Abgrenzung zu verwandten Begriffen

Quellen

• AWS: Change Enablement in the Cloud – Change enablement in ITIL 4 (Whitepaper)
• ITSM.tools: Change Enablement in ITIL 4 – Definition, Practice and Best Approaches
• Bundesamt für Justiz: § 650b BGB – Änderung des Vertrags; Anordnungsrecht des Bestellers

*** Keine Rechtsberatung. Dieser Eintrag ordnet rechtliche Rahmenbedingungen strategisch ein und ersetzt keine Rechtsberatung im Einzelfall.