0

Was Du wissen musst, um die richtigen Services anzubieten.

Du suchst die richtige "Flughöhe" für Deine Services? Du weißt nicht, was Du in Deinen Servicekatalog schreiben sollst? Dein Servicekatalog quillt über? Alles drei Anzeichen für ein Problem: Du weißt nicht genau wer Dein Kunde ist. Heute beantworte ich dazu eine Leserfrage.

Damit Dein Unternehmen oder Deine IT-Organisation vom Kunden als serviceorientiert wahrgenommen wird, gehört das passende Angebot dazu.

Deine Services können top sein – wenn Sie für den Kunden nicht passen, dann wird er sie nicht gern buchen. Muss er sie buchen, dann wird er keine Freude dabei haben. Egal, wie sehr Du Dich anstrengst.

Genau dieses Problem haben wir in der Beziehung zwischen IT-Organisationen und dem Rest des Unternehmens. Ob Du dieses Problem hast, erkennst Du an folgenden drei Punkten:

1. Die Kunden versuchen Ihren Bedarf an Prozessunterstützung außerhalb des Unternehmens zu decken, obwohl sie verpflichtet sind die Services bei der IT einzukaufen
2. Das Angebot der IT-Organisation ist viel zu umfangreich, als das es jemand Außenstehender überblicken kann
3. Der Kunde versteht bei einem Großteil der Services nicht, warum er diese beziehen muss

Der Wurm muss dem Fisch schmecken

Im Vertrieb lautet ein wichtiger Grundsatz: Nur wenn der Kunde anerkennt, das ein Problem auch wirklich ein Problem für ihn ist, dann hast Du die Chance zu verkaufen.

Das bedeutet: Wenn Du als CIO alle Deine Server bei Dir im Rechenzentrum stehen hast, werden alle möglichen Anbieter zu Dir kommen und Dir erzählen, warum das ein Problem für Dich ist. Sie werden Dir erzählen, dass:

• die RZ-Fläche, Strom, Klima und so weiter viel zu teuer sind
• die Verfügbarkeit in der Cloud wesentlich höher ist
• in der Cloud rund um die Uhr jemand da ist, der den Betrieb und Support sicherstellt
• die bauliche Sicherheit viel größer ist, als in Deinem Serverraum
• Du Ressourcen flexibel buchen kannst und nach Verbrauch abgerechnet wird

Das ist alles richtig. Wenn für Dich keiner der fünf Punkte ein Problem darstellt, dann werden die Anbieter bei Dir nicht verkaufen – egal was sie Dir erzählen. Du hast keinen Handlungsdruck.

In der vorletzten Folge haben wir eine schöne Definition eines Services gefunden: „Services sind Aktivitäten, aus denen Ergebnisse entstehen.“

Was ist das Ergebnis wert?

Mit diesen Ergebnissen verhält es sich genau wie mit dem Problem: Wenn das Ergebnis Deines Service in den Augen des Kunden nicht wertvoll ist, dann wird er den Service nicht nutzen. Er wird nicht verstehen, warum er den Service kaufen muss.

Wenn er es nicht versteht, dann bekommt er ein schlechtes Gefühl. Das führt zu Abwehrreaktionen und belastet Eure gesamte Beziehung. Es entsteht das Gefühl: „Die von der IT haben keine Ahnung was wir machen.“

Mal zurück zu unserer Tankstelle – da kannst Du das sehr gut nachvollziehen: Nach jedem Tankvorgang werden ich gefragt, ob ich eine Wäsche haben möchte. Meist lehne ich dankend ab, da ich warum auch immer keinen Sinn darin sehe.

Am Vorabend meiner Hochzeit war das ganz anders. Da habe ich von mir aus die Wäsche bestellt. Und zwar die teuerste.

In dem Moment war ein so großer Nutzen für mich gegeben, dass Geld egal war.

Übertragen auf unser IT-Geschäft. Der Service Active Directory ist notwendig und sinnvoll. Das Ergebnis der Aktivitäten hat für das Unternehmen einen sehr großen Nutzen: Nur berechtigte Nutzer bekommen Zugriff auf die Daten.

Für die Leiterin der Produktion erschließt sich dieser Nutzen überhaupt nicht. Die erwartet, dass nur berechtigte Personen Zugriff auf das ERP-System bekommen. Wenn Sie sich überhaupt Gedanken darüber macht.

