Change und Release für IT-Services und Verbesserung

Eine Serverliste zeigt dir, welche Geräte vorhanden sind. Um zu beurteilen, was bei einer Änderung an einem Server geschieht, musst du auch wissen, was auf ihm läuft und wer von ihm abhängt. Das Servicekonfigurationsmanagement stellt zuverlässige Informationen über Servicekonfigurationen dort und dann bereit, wo und wann Teams sie benötigen.

Entscheide, was Konfigurationskontrolle benötigt

Ein Konfigurationselement (CI) ist eine Komponente, die verwaltet werden muss, um einen IT-Service bereitzustellen. CIs können physische Geräte, virtuelle Maschinen, Datenbanken, Anwendungen, Cloud-Services, Dokumente oder Services selbst sein. Die Organisation wählt aus, welche Komponenten diese Kontrolle benötigen. Ein Service Level Agreement kann ein CI sein, weil sein vereinbarter Inhalt für die Servicebereitstellung wichtig ist; eine günstige Ersatztastatur benötigt normalerweise keinen Konfigurationsdatensatz.

Ein Konfigurationsdatensatz beschreibt ein CI. Nützliche Felder sind Kennung, Typ, Version, Verantwortlicher, Standort, Status und Beziehungen. Die Kennung verhindert, dass zwei ähnliche Server verwechselt werden. Die Version hilft einem Deployment-Team zu prüfen, ob eine geplante Aktualisierung ein Ziel bereits erreicht hat.

Verfolge Abhängigkeiten, um Auswirkungen zu bewerten

Beziehungen wie „läuft auf“, „nutzt“ und „hängt ab von“ machen aus Datensätzen eine Service Map. Achte genau auf ihre Richtung: Eine Anwendung, die eine Datenbank nutzt, hängt davon ab, dass diese Datenbank verfügbar ist.

Betrachte die Bestellanwendung WEB-ORD. Sie läuft auf den virtuellen Servern VS-01 und VS-02 und nutzt DB-ORD. Diese Datenbank läuft auf dem Cluster CL-02. Auch die monatliche Umsatzberichterstattung nutzt DB-ORD.

Um eine Aktualisierung von CL-02 zu bewerten:

1. Finde die Datenbank, die auf dem Cluster gehostet wird: DB-ORD.
2. Verfolge, welche Services diese Datenbank nutzen: Bestellung und Umsatzberichterstattung.
3. Besprich die Auswirkungen mit beiden Serviceverantwortlichen und wähle einen Zeitpunkt außerhalb der bestellstarken Zeiten.

Würdest du nur den Verantwortlichen von CL-02 befragen, übersähest du die darauf aufbauenden Geschäftsservices. Dieselbe Darstellung hilft Supportmitarbeitenden, einen Fehler zurückzuverfolgen, und Sicherheitsmitarbeitenden, Systeme zu finden, die einen Patch benötigen. Release- und Deployment-Teams nutzen Konfigurationsversionen, um zu prüfen, was in den einzelnen Umgebungen installiert ist.

Verbinde Datensätze mit der tatsächlichen Arbeit

Aktualisiere betroffene Datensätze im Rahmen autorisierter Changes und Deployments. Sonst wird eine korrekte Service Map nach der nächsten Aktualisierung irreführend. Verifizierungen und Audits vergleichen Datensätze mit der tatsächlichen Umgebung; die automatisierte Erkennung kann helfen, Unterschiede zu finden. Untersuche eine Abweichung, um festzustellen, ob der Datensatz falsch ist oder ein Change ohne Autorisierung durchgeführt wurde.

Eine Konfigurationsbaseline ist eine vereinbarte, überprüfte Momentaufnahme von CIs, die als Bezugspunkt für spätere Changes dient. Sie hilft Teams, einen bekannten Zustand mit dem aktuellen Zustand zu vergleichen.

Erfasse die Einzelheiten, die für tatsächliche Entscheidungen benötigt werden. Jedes Attribut jedes Geräts zu erfassen, verursacht Arbeit, die möglicherweise nicht dauerhaft geleistet wird. Nützliche Datensätze unterstützen Auswirkungsprüfungen, Diagnose und die Einhaltung von Vorgaben und weisen die Verantwortung für Aktualisierungen klar zu. Ein Inventar allein kann diese Abhängigkeiten nicht zeigen.

IT-Assets haben finanziellen Wert und können zur Bereitstellung eines IT-Produkts oder -Services beitragen. Dazu gehören Geräte, Softwarelizenzen und Cloud-Abonnements. Das IT-Asset-Management verwaltet ihren gesamten Lebenszyklus, um Wert zu erzielen, Kosten und Risiken zu kontrollieren und vertragliche und regulatorische Anforderungen zu erfüllen.

Verfolge das Asset durch seinen Lebenszyklus

Der Lebenszyklus beginnt vor dem Kauf und setzt sich fort, nachdem das Asset nicht mehr genutzt wird:

1. Planen: Ermittle den Bedarf und berücksichtige, was bereits vorhanden ist.
2. Beschaffen: Kaufe, lease oder abonniere das Asset.
3. Entgegennehmen und registrieren: Erfasse das Element und die Eigentumsverhältnisse oder Bedingungen.
4. Bereitstellen: Weise es einem Anwender oder Standort zu.
5. Betreiben und warten: Repariere oder verlagere das Asset, weise es neu zu oder verlängere es.
6. Außer Betrieb nehmen: Beende die aktive Nutzung.
7. Entsorgen: Lösche Daten oder zerstöre Datenträger und führe Geräte anschließend je nach Fall dem Recycling zu oder gib sie zurück.

Aktualisiere den Datensatz bei jedem Ereignis. Eine jährliche Bestandsaufnahme kann diese Aktualisierungen prüfen, sie aber nicht ersetzen. Wenn ein Laptop zwischen zwei Bestandsaufnahmen zweimal den Anwender wechselt, muss die Organisation trotzdem wissen, wer ihn jetzt hat.

Ein Asset-Register erfasst Informationen wie Inventarkennzeichnung, Modell, Seriennummer, Verantwortlichen oder Anwender, Standort, Kaufdatum und Kosten, Ende der Gewährleistung oder des Leasingvertrags, Lizenzbedingungen und Status. Der Status unterscheidet ein Element „auf Lager“ von einem „in Gebrauch“ oder „außer Betrieb“.

