Artikelreihe: ITSM im Fokus - Von Big Bangs und Migrationen
Im dritten Teil unserer Artikel-Serie wurde der Umgang mit alten bzw. existierenden IT-Service Management Prozessen (ITSM) und entsprechenden Tools in IT-Organisationen beleuchtet. Dieser Teil hat zum Ziel, die Herausforderungen zum Projektstart bei der Einführung eines ITSM-Tools genauer unter die Lupe zu nehmen. Der Fokus liegt hierbei insbesondere auf den Annahmen, die vom Projektteam getroffen wurden. An dieser Stelle sei jedoch nochmal hervorgehoben, dass die Einführung eines ITSM-Werkzeugs kein Selbstzweck ist, sondern mit konkreten Zielen der Stakeholder verbunden ist.
Vor dem Projektstart sind bestimmte Annahmen zu treffen, aus denen sich Bedingungen für die erfolgreiche Umsetzung ableiten. Diese haben einen maßgeblichen Anteil am Projekterfolg. Gleichzeitig stellen diese Bedingungen bei Nicht-Erfüllung aber auch potenzielle Fallen dar, die sich auf dem Weg zum Ziel auftun. Es folgt eine Aufzählung prominenter Beispiele für projektrelevante, kritische Einflussfaktoren, die jedoch keinen Anspruch auf Vollständigkeit hat.
Vor Projektstart muss die Verfügbarkeit der technischen Experten seriös geprüft und bestätigt werden. Das Staffing des Projektteams allein aus dem Betriebsteam führt früher oder später zu Interessenskonflikten: Personal und Organisation müssen Aufgaben im Betrieb oder Projekt gegeneinander priorisieren. Streng genommen ist das Projekt nur dann über den Betrieb abzuwickeln, wenn dieser die Ressourcen für Projekte in sich bereits vorhält und geübt in der Projektdurchführung ist. Nicht aber, wenn für ein Projekt betriebliche Verantwortungen zurückgefahren werden müssen. Letzteres ist lediglich bei kurzen Projektlaufzeiten (kürzer als drei Monate) tolerierbar.
Die existierenden Prozesse sind dokumentiert, Rollen und Verantwortungen sind beschrieben und werden „gelebt“. Sind sie es nicht, muss im laufenden Projekt eine „Null-Linie“ definiert werden, die den Start markiert, von dem aus die Neuentwicklungen und Änderungen implementiert werden.
Wie im dritten Teil der ITSM-Artikelreihe erläutert, hat die Bewertung der Ist-Prozesse einen großen Anteil am Business Case. Durch die Optimierung dieser, können Einsparungen in den Prozesskosten ausgewiesen werden. Daneben müssen die Kosten für Betrieb, Lizenzen, Wartung und Aufwände für spätere Anpassungen des Tools mit betrachtet werden.
Sollten im Unternehmen in der Vergangenheit Projekte mit vergleichbarem Umfang bereits realisiert worden sein, muss die Dauer dieser Vorhaben in die Laufzeitberechnung des neuen Projektes mit einbezogen werden. Wenn eine Organisation, beispielsweise für ein vergleichbares Projekt, ein Jahr benötigt hat, warum sollte es nun in sechs Monaten gelingen? Sind grundlegende Änderungen, u. a. in der Organisation, Projekt- oder Programmmanagementmethode zwischenzeitlich erfolgt, die eine Beschleunigung realistisch erscheinen lassen?
Ist das Wissen um die konkreten und aktuellen Anforderungen der Benutzer eines ITSM-Werkzeugs wirklich bekannt? Oder existiert lediglich eine Vermutung darüber, „was die Benutzer für ihre Arbeit benötigen“? Gegebenenfalls haben sich in den zurückliegenden Jahren die Benutzer die Mängel des bestehenden ITSM-Werkzeugs optimiert (Stichwort Schatten-IT) und so ihre realen Anforderungen „versteckt“.
Zusammenfassend kann abgeleitet werden, dass in der Vorprojektphase ein umfassender und belastbarer Proof of Concept (POC) durchgeführt werden muss. Im POC sollten die Ziele, Annahmen, zu erfüllende Bedingungen und die Ist-Situation umfassend bewertet werden. Nur auf Grundlage dieser Synthese sollte der Projektstart erfolgen.
Wir sind vom Wettbewerbsvorsprung durch adaptive IT überzeugt. Und wir erläutern Ihnen gern, wie sich Ihr Unternehmen hierfür am besten positioniert. Nutzen Sie unser Angebot und sprechen Sie mit einem Cassini-Experten darüber, welche Rolle Ihre IT-Organisation einnehmen könnte.