Und so geht das mit einer großen Anzahl der Positionen des heute üblichen Servicekatalogs. Die Kunden erkennen für sich und ihre Arbeitsabläufe keinen Nutzen.

Mal kurz eine Pause: Zur heutigen Folge wurde ich durch ein Mitglied der Servicenerds.Bibliothek inspiriert. Wenn Du Dich für die kostenfreie Bibliothek unter www.servicenerds.de anmeldest, dann bekommst Du unten links ein kleines Popup mit einer Frage. Ich frage Dich nach Deiner momentan größten Herausforderung.

Dazu schrieb das Mitglied: „Die Summe unserer Leistungen in sinnvolle Services bündeln. Wir wollen auf eine richtige Menge hinunterkommen – dagegen stehen Service-Owner, die sich gegen Streichung wehren.“

Darauf versuche ich, heute eine Antwort zu geben. Ich hoffe, meine Aktivitäten erzielen das gewünschte Ergebnis. Auf jeden Fall geben Sie Dir einige Anregungen für den Frühjahrsputz im Servicekatalog.

Sinnvolle Services

Der Fragende geht mit „sinnvolle Services“ schon genau in die richtige Richtung: Services mit einem Ergebnis, welches für den Kunden wertvoll ist.

Das ist auf jeden Fall der richtige Ansatz.

Nun darfst Du die Richtung ändern: Schau Dir das alles aus der Sicht des Kunden an.

„Mach ich doch, ich frage mich doch welche Services für ihn sinnvoll sind“ ist vielleicht jetzt Dein Gedanke.

Wenn ich schaue, welche meiner Services für den Kunden sinnvoll sind, dann kommt der Antrieb aus der Anbietersicht: Ich habe 124 Services definiert und nun muss ich entscheiden, welche davon ich in den Servicekatalog packe, damit der Kunde zufrieden ist.

Das legt einen ganz bestimmten Schwerpunkt. Dieser liegt hier: Wie kann ich mein Produkt so verpacken, dass es der Kunde kauft. Oder in ITIL ausgedrückt: Was sind mein customer-facing services.

Von oben nach unten

Ich möchte, dass Du den anderen Weg wählst: Schau Dir an, wer ist Dein Kunde. Welche Aufgaben hat Dein Kunde und Ergebnisse werden von ihm erwartet. Nicht umsonst sind die ersten beiden Schritte in der IT-Service-Canvas die Prozesse und der Nutzer. Und genau deswegen beginnt OBASHI auch mit den Menschen und Prozessen.

Es steht in dem Moment nicht die IT im Mittelpunkt. Dein Kunde und seine Bedürfnisse sind im Mittelpunkt. Führt mich auf die verkürzte Definition der Serviceorientierung aus der letzten Folge: „Geistige Ausrichtung auf das Dienen“.

Das Dienen beginnt schon ganz am Anfang. Es beginnt in dem Moment, in dem Du Dich entscheidest Services anzubieten.

Ich weiß, das klingt immer ganz einfach, wenn ich das hier im Podcast erzähle. Ist es nicht.

Ich erwische mich immer wieder selber dabei, dass ich genau diese Beschäftigung mit dem Kunden, versuche zu überspringen. Von unten nach oben ist der einfachere Weg. Da muss ich nicht mit jemanden sprechen, der potentiell meine Idee und Angebot ablehnt.

Wenn ich mich erwischt habe, dann geht es ein, zwei oder drei Schritte zurück, um den Kunden wieder in den Mittelpunkt zu stellen.

Das gleiche möchte ich Dir ans Herz legen. Du wirst viel erfolgreicher sein, wenn Deine Services genau die Ergebnisse liefern, die Deinem Kunden nutzen.

Das führt wiederrum zur Anerkennung als Partner auf Augenhöhe. Und dort müssen wir als IT hin. IT wird Kernbestandteil vieler zukünftiger Geschäftsmodelle sein. Dazu braucht es den Partner auf Augenhöhe.

Deinen Kunden lernst Du im Detail am besten kennen, wenn Du Dich mit seinen Prozessen auseinandersetzt.

