5

Der Service-Owner – es kann nur einen geben!

Service-Owner? Wer ist das? Hat den schon mal jemand gesehen? Was macht der Service-Owner? Diese und andere Fragen rund um den Service-Owner möchte ich Dir heute beantworten. Ich lassen Dich dann am Ende mit anderen Fragen allein - versprochen! ;-)

Das Anbieten von Services hat vor allem etwas mit der Konzentration auf den Kunden zu tun. Alles was dazu nicht beiträgt ist Verschwendung. Du bindest wertvolle Arbeitskraft mit sinnlosen Aktivitäten. Gern würde ich jetzt in Deinen Kopf schauen, woran Du gerade denkst. Genau, überleg mal, was Ihr alles veranstaltet, was Euren Kunden nicht weiter bringt. Und was davon kannst Du Morgen gleich abschaffen?

Eine Stelle, an der viel unnütze Reibung entsteht ist die Schnittstellen zwischen den einzelnen Silos. Lass mich das für Dich visualisieren: Stell Dir vor, wir haben einen Dienst Lohnabrechnung. Dieser Dienst stellt dem Kunden alles zur Verfügung, dass er Stunden und Fehlzeiten erfassen, den Lohn abrechnen, alle Sozial-Meldungen durchführen kann und der Nutzer kann sich seine Lohnbescheinigung selbst runterladen.

Das klassische Service-Gespinst

Für die einzelnen Funktionen braucht es einzelne Komponenten. Klassisch gibt es da das ERP-Programm mit seinem Lohnmodul oder ein eigenes Lohnmodul. Dieses wird inkl. der Schnittstellen zur FiBu, Elster und DUEV von Team A betreut. Die Zeiterfassung, Erfassung von Fehlzeiten und die Bereitstellung der Lohnbescheinigung ist eine Webapplikation, also wird das alles vom Webteam / Team B betrieben. Das Portal versendet natürlich auch eMails an die Nutzer. Die Mailserver administriert Team C. Alle drei Teams setzen auf den virtuellen Maschinen aus Team D auf. Das braucht natürlich Storage und Netzwerk.

In der klassischen Organisation achtet jeder darauf, dass sein Spielfeld sauber ist. Ich habe es sowohl als Administrator am Anfang meines beruflichen Weges als auch letztens als CIO erlebt, dass beispielsweise die Kollegen von den Mailservern darauf bestanden, dass „ihr Exchange“ läuft, aber das die Applikation oder das Portal keine Mail versenden konnte, war ihnen fürchterlich egal.
Und wenn alles nichts hilft, dann ist in der Regel das Netzwerk schuld, wenn es nicht funktioniert.

Für alle, die so drauf sind, habe ich eine schlechte Nachricht: Dem Kunden ist es fürchterlich egal, was genau nicht funktioniert – wenn die Mitarbeiter keine Benachrichtigung über den neuen Lohnzettel bekommen, dann ist das Mist.

Diese beschriebene Reibung zwischen Team A und B auf der einen und Team C auf der anderen Seite gibt es nicht nur im Fehlerfall. Nein, die gibt es schon viel früher beim Design des Service. Da braucht die Applikation vielleicht ein POP3-Konto und das gibt es nicht, weil der Mailadmin nur IMAP macht. Er hat sicher gute Gründe dafür, allerdings bringt es den Service Lohnabrechnung kein Stück weiter. Da kann man auch wunderbar viele Stunden an kostbarere Lebenszeit versenken, um zu einer Lösung zu kommen.

Ich fange jetzt gar nicht an darüber zu sprechen, wie die Vereinbarung und Auswertung von SLAs in diesem Umfeld läuft.

Das ist alles nur noch zu toppen, wenn einzelne Teams noch zu unterschiedlichen Abteilungen gehören. Da gestaltet sich die Kommunikation meist noch viel schwieriger.

Wie konnte es soweit kommen?

Warum ist das so?

Ich glaube es gibt einen wesentlichen Grund: Die fehlende Verantwortung für das Ergebnis!

Zwei böse Worte in einem Satz: Verantwortung und Ergebnis. Was meine ich damit? Was ist das Ergebnis?

Das ist eigentlich leicht beantwortet – wenn wir es vom Kunden aus sehen. Das Ergebnis des Service Lohnabrechnung ist aus Kundensicht:

