ITSM
Beim IT Service Management sind "kleine" Lösungen oft besser
IT-Dienstleister wollen damit Transparenz in ihre Leistungen bringen, um diese besser auf den Bedarf ihrer Kunden zuschneiden zu können und ihre Wertschöpfung zu verbessern. Bei der Abbildung des Servicekatalogs inklusive des dazugehörigen Prozesses gibt es spürbare Qualitätsunterschiede. Der Servicekatalog sollte beispielsweise mit den Informationen aus dem Asset- und Konfigurationsmanagement verknüpft werden können. Und das erfordert eine flexible Anpassung des hinterlegten Datenmodells auf die Anforderungen des eigenen Unternehmens.
Unabhängige Zertifikate helfen Tools zu beurteilen
Eine gute Hilfestellung zum Beurteilen verschiedener Hersteller liefern unabhängige Tool-Zertifizierungen wie die von PinkElephant mit PinkVerify oder in Deutschland die von Serview mit Serview Certified Tools. Wichtig ist hierbei eine strikte Neutralität gegenüber den Anbietern, und das bedeutet, dass keine Gebühren für die Zertifizierung oder Provisionen bei der Empfehlung von Software anfallen sollten. Softwarehersteller müssen ihre Qualität über standardisierte Assessment-Kriterien beweisen.
- Der Teufel steckt bekanntermaßen im Detail
Wenn ein IT-Services-Management umgesetzt werden soll, kommt es immer wieder zu denselben Schwierigkeiten. Wie lassen sie sich umgehen oder beseitigen? - 1. Aufgelaufene Kosten sind kein Argument
Wenn Entscheidungen zum weiteren Verlauf eines Projekts anstehen, werden die bereits investierten Kosten gern als Argument genannt. Das ist nicht zielführend. Es gilt, an den entscheidenden Stellen des Projekts einen zukunftsbezogenen Business Case zu erstellen. - 2. Kein Projekt ohne ausreichende Ressourcen
Nicht nur ITSM-Vorhaben werden häufig ad hoc gestartet. Das heißt: Es sind noch keine ausreichenden Ressourcen verfügbar. Das liegt oft daran, dass die Berechtigungen zur Ausgabe des Projektmandats überhaupt unklar sind. Abhilfe kann die Einführung eines Projekt-Management-Prozesses schaffen. Dabei sollte unbedingt eine Zuständigkeitsmatrix erstellt werden. Sie gibt an, welche "Rollen" einen Projektauftrag erteilen können - und zwar differenziert nach Projektgröße und -typ. - 3. Grundverständnis geht vor Lösungsansatz
Bei der Projektplanung wird zu schnell über konkrete Lösungsansätze und dafür erforderliche Aktivitäten gesprochen - ohne dass ein einheitliches Verständnis hinsichtlich der genauen Ziele besteht. Die Projektplanung sollte konsequent auf die zu liefernden Ergebnisse ausgerichtet sein. Dabei sind diese Ergebnisse möglichst exakt und in einer messbaren Kategorie zu beschreiben (Spezifikation des Ergebnisses, Form, Umfang, Qualität etc.). - 4. Besser Kanban als Bildschirm oder Beamer
Umfangreiche Projektpläne lassen sich nicht am Bildschirm oder über Beamer visualisieren. Stattdessen ist es sinnvoll, die Kanban-Methode zu nutzen. Das heißt: Visualisierung auf großen Wänden und Verwendung von Karten für die einzelnen Tasks. Das hilft, komplexe Zusammenhänge für alle Beteiligten auf den unterschiedlichen Hierarchiestufen darzustellen. - 5. Jeder muss seine Rolle im Projekt kennen
Viele Ansprechpartner sind sich ihrer Rolle in den Projekten nicht bewusst. Sie sollten aktiv in die Vorhaben eingebunden werden - über Use-Case-Definitionen und die gemeinsame Entwicklung eines Kommunikationsplans. - 6. Der Informationsfluss darf nicht stocken
Zu Projektbeginn ist das Team meist relativ gut informiert. Aber mit zunehmender Dauer sowie außerhalb des eigentlichen Projekts fehlt es häufig an Informationen. Um dem abzuhelfen, ist es sinnvoll, zu Projektbeginn eine Stakeholder-Analyse zu erstellen, aus der sich Form und Umfang der nötigen Informationen ableiten lassen. Dort kann auch definiert werden, wie die Akteure eingebunden werden sollen. Auf dieser Basis lässt sich ein Stakeholder-spezifisches Kommunikationskonzept aufsetzen. - 7. Wenn der Fachbereich keinen Input liefert
Immer wieder krankt ein Projekt auch daran, dass der vereinbarte Input aus den Fachabteilungen ausbleibt. Da helfen zwei Maßnahmen. Zum einen müssen eindeutige Verantwortlichkeiten geschaffen werden. Zum anderen muss den Fachbereichen, auch durch Visualisierung über den Produktstrukturplan, eindrücklich klargemacht werden, wie abhängig das Gesamtprojekt von ihrem Input ist und welche Folgen die ausbleibende Lieferung hat. - 8. Es geht einfach nicht ohne formale Anträge
eue Projekte und Serviceänderungen werden "on the fly" und ohne Spezifikationen direkt an einen Mitarbeiter der IT geleitet. Was ist dagegen zu tun? Es muss ein strukturiertes Verfahren zur Projektantragsstellung und -freigabe etabliert werden, verbunden mit der Definition von Verantwortlichkeiten zur Steuerung dieses Prozesses - beispielsweise durch einen IT-Koordinator. - 9. Arbeitspakete beugen Verzögerungen vor
Mit den Kunden sind klare Termine vereinbart, die aber werden immerzu verschoben. Das schreit nach einem Workshop zur Definition der Arbeitspakete mit Abschätzung der Dauer durch Experten. Dabei ist eine genaue Priorisierung vorzunehmen, der Abstimmungsprozess zu überdenken und der Dokumentationsbedarf zu klären. - 10. Alle müssen den Status des Projekts kennen
Während des Projekts ist häufig unbekannt, wo es eigentlich gerade steht. Damit alle Bescheid wissen, empfehlen sich eine kleine Website sowie ein Newsletter mit Reporting. Auf diese Weise kann jeder Stakeholder die Statusinformationen jederzeit abrufen.
In den vergangenen Jahren wurde eine Reihe verschiedener Service-Management-Tools in die Liste der Certified Tools aufgenommen. Darunter sind auch solche etlicher kleinerer Hersteller, wie etwa der deutsche Anbieter USU oder Omninet, helpLine, Matrix42 und Wendia, die alle über eine große und qualitativ ansprechende Funktionsbandbreite verfügen. Analysten wie die von Gartner oder Forrester Research sind global ausgerichtet und berücksichtigen solche leistungsfähigen lokalen Tools oft gar nicht.
Anpassen und Tools kombinieren
Unternehmen werden ihr ITSM-Tool in der Regel den eigenen Anforderungen anpassen. So ist gewährleistet, dass die Nutzer später die Handhabung der Prozesse auch akzeptieren. Vor allem in größeren Organisationen ist es oft effizienter, das Tool an die bestehenden Prozesse anzupassen, nicht umgekehrt. Bei der Evaluierung eines Werkzeugs ist es daher wichtig zu prüfen, in welchem Maße es die konzerneigenen Prozesse abbildet und wie hoch der Aufwand einer Anpassung wäre.
Auch die Integrationsfähigkeit des zukünftigen ITSM-Tools in die bestehende Umgebung spielt eine entscheidende Rolle. Und das nicht nur, weil Schnittstellen zu dem bestehenden ERP-System geschaffen werden müssen, sondern auch weil es immer Aufgaben gibt, die über zusätzliche spezialisierte Tools erledigt werden sollen. Beispiele hierfür sind System-Management, Automatisierungs- oder Analyse-Werkzeuge. Dafür empfiehlt es sich im Vorfeld zu prüfen, welche Prozesse und Verfahren miteinander verknüpft sein müssen, und wie der Datenfluss gestaltet ist, um das Zusammenspiel der Tools in diesen Bereichen sicherstellen zu können. Danach kann die Schnittstellenfähigkeit der Lösung gezielt evaluiert werden.