Gleiche Softwarenutzungsrechte mit der Nutzung ab

Software-Asset-Management vergleicht Nutzungsrechte mit der tatsächlichen Installation oder Nutzung. Der Kauf zu weniger Lizenzen schafft ein Risiko für die Einhaltung von Vorgaben; ungenutzte Lizenzen zu behalten, verschwendet Geld. Prüfe die Lizenzbedingungen, bevor du Abonnements neu zuweist oder ihre Anzahl verringerst.

Ein Unternehmen zahlt für 500 Abonnements einer Bürosoftware-Suite jeweils 120 € pro Anwender und Jahr. Es hat 430 zugewiesen, sodass 70 ungenutzt bleiben. Ihre jährlichen Kosten in Euro betragen:

Vierzig neue Beschäftigte benötigen die Suite. Die Neuzuweisung von 40 ungenutzten Abonnements vermeidet den Kauf von 40 weiteren und damit zusätzliche jährliche Ausgaben von 4.800 €. Dreißig bleiben ungenutzt; werden diese bei der Verlängerung abbestellt, spart das 3.600 € pro Jahr. Das sind unterschiedliche Vorteile: vermiedene neue Ausgaben und verringerte bestehende Ausgaben.

Cloud-Konten gehören in dieselbe finanzielle Betrachtung. Ein nicht gemeldetes Abonnement einer Abteilung kann sowohl der Kontrolle von Verlängerungen als auch der Sicherheitsprüfung entgehen. Diese Schatten-IT muss sichtbar sein, auch wenn kein physisches Gerät gezählt werden kann.

Unterscheide finanzielle Fragen von Konfigurationsfragen

Dasselbe Werkzeug kann beide Datensätze enthalten, aber die Zwecke unterscheiden sich. Der Wiederverkaufswert ist nicht das Kriterium für ein IT-Asset: Ein Cloud-Abonnement kann finanziellen Wert haben, ohne weiterverkauft zu werden.

Die Außerbetriebnahme schließt die Entsorgung nicht ab. Bevor Geräte die Organisation verlassen, lösche ihre Daten sicher oder zerstöre die Datenträger und dokumentiere die Maßnahme. Gib Elektroschrott an zugelassene Recyclingbetriebe und geleaste Geräte an den Leasinggeber zurück. Der Asset-Datensatz sollte zeigen, was mit dem Element geschehen ist und wann.

Die Änderung eines Supportverfahrens kann einen Service ebenso beeinflussen wie die Änderung an einem Server. Ein Change ist das Hinzufügen, Ändern oder Entfernen von etwas, das Services direkt oder indirekt beeinflussen könnte. Dazu gehören Geräte, Anwendungen, Dokumente, Prozesse und Lieferantenvereinbarungen innerhalb des von der Organisation gewählten Umfangs.

Ermögliche nützliche Changes

Change Enablement zielt darauf ab, erfolgreiche Service- und Produkt-Changes zu maximieren. Dies geschieht durch drei zusammenhängende Aufgaben:

• Risiken angemessen bewerten.
• Die Durchführung von Changes autorisieren.
• Den Change-Kalender verwalten.

Das Ziel sind erfolgreiche Changes mit einem dem Risiko angemessenen Schutz. Anwender brauchen Verbesserungen und Korrekturen zeitnah. Sie brauchen außerdem bestehende Services, die weiter funktionieren. Ein langsamer Genehmigungsweg für jede kleine Aufgabe verschwendet Zeit und kann Teams dazu verleiten, ihn zu umgehen. Wenn jedes Team gemeinsame Systeme ohne Koordination ändern darf, sind Anwender vermeidbaren Ausfällen ausgesetzt.

Beispielsweise kann der Ersatz einer Anwendung neue Funktionen bringen, aber auch bestehende Arbeitsabläufe unterbrechen. Auch das Entfernen einer alten Datenbank ist ein Change: Ein anderer Service könnte ihre Daten noch nutzen. Selbst eine Dokumentänderung gehört zum Umfang, wenn sie ändert, wie Mitarbeitende Support leisten. Entscheidend ist die mögliche Auswirkung auf Services, nicht ob jemand neuen Code schreibt.

Beurteile den Erfolg anhand des Ergebnisses

Ein erfolgreicher Change wird wie geplant implementiert, liefert das beabsichtigte Ergebnis und verursacht keinen ungeplanten Schaden wie Incidents. „Die Installation ist abgeschlossen“ beantwortet nur einen Teil dieser Prüfung. Anwender können möglicherweise weiterhin nicht die Aufgabe erledigen, die der Change verbessern sollte.

Angenommen, in einem Quartal wurden 240 Changes implementiert und 12 schlugen fehl oder wurden zurückgenommen. Die Anzahl erfolgreicher Changes beträgt 228. Berechne die Quote mit allen implementierten Changes als Nenner:

Die Fehlschlagsquote von 5 % ergänzt die Erfolgsquote von 95 %. Wenn ein Team sowohl die Anzahl als auch die Quote festhält, erkennt es den Umfang der Arbeit. Eine hohe Erfolgsquote sollte zusammen mit der Geschwindigkeit betrachtet werden, mit der wertvolle Changes Anwender erreichen; das Blockieren nützlicher Arbeit könnte zu wenigen Fehlschlägen führen, dabei aber nur wenige Bedürfnisse erfüllen.

Erkenne Namen und Quellen von Changes

ITIL 4 verwendet Change Enablement, ebenso ITIL (Version 5). In älteren Materialien kann „Change Control“ oder „Change Management“ stehen. Organisatorisches Veränderungsmanagement ist eine eigene Practice, die sich damit befasst, wie Menschen neue Arbeitsweisen annehmen, einschließlich Kommunikation und Schulung.

Änderungsanträge können durch Problembehebungen, dringende Incidents, Sicherheitsaktualisierungen, Aktualisierungen von Lieferanten, neue Funktionen oder Verbesserungsideen entstehen. Ihr Ursprung hebt die Notwendigkeit nicht auf, sie zu bewerten, zu autorisieren und zu koordinieren. Auch ein Patch eines Lieferanten braucht einen angemessenen Change-Weg; auch bei einer kleinen Prozessverbesserung muss auf die Auswirkungen für Anwender geachtet werden.