• Mitarbeiter des Unternehmens bekommen zuverlässig Ihr Lohn und Gehalt
• alle notwendigen Meldungen an Finanzamt und Sozialträger werden fristgerecht ausgeführt und so Strafen vermieden
• Abrechnung ist korrekt, d.h. Mitarbeiter können ihre Arbeits- und Fehlzeitenzeiten erfassen
• Aufwand und Kosten sind gering, d.h. Mitarbeiter können ihre Lohnbescheinigung selbst runterladen

Sprechen wir von einem erwartetem Ergebnis oder Nutzen, dann müssen wir das immer aus Sicht des Kunden sehen.

Der zweite Teil ist die Verantwortung – die Verantwortung, dass das Ergebnis auch entsprechend geliefert wird. Und zwar Ende zu Ende. Was das bedeutet, dazu gleich.

Wo bleibt der Kunde?

Lass uns bitte noch kurz beim Ergebnis bleiben. Das heißt, wir dürfen uns schon ganz am Anfang damit beschäftigen, was der Nutzen eines Service für den Kunden ist. Um das zu können, müssen wir wissen was der Kunde ist. Damit wir mit ihm sprechen können. Denn den Nutzen findest Du am besten im Gespräch raus.

Ich setzte dazu die IT-Service-Canvas ein. Gemeinsam mit dem Kunden gehen wir die ersten Felder durch. Dadurch lernt das Team sehr viel über den Kunden. Wir müssen nicht mit Annahmen arbeiten, sondern können uns auf gesicherte Fakten stützen. Das ist ein riesiger Vorteil für Dich.

Die IT-Service-Canvas hilft Dir, Dich auf Nutzen und das durch den Kunden erwartete Ergebnis zu  fokussieren. Probier’s einfach mal aus. Du kannst Dir die IT-Service-Canvas hier kostenlos runterladen:

 

Kommen wir zurück zur Verantwortung. Ich sprach davon, dass es eine Ende-zu-Ende-Verantwortung geben muss.

Ich drücke es jetzt mal ganz platt aus, was das bedeutet: Ich als Verantwortlicher des Services kann mich nicht darauf zurückziehen, dass der Fehler in einem anderen Team liegt. Nein, ich bin über die komplette Leistungskette dafür verantwortlich, dass es funktioniert. Egal ob die Komponente in meinem Team, in einem anderen Team, einer anderen Abteilung oder bei einem externen Provider produziert wird.

Der Service-Owner

Diesen Verantwortlichen nenne ich Service-Owner. Und dieser ist verantwortlich, dass alle internen und externen Lieferanten ihren Beitrag ordentlich liefern.

Nochmal einen kurzen Schritt zurück: Der Service Owner ist verantwortlich für eine Leistung, die nicht komplett in seinem Team produziert wird. Lass Dir das mal durch den Kopf gehen. Was würde das in Deiner Organisation bedeuten?

Ich höre jetzt im Servicekatalog-Bootcamp oder bei meinen Kunden: „Das geht bei uns nicht.“

Ja, das hört sich für viele im ersten Moment echt revolutionär an. Anders kann es meiner Meinung  nach nicht funktionieren. Frei nach dem Motto: Es kann nur einen geben.

Lass mir Dir an einem Beispiel zeigen was passiert, wenn es diesen Highlander nicht gibt: Stell Dir vor Deine IT-Abteilung ist leidlich groß und es gibt ein Team für Softwareverteilung, Telefonie, eMail und den Arbeitsplatz.
Nun bekommt das Telefonie-Team den Auftrag eine neue Telefonanlage zu beschaffen. Bisher gibt es klassische Telefonie im Haus und zusätzlich einen Skype-for-Business.

Aus der Praxis – wenn der Service Owner fehlt

Die Telefoniekollegen gehen hin und beschaffen nach bestem Wissen und Gewissen eine neue VoIP-Anlage. Die wird installiert, getestet und der Rollout steht an. Ach ja, und Skype-for-Business braucht es ja nun nicht mehr, da die Anlage selber eine Präsenzfunktion mitbringt.

Jetzt kommt es zum Rollout. Es passieren zwei Dinge:

1. die Applikation der Telefonanlage läuft nur schlecht auf den Terminalservern und auf bestimmten Clients gar nicht
2. die Nutzer gehen auf die Barrikaden weil sie nun keinen Chat und keine Funktion zum Bildschirmteilen mehr haben.

Ein realer Fall. Was ist passiert: Die Telefoner haben sicher das beste Gerät besorgt – fürs Telefonieren. Sie haben sich nicht damit beschäftigt, was das gewünschte Ergebnis für den Kunden sein soll. Zusätzlich haben sie nicht alle Szenarien des Betriebs der Clientapplikation bedacht und getestet.