Für das Institut für digitale Transformation habe ich ein eBook mit dem Titel „Der CIO als Prozessberater“ geschrieben.

Es richtet sich an den IT-Leiter, CIO und andere Verantwortliche interner IT-Organisationen, die es satt haben, folgende Sätze zu hören:

• Wir haben eine Software gekauft, die muss nur noch installiert werden.
• Wir brauchen eine neue Software für das Controlling. Bitte beschaffen Sie diese.
• Wir nutzen den Clouddienst xyz seit vier Monaten, nun muss der endlich mal an unser Directory angebunden werden

Ich schreibe in dem eBook darüber, wie ich in meiner Tätigkeit als CIO mit den Fragen umgehe. Du lernst im Detail die ersten 4 Schritte meines Vorgehens kennen. Das eBook findest Du unter https://transformation-it.de/d/eBook-Prozessberater

Kunden kennenlernen

Meiner Meinung nach geht nichts daran vorbei, dass es im Unternehmen eine Verantwortung für die Digitalisierung, die Prozesse und die IT gibt. Früher nannte man das glaube ich Betriebsorganisation. Also, zurück zu den Anfängen.

Ich möchte das Gesagte für Dich zusammenfassen:

• Bietest Du Services an, dann beschäftige Dich zuerst mit Kunden:
  • Wer ist Dein Kunde?
  • In welchen Prozessen arbeitet er?
  • Welche Ergebnisse werden von ihm erwartet?
  • Welche Unterstützung / Ergebnisse erwartet er von der IT?
• Baue Dein Serviceportfolio auf Basis dieser Erkenntnisse auf:
  • Biete nur Services an, die dem Kunden die gewünschten Ergebnisse liefern – also einen Nutzen haben.
  • Deine Servicebeschreibung darf ganz klar den Nutzen aus Sicht des Kunden wiedergeben. Technische Parameter sind zweitrangig.
• Abstrahiere soweit wie möglich, um die Zahl der Services zu minimieren. (Dazu später noch mehr)
• Nutze Werkzeuge und Hilfsmittel, die Dir helfen, den Kunden immer im Blick zu haben:
  • Für die Definition Deiner Services kannst Du die IT-Service-Canvas nutzen. Die führt Dich Schritt für Schritt durch den Prozess und Du kannst dabei nichts vergessen. 
  • Für den Aufbau Deiner Servicearchitektur und die Berechnung der Gestehungskosten empfehle ich Dir OBASHI als Werkzeug. 

Ein Service ist ein Service ist ein Service!

Lass uns jetzt noch zum zweiten Teil der Frage kommen: „Wir wollen auf eine richtige Menge hinunterkommen – dagegen stehen Service-Owner, die sich gegen Streichung wehren.“

Ja klar. Wenn ein Service nicht mehr als Service im Servicekatalog auftaucht, dann bin ich als Service-Owner plötzlich nicht mehr wichtig.

Ist schon Mist, wenn es in der IT-Abteilung mal wieder menschelt.

Spaß beiseite: In den Augen der Service Owner sinkt deren Bedeutung. Das ruft Widerstand hervor und sie werden alles versuchen, um Deine Veränderung zu verhindern oder wenigsten schlecht zu machen.

Hier gibt es aus meiner Sicht zwei Aspekte: den Rationalen und den Menschlichen.

Menschlich gesehen, brauchst Du hier den Werkzeugkasten des Change-Managements. Denn es ist in den Augen der Menschen eine Veränderung ihres Status in der Organisation.

Das Ziel: Die Service-Owner dürfen von sich aus erkennen, dass die Wichtigkeit Ihrer Aufgabe nicht davon abhängt, ob der Service im Katalog auftaucht oder nicht.

Diesem Satz liegt eine Annahme zu Grunde: Die Anzahl der Services wird kaum abnehmen. Der Service Active Directory wird zwar nicht mehr in Deinem Servicekatalog auftauchen, ihn wird es auf jeden Fall weiter als Service geben.

2 Klassen

Wenn Du im Servicekatalog nur noch das anbieten möchtest, was dem Kunden einen direkten Nutzen bringt, dann darfst Du beginnen Deine Services zu klassifizieren:

Services, die im Katalog stehen und Services, die nicht im Katalog stehen.

Auch wenn ein Service nicht mehr im Katalog steht, ist er immer noch ein Service!

