Services sind digitale Produkte

Die Sprache hat eine Schlüsselfunktion, um gegenseitiges Verständnis, Respekt und Toleranz auszudrücken. Gegenseitige sprachliche Verständigung dient somit als Grundlage für ein friedvolles Zusammenleben. Man mag geteilter Meinung sein, wie effektiv und nachhaltig die Service Management Praktiken aus den ITIL-Trainings in den Unternehmen umgesetzt wurden. Aber einer der Hauptgründe, weshalb die CIOs ihre Mitarbeiter in die Schulungen geschickt haben, war auch die Vermittlung einer einheitlichen Sprache und die Klärung von Begriffen. Ohne klare Begriffe und abgestimmtes Verständnis reden die Leute aneinander vorbei. Kein seltenes Phänomen in IT-Organisationen.

Mit dem Aufkommen von agilen Methoden und Praktiken hat sich der Graben mitten in der IT-Organisation eher vergrössert, als geschlossen. Der Graben zwischen den Projekt- und Entwicklungs-Teams einerseits und den Service Delivery und Support Teams andererseits.  Ich habe im Dezember 2013 einen Traum gehabt, dass den Graben dieser zweiten Welten schliesst (I have a dream … 2014 und später).  Es hat sich zwar viel getan, aber der Graben ist heute noch lange nicht geschlossen. Obwohl mit der Publikation von ITIL 4 das Service Management die Tür in die agile Welt weit aufgestossen wurde, hat die Agile Community die Service Manager Welt nicht mit offenen Armen empfangen. Und das hat aus meiner Sicht auch mit der Sprache zu tun. Wir sind sprachlich noch zu weit auseinander.

Der Grosse Graben – Asterix, Band 25

Während die Agilisten aus Scrum, SAFe und DevOps von Produkten sprechen, hangen wir in der Service Management Community am Begriff aller Begriffe: dem Service. Der Service ist alles, um was es im Service Management geht. Darin wird der Mehrwert, die SLAs, die Qualität und alles was sonst noch dazu gehört, hineinprojiziert. Es beinhaltet alle funktionalen und vor allem auch nicht-funktionalen Anforderungen des Kunden. Was dann aber ein Service genau ist, da tun wir uns mit der Definition immer wieder schwer. Was uns vom ITIL-Framework zur Verfügung gestellt wird, tönt eher hölzern und akademisch, als dass ich dies Personen ausserhalb des ITIL-Zirkels und insbesondere dem Kunden verständlich erklären kann: «Eine Möglichkeit, gemeinsamen Wert zu schaffen, indem das Erreichen der von Kunden gewünschten Ergebnisse erleichtert wird, ohne dass der Kunde bestimmte Kosten und Risiken managen muss

Die Definition des Begriffs «Service» muss natürlich generisch für alles Gültigkeit haben, was letztlich als Service verstanden werden will. Darum kommt er wohl so sperrig daher. Andererseits hat die agile Welt für ihren zentralen Begriff «Produkt» gar nicht erst eine Definition bereitgestellt. Sowohl bei Scrum.Org, SAFe oder DevOps sucht man vergeblich nach einer Definition im Glossar. Dafür gibt es aber Product Owern, Product Lifecycle und Product Backlogs.

Alles was ein Product ausmacht, wird über das Backlog definiert. Darin enthalten sind alle Anforderungen aus funktionaler, nicht-funktionaler Sicht, alle Sicherheits- und Compliance-Anforderungen und vielem mehr. Der Product Owner ist für den gesamten Product-Lifecycle verantwortlich – also nicht nur bis Ende Entwicklungsprojekt. Siehe Definition «Product and Solution Management» von SAFe 5.0. Gerade mit DevOps wird alles darangesetzt, dass auch die Anforderungen aus dem Betrieb hinsichtlich Bereitstellung, Überwachung und Support in die Anforderungen mit einfliessen. Und wenn mal etwas im Betrieb schiefläuft, dann wird es vom DevOps-Team aufgenommen und gelöst: «We build it, we own it, we fix it.». Aus dieser Optik braucht es nichts Zusätzliches, was ein Service Management rechtfertigt.

Product Lifecycle gemäss SAFe 5.0

