0

A fool with a tool is still a fool

„Ein Narr mit einem Werkzeug ist immer noch ein Narr“. Und Werkzeug bedeutet auch Software. Du kennst die Projekte bestimmt: Intranet, Sharepoint, Collaboration, CRM, Projektmanagementsoftware oder eben ITSM Tools – die Integration in die Arbeitsabläufe, die Pflege der Daten und Dokumente oder die gewünschte Transparenz des Vertriebsprozesse bleiben aus, obwohl eine neues Tool eingeführt wurde. Oder vielleicht gerade deswegen? Ich erzähle Dir heute unter anderem über meinen Weg, ein ITSM-Tool auszuwählen.

Wenn Du mich schon länger kennst, weißt Du, dass ich nicht so viel Wert auf ITSM-Tools lege. Ich sollte vielleicht sagen, gelegt habe. Warum, erfährst Du heute.

Zu Beginn möchte ich mit Dir mal näher auf den Titel eingehen. „A fool with a tool is still a fool“.

Wenn Du das mal bei einer Suchmaschine Deiner Wahl googlest, findest Du viele Einträge. Aus völlig unterschiedlichen Branchen. Find ich spannend, dass das nicht nur ein Problem bei uns im ITSM ist.

Eines haben sie gemeinsam: Es dreht sich immer um Software.

Weißt Du eigentlich wie der Spruch auf Deutsch lautet? Ich habe den Spruch oft genutzt, ohne die genaue Übersetzung parat zu haben.

Auf Deutsch lautet er: „Ein Narr mit einem Werkzeug ist immer noch ein Narr“.

Wenn wir jetzt die beiden zusammenbringen, dann wird ein Schuh draus, oder? Wie gefällt Dir folgende Interpretation: Der bloße Einsatz einer Software hat selten etwas grundsätzlich verbessert.

Du kennst die Projekte bestimmt: Intranet, Sharepoint, Collaboration, CRM, Projektmanagementsoftware oder eben ITSM Tools – die Integration in die Arbeitsabläufe, die Pflege der Daten und Dokumente oder die gewünschte Transparenz des Vertriebsprozess bleiben aus, obwohl eine neues Tool eingeführt wurde.

Oder vielleicht gerade deswegen? Was meinst Du?

Falsches Problem

Das hat aus meinem Erleben zwei Gründe:

1. Das Problem liegt wo ganz anders – nicht in der Software – oder
2. Es gibt keinen richtigen Plan wer was wann mit dem Tool anstellen soll

Dir fallen bestimmt noch mehr Gründe ein.

In der vorletzten Folge habe ich mit Dir über die Fähigkeiten des Innovationskatalysators gesprochen. Eine wichtige Fähigkeit dafür ist die Business Analyse.

Ein Business Analyst geht in 5 Schritten vor, um dieses Problem zu vermeide:

1. Situation erforschen
2. Perspektiven der Stakeholder einnehmen
3. Bedarf analysieren
4. Möglichkeiten untersuchen
5. Anforderungen definieren

Aus eigener Erfahrung bin ich überzeugt: Du vermeidest das Laborieren an der falschen Krankheit, wenn Du die Schritte durchläufst.

Dazu jetzt nicht mehr, denn zu Business Analyse gibt es einige Folgen (hier, hier und hier). Möchtest Du Dich vom Business Analyse Virus anstecken lassen, dann geh zum BA CAMP nach Wien. Ich werde sehr wahrscheinlich auch dabei sein.

Lass uns zum zweiten Punkt kommen. Ich denke, dass viele Projekte im ITSM Umfeld genau an diesem Punkt scheitern.

Ohne Plan

Zu oft höre ich folgende Sätze, Fragen oder Forderungen:

• Ist das Tool ITIL complaint?
• Bringt es out-of-the-box Prozesse mit?
• Wie wir das machen, muss uns das Tool vorgeben
• Wie machen das denn andere?
• Wie viele ITIL-Prozesse sind denn zertifiziert?