Diesen Gedankenschluss, dass nur das ein Service ist, was im Katalog steht, darfst Du unbedingt vermeiden. Nicht nur, weil die Service-Owner sonst Probleme machen.

Das wiederspricht zu 100% dem, was ich unter Servicearchitektur verstehe.

Jetzt darf ich aufpassen, dass ich mich nicht verheddere. Die Gedanken überschlagen sich gerade.

Einen Schritt zurück: Es gibt grundsätzlich zwei Arten von Diensten:

1. Services, die vom Kunden direkt konsumiert werden – ich nenne diese Business Services; ITIL spricht von customer-facing services
2. Services, die ich brauche, um die Business Services bereitzustellen, dass sind in meiner Sprache die IT-Services; ITIL spricht von support services; viele Organisationen von technischen Diensten

Du hast also zwei Kategorien von Diensten. Der einzige Unterschied: Business Services stehen im Servicekatalog, IT-Services nicht. Alles andere ist gleich! Alle Services haben einen Service-Owner, eine Servicebeschreibung usw.

Was Deine Business Services genau sind, das hängt von Deinem Kunden ab.

Ist Dein Kunde ein interne Entwicklungsabteilung, dann sind Deine Business Services sowas wie „virtueller Server Größe M“ oder „100 TB SSD Speicher“. Services, die in meiner Welt auf jeden Fall IT-Services sind.

Also schau Dir vorher Deinen Kunden an. Du erinnerst Dich: Da waren wir vorhin schon mal.

Service-Architektur

Vor einiger Zeit haben wir hier im Podcast über die Rollen der IT gesprochen. Eine der drei Rollen ist der Service Broker.

Was macht dieser? Er nimmt die Anforderungen der Kunden, definiert mit Ihnen den Funktionsumfang eines Services und baut diesen aus vorhandenen Diensten zusammen.

Nur mal so ganz kurz ins Unreine gesprochen. Im Detail hörst Du das in der Folge 52. 

Die Aussage, die ich heute für meine Argumentation brauche, ist folgende: Ein Service Broker bezieht Services von Lieferanten. Diese setzt er so zusammen, dass das gewünschte Ergebnis rauskommt.

Um, wie in der letzten Folge, ein Beispiel aus meinem Blog zu bemühen: Erstellst Du Dir den kostenlosen Account für die Servicenerds-Bibliothek, bekommst Du in der linken unteren Ecke eine Frage angezeigt. Für diese Frage nutze ich ein WordPressplugin, welches wiederrum auf einem Service aus dem Internet beruht.

Kann jeder einkaufen und sich individuell in Farbe und der Frage gestalten, wie er es möchte. So bin ich an die Frage für die heutige Folge gekommen.

Genau das ist die Aufgabe des Service Broker. Er nimmt die Anforderungen der Kunden und baut eine Servicearchitektur.

Diese besteht aus einzelnen Bausteinen – wie Lego. Idealerweise werden vorhandene Bausteine wiederverwendet. Ist dies nicht möglich, werden neue Bausteine von Lieferanten bezogen.

Die Bausteine sind standardisiert. Die Art und Weise, wie Du als Service Broker diese mit einander verknüpfst und konfigurierst, die führen zu dem gewünschten Ergebnis.

Einer dieser Lieferanten kann Deine eigene IT sein. Und damit sind wir wieder bei den Service-Ownern.

Im Prinzip ändert sich für die Service-Owner nur der Kunde. Der Kunde  ist nicht mehr die Fachabteilung. Der Kunde ist jetzt die interne IT selbst.

Also endlich ein Kunde, der den Wert eines funktionierenden Active Directory Service zu schätzen weiß.

Zusammenfassung

Unterscheide klar zwischen Business Services und IT-Services. Business Services sind die Dienste, die das gewünschte Ergebnis für den Kunden erzeugen.

IT-Services sind die Bausteine, die Du verwendest, um die Business Services zu erstellen.

Beide Service-Kategorien sind für Dich als Service Broker gleich wertvoll.

Welche Business Services Du anbietest, dass entscheidet Dein Kunde. Achte darauf, dass es nur Services sind, die wirklich Ergebnisse für den Kunden erzeugen. Also einen Nutzen haben.