Apollo-Optik hat sein IT-Service-Management (ITSM) neu gestaltet. Zu den zentralen Erkenntnissen des Projekts gehört dabei, dass zum Service-Management heutzutage unbedingt auch die Position eines Service-Managers gehört.
Projekte definieren sich über Ziele und Anforderungen. Aber allein in der Ergebnisqualität erschöpft sich der Nutzen von Projekten sicher nicht. Vielmehr bieten insbesondere komplexe und innovative Maßnahmen auch ein breites Lernfeld. Die systematische Auswertung der Erfahrungen lässt sich für künftige Maßnahmen zur Erfolgssteigerung nutzen.
Das gilt auch für die international agierenden Apollo-Optik, mit mehr als 800 Filialen die größte Optikerkette in Deutschland. Aus ihrem Projekt zur Neugestaltung des IT-Service-Managements zog sie einige nützliche Erkenntnisse.
Prozessverantwortung klar regeln
"Das IT-Service-Modell von früher ist nicht mehr zukunftsgerecht", betont Erich Ehbauer, IT-Leiter bei Apollo-Optik. Damals bildeten allein technisch fokussierte Mitarbeiter das Thema ab - in der Administration, im Helpdesk etc. "Es wird immer wichtiger, dass auch jemand die Prozesse verantwortet und als Motor für das IT Service Management fungiert", fordert Ehbauer. "Auch die Infrastrukturen und Anwenderlandschaften verändern sich permanent, wodurch sich das IT-Service-Management ebenfalls ständig neuen Herausforderungen gegenüber gestellt sieht", ergänzt Ehbauer.
Die Protagonisten des Projekts (von link): IT-Chef Erich Ehbauer, Robert Zellner als Vorstand der COC AG und der frischgebackene Service-Manager Gerad Ringel Foto: Apollo Optik
Aus dieser Einschätzung zog Apollo-Optik Konsequenzen: Im Verlauf des Projekts wurde die Position des Service-Managers neu geschaffen. Gerald Ringel sieht sich nun vor eine Vielfalt interessanter Aufgaben gestellt. "Die Bedeutung der IT-Services für die Verfügbarkeit und Performance der marktnahen Geschäftsprozesse steigt kontinuierlich", sagt er, "dementsprechend anspruchsvoll ist auch der weitere Entwicklungsbedarf." Themen wie Effizienz, Qualität oder Kundenorientierung der IT-Services blieben dauerhaft aktuell, weil sie noch erhebliche Potenziale zur Optimierung böten.
Zu den Zielen gehört, dass künftig jeder Prozess in seinen Ergebnissen messbar sein soll. Nur so lassen sich nach Einschätzung von Apollo Optik der jeweilige Reifegrad und seine Performance belastbar darstellen, also der Optimierungsbedarf konkret bewerten. Dazu gehören auch Kennzahlen zu den einzelnen Prozessen, die über Reports regelmäßig den betroffenen Mitarbeitern zur Verfügung gestellt werden sollen.
Kleinere Schritte statt komplexe Ziele
Eine wesentliche Erkenntnis aus dem Vorhaben betrifft die Projektkonzeption. Wie der Beratungspartner der Apollo-Optik, die COC AG, anmerkt, wird in ITSM-Projekten häufig versucht, die ideale, theoretisch perfekte Lösung in einem einzigen großen Sprung zu erreichen.
"Komplexe Anforderungen erzeugen hohe Anstrengungen und führen meist zu größeren Veränderungen, die auf verschiedenen Ebenen hohe Widerstandspotentiale in sich bergen", so der COC-Consultant Hans-Peter Schernhammer. Wie sich auch bei dem Apollo-Projekt bestätigt habe, lassen sich Lösungen in praktikablen Einzelschritten erfolgreicher realisieren.
Zudem rät Schernhammer, bereits in der Planungsphase die möglichen Abhängigkeiten verschiedener Projekte untereinander zu berücksichtigen - angesichts einer sich fortlaufend ändernden Umgebung mit vielen durch das Business oder durch Technologie ausgelösten Vorhaben. Nur durch eine solche Abschätzung sei es möglich, negative Folgen - beispielsweise hinsichtlich des Ressourcenbedarfs oder der Projektzeiten - zu verhindern oder abzumildern.
8 Fehler beim IT-Service-Management -
Das sollten Sie bei ITSM vermeiden Sie lassen sich von billiger Software blenden und denken nicht voraus: Über die acht häufigsten Fehler von CIOs beim Service Management.
1. Lastenhefte sind nicht zukunftsorientiert: In der Regel beschreiben Lastenhefte den aktuellen Funktionsbedarf einer ITSM-Lösung. Da IT-Organisationen die vorhandene IT-Landschaft jedoch laufend durch technologische Innovationen und neue Prozesse erweitern, muss die Entscheidung für ein ITSM-Tool in die Zukunft gerichtet sein und auch mögliche neue Anforderungen für die nächsten zwei bis drei Jahre erfassen.
2. IT-Betriebskosten werden unterschätzt: Bei Business-Applikationen werden Folgekosten von Beginn an in die Projektplanung einbezogen. Immerhin machen sie rund ein Viertel der Implementierungskosten aus. Nicht so bei ITSM-Software. Insbesondere der Personalbedarf für den laufenden Betrieb wird unterschätzt. IT-Organisationen von Konzernen brauchen in der Regel ein Team von vier bis fünf Mitarbeitern. Auch Outsourcing kostet Geld.
3. ITSM-Tools sind keine Out-of-the-Box-Systeme: Um Werkzeuge für das IT-Service-Management sinnvoll zu nutzen, müssen diese ständig mit Daten aus den Business-Systemen gefüttert werden, die zugleich laufend zu pflegen sind. Ebenso wichtig ist die Betreuung der Schnittstellen zwischen den ITSM-Tools und den angeschlossenen IT-Systemen. Oft sind das mehr als 100.
4. All-in-One-Ansatz statt: IT-Verantwortliche wollen in der Regel alle Anforderungen an das IT-Service-Management durch integrierte ITSM-Produkte eines Herstellers abbilden. Die Vorzüge: einfache Implementierung und direkte Integration, geringere Projektkosten und weniger Bedarf an Spezial-Know-how. Diese Vorteile werden jedoch mit erheblichen Leistungseinschränkungen erkauft, weil kein Werkzeug ein Top-Spezialist auf jedem Gebiet sein kann.
5. Die Auswahl von ITSM-Tools erfolgt emotional statt rational: CIOs führen zwar die klassischen Schritte bei der Evaluierung von ITSM-Werkzeugen durch - Erstellung des Anforderungsprofils, Ausschreibung, Proof of Concept mit ausgewählten Anbietern. Die Entscheidung für ein Tool erfolgt jedoch meist aus dem Bauch heraus, etwa nach dem Look-and-Feel der Benutzeroberflächen.
6. Unternehmen tappen in die Preisfalle: Erfahrungsgemäß machen die Softwarekosten nur ein Drittel der gesamten Aufwendungen aus. Zwei Drittel der Kosten - meist Summen in sechsstelliger Höhe - verschlingt die Projektrealisierung mit internen oder externen Ressourcen. Letztere können IT-Verantwortliche durch geschicktes Verhandeln und unter Nutzung des Wettbewerbs der Anbieter um 50 bis 70 Prozent gegenüber dem Listenpreis reduzieren.
7. Investitionssicherheit wird zu wenig beachtet: Unternehmen beziehen in die Auswahl des künftigen ITSM-Lieferanten kaum Aspekte wie Weiterentwicklung der ITSM-Lösung und Investitionssicherheit ein. Das könnte sich später einmal rächen. Wichtige Bewertungskriterien, die Aufschluss über die Zukunftssicherheit einer Lösung geben, sind zum Beispiel die Größe der Entwicklungsmannschaft, das F&E-Budget sowie Fusions- oder Übernahmeprozesse beim Hersteller.
8. Tool-Gläubigkeit statt Prozessorientierung: In der Praxis tritt beim ITSM die Prozesssicht häufig in den Hintergrund. Stattdessen dominieren funktionale und technische Aspekte. Effizienzsteigerungen lassen sich jedoch nur durch optimierte Prozesse, die durch ITSM-Lösungen angemessen unterstützt werden, erzielen und nicht umgekehrt.
Projekt-Marketing nicht vergessen
Auf einen weiteren Aspekt weist der IT-Verantwortliche Ehbauer hin: "Es ist es wichtig, die Projektfortschritte gegenüber den Verantwortlichen und Mitarbeitern öffentlich zu machen". Ansonsten könne es passieren, dass allgemein gültige Definitionen für Prozesse im Tagesgeschäft untergingen. Die Folge: Aus Sicht des Managements oder auch der Mitarbeiter lassen sich dann trotz des Projektaufwands keine Verbesserungen spüren.
Ohnehin ist es unerlässlich, wie sich in dem Apollo-Projekt wieder einmal bestätigte, dass mit allen Beteiligten einschließlich der externen Berater eine offene Kommunikation gepflegt wird. Bereitschaft zur konstruktiven Lösung vorausgesetzt, stellen Konflikte im Projektverlauf dann auch keine bloßen Störungen dar, sondern werden als Impulse zum genauen Hinschauen verstanden.
Allerdings muss sich die Diskussionskultur bei einem derartigen Reorganisationsprojekt erst einmal entwickeln, und sie benötigt Moderationskompetenz. "Liegt diese Aufgabe zunächst bei den Beratern, so sollte sie im Projektverlauf sukzessive auf die internen Führungskräfte übertragen werden", empfiehlt Ehbauer.
Support-Mitarbeiter beim Kunden platzieren
Hinsichtlich der fachlichen Ressourcen mit ihren veränderten Rollen und Verantwortlichkeiten galt es zunächst, die Eignung der Mitarbeiter zu prüfen. Abgeleitet aus den künftig notwendigen Kompetenzen für Technik und Organisation wurden Schulungs- und Entwicklungspläne entworfen.
Doch darauf beschränkten sich die Maßnahmen nicht. Es wurden auch Veränderungen in der räumlichen Platzierung der Support-Einheiten vorgenommen, um die Sichtbarkeit der Teams zu erhöhen. In ihrer Neuanordnung folgen die Arbeitsplätze dem Prinzip der Kundenorientierung: So wird beispielsweise ein Service-Desk mit Kundenpräsenz so positioniert, dass er leicht zu finden ist, die Mitarbeiter ihre Aufgaben erfüllen können und die Kunden ein unmittelbares Serviceerlebnis bekommen.
ITSM-Tool vorwärtsgerichtet auswählen
Mit dem ITSM-Projekt verbunden war die Einführung eines neuen Tools zur Steuerung der IT-Prozesse. Der Nutzen dieser Software besteht darin, die Mitarbeiter in den Prozessen zu unterstützen und die Abläufe zu beschleunigen. Dadurch verbessert sich aber auch die Dokumentationsqualität. Last, but not least können Auswertungen über die umfangreiche Datenbasis erzeugt werden.
Bei Apollo-Optik bestehen unterschiedliche Leistungsanforderungen - durch den Filial-Support einerseits und den Support in der Filiale andererseits. Beide Nutzergruppen und ihre Anforderungen müssen aufeinander abgestimmt sein.
In den Evaluierungsprozess flossen neben den funktionalen Erfordernisse aber auch das Handling und die Ergonomie der Software sowie die Servicequalität der Hersteller ein. Das vorhandene System wurde bewusst nicht als Basis für die Produktevaluierung herangezogen, denn das Tool sollte ja künftige statt rückwärtsgerichteter Anforderungen abbilden.
Probleme in ITSM-Projekten -
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.
Die Aufgaben der Berater definieren
Eine externe fachliche Hilfestellung ist nach Ansicht von Ehbauer bei Maßnahmen dieser Komplexität fast unumgänglich. Wichtig ist dabei eine klare Definition, worin deren Aufgaben bestehen und Verantwortlichkeiten sie übernehmen. Wie der IT-Chef berichtet, haben Apollo-Optik und COC "zunächst gemeinsam die Critical Success Factors ermittelt, deren Überwachung einschließlich der möglichen Eskalationsverfahren anschließend den Consultants überantwortet wurde."
Zu den Aufgaben der Berater gehörte es, die Messbarkeit im Projekt zu etablieren, um mit Hilfe dieses Kontrollinstruments den Projektfortschritt kontinuierlich abzubilden. Da die Berater typischerweise eine neue Sicht auf die Organisation mit Erfahrungswissen aus ähnlichen Projekten verbinden, erhielten sie noch einen anderen Auftrag: Sie in einer offenen Gesprächskultur den Veränderungsprozess kommunizieren und moderieren. (qua)