0

Wie Du das perfekte ITSM-Tool suchst!

Die Auswahl des perfekten ITSM-Tool für Dein Unternehmen scheitert meist schon beim ersten RfP (Request for Information). 90% aller Tool-Projekte machen dort einen entscheidenden Fehler. Welcher das ist und meine 4+1 Ideen, diesen zu umgehen, erfährst Du in dieser Folge.

Ich bin momentan beim Kunden als Berater rund um den Servicekatalog engagiert. Der Kunde hat seit vielen Jahren ein etabliertes Werkzeug für die ITSM-Prozesse im Einsatz. Es wird sogar aktiv gepflegt und das nächste Update steht an. Fragt man den Verantwortlichen für das Werkzeug, dann ist alles in Butter und alle Anforderungen können abgedeckt werden. Also kein Grund nach was Neuem zu schauen.

Und da hat die Falle zugeschnappt: Der Verantwortliche hat seit Jahren einen bestimmten Aufgabenbereich und beherrscht das Tool. Die Organisation an sich hat sich weiterentwickelt und es sind neue Anwendungsfälle und damit neue Anforderungen entstanden. Andere Einheiten des Kunden sind mit dem Tool nicht so zufrieden. Viele wünschen sich was Neues. Keiner ist auf der aktiven Suche.

Wo stehst Du heute?

Deine Organisation entwickelt sich weiter. Es ist wichtig das immer im Hinterkopf zu haben und regelmäßig zu fragen, was hat sich an unseren Anforderungen verändert und können wir diese mit dem aktuellen Werkzeug zufriedenstellend abdecken? Ansonsten bleibst Du in der Toolfalle stecken und verhinderst so mehr Effizienz und Effektivität – und vor allem Kundenzufriedenheit.

Bei meinem Beratungsmandat können wir die definierte und dokumentierte Servicearchitektur für niemanden anderen nutzbar machen, weil wir sie im Tool nicht abbilden können. Niemand kann daran partizipieren und so droht das alles ein privates Vergnügen der einen Organisationseinheit zu werden. Und das ist fürchterlich schade.

Also: Auch wenn Du nicht auf der Suche nach einem ITSM-Tool bist – sei bitte regelmäßig auf der Suche nach geänderten Anforderungen an Deine Toollandschaft. Schau auch einfach mal so, was sich am Markt getan hat und bekomme so Inspiration und Ideen. Die die Plattform servicemanagement.tools ist dafür natürlich die ideale Gelegenheit – zwinker, zwinker.

Objektivität gibt es nicht!

Sind Menschen auf der aktiven Suche nach einem ITSM-Werkzeug, dann gestaltet sich das regelmäßig als schwierig. Sowohl für den Suchenden, als auch die Hersteller der Werkzeuge.

Viele Auswahlwahlprozesse starten mit einem Request for Information – ein RfP. Das ist in vielen Fällen eine Excelliste mit bis zu 1.000 Zeilen und somit eintausend Fragen. Ja, Du hörst richtig. In meiner Zeit als Verantwortlicher für den Geschäftsbereich IT-Service-Management kenne ich solche Listen. Sie sind der Horror! Und vor allem Sie bringen dem Anfragenden nicht wirklich viel mehr Informationen!

Finde das perfekte ITSM-Tool für Dein Service-Management

Warum nicht? Ich als Hersteller werde jede Frage so interpretieren, dass ich die Antwort möglichst mit voller Punktzahl bewertet bekomme. Klar, weil ich will ja in die nächste Runde! Ich will Dir ja helfen und bin überzeugt, dass mein Tool genau das Richtige für Dich ist!

Wenn ich diese Listen sehe, dann habe ich immer das Gefühl, da ist ein Unternehmen, welches einen Großteil der ITSM-Prozesse sehr umfangreich am Laufen hat. Schauen wir hinter die Kulissen, dann sehen wir meistens, dass dem nicht so ist. Meist besteht der fromme Wunsch und man möchte sich ja nichts verbauen.

Was glaubst Du, warum es zu diesen Listen kommt? Ich meine, für den Suchenden ist es ja auch eine wahnsinnige Aufgabe eine solche Liste zusammenzustellen. Er rennt durch alle Fachabteilungen und fragt, was die brauchen. Er dokumentiert das, konsolidiert und entwickelt eine komplizierte Bewertungsmatrix. Das ganze wird dann noch in ein ausgefeiltes Excel gegossen, damit die Bewertung am Ende automatisch rauskommt und man eine ganz objektive Bewertung hat.

Ha –objektiv? Erinnere Dich bitte daran, was ich zum Thema Interpretation der Fragen durch den Hersteller gesagt habe. Da ist nichts objektiv!