Aus der Optik von Service Management betrachtet man demgegenüber den «Service Lifecycle», wobei der Service mit der Strategie und Business Demand startet und über die Service Wertschöpfungskette inklusive Entwicklung, Design, Transition sowie Bereitstellung und Support» dem Kunden zur Verfügung gestellt wird. Da scheint also mit dem agilen Produkt Management und dem Service Management nicht völlig unterschiedliche Ziele verfolgt werden.

Dem genauen Beobachter wird wohl aufgefallen sein, dass in ITIL 4 das ultimative Ergebnis aus Service Management nicht der Service selbst ist, sondern der Mehrwert oder neudeutsch «Value».  Und in ITIL 4 hat man sich sogar durchringen können, dass es so etwas wie Produkte gibt. Aber damit man Service nicht dem Produkt gleichsetzen kann, hat man mit einer eigenen Definition für den Begriff Produkt gesorgt: «Ein Produkt ist eine Kombination der Ressourcen einer Organisation, die darauf ausgelegt ist, einen Wert für einen Konsumenten zu bieten.».  Während sich die Service Management Gemeinde in ihrem Verständnis für Produkte geradezu bestätigt sehen, fühlen sich die Agilisten definitiv bestätigt, dass die Service Managers nie auf der gleichen Ebene mit ihnen sprechen können. Mit so einem Produktverständnis hat man in der agilen Welt rein gar nichts begriffen.

So wird eine Annäherung sehr schwierig, wenn nicht gar unmöglich. Auch wenn wir uns sehr viel Mühe geben, agiles Service Management nicht nur so zu nennen, sondern auch zu leben. Agilität ist zu einem Grossteil eine Bewusstseins- und Einstellungsfrage und weniger eine Frage des Frameworks. Aber die Sprache ist für ein gemeinsames Verständnis und wirkungsvoller Zusammenarbeit einfach unerlässlich.

Ich werfe einen Stein ins Wasser: Services sind neu “Digitale Produkte

Wir durchleben derzeit eine turbulente und für uns alle nicht ganz einfache Zeit. Wir wissen nicht, wie die neue Normalität nach dieser Pandemie-Krise aussieht. Aber es gibt sicher nicht nur viele Probleme, es gibt bestimmt auch viele neue Chancen. So eine Chance möchte ich nun aufgreifen und eine Idee platzieren: Wir springen über unseren eigenen Schatten und gehen mit einem grossen Schritt auf die agile Community zu. Wir stellen unseren Begriff «Service» zurück und definieren neu einen Oberbegriff «Digitale Produkte».

Ein «digitales Produkt» besteht aus meiner Sicht einerseits aus einem Produkt gekoppelt mit Software und andererseits einem Service.  Damit möchte ich klar den Bezug auf die Digitalisierung ansprechen und nicht irgendwelche Produkte in Betracht ziehen. Ein Tisch mag wohl ein Produkt sein und ich könnte mir sogar vorstellen, damit einen Service zu kreieren. Dies ist aber sicherlich kein digitales Produkt. Eine Taxifahrt wird gerne auch als Vergleich mit dem Service herangezogen, wobei ich mich nicht um das Fahrzeug (sprich Produkt) zu kümmern brauche. Das allein ist aus meiner Sicht aber kein digitales Produkt, da hier wenig mit Digitalisierung in Verbindung gebracht werden kann. Wenn ich jedoch eine Gesamtlösung habe, wo ich per App (wie beispielsweise Uber) eine Fahrt organisieren und noch die Qualität beeinflussen kann (Komfort des Autos), dann haben wir ein digitales Produkt.

In der zunehmenden Digitalisierung der Geschäftsprozesse wird es immer mehr so sein, dass die direkte Interaktion nur noch über die digitalen Produkte erfolgen. Überwachung und Support geschieht in Zukunft vermehrt über AIOps, Chatbots und NLP. Service und Produkte wachsen zusammen. Damit wird es Zeit, dass auch die Teams endlich zusammenwachsen und anfangen, die gleiche Sprache zu sprechen.  Ich bin gespannt auf Euren Feedback und freue mich auf einen angeregten Austausch.

Leave a Comment

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.