1. Um zu vermeiden, dass die Einführung beispielsweise eines neuen Prozesses oder einer ITSM-Plattform bei den späteren Usern auf Akzeptanzprobleme stößt, muss sie ausreichend in das Change-Projekt einbezogen werden. Zu diesem Zweck lässt sich etwa einmal wöchentlich ein „Open Door Day“ durchführen, bei dem Vertreter des Projektteams Rede und Antwort stehen. Es können dort auch Konzepte und deren Umsetzung in Prototypen bzw. Piloten präsentiert werden. Im Falle mehrerer Standorte ist alternativ auch eine virtuelle Durchführung per Webcasts realisierbar.
Eine weitere Möglichkeit des Einbezugs besteht darin, Advisory Groups zu bilden, die dem Projektteam beratend zur Seite stehen und ihm aus Benutzersicht ein wichtiges Feedback geben. Zudem muss auch eine Antwort darauf gefunden werden, wie der oft große Kreis an Stakeholdern kontinuierlich informiert wird. Hierfür bietet es sich an, einen regelmäßig erscheinenden Newsletter zu versenden, in dem Neuigkeiten aus dem Projekt dargestellt werden.
2. Bei der Durchführung von Changes im Softwarebereich entstehen während der Implementierungsphase oftmals zahlreiche spontane und manuelle Änderungen, die sich schwer nachvollziehen lassen und deshalb Störungen verursachen. Zur Vermeidung dieser Probleme ist auf eine klare Schnittstelle zum Release Management zu achten, indem nur die dort abgenommenen Releases in das Change Management übernommen werden sollten. Es sollte auch mindestens eine Testumgebung bestehen, auf der das Release per Change eingespielt wird, bevor es in die Produktivumgebung übertragen wird. Weiterhin ist zu empfehlen, dass Abweichungen vom freigegebenen Change dokumentiert und begründet werden müssen.
3. Aus den Change-Tickets ist nicht ersichtlich, welche Configuration Items (CI) verändert und welche nur für die Durchführung des Changes benötigt werden. Eventuell werden die benötigten gar nicht erst erfasst, so dass es während des Changes zu Beeinträchtigungen kommt. Hilfreich ist es deshalb, die im Change Ticket erfassten CIs in zwei Kategorien zu gliedern. Dafür sollten einerseits die während des Changes veränderten CIs und andererseits die für den Change unmittelbar benötigten bzw. beeinflussten Configuration Items genutzt werden. Diese Trennung erlaubt eine problemfreiere Auswertung und Planung.
4. Fachabteilungen zeigen oft Schwierigkeiten bei der Umsetzung eines Change-Prozesses, zusätzlich erschweren komplexe Change-Masken das Verständnis. Den Fachbereichen sollten deshalb vereinfachte Masken zur Verfügung gestellt werden, die sich auf die tatsächlich notwendigen Pflichtfelder beschränken. Die Möglichkeit einer Nutzung der vollständigen Maske sollte als Option trotzdem bestehen bleiben.
5. Häufig findet im Change Management keine Risikobetrachtung statt, weshalb Change-Typen mit einem bestimmten Risikomerkmal versehen werden. Dies kann in der Weise erfolgen, dass die Benutzer Risiko, Dringlichkeit und Auswirkung auswählen und der Change-Typ automatisch gewählt wird. Ist hier keine eindeutige Zuordnung möglich, können auch mit der Auswahl des Change-Typs bestimmte Werte vorgeben werden. Zumindest ein Default-Wert sollte pro Change-Typ angegeben sein.
6. Es treten eine hohe Anzahl Emergency Changes auf, die zwar teilweise in der Qualitätssicherung als nicht berechtigt identifiziert werden, deren Auswahl lässt sich jedoch nicht unter Kontrolle bringen. Ein Ausweg besteht darin, dass die Erstellung eines Emergency Changes an bestimmte Bedingungen geknüpft wird. Hier empfiehlt sich zum Beispiel die verpflichtende Dokumentation des dem Emergency Change zugrunde liegenden Major Incidents.
7. Im SAP-Bereich kommt es immer häufiger zum Einspielen von Emergency-Fixes, die wiederum zu einer erheblichen Anzahl zusätzlicher Incidents führen. Ein Lösungsweg besteht in der Einführung eines Change-Verfahrens, das im ersten Schritt lediglich auf die Durchführung von Patch- und Release-Updates fokussiert ist. Dadurch kann eine Gewöhnung an formalisierte Prozesse im Change-Bereich erreicht werden.
8. Operative Changes werden zwar dokumentiert, es erfolgt jedoch keine zuverlässige Aktualisierung weiterer relevanter Dokumente. Vermeiden lässt sich dies, indem wiederkehrende Aufgaben während eines Changes als Template verfügbar gemacht werden. Beispiele hierfür sind die Aktualisierung der Configuration Management Database (CMDB) und der Handbücher oder das Deaktivieren und Aktivieren von Datensicherungen. Diese Templates sollten zur allgemeinen Gültigkeit und Vermeidung von Duplikaten zentral verwaltet werden.
9. Im ITSM-Tool sind viele veraltete und doppelte Change-Templates vorhanden, so dass für den Benutzer unklar ist, bei welchen es sich um die aktuelle Version handelt. Dieses Problem lässt sich lösen, indem die Verantwortung für die Template-Pflege des Changes auf bestimmte Teams oder lokale Change Manager übertragen wird. Ausschließlich ihnen obliegt es dann, Templates für die eigene Gruppe zu erstellen und für deren Aktualisierung zu sorgen. Diese Verantwortung zur Pflege muss für jedes Change-Template definiert werden, ansonsten darf keine Freigabe zur Nutzung erfolgen.
