Das Changemanagement kann ein recht steifer und langwieriger Vorgang sein. Möchten Sie Ihre Change-Implementierungen agiler gestalten? Es gibt mehrere Wege, dieses Ziel zu erreichen. In diesem Artikel wird darauf eingegangen, wie Sie einen einzelnen Change auf eine agile Art und Weise implementieren, und darauf, wie sich alle Changes Ihrer Abteilung agiler gestalten lassen.
(Bild: topdesk)
Wir setzen unsere Entdeckungstour in der Welt des agilen Servicemanagements fort. Wir möchten Wege finden, wie Sie die Abläufe Ihres Servicedesks beschleunigen und weniger steif gestalten können. Bisher haben wir uns angeschaut, wie ITIL und eine agile Denkweise zusammenarbeiten können, haben uns intensiv mit dem agilen Incidentmanagement befasst und zu diesem Thema sogar ein ganzes E-Book veröffentlicht.
Kürzlich haben wir das Changemanagement aus einer agilen Perspektive betrachtet. Beleuchten wir dieses Thema weiter. Wie funktioniert es in der Praxis?
Wie Sie einen einzelnen Change agiler implementieren können
Starten wir damit, wie Sie die Implementierung eines einzelnen Changes agiler gestalten können.
Beschreiben Sie nur Ihr Ziel und Ihre Voraussetzungen
Idealerweise füllen Sie beim ersten Einreichen Ihrer Anfrage nicht das komplette Change-Requestformular aus. Ihre Beschreibung enthält nur die grundlegenden Informationen. Die wichtigsten zu nennenden Punkte sind Ihr Ziel und Ihre Voraussetzungen.
Ein Beispiel: Sie erhalten mehrere Incidents wegen einem langsamen Mailserver. Am liebsten würden Sie nicht mehrere Incidents wegen dem gleichen Problem bekommen. Es wäre Ihnen lieber, dass Ihre Melder sehen können, ob ein Problem bereits gemeldet wurde. Ihr Ziel ist: Ihren Meldern zeigen, welche Incidents bereits eingereicht wurden. Sie möchten aber ebenfalls sicherstellen, dass Ihre Melder nicht die privaten Informationen anderer Benutzer einsehen können. Dies wäre Teil Ihrer Voraussetzungen.
Neben dem Ziel und den Voraussetzungen gibt es kaum notwendige Informationen, um einen Change einzuleiten.
Prüfen Sie regelmässig, ob Ihr Change noch mit dem zuvor gesetzten Ziel und den Voraussetzungen in Einklang ist
Implementieren Sie Changes noch immer nach der traditionellen Wasserfall-Methode? Dann besteht immer die Möglichkeit, dass Ihre Lösung nach der Implementierung doch nicht die Erwartungen des Melders erfüllt. Denn die Wasserfall-Methode geht davon aus, dass Sie den erstellten Plan direkt ausführen, ohne dabei Änderungen vorzunehmen. Es gibt keinen Spielraum, sich an neue Situationen anzupassen. Und Ihre Situation kann sich ändern. Sie könnten neue Erkenntnisse über die genauen Bedürfnisse Ihres Melders erlangen oder es könnte neue Technologien auf dem Markt geben, die eine bessere Lösung ermöglichen.
Während Sie also einen Change entwerfen und implementieren, sollten Sie sich regelmässig die folgenden Fragen stellen:
- Tragen unsere aktuellen Handlungen noch zum ursprünglichen Ziel bei?
- Erfüllen wir noch unsere Voraussetzungen?
Ist Ihre Lösung nicht mehr hinreichend? Ein agiler Prozess ermöglicht Ihnen, nebenbei Änderungen vorzunehmen. Vielleicht haben Sie den Punkt, an dem Sie noch einen anderen Weg hätten einschlagen können, schon überschritten. Sollte dies der Fall sein, dürfen Sie keine Angst haben, einen Change zu verwerfen. Etwas zu verwerfen mag schwer fallen, da Sie bereits Zeit und Energie hineingesteckt haben. Ihren Change zu verwerfen ist dennoch besser, als an einer Lösung zu arbeiten, die niemandem weiterhelfen würde.
Beziehen Sie andere Fachleuchte in Ihren Change mit ein
Sobald Sie eine Idee entwickelt haben, wie Sie einen Change implementieren möchten, sollten Sie verschiedene Fachleute einen Blick auf Ihre Pläne werfen lassen. Welche Auswirkungen hätte Ihr Change auf andere Anwendungen und Hardware? Würde der Change zu Sicherheitsrisiken führen? Üblicherweise würde diese Plausibilitätsprüfung von den CAB-Mitgliedern durchgeführt, wenn diese einen Change-Request bewerten. Gemäss der agilen Denkweise ist es jedoch viel besser, Ihr Team eine eigene Lösung finden zu lassen. Wenn Ihr Team jedoch alles selbst erarbeitet, wer führt dann die Plausibilitätsprüfung durch?
Freiheit bringt Verantwortlichkeit mit sich. Gewähren Sie Ihrem Team nicht einfach nur die Freiheit, eine Lösung zu finden, sondern machen Sie es ebenfalls dafür verantwortlich, in Zusammenarbeit mit Fachleuten zu prüfen, ob die Lösung funktionieren würde.
Wie sämtliche Changes agiler gehandhabt werden können
Ihre IT-Abteilung arbeitet selten nur an einem Change. Selbst eine kleine IT-Abteilung mit nur sechs bis acht Leuten wird öfter an zehn bis 20 Changes gleichzeitig arbeiten. Aber das sind zu viele.
Führen Sie so wenige Changes wie möglich gleichzeitig durch
Die Lösung ist ganz einfach: Limitieren Sie die maximal gleichzeitig durchgeführte Anzahl an Changes. Das ist natürlich leichter gesagt als getan. Dennoch lohnt es sich. Sie schlagen zwei Fliegen mit einer Klappe:
- Es wird leichter, die Laufzeit von Changes vorherzusehen. An weniger Changes gleichzeitig zu arbeiten bedeutet, dass Sie mit weniger Variablen arbeiten und somit besser vorhersehen können, wann Sie einen Change abschliessen werden.
- Ihre Servicequalität steigt. Wenn Sie sich mehr auf den Change, an dem Sie momentan arbeiten, konzentrieren können, verringern Sie die Fehleranfälligkeit.
- An Changes zu arbeiten wird Ihrem Team mehr Spass machen. Sie können sich auf Ihre Arbeit konzentrieren und sehen direkt Resultate. Studien haben gezeigt, dass sichtbarer Fortschritt einer der wichtigsten Motivationsfaktoren am Arbeitsplatz ist. Etwas termingerecht zu erledigen fühlt sich viel motivierender an, als andauernd an hundert verschiedenen Dingen zu arbeiten und das Gefühl zu haben, dass nichts fertig wird.
Changes vs. Incidents: treffen Sie eine eindeutige Wahl
Wie schaffen Sie sich Zeit, an Changes zu arbeiten, wenn gleichzeitig ein nie endender Strom an Incidents eingereicht wird? Treffen Sie bewusst eine Entscheidung hinsichtlich der Prioritäten Ihres Teams.
Möchten Sie eine maximale Laufzeit für Changes garantieren? Dann müssen Sie jedem Team einen Zeitrahmen einräumen, in dem dieses an Changes arbeiten kann. Das bedeutet gleichzeitig, dass Sie akzeptieren müssen, dass Incidents manchmal eine längere Bearbeitungszeit haben könnten.
Finden Sie es wichtiger, dass Tickets schnell gelöst werden? In diesem Fall müssen Sie akzeptieren, dass die Implementierung von Changes manchmal etwas länger dauern könnte, und dass sich Ihr Team nicht so schnell mit neuen Changes befassen können wird.
Erfahren Sie mehr über Agile Servicemanagement
Das agile Changemanagement steht noch am Anfang. Haben Sie schon damit experimentiert? Erfahren Sie in unserem E-Book mehr darüber, wie Sie Ihren Servicedesk mit Agile effizienter machen können.
TOPdesk Deutschland Gmbh | 67657 Kaiserlautern | www.topdesk.de
Mehr Informationen finden Sie auch unter TOPdesk auf der topsoft Marktübersicht