Organisationen legen den Umfang und die Entscheidungswege fest, die zu ihren Services passen. Ein nützlicher Weg macht die verantwortliche Entscheidung sichtbar, gibt den Beteiligten genügend Informationen zur Risikobeurteilung und ermöglicht dem Team, die Arbeit zu einem passenden Zeitpunkt auszuführen.

Der Weg eines Change hängt davon ab, wie er bewertet und autorisiert wird. Seine technische Größe allein entscheidet nicht, ob er Standard, normal oder ein Notfall ist. Eine einzeilige Änderung an einem Router kann ein höheres Risiko bergen als eine umfangreiche, erprobte Softwareinstallation.

Wähle den passenden Weg

Das Risiko eines Standardverfahrens wird bei seiner Erstellung und bei Änderungen daran bewertet. Seine Vorabautorisierung gilt für dieses vereinbarte Verfahren. Ein Team kann eine unbekannte Aufgabe nicht einfach als Standard bezeichnen, weil es erwartet, dass sie leicht ist.

Normal bedeutet nicht mittleres Risiko. Ein risikoarmer normaler Change benötigt möglicherweise nur eine schnelle Genehmigung durch Fachkolleginnen oder Fachkollegen oder automatisierte Prüfungen. Ein großer normaler Change kann die obere Führungsebene benötigen. Change-Modelle legen diese Wege fest, damit Teams wissen, welche Informationen und welche Autorität für die jeweilige Art benötigt werden.

Verfasse einen brauchbaren Änderungsantrag

Ein normaler Change beginnt üblicherweise mit einem Änderungsantrag, auch RFC genannt. Gib der entscheidenden Person die Informationen, die sie für die Bewertung benötigt:

• Was sich warum ändern wird und welcher Nutzen erwartet wird.
• Betroffene Services und CIs sowie Risiko und Auswirkung.
• Implementierungs- und Testpläne.
• Einen Wiederherstellungsplan für den Service, falls der Change fehlschlägt.
• Vorgeschlagenes Datum und Uhrzeit.

Beim Verschieben einer Datenbank erklärt die Aussage „Der neue Speicher ist schneller“ einen erhofften Nutzen, lässt die Autorität aber nicht beurteilen, wer betroffen sein könnte oder wie das Team den Betrieb wiederherstellen würde.

Bewältige echte Dringlichkeit, ohne die Kontrolle zu verlieren

Bewertung und Autorisierung erfolgen bei Notfällen schneller, oft durch eine kleinere Autorität. Teste so umfassend, wie es die Zeit erlaubt. Ein Teil der Dokumentation kann danach abgeschlossen werden, aber die Dringlichkeit macht die Arbeit nicht zu einem nicht autorisierten Change. Eine ungetestete Korrektur kann einen weiteren Incident verursachen.

Wenn eine Führungskraft eine Funktion noch heute möchte, macht das die Anfrage nicht zu einem Notfall. Unmittelbare Bedrohungen für Services oder die Informationssicherheit rechtfertigen den beschleunigten Weg. Bei 18 Notfall-Changes von 240 Changes in einem Quartal beträgt der Anteil:

Verfolge diesen Wert im Zeitverlauf. Häufige dringende Arbeit kann auf Planungsprobleme hinweisen, die verbessert werden sollten.

Ein wiederholter normaler Change kann zum Standard werden, nachdem das Team das erprobte Verfahren dokumentiert, sein Risiko bewertet und die Genehmigung eingeholt hat. Das monatliche Einspielen von Patches auf nicht kritischen Testservern könnte dafür infrage kommen. Wiederholung allein liefert Erfahrung, aber keine Vorabautorisierung. Eine Firewall-Änderung für einen neuen Partner bleibt ein normaler Change, sofern nicht ein genehmigtes Standardverfahren genau diese Art von Änderung abdeckt.

Eine Genehmigung ist nützlich, wenn die entscheidende Person das Risiko versteht und rechtzeitig entscheiden kann. Eine Change-Autorität ist die Person oder Gruppe, die einen Change autorisiert. Weise die Autorität passend zu Art und Risiko der Arbeit zu und halte Routineentscheidungen nah bei den Menschen, die sie ausführen.

Bewerte Wahrscheinlichkeit und Auswirkung getrennt

Die Wahrscheinlichkeit betrifft die Chance eines Fehlschlags: Komplexität, Tests und die Erfahrung des Teams sind relevant. Die Auswirkung betrifft die Folgen: betroffene Services und Anwender, Datenverlust, Schwere und Wiederherstellungszeit. Nutze Konfigurationsbeziehungen, um Services zu finden, die von der geänderten Komponente abhängen.

Eine Organisation könnte Auswirkung und Wahrscheinlichkeit, jeweils auf einer Skala von 1 bis 5 bewertet, multiplizieren. In diesem Beispiel weist sie Werte von 1–5 der Genehmigung durch Fachkolleginnen oder Fachkollegen zu, 6–12 einem Change Manager und 13–25 einer ranghohen Autorität oder einem CAB. Dies sind organisationsinterne Schwellenwerte.

Ein Change Advisory Board (CAB) berät zu bedeutenden Changes. Es muss nicht jeden Change genehmigen. Prüfungen durch Fachkolleginnen und Fachkollegen und automatisierte Prüfungen können für geeignete risikoarme Arbeiten autorisierte Wege bieten.

Plane die Wiederherstellung vor der Implementierung

Jeder normale Change benötigt einen Wiederherstellungsplan, der angibt, wie der Service wiederhergestellt wird und wann die Wiederherstellung beginnt. Ein Rollback oder eine Rücknahme führt zum vorherigen Zustand zurück. Eine Vorwärtskorrektur behebt den Fehler; eine weitere Möglichkeit ist der Wechsel zu einem alternativen Service.

Ein getesteter Wiederherstellungsweg kann die Folgen eines Fehlschlags verringern. Ein Change ohne getestete Wiederherstellung birgt ein höheres Risiko und erfordert eine Entscheidung auf höherer Ebene. Nur „Bei Bedarf zurücksetzen“ aufzuschreiben, lässt das Team ohne Auslöser, Zuständigkeit oder praktische Abfolge zurück.

Koordiniere den Change-Kalender