Klingt für mich, als ob da jemand nicht die Verantwortung übernehmen möchte. Quasi die Abkürzung über das Tool.

Klar, Du hast immer zwei extreme Wege:

1. Du passt Deine Prozesse an die des Tools an
2. Du passt das Tool komplett an Deine Prozesse und Anforderungen an

Bei beiden Wegen kommst Du nicht drum herum, Dir Gedanken über die Verwendung, die Prozesse, Daten und Schnittstellen zu machen. Schon gar nicht bewahrt Dich einer der beiden Wege davor, die Verantwortung und damit verbundenen Rechte und Pflichten für das Service-Management und die Prozesse zu klären.

Die Realität bewegt sich irgendwo dazwischen.

Klicke hier für einen Überblick, der verfügbaren ITSM-Lösungen.

Ein Plan muss her

Ich legen sehr viel Wert darauf, dass der Kunde sich klar wird, was er von einem Tool erwartet. Im Detail meine ich. Für mich gehört folgendes mindestens dazu:

• Welche Prozesse sollen abgebildet werden?
• Wie sehen die abzubildenden Prozesse aus?
• Wie sieht die abzubildende Service-Architektur aus?
• Wie sieht der abzubildende Service-Katalog aus?
• Welche Umsysteme sollen eingebunden werden?
• Welche Dienstleister mit welchen Schnittstellen sollen angebunden werden?
• Soll es nur IT oder gleich Enterprise-Service-Management sein?
• Self Service oder nicht?
• Welcher Grad an Customizing ist gewünscht?
• Wie viel Aufwand willst Du in Implementierung, Customizing und Betrieb stecken?
• Wie sieht es mit dem Thema Automatisierung aus?
• SaaS oder on Premise?
• Und zu diesen Punkten die entsprechenden Anforderungen

So entsteht ein Lastenheft, mit dem Du auf die Suche gehen kannst.

Wenn Du Dich tiefer für den Auswahlprozess interessierst, dann schau mal auf servicemanagement.tools vorbei – dort findest Du einen großen Leitfaden für die Auswahl einer ITSM-Suite oder eines ITSM-Tools.

Schon eine ganze Menge, oder?

Ja und zwar weil die Toolauswahl nur am Ende eines Prozesses stehen kann, der die zukünftige Organisation beschreibt.

 

Kurzer Einwurf: Du musst das nicht im Wasserfall abarbeiten. Also nicht erst alles dokumentieren und definieren und dann erst auswählen. Du kannst auch iterativ vorgehen.

Nimm die Punkte, die Dir wichtig sind und definiere diese. Bei den anderen lässt Du mehr Unschärfe zu.  Damit gehst Du dann in die Toolauswahl.

 

Magst Du ein Beispiel?

Ja? Dann plaudere ich mal ein wenig aus dem Nähkästchen. Und komme auch auf den Anfang des Podcasts zurück.

Ich bin den Weg gegangen, dass ich ausgehend vom Zielbild meiner Organisation, die einzelnen Prozesse, Funktionen usw. definiert und dokumentiert habe.

In meinem Projektplan stand schon von Anfang an drin, dass ein Tool auszuwählen sei.

Wie immer, war die Zeit schneller weg als gedacht und der Markt sehr unübersichtlich. Wenn Du mal einen Blick in die üblichen Publikationen wirst oder einfach im Internet danach suchst, findest Du einfach viel zu viele Werkzeuge.

Viel zu viele für mich, um einen klassischen Auswahlprozess durchzuführen.

Ich habe für mich festgelegt, was die entscheidenden Kriterien für die Auswahl sind. In meinem Fall waren das:

