Artikelreihe: ITSM im Fokus - Von Big Bangs und Migrationen

ITSM, auf die Plätze, fertig, los! Aber was ist noch mal das Ziel?

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.

Ziele

  • Fokus auf Qualität:
    Anforderungen an Stabilität, Performance sowie Release- und Deployment-Fähigkeiten
  • Fokus auf strategische Ausrichtung:
    Partneranbindungen durch Mandantenlösungen und Schnittstellen zu anderen IT-Systemen
  • Fokus auf wirtschaftliche Faktoren:
    Optimierung der Lizenzkosten, Weiterrechnung der Bereitstellungskosten und Implementierung nutzerspezifischer Abrechnungsmodelle

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.

Bedingung 1: Es sind ausreichend technische Experten über die Laufzeit des Projektes vorhanden

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.

Bedingung 2: Die Dokumentation der Ist-Prozesse im IT-Service Management ist aktuell und vollständig

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.

Bedingung 3: Der Business Case ist seriös gerechnet

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.

Bedingung 4: Die Projektlaufzeit ist realistisch geschätzt

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?

Bedingung 5: Alle Stakeholder wurden einbezogen

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“.

Fazit

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.

Artikel von:
Jürgen Wilmink, Senior Management Consultant, Cassini Consulting AG
Jürgen Wilmink
Senior Management Consultant
Alexander Graf Strachwitz
Alexander Graf Strachwitz
Consultant

Ihre Ansprechpartner für IT-Exzellenz

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.

Jürgen Wilmink, Senior Management Consultant, Cassini Consulting AG

Jürgen Wilmink

Senior Management Consultant

juergen.wilmink@cassini.de
+49 211 - 65 85 41 33
Seite teilen
Newsletter Cassini

Newsletteranmeldung

Sie möchten regelmäßig die neuesten Informationen zum Thema Digitalisierung und digitale Transformation erhalten und über spannende neue Jobangebote informiert werden?
Melden Sie sich kostenlos für unseren Newsletter an.


Ja, ich möchte den regelmäßigen Newsletter von Cassini erhalten. Weitere Informationen finden Sie in unseren Datenschutzbestimmungen.

*Pflichtangaben