Der Kalender unterstützt Planung, Kommunikation, Konfliktprüfung und Ressourcenzuweisung. Er hilft auch Incident- und Problemteams, kürzlich durchgeführte Changes zu erkennen, die einen Fehler erklären könnten. Organisationen können Sperrzeiten festlegen, etwa für einen Abrechnungslauf, mit Ausnahmen für Notfälle.

Angenommen, der Austausch eines Switches und eine Anwendungsaktualisierung sind beide für Samstag von 22:00 bis 02:00 Uhr angesetzt. Die Server der Anwendung hängen vom Switch ab. Der Ausfall würde Anwendungstests verhindern und die Fehlersuche erschweren. Verschiebe die Anwendungsaktualisierung auf Sonntag um 22:00 Uhr und informiere den Service Desk über beide Zeitfenster.

Überprüfe, was tatsächlich geschehen ist

Prüfe nach der Implementierung Zielerreichung, Incidents und unbeabsichtigte Auswirkungen, bevor du den Datensatz schließt. Untersuche Fehlschläge, um daraus zu lernen. Nützliche Kennzahlen sind Erfolgsquote, Changes mit Incidents als Folge, Notfallanteil und Zeit vom Antrag bis zur Implementierung.

Eine Funktion kann in der Produktivumgebung installiert sein, während Anwender noch nicht darauf zugreifen können. Release Management macht neue und geänderte Services und Funktionen zur Nutzung verfügbar. Es plant die Bereitschaft und Kommunikation ebenso wie den Zeitpunkt, zu dem Anwender Zugang erhalten.

Lege fest, was das Release enthält

Ein Release ist eine Version eines Services oder eines anderen CI oder eine Sammlung von CIs, die zur Nutzung verfügbar gemacht wird. Es kann Anwendungscode, Infrastruktur, Dokumentation, aktualisierte Verfahren, Schulungen und Wissensartikel enthalten. Wenn Supportmitarbeitende Anwendern bei der Funktion nicht helfen können, bleibt trotz technischer Bereitschaft eine Lücke.

Die Release-Planung legt Umfang, Zeitpunkt und Freigabekriterien fest. Verlange zum Beispiel, dass Tests bestanden, Supportmitarbeitende informiert, das Benutzerhandbuch aktualisiert und der Rollback getestet wurden. Anhand dieser Kriterien kann das Team vor der Erweiterung des Zugangs fundiert über die Bereitschaft entscheiden.

Versionskennungen unterscheiden, was verfügbar ist. In einem verbreiteten Schema Hauptversion.Nebenversion.Patch kennzeichnet der Wechsel von 4.2.0 zu 4.3.0 ein Release mit kleineren Funktionen; 5.0.0 kennzeichnet ein größeres Release. Teams vereinbaren ihre Nummerierungskonvention, damit Release Notes, Supportdatensätze und installierte Versionen sich auf dasselbe beziehen.

Trenne Deployment und Zugang

Deployment überführt Komponenten in eine Umgebung. Ein Release macht sie zur Nutzung verfügbar. Ein Feature Flag kann bereitgestellten Code inaktiv lassen und ihn anschließend für ausgewählte Anwender aktivieren.

Betrachte eine Banking-App, die Kontoauszüge als PDF ergänzt:

1. Überführe am Dienstag Version 3.4 auf die Produktivserver, wobei die Funktion ausgeschaltet ist. Der Code ist vorhanden, aber Kunden können die neue Funktion nicht nutzen.
2. Gib sie am Donnerstag für 10 % der Anwender frei. Überwache die Absturzrate im Verhältnis zum Grenzwert des Teams von 0,5 % der Sitzungen.
3. Die Rate bleibt unter diesem Grenzwert, gib sie daher am Montag für alle Anwender frei.

Der Grenzwert für die Einführung gehört zum Release-Plan dieses Teams. Er ist kein allgemeiner Schwellenwert für Releases. Der kontrollierte Zugang liefert Feedback, bevor die Funktion alle Anwender erreicht.

Passe die Planung an den Bereitstellungsrhythmus an

Häufige Bereitstellung verändert, wie die Arbeit organisiert wird. Regeln und automatisierte Prüfungen können schnelle Entscheidungen unterstützen, während ein Team weiterhin entscheidet, wer welche Funktion wann erhält.

Release Notes erklären in einfachen Worten, was sich geändert hat, was behoben wurde und welche Probleme bekannt sind. Für die Banking-App: „Du kannst monatliche Kontoauszüge als PDF herunterladen. Kontoauszüge, die älter als 24 Monate sind, sind noch nicht verfügbar.“ Gib dem Service Desk diese Informationen, bevor Anwender danach fragen.

Sammle nach dem Release Anwenderfeedback, Incidents und Leistungsdaten. Führe die Erkenntnisse der kontinuierlichen Verbesserung zu. Das Drücken einer Deployment-Schaltfläche erledigt diese Arbeit an Bereitschaft, Zugang, Kommunikation und Überprüfung nicht.

Deployment Management überführt neue oder geänderte Komponenten in Produktivumgebungen und kann sie zum Testen in andere Umgebungen überführen. Zu den Komponenten gehören Hardware, Software, Dokumente und Prozesse. Die Practice kontrolliert, was das jeweilige Ziel erreicht, und prüft, ob es dort funktioniert.

Kenne das Ziel der Komponente

Ein bestandener Test in der Staging-Umgebung liefert einen Beleg für die Überführung in die Produktivumgebung. Nach der Überführung prüfen kurze Funktionstests und Monitoring das tatsächliche Ergebnis in der Produktivumgebung. Aktualisiere Konfigurationsdatensätze, damit sie die installierte Version und geänderte Beziehungen zeigen.

Wähle einen Ansatz, der zum Service passt

Schrittweises Deployment überführt Komponenten jeweils in einen Teil der Produktivumgebung. Es begrenzt die anfänglichen Auswirkungen und liefert Feedback vor der nächsten Welle. Ein Team, das 2.000 Laptops aktualisiert, wählt vier Wellen zu je 500 und beginnt mit IT-Mitarbeitenden, die Probleme klar melden können.

Das Team pausiert, wenn deploymentbedingte Incidents mehr als 2 % der Laptops einer Welle betreffen. In der ersten Welle betreffen Incidents 25 verschiedene Laptops:

Fünf Prozent liegen über dem Grenzwert des Teams. Deshalb pausiert es, untersucht und behebt die Ursache und testet vor Welle 2 erneut. Der Nenner ist die überführte Welle, nicht alle 2.000 Laptops. Zähle betroffene Geräte, da sich mehrere Incident-Tickets auf dasselbe Gerät beziehen können.

Big-Bang-Deployment überführt Komponenten gleichzeitig an alle Ziele. Es eignet sich für eine klare Umstellung, wenn alte und neue Versionen nicht nebeneinander bestehen können. Beispielsweise erhalten alle 120 Filialen in derselben Nacht neue Kassensoftware, weil beide Versionen das zentrale System nicht gemeinsam nutzen können. Ein Fehlschlag könnte jede Filiale betreffen, teste deshalb gründlich und übe die Wiederherstellung.

Pull-Deployment stellt freigegebene Software in einem kontrollierten Repository bereit, damit Anwender sie zu einem selbst gewählten Zeitpunkt installieren können. Eine Organisation kann eine Aktualisierung für Videokonferenzen in ihrem Softwareportal veröffentlichen und eine Frist festlegen, bevor die alte Version nicht mehr funktioniert.

Continuous Delivery integriert, testet und überführt Komponenten, sobald sie benötigt werden, und unterstützt häufiges Feedback. Auch die automatisierte Überführung benötigt kontrollierte Quellen, Autorisierung, Validierung und aktuelle Datensätze.

Kontrolliere Quelle und Wiederherstellung

Bewahre Komponenten, die für das Deployment bereit sind, an sicheren, kontrollierten Orten auf, etwa in einer maßgeblichen Bibliothek oder einem Artefakt-Repository. Teams sollten stets die autorisierte, getestete Version beziehen, statt sich auf eine ungeprüfte lokale Kopie zu verlassen.

Führe das Deployment im Rahmen eines autorisierten Change durch. Halte einen Wiederherstellungsplan bereit, bevor du Komponenten überführst. Prüfe das Ergebnis sofort und handle, wenn Prüfungen fehlschlagen. Eine installierte Version kann inaktiv bleiben, bis Release Management ihre Funktion für Anwender verfügbar macht; ein abgeschlossenes Deployment belegt nicht, dass das Release erfolgt ist.

Eine Bereitstellung nutzt mehrere Practices, weil jede ein anderes Problem löst. Ihre Koordination verhindert eine Lücke zwischen einer autorisierten technischen Aufgabe und einer Funktion, die Menschen erfolgreich nutzen können.

Stelle die Frage, die jede Practice beantwortet

Diese Aufgaben kann dasselbe Team übernehmen. Sie benötigen dennoch eigene Entscheidungen und Datensätze. Ein agiles Team kann Prüfungen durch Fachkolleginnen und Fachkollegen, automatisierte Prüfungen und dokumentierte Entscheidungen kombinieren, ohne jede Bereitstellung in eine Besprechung zu bringen.

Verfolge eine Portalfunktion durch die Bereitstellung

Ein HR-Portal soll es Beschäftigten ermöglichen, Ausgabenbelege hochzuladen. Der Änderungsantrag beschreibt den Nutzen, betroffene CIs, Implementierung, Tests und Wiederherstellung. Nach dem Risikomodell der Organisation ergeben Auswirkung 3 und Wahrscheinlichkeit 2 einen Wert von 6. Der Change Manager autorisiert nach einer Prüfung auf Konflikte am Portal einen normalen Change für Mittwoch von 20:00 bis 22:00 Uhr.

Das Team testet Version 2.8 in der Staging-Umgebung und überführt sie dann während dieses Zeitfensters auf die Produktivserver. Es lässt die Upload-Funktion ausgeschaltet. Die Konfigurationsdatensätze zeigen nun Version 2.8. Für zusätzlich beschaffte Abonnements oder Geräte sind ebenfalls Asset-Datensätze und eine Zuständigkeit für den Lebenszyklus erforderlich.

Am Freitag macht Release Management die Funktion für 150 Beschäftigte der Finanzabteilung verfügbar. Der Service Desk erhält vorher Release Notes und eine kurze Anleitung. Eine Woche später wird der Zugang auf alle 2.400 Beschäftigten erweitert. Installation und Verfügbarkeit für Anwender haben unterschiedliche Daten. Die Frage, ob die Funktion „live“ ist, braucht daher eine genaue Antwort darauf, welches Ereignis gemeint ist.

Überprüfe Ergebnisse und gib Erkenntnisse weiter

In der ersten Woche fragen drei Personen, wie die Upload-Funktion genutzt wird. Der Service funktioniert normal: Dies sind Beratungsanfragen, keine Incidents. Die Überprüfung bestätigt, dass Belege wie beabsichtigt hochgeladen werden können, und findet keine Unterbrechung oder Beeinträchtigung. Der Change kann als erfolgreich abgeschlossen werden; als Verbesserungsidee wird festgehalten, einen Hinweis direkt in der Anwendung zu ergänzen.

Ein Release kann mehrere Deployments erfordern, etwa Wellen an unterschiedliche Ziele. Ein Deployment kann mehrere Funktionen enthalten, die mithilfe von Feature Flags zu unterschiedlichen Zeiten freigegeben werden. Zwischen einem Change, einem Deployment und einem Release ist keine Eins-zu-eins-Beziehung vorgeschrieben.

Verbinde die Arbeit mit der Wertschöpfung

In ITIL 4 tragen diese Practices insbesondere zu den Aktivitäten Design und Überführung, Beschaffen/Erstellen sowie Bereitstellen und Unterstützen bei. ITIL (Version 5) beschreibt acht Aktivitäten des Produkt- und Servicelebenszyklus: Entdecken, Entwerfen, Beschaffen, Erstellen, Überführen, Betreiben, Bereitstellen und Unterstützen. Erstellen und Überführen sind zentral für die Vorbereitung und Einführung geänderter Komponenten. Für die Bereitstellung wird weiterhin ein Beleg benötigt, dass das beabsichtigte Serviceergebnis die Anwender erreicht hat.