Warum ist das passiert? Weil die Verantwortung an der Abteilungsgrenze aufgehört hat. Telefonieren können die Menschen und damit ist doch gut. Es fehlte in diesem Fall einfach an einem Service-Owner für den Service Arbeitsplatz. Unter der Annahme, dass Telefonie ein Teil des Arbeitsplatzes ist, hätte er dafür sorgen dürfen, dass beide Probleme nicht auftreten.

Er hätte das auch gekonnt, denn er weiß welches Ergebnis die Kunden erwarten. Er weiß auch, in welchen Varianten der Arbeitsplatz bereitgestellt wird.

Es hätte alles vermieden werden können, wenn es eine klare Verantwortung für ein, vom Kunden erwartetes, Ergebnis gegeben hätte. Es fehlt einfach der Service-Owner.

Das ist keine gute Idee!

Nachdem geleugnet wurde, dass es in der eigenen Organisation geht, eine Rolle wie den Service-Owner zu etablieren, folgt meist diese Reaktion: Das muss ja dann eine Führungskraft sein. Und wenn die zuliefernden Teams in unterschiedlichen Abteilungen sind, dann kann das kein Teamleiter sein, sondern muss ein Abteilungsleiter sein oder noch besser einer oben drüber. Damit die beiden Abteilungsleiter sich nicht zu sehr streiten.

Aus meiner Sicht keine gute Idee! Alle drei Punkte nicht.

Ich war Führungskraft. Als gute Führungskraft delegiere ich so viel wie möglich an meine Kollegen. Meine Aufgabe ist es, am Team und am eigenen Geschäftsmodell zu arbeiten. Wenn ich schon die Arbeit delegiere, dann gehört es in meiner Welt unmittelbar dazu, dass ich auch die Verantwortung und die Rechte delegiere. Was hindert mich jetzt daran, diesem Mitarbeiter die Rolle des Service-Owners mit allen Rechten und Pflichten offiziell zu geben?

Verantwortung darf dort „aufgehangen“ sein, wo sie am besten ausgefüllt werden kann. Und das ist nicht der Teamleiter oder der Abteilungsleiter – glaub mir.

Ein Einschränkung: Bist Du aufgrund der Struktur und Größe Deiner IT ein sehr operativer Teamleiter, dann kannst Du schon den einen oder anderen Service als Service-Owner betreuen. Aber nur dann.

Ermächtigt die Mitarbeiter!

Ich bin mir bewusst, dass vor allem der Teil mit der Rolle und Verantwortung in vielen Organisationen ein super Sprengstoff ist. Ich bin mir sicher, dass es mit einem Service-Owner, der quer zur Aufbauorganisation liegt, wesentlich besser geht.

Du wirst über kurz oder sehr kurz nicht daran vorbei kommen, den Kunden in den Mittelpunkt der IT zu stellen. Dazu ist es notwendig die interne Verschwendung auf ein notwendiges Minimum zu beschränken.
Der Service-Owner kann dazu einen sehr großen Beitrag leisten. Steht das Ergebnis für den Kunden und nicht die Interessen einzelnen Abteilungen und Führungskräfte im Mittelpunkt, dann flutscht es besser!

Um Dir den Einstieg in die Diskussion in Deiner Organisation zu erleichtern, habe ich für Dich eine Stellenbeschreibung für einen Service-Owner vorbereitet. Sieh die bitte, als Anregung für eine intensive Beschäftigung damit, was der Service-Owner in Deiner Organisation für Verantwortung und Aufgaben hat. Daraus kannst Du dann ableiten, welche Rechte er benötigt.

Du findest den Download hier:

Zusätzlich enthält der Download auch einen Stellenbeschreibung für die Rolle des Service Managers.

Ich möchte Dir zum Abschluss noch einige Fragen mitgeben, die Dir helfen sollen, das gehörte auf Deine Organisation zu adaptieren:

Stell Dir vor, Du hast vor einem Jahr für jeden Service einen Service-Owner etabliert, was hat sich in der Zusammenarbeit innerhalb Deiner Organisation verändert? Woran merkt der Kunde, dass es den Service-Owner gibt?

Wenn Du Deinem CIO die Rolle des Service-Owners schmackhaft machen möchtest: Was sind die Argumente, die Dir dabei helfen? Welche Vorwände und Einwände wird Dein CIO haben?

Gern kannst Du mir Deine Gedanken in den Kommentaren oder per eMail mitteilen.