• Tool muss richtige Services kennen und nicht Service Requests mit Services durcheinander bringen
• Es muss meine Service-Architektur abbilden können und das direkt in der CMDB
• Servicekatalog muss Dreh- und Angelpunkt des Werkzeuges sein
• Die Integration verschiedener Kunden in den Servicekatalog muss von unterschiedlichen Preisen bis hin zur Abrechnung funktionieren
• Self Service muss stark ausgeprägt sein, um den Nutzer dabei zu unterstützen, sich selbst zu helfen
• Es muss eine SaaS Lösung mit Integration an eMail, AD und andere Systeme im eigenen Netz sein.

 

Danach habe ich mit einigen Menschen telefoniert, die eine Evaluierung gerade hinter sich hatten. Die Shortlist war so schnell gefunden. Einer viel raus, weil er einfach nicht zu mir passt. Die beiden anderen habe ich mir angeschaut.

Es hat sich dabei schnell ein Favorit herausgestellt, den ich dann näher unter die Lupe genommen habe.

Ich habe mir vor allem die gerade genannten Punkte angeschaut. In die anderen Prozesse habe ich kurz reingeschaut und für mich entschieden, dass ich dafür lieber meine Prozesse und Wünsche dem Tool annähere.

So bin ich in kurzer Zeit zu meinem Werkzeug gekommen.

Die Implementierung ist inzwischen gelaufen und Mitte Dezember war die Schulung. Ich bin nach wie vor mit der Auswahl zufrieden.

Ich habe folgende Prozesse, in unterschiedlicher Ausprägung, abgebildet:

• Service Portfolio Management
• Service Katalog Management
• Self Service
• Ideen- und Anforderungsmanagement
• Projektmanagement
• CMDB mit Service-Architektur
• Incident-, Problem- und Change-Management
• Financial Management

 

Wenn mich einer fragt was die Software ist, dann sage ich immer das ERP- und CRM-System der IT. Denn genau das ist es.

In diesem Prozess ist mir bewusst geworden, dass ich den Nutzen eines Tools bisher unterschätzt habe.

Ich bin nach wie vor der Meinung, dass ich erst, wenn ich meine Hausaufgaben erledigt habe, in die Toolauswahl gehen kann. Alles andere führt zu einem Narr mit einem Werkzeug.

Was das Werkzeug wert ist, wird es ab 1.1.2017 zeigen, dann beginnt der Echtbetrieb.

Einen Wermutstropfen gibt es leider jetzt schon. Der Hersteller hat dieses tolle, innovative Produkt zugunsten seines Dinosaurier-ITSM-Tools abgekündigt.

Das heißt: Nach der Toolauswahl ist vor der Toolauswahl.

Lust auf Tool? Hier klicken!

Eine Idee

Ehrlich gesagt habe ich darauf nicht wirklich Lust. Mir bleibt jedoch nichts anderes übrig. Wie ich mit diesem Problem umgehe und was daraus für eine Idee entstanden ist, schreibe ich Dir nächste Woche per eMail.

Vielleicht so viel zu der Idee:

Ich glaube, dass viele von uns sich fragen, ob das Werkzeug, was sie im Einsatz haben, den neuen Anforderungen gewachsen ist.

Vielfach haben wir das Tool danach ausgewählt, wie es Incident-, Problem- und Change-Management beherrscht. Die Anforderungen haben sich inzwischen gewandelt. Servicekatalog, Automatisierung, Self Services und die Anbindung von mehreren Providern sind nur einige dieser. Beherrscht das Dein Tool so, wie Du es brauchst?

Und wie sieht es mit Financial Management oder der Abbildung der Service Architektur aus? Bei der Vielzahl von Herstellern ist es mir sehr schwer gefallen, ohne viel Zeit zwei Tools auszuwählen, die ich testen wollte. Und dabei hatte ich eine Idee. Nächste Woche verrate ich Dir dann, worum es sich bei meiner Idee genau geht. – Trage Dich in den Newsletter ein oder melde Dich gleich zur Servicenerds.Bibliothek kostenlos an: