Beherzige diesen einen Tipp bei der ITSM-Tool-Auswahl
Die Auswahl eines Tools ist aufwendig und kostet viel Zeit und Geld. Und trotzdem bekommen viele Unternehmen ein (ITSM)-Tool, welches nicht das abbilden kann, wozu es gekauft wurde. Wie Du das verhindern kannst, erkläre ich Dir an einem ganz aktuellen Beispiel.
Letzte Woche war ich bei einem Kunden, mit dem ich schon einige Zeit beim Aufbau des Servicekatalogs zusammenarbeite. Wir haben bisher schon sehr viel geschafft und es ging überraschend schnell voran. Bis auf einen Punkt – die Beschaffung eines ITSM-Tools.
Aus Gründen, die zu 100% der Hersteller des ausgewählten Tools zu verantworten hat, hat sich der Beschaffungsvorgang um mindestens ein dreiviertel Jahr verzögert. Zwischendurch stand es sogar zur Debatte, einen ganz anderen Hersteller zu wählen – so schwierig gestaltete sich der Beschaffungsvorgang.
Letztlich sind der Kunde und der Hersteller doch zueinander gekommen. Ich war diese Woche vor Ort, um die Umsetzung der Services, Service-Requests, des Katalogs und Portals zusammen mit dem Implementierungsdienstleister zu definieren.
In diesem Termin hat sich gezeigt, was im Toolauswahlprozess wirklich wichtig ist. Klassisch ist es doch so, dass wir sehr viel Aufwand, Zeit und Geld in die Erstellung und Auswertung des Anforderungskataloges stecken. Danach gibt es noch Demos, einen weiteren Anforderungskatalog und dann, wenn noch Zeit ist, einen Proof-of-Concept (POC).
Die Unterstützung bei der Toolauswahl durch einen externen Berater kostet locker zwischen 15.000 und 30.000 €.
Nehme ich Zeit und Geld zusammen, dann sage ich Dir: Das ist das falsche Ende an dem Du investierst! Nachdem, was ich diese Woche wieder erlebt habe, darfst Du viel mehr in das Ende des Auswahlprozesses investieren – den Proof-of-Concept. Denn dort entscheidet es sich, wie das Tool zu Dir und Deiner Art und Weise, Services zu erbringen, passt.
Klingt etwas esoterisch – ich zeig es Dir gleich an Beispielen. Zuvor: Ich gehe momentan sogar soweit, dass ich einen Teil des eigentlichen Implementierungsprojektes schon vor dem Kauf der Lizenzen durchziehen würde. Warum und was genau, gleich – vorher die Beispiele, warum das so wichtig ist.
Zu spät!
Wir saßen zusammen und haben darüber gesprochen, was wir uns im Bereich Servicekatalog und Request Fulfillment vorstellen. Und da fing es an: geht nicht, geht nicht, da müssen wir einen Workaround nutzen und so weiter. Ein paar Beispiele:
- dem Nutzer werden im Serviceportal alle Service-Requests angezeigt – egal ob er den Services gebucht hat oder nicht – das heißt, dass jeder Nutzer ganz viele Service-Requests sieht, mit denen er gar nichts anfangen kann – im schlimmsten Fall nutzt er den falschen Service-Requests und alles läuft schief – mit dem sinnlosen Aufwand auf IT- und Nutzerseite
- die Anzeige der Services, die der Nutzer gebucht hat, zusammen mit den zugeordneten Service-Requests ist nicht möglich
- es gibt keine Verbindung zwischen dem Service in der CMDB und dem Objekt im Portal – dementsprechend gibt es auch keinen Bestellprozess, der aufzeichnet, wer den Service bestellt und kündigt
- es gibt keine Verbindung zwischen Service und Service-Request
- es gibt keine SLAs nur einzelne Service-Level-Targets
und noch einiges mehr.
Das hat zwei Konsequenzen:
Einige Punkte lassen sich definitiv nicht umsetzen, so dass im einfachen Fall umgedacht werden muss und in einigen Fällen es gar nicht realisierbar ist, was zu Einschränkungen für die Servicequalität und die Steuerbarkeit der Serviceerbringung führt
Die zweite Konsequenz ist, dass die Implementierung teurer wird. Einige Punkte lassen sich durch Anpassung der Lösung halbwegs oder auch ganz erreichen. Es kostet einfach nur mehr Geld. Das Schlimmste ist: Der Kunde kann nicht mehr zurück – er hat einen Vertrag für fünf Jahre unterschrieben – also zahlt er die Anpassungen.
Ich möchte weder den Hersteller noch den Kunden hier an den Pranger stellen. Ich möchte Dir deutlich zeigen, wie wichtig die Phase der Demonstrationen und vor allem des Proof-of-Concept für Deine Toolauswahl sind. Jeden Euro, den Du hier investierst, ist gut investiertes Geld.
Drum prüfet, wer sich …
Bevor Du die Lizenzen kaufst und Dich für mehrere Jahre bindest, hast Du immer noch die Wahl, für welchen Hersteller Du Dich entscheidest. Nach der Vertragsunterschrift wird der Wechsel nur teuer.
Genau um das zu vermeiden, würde ich den Hersteller, dem ich es aufgrund des Auswahlverfahrens am ehesten zutraue, sogar schon einen Teil Leistung bezahlen, der eigentlich ins Implementierungsprojekt gehört. Nur um die Gewissheit zu bekommen, dass das, was versprochen wurde, auch tatsächlich funktioniert.
Denn nur, wenn Du Dich mit dem Hersteller oder Implementierer ganz konkret über die Umsetzung am lebenden System unterhältst und arbeitest, kommst Du an die Punkte, die kritisch sind.
Wenn dann alles passt, hast Du das Geld nicht in den Sand gesetzt – einen Teil der Implementierung ist dann schon erledigt! Sollte es Gründe geben, den Hersteller noch mal zu wechseln, dann hast Du viel mehr Geld gespart als investiert. Davon bin ich überzeugt.
Fokus bewahren
Natürlich kannst Du das nicht für alles machen, was Du im ITSM-Tool umsetzen möchtest. Das sollst Du auch gar nicht.
Such Dir die Knackpunkte raus – was ist für Deine Serviceerbringung kritisch? Oder anders gefragt: Was sind die Punkte, die die Tooleinführung potentiell zum Scheitern bringen. Das sind in der Regel zwei oder drei Punkte. Das sind selten Incident, Problem oder Change. Das ist vielleicht die Usability des Portals, die Fähigkeit Multi-Provider-Management oder Financial-Management zu betreiben.
Was auch immer dies bei Dir ist – geh vor dem Kauf der Lizenzen in die Diskussion und Konzeption der konkreten Umsetzung. Lass Dir einen Prototypen dafür bauen. Nur dann siehst Du, was geht und was nicht geht.
Die Zeit und das Geld sollten ja da sein, weil Du die Phasen vor dem Proof-of-Concept auf das sinnvolle zusammen gedampft hast.
Meine ganz klare Empfehlung an Dich: Verschaffe Dir einen Überblick zu den Anforderungen in Deiner Organisation. Nutze den ITSM-Tool-Vergleich auf servicemanagement.tools, um Dir eine Liste von maximal vier Herstellern zusammenzustellen. Diesen schickst Du verschiedene Szenarien mit der Bitte, diese in einem Termin so zu zeigen, wie sie im Tool funktionieren. Binde dazu so viel wie sinnvoll zukünftige Nutzer ein. Danach hast Du einen Favoriten und mit dem gehst Du in den Proof-of-Concept. Scheitert dem kommt der zweite Sieger oder erste Verlierer der Vorauswahl zum Zug.
Damit vermeidest Du böse Überraschungen bei der Implementierung – nicht alle, aber die, bei den für Dein Unternehmen wichtigen Punkten!
PS: Alles was ich hier sage, trifft auch auf Software zu, die eine große Wirkung in Deinem Unternehmen haben soll.