Informationssicherheitsmanagement schützt die Informationen, die eine Organisation für ihre Arbeit benötigt, indem es Risiken ermittelt und managt. Es gilt für die Menschen, Verfahren, Lieferanten und Technologien, die mit diesen Informationen umgehen. Das Sicherheitsteam koordiniert die Facharbeit, aber alle haben eine Aufgabe.

Erkenne, was geschützt werden muss

Die ersten drei werden oft als CIA bezeichnet. Ein Service kann Vertraulichkeit schützen und dennoch bei der Verfügbarkeit versagen, wenn Anwender ihn nicht erreichen können. Authentifizierung prüft die Identität einer Person; sie legt für sich genommen nicht fest, worauf diese zugreifen darf. Nichtabstreitbarkeit betrifft den Nachweis einer Handlung über den Anmeldevorgang hinaus.

Wäge Prävention, Erkennung und Korrektur ab

Prävention verringert die Wahrscheinlichkeit von Incidents. Beispiele sind das Einspielen von Patches, Zugriffskontrollen, Firewalls und Sensibilisierungsschulungen. Erkennung findet Incidents, die dennoch eintreten, mithilfe von Monitoring, Warnmeldungen und Protokollprüfungen. Korrektur begrenzt Schäden und stellt den Normalbetrieb durch Isolierung, Wiederherstellung und Korrekturen wieder her.

Bei Ransomware berücksichtigt ein ausgewogener Ansatz alle diese Phasen:

1. Spiele Patches zeitnah ein, filtere schädliche E-Mails, verlange eine Mehrfaktor-Anmeldung und gib Konten nur die benötigten Zugriffsrechte.
2. Löse eine Warnung aus, wenn Software unerwartet beginnt, viele Dateien zu verschlüsseln.
3. Isoliere infizierte Computer, stelle Daten aus Offline-Sicherungen wieder her und finde und schließe den Angriffsweg.

Sicherungen unterstützen die Wiederherstellung; sie ersetzen keine Maßnahmen, die Angriffe verhindern oder früh erkennen. Wähle Maßnahmen angemessen zum Wert der Informationen, zu Bedrohungen und zu Schwachstellen. Maßnahmen, die die normale Arbeit unnötig erschweren, können inoffizielle Workarounds begünstigen.

Verankere Informationssicherheit in alltäglichen Practices

Eine Sicherheitsrichtlinie, definierte Rollen und regelmäßige Schulungen geben Orientierung für das tägliche Verhalten. Entziehe ausscheidenden Beschäftigten am letzten Arbeitstag ihre Zugriffsrechte. ISO/IEC 27001 legt Anforderungen an ein Informationssicherheitsmanagementsystem fest; Organisationen können eine entsprechende Zertifizierung anstreben.

Konfigurationsinformationen helfen, betroffene Systeme zu finden: Eine verwundbare Bibliothek auf 37 von 400 Servern zeigt, wo der Patch eingespielt werden muss. Routine-Patches nutzen Standard- oder normale Change-Wege. Eine aktive Bedrohung, die sofortiges Handeln erfordert, nutzt die Notfallbewertung und -autorisierung. Das Asset-Management sichert Daten vor der Entsorgung, während das Lieferantenmanagement Sicherheitsanforderungen festlegt und den Zugriff von Lieferanten kontrolliert.

Die Arbeit eines Lieferanten wird Teil des Services, den Kunden erleben. Lieferantenmanagement managt Lieferanten, Beziehungen, Vereinbarungen und Leistung, damit hochwertige Produkte und Services reibungslos zusammenwirken. Lieferanten können externe Unternehmen oder interne Abteilungen sein.

Wähle, wie die Arbeit beschafft wird

Diese Strategien beschreiben verschiedene Aspekte der Beschaffung: Eine Organisation kann Aufgaben an einen einzelnen Partner oder an mehrere Lieferanten auslagern. Wähle anhand von Organisationskultur, knappen Fähigkeiten, Fachwissen, Gesamtkosten, externen Beschränkungen und Vorhersehbarkeit der Nachfrage. Der günstigste Angebotspreis kann Koordinationsaufwand oder schwache Servicequalität verdecken.

Mache Erwartungen messbar

Sorge für Transparenz über Lieferanten, Strategie, Richtlinien und Vertragsinformationen. Vereinbare Serviceziele, Reaktionszeiten, Sicherheits- und Datenanforderungen, Berichterstattung, Preise und Ausgleichsleistungen wie Servicegutschriften. Nimm Regelungen zur Streitbeilegung und zum Ausstieg auf, insbesondere zur Rückgabe von Daten.

Verträge sind der Anfang eines laufenden Managements. Verfolge die Leistung, überprüfe Beziehungen und plane Verlängerungen und Ausstiege. Ein strategischer Cloud-Lieferant benötigt gemeinsame Planung und regelmäßige Überprüfungen; ein Kabellieferant kann normalerweise über übliche Einkaufsbedingungen gesteuert werden.

Prüfe die Leistung anhand der Vereinbarung

Angenommen, ein Hosting-Vertrag verspricht 99,9 % Verfügbarkeit über einen gesamten Monat mit 30 Tagen. Der Messzeitraum umfasst:

Die zulässige Ausfallzeit beträgt 0,1 % dieses Zeitraums oder 43,2 Minuten. Die tatsächliche Ausfallzeit beträgt 95 Minuten. Die Verfügbarkeit beträgt:

Das Ziel wurde verfehlt. Wende die im Vertrag festgelegte Servicegutschrift an und vereinbare bei der Lieferantenüberprüfung einen Verbesserungsplan. Ein klein erscheinender Unterschied zwischen Prozentangaben kann dennoch eine erheblich längere Ausfallzeit bedeuten. Nutze bei der Leistungsbewertung den vereinbarten Messzeitraum und die Vertragsregeln.

Behalte die Verantwortung und manage Abhängigkeit

Die Organisation bleibt gegenüber ihren eigenen Kunden rechenschaftspflichtig, auch wenn ein Lieferant einen Teil des Services erbringt. Eine Lieferantengutschrift erfüllt eine Vereinbarung; sie stellt die unterbrochene Arbeit eines Kunden nicht wieder her. Teams benötigen außerdem eine koordinierte Reaktion und Verbesserungsmaßnahmen.

