Ganzheitliches-Servicedesign
Bei der Einführung von Enterprise Service Management (ESM) setzen sich Unternehmen intensiv mit ihren internen und nach außen gerichteten Prozessen sowie Services auseinander. Das ist allerdings nur der erste wichtige Schritt für einen vollumfänglichen Servicekatalog. Das System muss sich kontinuierlich mit den geänderten oder steigenden Anforderungen der Nutzenden weiterentwickeln.
Wer rastet, der rostet
Das Service-Management und der Servicekatalog sind keine in sich abgeschlossenen Aufgaben. Sie sind ein lebendiger Zyklus, der sich anhand geänderter Anforderungen nutzerorientiert weiterentwickelt. Was genau steckt hinter dem Begriff „Service“? Hierzu orientieren wir uns an der Definition von Prof. Dr. Steven Alter von der University of San Francisco: „Services are acts or groups of acts performed with the intention of providing outcomes for the benefits of others.”
Demnach bestehen Services aus Handlungen oder gebündelten Handlungen, die für andere einen Nutzen erfüllen. Bedingt durch Veränderungen innerhalb von Organisationen müssen Services kontinuierlich ergänzt oder verändert werden. Andernfalls verlieren sie ihren Nutzen und Anwender:innen werden unzufrieden. Gleiches gilt auch, wenn Services nicht schnell oder umfassend genug im Service-Management-Tool implementiert werden.
Servicedesign als Grundlage für bestmöglichen Service
Das Service-Management ist eine der wichtigsten Disziplinen für (IT-) Organisationen. Es verarbeitet zahlreiche potenzielle und auch ganz neue Services und muss auf gleichzeitig steigende Anforderungen reagieren. Hierbei geht es um einen hohen Erfüllungsgrad, Effizienz, Qualität und gleichzeitig die zeitnahe Reaktion auf Anfragen und Störungen. Um den bestmöglichen Service zu bieten, müssen die Nutzenden im Fokus stehen, nicht die Funktionen der Tools. Welche Anforderungen haben Nutzende? Welche Services werden erwartet? Wie nutzenstiftend sind sie wirklich? Die Antworten auf diese Fragen beginnen beim Designprozess für Services. Dieser Prozess muss wohlüberlegt sein, um die Balance zwischen zu vielen, zu hohen und zeitgleichen Anforderungen zu finden. Schleichen sich schon im Designprozess Fehler ein, ziehen sich diese schnell durch den gesamten Service – unzufriedene Nutzende sind dann vorprogrammiert.
Ein strukturierter Prozess mit einer iterativen Vorgehensweise erfüllt langfristig die Ziele und führt zu zufriedenen Nutzenden. Ein entsprechender Prozess kann beispielhaft wie folgt aussehen:
Dieser Prozess ist eine stark reduzierte Darstellung und zeigt nur die wesentlichen Prozessschritte eines möglichen Grundgerüsts. Auf den ersten Blick sieht es einfach aus, aber der Teufel steckt bekanntlich im Detail. In der Praxis kann sich ein solcher Prozess ohne eine gute Vorbereitung schnell zu einer unübersichtlichen Gemengelage unterschiedlichster Prozessabzweigungen und Stakeholder entwickeln. Sinnvoller ist es, den bereits in einzelne Schritte gegliederten Prozess nochmals gesondert in ein stufenweises Vorgehen zu unterteilen.
Vier Stufen für agiles Service-Management
Das stufenweise Vorgehen ist an das agile Vorgehensmodell Scrum angelehnt und fordert entsprechende Rollen ein, wie zum Beispiel den Scrum Master, den Product Owner und das Development Team. Einzelne Aufgaben(-stränge) werden im Rahmen des Vorgehens in Sprints zusammengefügt und entsprechend der agilen Vorgehensweise bearbeitet.
Stufe 1: Die Analyse der Ausgangssituation
In der ersten Stufe des Designprozesses werden die Anforderungen definiert und die Ideen identifiziert und aufgenommen. Organisationen sollten offen sein für Ideen, Anforderungen und Wünsche jeglicher Art. Zu diesem Zeitpunkt werden ebenfalls das Team zur Umsetzung der Idee zusammengestellt sowie die Stakeholder identifiziert und in das Team integriert. Potenzielle Stakeholder sind zum Beispiel Nutzende, Product Owner und Vertreter:innen der IT-Organisation, Mitarbeitende, der Vorstand, der Betriebsrat, Fachbereiche, Lieferanten oder auch Datenschutzbeauftragte. Sobald die Anforderungen an einen Service und seine Stakeholder feststehen, geht es nahtlos in die zweite Stufe über – das Design.
Stufe 2: Design
Im Designprozess werden die Zielprozesse, die Zielarchitektur und die Templates definiert. Aus diesen Komponenten werden die einzelnen Sprint Items gewählt, die für den Entwicklungsprozess des Services erforderlich sind. Für die Definition der Zielprozesse werden die vorhandenen Services auf den Prüfstand gestellt. Es wird festgehalten, inwiefern ein bereits genutzter Service die Anforderungen für den neuen, benötigten Service erfüllt. Das betrifft zum Beispiel Schnittstellen oder Abhängigkeiten einzelner Prozessschritte. Kann auf bereits vorhandene Prozesse oder Schnittstellen aufgesetzt werden, werden diese in die nachfolgenden Schritte mit einbezogen. Ist das nicht der Fall, so gilt es, neue Zuständigkeiten, Ansprechpartner:innen, Schnittstellen und Abhängigkeiten zu definieren. Im Rahmen der Zielarchitektur werden mit diesen Vorüberlegungen Zielprozesse und Rollen definiert und die angestrebte Zielstruktur modelliert. Diese Überlegungen fließen dann in die Entwicklung und Übernahme von Templates ein. Zu den benötigten Templates gehören u. a. Release Notes, Testprotokolle und vieles mehr. Erst wenn diese Überlegungen fixiert sind, geht es in der dritten Stufe an die Entwicklung des Services.
Stufe 3: Deployment
Auf Basis der Analyse und des Designs folgen in der dritten Stufe die Umsetzung und Implementierung des Services. Das Mittel der Wahl sollte ein Minimum Viable Product (MVP) sein, um potenzielle Schwachstellen zu identifizieren und Anpassungen vornehmen zu können. Im Anschluss wird die MVP-Vorgehensweise auch bei der Produktivsetzung angewendet, um auch in dieser Phase iterativ das Nutzer-Feedback integrieren zu können. Gleichzeitig gilt es, Nutzende im Umgang mit dem Service und den dahinterliegenden Prozessen und Strukturen zu schulen. Die Schulungsmethoden reichen von Broschüren über Videos bis zu umfangreichen E-Learnings. Wie intensiv geschult werden muss, ist abhängig vom Serviceprozess und dem neuen Service. Im einfachsten Fall reicht eventuell schon eine Mailing-Kampagne mit Informationen.
Stufe 4: Change
„Change“ – und damit die Kommunikation der Veränderung – ist kein eigenständiger Strang, sondern verläuft als paralleler Prozess und steigert die Akzeptanz eines neuen Services. Änderungen werden leider häufig skeptisch betrachtet und zwingen Anwender:innen womöglich aus der eigenen Komfortzone. Ein gezieltes Change Management mit einer passgenauen Kommunikation baut Hürden ab. Sie startet bestenfalls bereits mit dem Beginn des Projektes und berichtet sukzessive über die gesetzten Meilensteine, Vorteile und den Zeitpunkt der Einführung des neuen Services. Schulungen, wie bereits in Stufe 3 beschrieben, runden ein erfolgreiches Change Management ab. Wie umfangreich die Maßnahmen sein sollten, ist abhängig vom jeweiligen Service. Erfahrungsgemäß sollten sie bereits in der ersten Stufe, bei der Ausarbeitung der Idee, berücksichtigt werden.
Servicebetrieb aufrechterhalten
Ist ein neuer Service erfolgreich implementiert, geht er nahtlos über in den Servicebetrieb. Der Betrieb muss die Verfügbarkeit des Services, entweder über Serviceportale oder im Rahmen einer automatisierten Bereitstellung, gewährleisten. Störungen und Beschwerden müssen prädiktiv erkannt und behandelt werden. Darüber hinaus wird ein Service regelmäßig weiter optimiert. Um einen zufriedenstellenden Service anzubieten, ist die Arbeit daran eigentlich nie abgeschlossen. Denn im Rahmen von Services gilt: Wer rastet, der rostet.
Die Top 5 des Servicedesigns
- Ein Service muss immer nutzenstiftend sein und ist nicht gleichzusetzen mit einer bezahlten Dienstleistung.
- Stellen Sie beim Servicedesign immer die Nutzenden in den Mittelpunkt.
- In der Phase der Ideenfindung gibt es kein richtig oder falsch.
- Ein strukturierter, vierstufiger Prozess erleichtert den Aufbau, die Implementierung und die Akzeptanz eines neuen Services.
- Auch nach der Fertigstellung ist die Arbeit am Service nicht abgeschlossen.
Lesen Sie in der vorherigen Ausgabe des Materna Monitors mehr über die Nutzerzentrierung von Services im Beitrag „Paradigmenwechsel im Enterprise Service Management“.