Ich habe eine Theorie, warum solche Listen entstehen: Die Suchenden wissen einfach nicht, was sie wirklich brauchen. Aus welchen Gründen auch immer, legen sie sich nicht klar fest, was der Scope der Toolsuche ist und was dafür die wirklich harten Kriterien sind.

So enthalten die RfPs eine Unzahl detaillierter Anforderungen, die weder heute noch morgen vom Kunden je gebraucht werden. Ich glaube, da steht der Gedanke im Mittelpunkt, dass das Tool quasi heute schon das können muss, was man in 10 Jahren als Prozessreife vielleicht erreicht. Oder auch nicht. Der Suchende will sich für alle Fälle absichern. Und das am besten noch an alle verfügbaren Hersteller senden.

Geht auch anders!

Das ist kein sinnvoller Weg. Wenn Du so vorgehst, verschwendest Du viel Zeit und Fleiß und kommst wahrscheinlich nicht an das Ziel, welches Du erreichen möchtest.

Ich möchte Dir ein paar Ideen geben, wie Du den Prozess anders gestalten kannst.

An erster Stelle kommt die Festlegung für den Scope Deiner Toolauswahl.

Nein, Du suchst kein ITSM-Tool. Du suchst ein Werkzeug, welches Dich am besten in Deiner aktuellen Prozesslandschaft unterstützen kann. Oder welches Dich unterstützt, wenn Du zusätzlich Prozesse x, y und z etabliert hast.

Das heißt, Du brauchst eine Beschreibung des Scope. Du darfst darlegen, an welcher Stelle Ihr Euch befindet und wo es mittel- und langfristig hingeht. Das ist für den Hersteller wichtig zu verstehen.

Steht der Scope fest, setze ich dann nochmal Schwerpunkte: Als ich 2016 ein Tool suchte, lag mein Fokus auf Anforderungs-, Projekt- und Providermanagement sowie dem ServiceDesk. Das heißt, die Prozesse Incident, Problem, Knowledge, Financial, sowie Servicekatalog, Selfservice, Anforderungsverwaltung und Projektmanagement waren die Punkte, die es zu unterstützen galt.

Ich habe für mich festgelegt, dass das Hauptaugemerk auf Servicekatalog, SelfService und Financial Management liegt. Dafür habe ich Anforderungen definiert. Für alles andere habe ich geschaut, was das Tool kann und ob das sich halbwegs mit dem deckt, was wir uns vorstellen.

Damit habe ich nicht nur meinen Arbeitsaufwand gesenkt, sondern es fielen sehr viele Werkzeuge schon von Anfang an aus dem Rennen. Mit denen brauchte ich mich nicht zu beschäftigen.

Verschaffe Dir Klarheit, was für Dich in Deiner konkreten Situation wirklich wichtig ist und konzentriere Dich darauf.

Für diesen Bereich definierst Du die Anforderungen. Anforderungen aufzuschreiben ist eine eigene Wissenschaft. Dazu gibt es eigene Weiterbildungen und Zertifizierungen. Es ist also nicht damit getan eine Funktion zu nennen, dieser eine Wertzahl zu geben und den Anbieter mit ja oder nein antworten zu lassen.

Hol Dir den großen Leitfaden für Deine Toolauswahl.

Anforderungsgrammatik

Ne, da würde ich etwas mehr Arbeit reinstecken. Es gibt zwei Wege wie Du damit gut umgehen kannst. Das eine nenne ich die Anforderungsgrammatik. Das ist eine spezielle Schreibweise, die ich Dir erläutern möchte:

Du schreibst immer ganze Sätze. Zum Beispiel:

Das System muss für Bestellungen einen Genehmigungsworkflow unterstützen.

Dieser Satz besteht aus:

• dem Objekt – das System
• der Gewichtung – muss
• Aktion 1 – für Bestellungen
• Aktion 2 – einen Genehmigungsworflow unterstützen

Alternativ kannst Du auch eine Bedingung einbauen. Der Satz würde dann wie folgt lauten:

Bei der Nutzung via Smartphone muss das System den kompletten Servicekatalog zur Verfügung stellen.

Dieser Satz beginnt mit der Bedingung, gefolgt von der Gewichtung, dem Objekt und dann den zwei Aktionen.

Diese Sätze folgen Regeln:

• Schreibe kurze Sätze – diese sind verständlicher und nachvollziehbar
• Nur eine Anforderung in einem Satz
• Nutze nur aktive Formulierungen – kein passiv
• Keine Generalisierung wie jemand, alle, etc.
• Keine Negierung – also nicht das Wort nicht

Die Gewichtung erfolgt über folgende Schlüsselwörter:

Schlüsselwort	Gewichtung	Erfüllungsgrad
muss	Diese Anforderung ist uneingeschränkt einzuhalten.	100 %
soll	Diese Anforderung ist einer entsprechenden Form einzuhalten.	75 %
sollte	Diese Anforderung ist in einer ähnlichen Form einzuhalten.	50 %
kann	Diese Anforderung ist eine Empfehlung.	25 %

 

Ich habe schon einige Lastenhefte nach dieser Methodik geschrieben. Es ist ein Stück Arbeit, es lohnt sich jedoch! Du und Deine Organisation bekommen viel Klarheit darüber, was Ihr wirklich wollt. Die Detailtiefe obliegt dabei Euch. Du kannst formulieren: Das System muss den Absendenbutton unten rechts anzeigen. Wenn es wichtig ist.

User Storys

Die zweite Möglichkeit sind User Storys. User Storys sind in Alltagssprache formulierte Softwareanforderungen. So wikipedia. Allerdings stimmt das nicht ganz – denn auch diese folgen eine Grammatik.

Beispiel: Als Lizenzmanager benötige ich eine Übersicht der einem Nutzer oder Endgerät zugeordneten Lizenz, um eine Lizenzbilanz für Lizenzaudits zu erstellen.

Hier haben wir mehr Informationen: Wir wissen welche Rolle diese Anforderung in welchem Kontext hat. Und die Anforderung ist viel weniger detailliert – hinter der verstecken sich noch viele andere Anforderungen. Die User Story ist eher Ergebnisorientiert. Du beschreibst, was Du machen willst.

Die Grammatik dahinter lautet: Als … möchte ich … , so daß …

Als	möchte ich	so daß
Business Relationship Manager	alle offenen Vorgänge nach Kunden gruppiert auf einen Blick sehen	ich rechtzeitig den Kunden über Verzögerungen informieren kann

Szenarien

Und wenn wir jetzt schon bei User-Storys sind, dann habe ich noch eine andere Idee für Dich:

Arbeite doch mal mit realen Szenarien. Also schreibe detailliert auf, wie ein bestimmter Ablauf zukünftig funktionieren soll. Nehmen wir zum Beispiel die Buchung eines Service über das Self Service Portal. In einer Art Geschichte beschreibst Du was wer macht und was dann passiert. Also in dem Beispiel:

• wie findet der Nutzer den Service den er braucht
• welche Informationen bekommt er
• wie kann er bestellen
• was passiert nach der Bestellung
• wie wird das Fulfillment angesteuert
• was passiert im Lizenzmanagement

Davon erstellst Du drei oder vier wichtige Szenarien und sendest diese den in Frage kommenden Herstellern mit der Bitte dies in einem Termin zu präsentieren. Das kann drei Folgen haben:

1. Der Hersteller lehnt es ab oder meldet sich nicht
2. Der Hersteller kommt zur Präsentation und geht gar nicht oder nur sehr halbherzig auf Deine Szenarien ein
3. Der Hersteller kommt top vorbereitet und Du erlebst, wie Dein Prozess in dem Tool konkret aussehen wird und ihr könnt darüber diskutieren.

Du erfährst also nicht nur was über das Tool, sondern auch viel über den Hersteller. Viel mehr als in einem klassischen RfP.

4 Tipps + 1 Bonustipp

Ich bin überzeugt, dass wir den klassischen RfP haben, weil wir uns nicht festlegen und nicht beschränken wollen. Wir wollen alle Eventualitäten absichern und eine rationale Entscheidung auf der Basis eines Punktwertes treffen. Der Aufwand der dahinter steckt führt nicht zu dem Ergebnis was Du Dir als Suchender wünschst.

Folgende Punkte empfehle ich Dir für den Einstieg in eine erfolgreiche Toolauswahl:

1. Definiere den Scope Deiner Auswahl und lasse die Hersteller wissen, wo Du stehst und welche Unterstützung du brauchst
2. Setzte innerhalb des Scopes erneut Schwerpunkte. Konzentriere Dich beim Vergleich vor allem auf diese Teilaspekte. Den Rest schaust Du Dir zum Schluss an und entscheidest.
3. Nutze eine definierte Form, Deine Anforderungen zu formulieren: Die Anforderungsgrammatik oder User Storys
4. Erstelle Szenarien und lasse diese Dir von den Herstellern in Ihren Tools zeigen. Damit erfährst Du viel über die Tools und die Hersteller

Bonus-Tipp: Teste das Tool, spiele damit und nimm den Support in Anspruch. Für mich persönlich ist das der wichtigste Weg, um nach einer Vorauswahl zu entscheiden, welches Werkzeug ich anschaffe.

Ich hoffe Du lernst auf servicemanagement.tools Werkzeuge kennen, die für Dich interessant sind.