Gute Beziehungen unterstützen ehrliche Berichterstattung und gemeinsame Ergebnisse. Manage die Anbieterbindung, also die Schwierigkeit, sich von einem Lieferanten zu lösen, mithilfe übertragbarer Daten und eines getesteten Ausstiegsplans. Mache bei mehreren Lieferanten Verantwortlichkeiten und Übergaben deutlich, damit ein Fehler über den gesamten Service hinweg behoben statt zwischen Verträgen weitergereicht wird.

Serviceanforderungen ändern sich, wenn sich Anwender, Technologie und Organisationen ändern. Kontinuierliche Verbesserung richtet Services und Practices an diesen Anforderungen aus, indem Produkte, Services, Practices und deren Management laufend verbessert werden. Ein klareres Formular kann für ein Team genauso wichtig sein wie eine neue Plattform für die Organisation.

Gib alltäglichen Ideen einen Weg zur Umsetzung

Alle sind für Verbesserungen verantwortlich. Ein speziell zuständiges Team kann die Arbeit koordinieren, Menschen anleiten und Ergebnisse verfolgen. Führungskräfte stellen Zeit und Budget bereit. Die Mitarbeitenden, die die Arbeit ausführen, erkennen Schwierigkeiten und testen bessere Wege, damit umzugehen.

Zu den Verbesserungsaktivitäten gehören, Möglichkeiten zu finden, zu erfassen, zu bewerten und zu priorisieren, Wirtschaftlichkeitsbetrachtungen zu erstellen, Maßnahmen zu planen und durchzuführen sowie Ergebnisse zu bewerten. Koordination hilft Teams, konkurrierende Vorhaben oder Changes zu vermeiden, die ein Problem an eine andere Stelle verlagern.

Ideen können aus Entwicklungen bei Incidents und Problemen, Kundenfeedback, Zufriedenheitsumfragen, Vorschlägen von Mitarbeitenden, Audits, neuer Technologie, Lieferantenüberprüfungen sowie Überprüfungen von Changes oder Releases stammen. Ein Supportteam, das nach Releases wiederholt Verwirrung bemerkt, hat einen nützlichen Hinweis auf Verbesserungsmöglichkeiten, auch wenn kein größerer Ausfall aufgetreten ist.

Führe ein Register für kontinuierliche Verbesserung

Ein Register für kontinuierliche Verbesserung (CIR) ist ein strukturiertes Dokument oder eine Datenbank, die Ideen von ihrer Identifizierung bis zur abschließenden Maßnahme verfolgt. Erfasse Idee, Quelle, erwarteten Nutzen, geschätzten Aufwand, Priorität, Verantwortlichen und Status. Ein Verantwortlicher sorgt dafür, dass jemand für die nächste Entscheidung zu einer nützlichen Idee zuständig ist.

Eine Organisation kann Register auf Team- und Organisationsebene führen. Entscheidend ist, Ideen durch Bewertung und Maßnahmen zu steuern. Eine lange Liste ohne Verantwortliche oder Statusaktualisierungen hilft wenig bei der Entscheidung, was als Nächstes geschieht.

Vergleiche Nutzen und Aufwand

Ein Team bewertet Nutzen und Aufwand von 1 bis 10 und nutzt den Nutzen pro Aufwandseinheit als eine Hilfe zur Priorisierung:

Nach dieser Messgröße beginnst du mit C, dann folgt A, dann B. Der höchste Gesamtnutzen ist nicht dasselbe wie der höchste Nutzen pro Aufwandseinheit. Belasse B im Register, damit sein Wert und Ressourcenbedarf erneut betrachtet werden können. Ein Verhältnis hilft beim Vergleich von Arbeiten; bei der Priorisierung müssen weiterhin Ziele und Beschränkungen der Organisation berücksichtigt werden.

Verbinde Verbesserung mit dem Service-System

ITIL 4 verortet kontinuierliche Verbesserung im Service-Wertsystem, in der Aktivität „Verbessern“ der Wertschöpfungskette und in den Management Practices. ITIL (Version 5) behält sie im ITIL-Wertsystem und als Practice bei.

Verbesserung setzt „Dort beginnen, wo man steht“, „Wertorientierung“ und „Iterative Weiterentwicklung mit Feedback“ im Arbeitsalltag um. Beginne mit Belegen für das aktuelle Problem, wähle eine Maßnahme mit einem nützlichen Ergebnis und nutze Feedback, um über die nächste Maßnahme zu entscheiden. Kleine, häufige Schritte der Menschen, die die Arbeit ausführen, gehören ebenso dazu wie größere Initiativen.

Ein Werkzeug zu kaufen oder ein Verfahren neu zu schreiben, ist eine Maßnahme. Um eine Verbesserung festzustellen, verbinde diese Maßnahme mit einem benötigten Ergebnis und miss, was sich verändert hat. Das Modell zur kontinuierlichen Verbesserung bietet sieben Schritte für diese Arbeit in jedem Umfang.

Lege die Richtung fest und verstehe den Ausgangspunkt

1. Was ist die Vision? Verbinde die Arbeit mit den Zielen der Organisation und erkläre den Nutzen, den Stakeholder benötigen.
2. Wo stehen wir jetzt? Bewerte den Ist-Zustand objektiv und erstelle eine Baseline für den Vergleich.
3. Wo wollen wir hin? Vergleiche Ist- und Soll-Zustand und lege konkrete, messbare und zeitlich begrenzte Ziele fest.

Eine Vision wie „Anwender können schnell zur Arbeit zurückkehren“ gibt die Richtung vor. Ein Ziel wie „Innerhalb von sechs Monaten 70 % Erstlösungsquote erreichen“ macht einen Teil dieser Richtung messbar. „Schnellerer Support“ allein nennt weder ein bestimmtes Ergebnis noch eine Frist.

Eine Baseline erfasst den Ausgangszustand. Nutze eine klare Messdefinition, damit sich das spätere Ergebnis aussagekräftig vergleichen lässt. Werden in den beiden Zeiträumen unterschiedliche Arten von Kontakten gezählt, kann eine scheinbare Veränderung schwer zu deuten sein.

Plane, handle, prüfe und sichere das Ergebnis

4. Wie kommen wir dorthin? Wähle einen Plan und nutze Iterationen, wenn der beste Weg unklar ist.
5. Handeln. Führe den Plan aus und achte dabei auf Risiken und Nebenwirkungen.
6. Haben wir das Ziel erreicht? Miss erneut und vergleiche das Ergebnis sowohl mit der Baseline als auch mit dem Ziel. Passe bei Bedarf frühere Schritte an.
7. Wie halten wir die Dynamik aufrecht? Teile Ergebnisse, verankere die bessere Arbeitsweise und setze die Verbesserung fort.

Diese Fragen unterstützen einen Kreislauf. Man muss nicht warten, bis ein großes Projekt abgeschlossen ist, um aus Feedback zu lernen. Eine erfolglose Iteration kann zeigen, was als Nächstes zu ändern ist.

Bearbeite eine Verbesserung am Service Desk

Ein Service Desk löst 696 von 1.200 monatlichen Kontakten beim ersten Kontakt. Seine Baseline beträgt:

Das Team setzt ein Ziel von 70 % innerhalb von sechs Monaten. Es plant bessere Wissensartikel und Fernzugriffswerkzeuge und führt sie dann ein. Nach drei Monaten werden 736 von 1.150 Kontakten beim ersten Kontakt gelöst:

Vergleiche die Quoten, weil sich die Gesamtzahl der Kontakte geändert hat. Vierundsechzig Prozent liegen über der Baseline, aber unter dem Ziel. Kehre zur Planung zurück, untersuche Kontaktarten, die noch weitergeleitet werden, und ergänze gezielte Schulungen. Es gibt Fortschritte, aber das Team kann nicht berichten, dass das Ziel erreicht wurde.

Nach einem nützlichen Ergebnis halte die Zuständigkeit für Artikel aufrecht, schule neue Mitarbeitende und teile Belege für das Ergebnis. Das hilft dem Service, Rückschritte zu vermeiden, wenn das ursprüngliche Verbesserungsteam andere Aufgaben übernimmt.

Erkenne die Formulierung in Version 5

ITIL (Version 5) behält sieben Schritte bei. Schritt 6 fragt „Kommen wir dem Ziel näher?“ und Schritt 7 „Wie halten wir die Verbesserungen relevant?“. Die Formulierung betont laufende Prüfungen des Fortschritts und der anhaltenden Relevanz. Baseline, Ziel, Maßnahme und Feedback bleiben für die Anwendung des Modells wesentlich.

Eine nützliche Messgröße zeigt, ob der Service etwas erreicht, das Menschen benötigen. Wer nur Aktivitäten zählt, kann ein ausgelastetes Team erfolgreich erscheinen lassen, während seine Anwender unzufrieden bleiben. Wähle Messgrößen, die die Arbeit mit beabsichtigten Ergebnissen verbinden.

Verbinde Erfolgsbedingungen mit Indikatoren

Ein kritischer Erfolgsfaktor (CSF) ist eine Bedingung, die erfüllt sein muss, um das beabsichtigte Ergebnis zu erreichen. Eine Leistungskennzahl (KPI) misst, ob ein CSF erfüllt wird. Für den CSF „Anwender erhalten schnell eine Lösung für ihre Probleme“ sind mögliche KPIs die Erstlösungsquote und die durchschnittliche Lösungszeit eines Incident.

Wäge Indikatoren gegeneinander ab, damit ein einzelnes Ziel kein schädliches Verhalten belohnt. Werden Mitarbeitende nur anhand der Lösungszeit beurteilt, lässt ein zu frühes Schließen von Tickets die Zahlen besser aussehen. Kombiniere diese Messgröße mit der Wiedereröffnungsquote und Anwenderfeedback, um zu prüfen, ob die Probleme tatsächlich gelöst wurden.

Wenn technische Berichte grün sind, Anwender aber ein schlechtes Erlebnis haben, wird diese Diskrepanz manchmal Wassermeloneneffekt genannt. Messgrößen für Zufriedenheit und Beschwerden helfen aufzudecken, was technische Indikatoren übersehen.

Vergleiche Prozentangaben genau

Ein Anstieg von 58 % auf 64 % beträgt 6 Prozentpunkte. Der relative Anstieg vergleicht diese Differenz mit der Ausgangsquote:

Gib an, welchen Vergleich du meinst. Wer für diese Veränderung eine „Verbesserung um 6 %“ meldet, verwechselt die Differenz in Prozentpunkten mit der relativen Veränderung. Nutze beim Vergleich von Ergebnissen einheitliche Grundgesamtheiten, Messdefinitionen und Zeiträume.

Wenn du Gruppen zusammenfasst, addiere die Anzahlen der Erfolge und die Gesamtzahlen, bevor du die Gesamtquote berechnest. Ein Webkanal löst 90 von 150 Kontakten und ein Telefonkanal 20 von 50. Zusammen lösen sie 110 von 200, also 55 %. Würdest du ihre Quoten von 60 % und 40 % gleich gewichtet mitteln, ergäbe das 50 %, aber die Webgruppe hat dreimal so viele Kontakte.

Wähle eine zur Frage passende Methode

Eine Reifegradskala könnte von 1, anfänglich, bis 5, optimiert, reichen; nutze die für die Bewertung festgelegte Skala. Eine höhere Bewertung einer Practice und ein besseres Kundenergebnis sind unterschiedliche Messgrößen und benötigen jeweils eigene Belege.

Ein normaler Change dauert vom Antrag bis zur Implementierung 6 Tage. Fünf Tage werden mit dem Warten auf eine wöchentliche Genehmigungsbesprechung verbracht. Der Anteil der Wartezeit beträgt:

Lean lenkt die Aufmerksamkeit auf diese Wartezeit. Ein passender Genehmigungsweg durch Fachkolleginnen und Fachkollegen für risikoarme Arbeit kann die Verzögerung verringern und gleichzeitig die Autorisierung erhalten. Eine kurze Implementierungsaufgabe zu beschleunigen, würde den größten Teil der Durchlaufzeit unberührt lassen.

Agilität unterstützt kleine Schritte und häufiges Feedback. DevOps verbindet Entwicklung und Betrieb mit Automatisierung für eine schnelle, sichere Bereitstellung. Beide passen zur iterativen Verbesserung. Wenn eine Verbesserung einen Service, ein Werkzeug oder einen Prozess ändert, führe sie durch Change Enablement und bei Bedarf durch Deployment und Release. Miss ihre Wirkung anhand der Baseline.