Am Anfang steht die Veränderung

ITIL gibt es nun schon in drei Versionen. Man sagt, eine vierte Version sei in Arbeit. Das ist ein guter Zeitpunkt, um über die Zukunft dieses Frameworks nachzudenken.

Nachdem ich vor einigen Jahren eine ausführliche deutsche Zusammenfassung über alle ITIL Prozesse der Version 2 und 3 geschrieben und mich weiter mit dem Thema Service Management befasst habe, hat sich die IT Welt verändert. Die Frage, die mich seither beschäftigt ist, was kommt nach ITIL V3? Oder braucht es überhaupt etwas Neues?

Ob Ihr am Ende diese Frage beantwortet habt, lasse ich offen. Ich habe gerade erst eben begonnen, meine Gedanken zu sortieren und niederzuschreiben. Die Idee dieses Blog ist es, in Abständen von ca. zwei Wochen, je einen weiteren Teil meiner Erkenntnisse zu veröffentlichen. Dabei bin ich natürlich gespannt auf Euer Feedback. Ich kann Euch versichern, wir werden nicht immer gleicher Meinung sein. Aber man kann im Leben nicht immer Allen gerecht werden.

ITIL ist out – es lebe Service Management

Vielleicht denkt Ihr jetzt, das ist ja dasselbe. ITIL beschreibt doch alle IT Service Management Prozesse. Was braucht es denn noch mehr?

Aber genau da beginnt das Problem. ITIL beschreibt wirklich die Service Management Prozesse.

Prozesse sind nötig, aber nicht hinreichend.

Um die Zukunft zu verstehen, müssen wir die Vergangenheit kennen. In den Anfangszeiten der IT herrschte Chaos. Könige in Form von Computerspezialisten beherrschten eine IT-Welt, in der es eine unendliche Menge finanzieller Ressourcen zu geben schien. Doch mit der Zeit gab es einzelne IT-Inseln, auf denen eine gewisse Struktur zu wachsen begann. ITIL V1 versuchte diese einzufangen und hat sie in einer Bibliothek von Büchern beschrieben. Diese ITIL Version hatte aber noch keinen Erfolg. Erst als die Entwicklung schneller wurde, als es die Könige verkraften konnten, wuchs der Wille, über den Hag des eigenen Königreichs zu blicken. Aus diesem Bestreben wurde ITIL V2 entwickelt. Darin wurden die zehn wichtigsten Prozesse und Funktionen beschrieben und die weite Welt begann es zu glauben. Alle IT Firmen und Abteilungen, die etwas von sich hielten, studierten diese Bücher und versuchten, so viel wie möglich in der eigenen IT zu implementieren. Und wenn ich sage, so viel wie möglich, so meine ich eigentlich ganz wenig. Nicht etwa, weil sie dies gegen ihren Willen tun sollten, sondern eher weil ITIL das „Wie es zu tun ist“ nicht dokumentierte. ITIL beschreibt auch heute noch nur ein Idealbild, das sich so nicht anwenden lässt. So musste es für jede Firma auf deren spezielle Bedürfnisse und Situationen zugeschnitten werden. Aus diesem Mako an Wissen und Erfahrung wuchs ein Heer von Beratern und Schulungsfirmen. Bald stellte man fest, dass noch viel zu wenig beschrieben war und es entstanden aus den zwei Büchern der Version 2 fünf Bücher für die Version 3. Ich möchte nicht etwa bestreiten, dass es diese fünf Bücher braucht. Nein, im Gegenteil, ich denke, sie ergeben eine recht gute Übersicht über die meisten Themen. Zudem beschreiben sie in einer guten Form, wie ein Service über den ganze Lebenszyklus betrieben und bewirtschaftet werden kann. Schade ist nur, dass ITIL den Mief des Prozessframeworks nicht losgeworden ist. Der Begriff ITIL ist auch heute noch ein Synonym für Prozesse. Und zwar Prozesse in einer Form und Detaillierung, die sich mit wenigen Ausnahmen in dieser Detaillierung nicht implementieren lassen. Dazu kommt, dass die eigentliche Bedeutung der Abkürzung IT Infrastruktur Bibliothek bedeutet. Daher ist es an der Zeit, über die Nachfolge von ITIL nachzudenken. Es muss etwas sein, das zwar die Vorteile der Prozesse mitnimmt, sich aber auf die eigentlichen Kundenbedürfnisse konzentriert. Ich nenne es IT Service Management – im vollen Wissen, dass auch dieser Begriff heute schon recht abgegriffen ist.

Der Begriff XaaS beschreibt den Trend recht schön. Er steht für „Etwas als Service“ und betont damit, dass der Service künftig im Vordergrund stehen wird.

Der nächste Blog wird das Thema „IT Maturität“ haben.

Reife und Erkenntnis beginnt im Kopf

Im letzten Blog habe ich aufgezeigt, dass die IT sich mehr und mehr in Richtung Service Management entwickeln wird (und muss). Diesmal geht es darum, diese Entwicklung auf eine Achse zu legen und sie in die bekannten Modelle einzubetten.

Eigentlich kann man die Entwicklung der IT in verschiedene Phasen gliedern. Die Königreiche in den Anfängen bilden die eigentliche Startphase. Nichts war übergreifend definiert. Alles war von den verschiedenen Königen der IT abhängig. Die finanziellen Ressourcen schienen unerschöpflich zu sein. Uns so entwickelte sich die IT zu einer Goldgrube. Eine Grube, in die man das Gold hineinwerfen konnte. Je mehr die Firmen aber von den eigenen Daten in elektronischer Form abhängig wurden, umso mehr stieg der Druck nach Ordnung. Die Qualität der eingekauften IT-Dienstleitungen war so schlecht, dass die Britische Regierungsbehörde in den 1980er den Auftrag erteilte, Best Praxis’s zusammenzutragen.

Erst in den Jahren um die Millennium-Zeit wurden die Firmen unter dem Druck der Anforderungen immer strukturierter und begannen Konzepte, Schnittstellen und erste Prozesse nach ITIL V2 zu implementieren. Diese Erkenntnis, die Qualität durch standardisierte Abläufe zu optimieren, kann man durchaus als Maturitätsstufe 1 bezeichnen. In einem CMM Reifegrad würde das in etwa dem Level 1 „performed“ entsprechen. Hier waren einige Firmen sicher auch schon auf dem Level 2 „managed“.

Fünf bis zehn Jahre später kommt nun mit ITIL V3 eine weitere Phase dazu. Die Sicht auf die IT wird ganzheitlicher, die Prozesse werden ausgereifter und der Kostendruck nimmt zu. Man erkennt, dass die finanziellen Ressourcen nicht unendlich sind und muss auf sehr schmervolle Weise den, in der Vergangenheit „angefressenen“ Speck“, wieder abtrainieren. Dazu werden auch Methoden wie SixSigma und Lean eingesetzt. Nach CMM könnte man das durchaus als Level 3 „established“ oder in einigen Firmen sogar als Level 4 „predictable“ bezeichnen. Das Problem ist nun, dass die Prozesse zwar etabliert sind und vorhersehbare Resultate mit guter Qualität liefern, dies aber immer mehr von den Anforderungen der Kunden abweicht. Denn vor lauter Genauigkeit in der Abwicklung der Prozesse geht der Service für den Kunden verloren.

Da ein Prozess nie perfekt genug sein kann, wird die entscheidende letzte Maturitätsstufe „optimized“ nie erreicht. Aber erst diese Stufe beinhaltet die Vernetzung und die Kundenorientierung.

Die Zeit zum Umdenken ist gekommen

IT Infrastruktur ist daran „Commodity“ zu werden. Sie wird zur Ware, die wie Strom einfach irgendwo in der weiten Welt eingekauft werden kann. Der Kunde kann das selbst einkaufen. Dazu braucht er keine IT-Abteilung oder IT Firma. Diese müssen, wenn sie überleben wollen, einen Mehrwert für den Kunden erzeugen. Das ist ein Prozess des Umdenkens. Zu realisieren, dass man so keine Existenzberechtigung mehr hat, ist sehr schmerzvoll.

Einige von Euch kennen ev. das Buch von Spencer Johnson mit dem Titel Who Moved My Chees? Wenn nicht, kann ich es wärmstens empfehlen. Es handelt von einer Mäusefamilie, die ihr Futter immer am selben Ort findet. Dabei realisiert sie nicht, dass es immer weniger wird und fragt sich zuletzt, wer es gestohlen hat. Durch die Veränderungen in der IT wird es Euch ähnlich ergehen. Die Welt ändert sich zu Euren Ungunsten.

Ihr müsst euch euren Käse künftig wo anders suchen

Darum befasst sich der nächste Blog mit dem Thema: „Was will der Kunde?“

Was braucht der Kunde ?

Um diese Frage zu beantworten, muss man sich überlegen, in welcher Situation sich der Kunde heute befindet. Der Kunde möchte seine Geschäftsprozesse möglichst optimal abwickeln. Dazu ist er auf die Unterstützung der IT angewiesen. Das heisst, er benötigt IT-Services, die seine Business-Services unterstützen. Die wichtigsten Erfolgsfaktoren sind dabei neben den Kosten, die Funktion und die Verfügbarkeit des Service. Damit heisst die Frage,

stiftet der IT Service dem Kunden mehr Nutzen als er kostet?

Dabei ist der Nutzen nicht das, was die IT in einen Service hineinbringt, sondern das, was der Kunde herausnimmt und bereit ist zu bezahlen.

Funktionen

Die funktionalen Anforderungen werden meist akribisch erfasst. Immer häufiger werden aber Standardprodukte eingekauft, die nur unvollständig mit dem Bündel der Anforderungen übereinstimmen. Sollen nun die Geschäftsprozesse dem eingekauften Produkt angepasst werden, oder soll das Produkt so erweitert oder abgeändert werden, dass es die Anforderungen erfüllt? Die Zeiten haben sich auch bei dieser Frage geändert. Früher war man der Meinung, dass zuerst der Prozess definiert werden muss und dann ein Produkt gewählt wird, das diesem entspricht. Oder das Produkt dem Prozess entsprechend angepasst werden muss. „Requirement Engineering“ ist dabei das grosse Schlagwort. Das führt dann zu jahrelangen Entwicklungsprojekten, die am Ende ein Resultat liefern, das weder update-fähig noch flexibel ist. Der Kunde hat zwar alle seine Wünsche erfüllt, ist aber dennoch nicht glücklich. Denn er hat sehr viel Geld in etwas investiert, das sich bei jeder Veränderung der Umwelt als Hindernis für sein Geschäft herausstellt. Vor allem aus öffentlichen Verwaltungen werden immer wieder IT-Projekte bekannt, die zwei- oder mehrstellige Millionenbeträge verschlingen und nie zu einem Ende kommen. In der Privatwirtschaft werden solche Projekte einfach nicht bekannt, sind aber sicher auch vorhanden.

So haben immer mehr Firmen begonnen, ihre Geschäftsprozesse den SW-Produkten anzupassen. Aber auch das hat seine Nachteile. Wenn ein globaler Player wie SAP, Oracle oder Microsoft dem Business vorgeben, wie sie ihre Geschäftsprozesse organisieren müssen, können sich diese nicht mehr gegeneinander abgrenzen. Zudem werden die Firmen zum Spielball der SW-Hersteller und sind fast nicht mehr in der Lage, ein eingeführtes Produkt zu wechseln.

Das eigentliche Hauptproblem ist aber weder das Requirement Engineering noch das Anpassen der Business-Prozesse an die Funktionen der Standardsoftware.

Das Problem ist die fehlende Agilität

IT-Projekte sind heute viel langsamer als die Entwicklung der Bedürfnisse des Kunden. Es ist damit gar nicht möglich, die Anforderungen zu erfassen, die bei der Einführung des IT-Services erwünscht sind, da sie zu Anfang des Projekts gar noch nicht bekannt sind. Werden Standardprodukte eingesetzt und die Business-Prozesse daran ausgerichtet, so gibt der Herstellen den Takt der Änderung vor. Das kann nur bei allgemein bekannten, standardisierten und stabilen Business-Prozessen zum Erfolg führen. Inzwischen versuchen neue Projektmethoden wie „SCRUM“ dieses Dilemma zu lösen und schaffen damit gerade das nächste Dilemma. Auf dieses werde ich in einem späteren Blog eingehen.

Verfügbarkeit - Garantie

Die beste Funktion bringt nur dann Nutzen,
wenn sie zur rechten Zeit in genügender Qualität und Menge zur Verfügung steht.

Das heisst, der Benutzer muss den IT Service dann nutzen können, wenn er ihn für seine Arbeit braucht. Damit wird die Verfügbarkeit und die Performance zu einer zusätzlichen Anforderung. Das rechte Mass zu finden ist jedoch sehr schwierig. Eine 100%tige Verfügbarkeit und eine unendliche Performance ist nicht bezahlbar (und auch nicht machbar). Jede Steigerung in diesem Bereich hat eine Erhöhung der Kosten zu Folge und muss sich mit einem entsprechenden Nutzen für das Business rechtfertigen lassen.

Abb. 1:          Kosten der Verfügbarkeit

Bei diesem Thema werden oft sie Sicherheit und die Kontinuität vergessen. Wenn der IT Service zu wenig sicher ist, verlieren die Daten an Wert, oder stehen gar nicht zur Verfügung. Auch können durch externe Einflüsse ganze Rechenzentren ausfallen und für längere Zeit nicht mehr zur Verfügung stehen. Im schlimmsten Fall kann das das Aus für eine Firma bedeuten.

ITIL beschreibt alle diese Themen als Prozesse in der Phase Service Design. Nur sind das eigentlich keine Prozesse sondern eher Konzepte oder Methoden.

Abb. 2:          Nutzen für das Business

Ich möchte an dieser Stelle noch auf zwei Bilder verweisen, die bereits in ITIL V3 Verwendung finden, aber leider viel zu wenig beachtet werden. Dem Block der funktionalen Anforderungen wird oft viel Beachtung geschenkt und dabei vergessen, dass die Funktionen dem Business nur dann Nutzen bringen, wenn die „nicht funktionalen“ Anforderungen den Service genügend garantieren können.

 

Abb. 3:            IT- und Business-Nutzen

Für das Business ist es entscheidend, dass die Business-Services unterstützt werden. Während das für die IT keinen grossen zusätzlichen Nutzen mehr bedeutet. Entscheidend für den Erfolg der IT ist zuletzt aber das Business. Daher sollte alles daran gesetzt werden, dieses Ziel nicht aus den Augen zu verlieren.

 

Damit sind die Erwartungen des Kunden bezüglich der Vollständigkeit eins Services besser bekannt. Das ist aber noch lange nicht das höchste der Gefühle.

Im nächsten Blog gehe ich aber wieder zurück zu den Prozessen. Genauer zum „verkehrten Prozessverständnis“.

Verkehrte Welt der Prozessmaturität

Um einen Prozess in seiner Maturität zu bestimmen wird oft das CMM (Capability Maturity Model) verwendet. Dieses beschreibt in fünf Stufen den Reifegrad eines Prozesses.

Level 1	performed (Voraus­setzungen)	Einzelne Schritte eines Prozesses werden ausgeführt. Die Schritte sind nicht festgelegt und werden ungeplant variiert. In der Summe entstehen gewünschte Ergebnisse, ohne eine Wiederholbarkeit des Ablaufes und der Ergebnisse sicherzustellen.
Level 2	managed (Zielsetzung und Prozess)	Es existieren definierte Prozessfolgen, die angewendet werden. Die Prozesse sind nicht aufeinander abgestimmt, das Bewusstsein für einen Prozess als Arbeitsgrundlage ist nicht durchgehend präsent und Veränderungen sind das Ergebnis aus „trial and error“
Level 3	established (Integration und Outputs)	Die Prozesse werden auf der Basis geplanter strukturierter und dokumentierter Beschreibungen gelebt. Die Prozesse sind aufeinander abgestimmt weil auch Rollen und Verantwortlichkeiten klar geregelt sind. Es ist eine Struktur vorhanden, in die Messkriterien zur Messung des Erfolges eingefügt werden können.
Level 4	predictable (Qualitäts­kontrolle und Mgmt Reports)	Für die eingeführten Prozesse gibt es Qualitätsziele, die planmäßig gemessen werden. Auf dieser Basis sind Verbesserungen des Prozesses möglich. Das Ergebnis (Output) des Prozesses ist vorhersehbar und hat eine gute Qualität.
Level 5	optimized (Vernetzung und Kundenorien­tierung)	Es findet eine geplante, kontinuierliche Verbesserung der Prozesse unter den sich weiterentwickelnden Unternehmensziele statt. Die Stärken der Prozesse sind transparent. Es besteht eine hohe Flexibilität, da die Prozesse schnell auf neue Bedürfnisse (der Kunden) ausgerichtet werden können.

 

Das Problem bei diesem Modell besteht darin, dass über vier Level der Prozess optimiert wird, bevor er beim fünften Level auf den Kunden ausgerichtet und laufend seinen Bedürfnissen angepasst wird. Die meisten Firmen erreichen diesen fünften Level nie und verlieren sich in Definitionen und Rollen. Der Prozess wird immer detaillierter und ausgeklügelter. Das führt unweigerlich zu mehr Formalismus und Trägheit. Gerade das Gegenteil von dem, was der Kunde erwartet und auch von dem, was ein guter Prozess sein sollte. Diese Entwicklung wird noch unterstützt von der internen oder externen Revision. Diese prüft und verlangt eine lückenlose Dokumentation des Prozesses, die belegt, dass dieser ohne Ausnahme korrekt durchgeführt wird. Jede Abweichung wird als potentielles Risiko eingestuft. Und so werden alle Schlupflöcher gestopft, bis der Prozess nichts mehr mit den Anforderungen des Kunden zu tun hat. Wir verlieren damit nicht nur unsere Kunden, sondern auch unsere Mitarbeiter und teilweise auch das Management. Denn alle beginnen zu verstehen, dass diese Entwicklung in die falsche Richtung geht.

Denn ein Prozess darf nur ein Ziel haben: Er muss uns dabei unterstützen, unserem Kunden einen noch besseren, flexibleren und günstigeren Service zur Verfügung zu stellen.

Das neue Prozessverständnis

Es braucht nicht mehr Prozesse sondern bessere. Die Maturität eines Prozesses darf nicht daran gemessen werden, wie lückenlos und perfekt er abläuft, sondern damit, wie viel Kundennutzen er stiftet. Jeder Prozessschritt muss dabei eine Wertschöpfung haben. Der Kunde erwartet zwar als Ergebnis ein Resultat mit guter Qualität. Er erwartet es aber auch innert nützlicher Frist, zu einem günstigen Preis und ohne Formalismus. Prozesse die langsam laufen sind ineffizient, teuer und kundenfern. Ein Prozess, der mehr als zehn Prozessschritte enthält oder, an dem mehr als drei bis vier Teams beteiligt sind kann selten effizient sein. Die Schlüsselgrösse dafür ist die „Durchlaufeffizienz“.

Das ist das Verhältnis des Arbeitsaufwandes für die wertschöpfenden Tätigkeiten zur Durchlaufzeit. Bitte erschrecken Sie nicht, wenn sie Werte kleiner ein Prozent erhalten. Nicht selten wird für eine Tätigkeit, die nicht mehr als 30 Minuten dauert eine Woche benötigt. Das liegt daran, dass bei jedem Prozessschritt ein Arbeitsvorrat vorhanden ist. Die Mitarbeiter, die diesen Schritt ausführen, sollen ja immer genügend Arbeit haben. Auf diese Weise können wir zwar die Teams optimal auslasten, jedoch werden die Prozesse unnötig verzögert.

Das sind alles nette Worte. Aber wie lässt sich das denn umsetzen? Diesem Thema werde ich im nächsten Blog nachgehen. Ich kann Ihnen aber jetzt schon verraten:

„Kompetenz ist der Schlüssel zum Erfolg“

 

Kompetenz ist der Schlüssel zum Erfolg

Im Umgang mit Prozessen und Prozessschritten gibt es ganz verschiedenen Möglichkeiten. Auf der einen Seite kann jeder einzelne Teilschritt so detailliert dokumentiert werden, dass jedermann ihn korrekt ausführen kann. Dies sieht auf den ersten Blick gut aus, reduziert den ausführen Menschen aber zu einer dummen, nicht denkenden Maschine. Es gibt eigentlich keinen Grund, dafür intelligente Menschen zu missbrauchen. In einigen Kulturen ist das daher auch nicht besonders beliebt. Leute die sich für solche Aufgaben eignen, möchten weder denken noch Verantwortung übernehmen. Entsprechend ist oft auch die Qualität des Resultats.

Der „Wie-Prozess“ beschreibt detailliert, wie etwas zu tun ist

denken nicht erwünscht

Als Gegensatz dazu kann man Mitarbeitende als intelligente Wesen betrachten und fördern, so dass sie schon bald mit der nötigen Erfahrung und Kompetenz selbst entscheiden können, wie sie die benötigten Resultate erzielen. In dieser Variante beschreiben wir das „Was“ und weniger das „Wie“.

Der „Was-Prozess“ beschreibt, was als Resultat gefordert wird

mitdenken wird vorausgesetzt

Als Resultat erhalten wir Mitarbeitende, die mitdenken und mitlernen und sich damit auch auf wechselnde Anforderungen einstellen können. Es ist nicht mehr nötig, die Prozessdokumentation in allen Details zu erstellen und laufend allen wandelnden Anforderungen anzupassen. Jedoch muss das geforderte Resultat für alle Beteiligten klar sein. Um einer solchen Aufgabe gewachsen zu sein, braucht es ganz andere Kompetenzen.

Zwei Dimensionen der Kompetenz

Kompetenz kann in zwei Dimensionen ausgedrückt werden. Das eine ist die fachliche und persönliche Fähigkeit des Mitarbeiters. Kompetente Leute haben das Wissen, eine Situation richtige einzuschätzen, richtig zu handeln und ihre Arbeit richtig zu tun. Damit ist die Qualität des Resultats gewährleistet. Die andere Dimension ist die Freiheit, die wir unseren Mittarbeitern zugestehen. Oder anders ausgedrückt, den Rahmen, den wir ihnen geben. Mit welchen Möglichkeiten sind unsere Mitarbeiter ausgestattet? Können sie denn auch tun, was sie in der Lage wären, zu tun?

Ich habe das Bild in vier Bereiche eingeteilt.

• Der blaue Bereich rechts unten sind die reinen Befehlsempfänger. Sie brauchen nicht viel zu wissen und sollen einfach nur ihren Job machen. Solche Tätigkeiten werden in der IT entweder nach Fern-Ost ausgelagert oder automatisiert.

• Viele Firmen hätten aber gerne ihre Mitarbeiter links oben im orangen Bereich. Sie suchen gut ausgebildete Leute und geben ihnen keine Möglichkeiten, ihr Wissen vernünftig einzusetzen. Das ist am Ende ineffizient und zu teuer. Zudem gewöhnen sich die Mitarbeiter daran und rutschen damit nach unten in den blauen Bereich zurück oder verlassen die Firma.

• Gefährlich wird es im roten Bereich rechts unten. Mitarbeiter, die alles machen dürfen, ihren Job aber nicht beherrschen, sind ein grosses Risiko. Ev. müsste man einige Manager in diesen Bereich einteilen.

• Am meisten Nutzen bringen die Mitarbeiter rechts oben. Sie sind die echten Profis und arbeiten auch in diesem Stil. Sie haben das nötige Wissen und die nötigen Mittel und Freiheiten. Sie brauchen keine detaillierte Prozessbeschreiben und bedienen den Kunden schnell und kompetent im Sinne der Firma.

Welche Mitarbeiter wollen Sie? Entscheiden Sie selbst ! Aber seien Sie ehrlich und konsequent. Viele sagen, sie wollen Mitarbeiter oben rechts, trauen ihnen dann aber doch nicht zu, selbständig und mündig zu handeln. Es braucht dazu ein völlig neues Managementverständnis. Schluss mit Micro-Management. Es braucht „Embark und Empower“. Aber eben beides. Das heisst, auch diese Leute müssen an Bord geholt werden. Sie müssen verstehen, wie die Strategie der Firma ist und was das konkret für die anstehenden Entscheide bedeutet. Und dann brauchen sie aber auch den nötigen Freiraum sowie die klaren Grenzen und Ziele um darin kompetent und flexibel ausgerichtet auf die Kunden zu handeln.

Das zwar schöne Worte. Aber wie können wir das konkret verwenden? Im nächsten Blog zeige ich an einem Beispiel, wie sich das auf den Bestellprozess (Request Fulfilment) in der IT auswirken kann.

Prozesse messen und verstehen

Wenn wir jetzt hingehen und nur ein Prozess-KPI für die Geschwindigkeit und einen für die Qualität bestimmen, diesen Messen und damit den Prozess steuern, fallen wir wieder ins alte Muster zurück. Diese Kennzahlen sind zwar nötig, aber noch lange nicht hinreichend. Wir vergessen damit den wichtigsten Punkt, den Kunden. Kennen wir seine Erwartungen? Warum fragen wir nicht ihn? Leider kann der Kunde uns seine Erwartungen selten in KPI-Werten ausdrücken.

Kundenzufriedenheit als wichtigster Erfolgsfaktor

Bei allen Prozessen, die im direkten Kundenkontakt stehen ist und bleibt der wichtigste Erfolgsfaktor die Kundenzufriedenheit. Sie lässt sich sehr oft recht einfach abfragen. Aber leider wird das noch nicht überall konsequent genug gemacht.

Bei dieser Gelegenheit möchte ich noch auf den Unterschied zwischen Kunde und Benutzer aufmerksam machen. Der Kunde ist der mit dem Geldbeutel Er bezahlt den Service und macht damit auch die Vorgaben. Der Benutzer ist das arme Schwein, das den Service anwenden muss. Wir müssen beide zufrieden stellen und damit auch beider Zufriedenheit abfragen. Oft sind die Benutzer mengenmässig viel grösser. Es brauche für eine Benutzerzufriedenheitsabfrage ein geeignetes Tool. Bei den Kunden hingegen empfehle ich den direkten Kontakt. Vor lauter „Sozial Media“ wird dies oft vergessen. Aber glauben Sie mir, das direkte Gespräch wirkt Wunder.

Beispiel Arbeitsplatz

Ich denke, es ist an der Zeit einen Prozess als Beispiel zu nehmen. Es gibt kaum eine Firma, bei der das Einrichten eines Arbeitsplatzes für einen neuen Mitarbeiter reibungslos und zur vollen Zufriedenheit aller abläuft. Dabei ist der Prozess meist gut dokumentiert und wir haben die Gelegenheit, ihn immer wieder zu üben. Für den neuen Mitarbeiter muss der Arbeitsplatz 2 Wochen im Voraus bestellt werden. Dabei kann (und muss) alles genau angegeben werden. Nicht nur das Gerät mit Zubehör, sondern auch die benötigten Programme und Zugriffsrechte müssen lückenlos definiert und in einem Formular aufgeführt werden. Das ist für die IT eine optimale Voraussetzung. Sie liefert genau, was bestellt wurde und auch innerhalb der vereinbarten zwei Wochen. Damit ist alles erfüllt, Lieferzeit 100% und Qualität 100%. Alle sind zufrieden – ausser der Kunde. Warum?

Das beginnt damit, dass er keine Ahnung hat, was er genau in der Bestellung alles angeben muss. Es ist ärgerlich, sich durch ein dreiseitiges Formular zu kämpfen und nicht zu wissen, was man einfüllen muss. Und damit geht es sicher auch schief. Ein Detail wurde falsch bestellt und damit auch falsch geliefert. Das ist natürlich ein eindeutiger Fehler des Kunden und die IT kann es sogar beweisen. Schliesslich ist im Bestelltool alles genau festgehalten. Nur glauben Sie nicht, das stimme den Kunden wohlwollender. Er fühlt sich „verarsc..“, verschaukelt und nicht ernst genommen.

Der Kunde will eben nicht einen PC, eine Tastatur, eine Maus, einen Bildschirm, eine Laptop-Tasche eine Mausmappe, MS.Office, Visio und weitere fünf Programme und zudem die zwanzig verschiedenen Zugriffsrechte, die der neue Benutzer für seine Arbeit braucht. Nein, er will, dass der neue Mitarbeiter an seinem ersten Arbeitstag an einen eingerichtet Arbeitsplatz kommen kann und sich sofort willkommen fühlt. Im Idealfall hat die IT die Mittelung vom Personaldienst erhalten, dass auf ein bestimmtes Datum ein neuer Mitarbeiter eintritt. Sie nimmt daraufhin selbstständig mit dem Vorgesetzten Kontakt auf und erkundigt sich, was für den neuen Mitarbeiter eingerichtet werden kann.

Merken Sie den Unterschied? Das erste ist eine Ansammlung von Produkten und der Kunde ist Bittsteller. Er stört lediglich die IT bei ihrer Arbeit. Im zweiten Falls ist der Kunde erwünscht. Sein Anliegen ist willkommen. Er bekommt einen Service. Ein Service lässt sich eben nicht mehr einfach durch einen Prozess beschreiben. Er erfordert das Mitdenken aller Beteiligten. Sie werden damit vom FTE (Full Time Equivalent) zum „Mit-Arbeiter“ und „Mit-Denker“. Um das zu erreichen brauchen wir gut ausgebildete und erfahrene Mitarbeiter einerseits und andererseits das Vertrauen deren Vorgesetzten. Das Vertrauen darauf, dass unsere Mitarbeiter wissen, was zu tun ist, um den Kunden einen effizienten und vollwertigen Service zu bieten.

Daher werde ich das nächste Mal über das Thema „Vom Produkt zum Service“ schreiben.

 

Produkte und Services

Ein Produkt ist das Ergebnis der Produktion

Auch wenn die IT heute vermehrt von Produktion als IT Umgebung spricht, assoziiert ein Produkt etwas, das hergestellt wird und das man im Laden kaufen kann. Ein IT Produkt ist damit ein PC, ein Server, ein Stück SW, usw.

Ein Service ist eine Dienstleistung

Diese Dienstleistung bezieht sich zwar oft auch auf ein hergestelltes Produkt und unterstützt dieses zusätzlich.

Zum besseren Verständnis möchte ich hier das Beispiel eines Autos anfügen. Wenn Sie sich ein Auto kaufen, kaufen Sie ein Produkt. Sie können dann Jährlich einen Service machen lassen. Das Auto bleibt aber ein Auto. Wenn Sie Ihr Auto dazu benutzen von A nach B zu gelangen, können da auch als Service einkaufen. Ich nenne es Limousinen Service. Sie brauchen dazu kein eigenes Auto. Sie bestellen einfach einen Fahrer mit Fahrzeug und er bringt Sie an den gewünschten Ort. Das ist, was ich als Service bezeichne.

Ein wesentlicher Unterschied ist die Lagerfähigkeit. Ein Produkt wird hergestellt und kann gelagert werden. Erst wenn der Kunde es nachfragt, wird es an ihn geliefert. Bei einem Service in Form einer Dienstleistung geht das nicht. Dienstleistungen können nicht gelagert werden. Sie müssen genau dann erbracht werden, wenn der Kunde danach fragt. In Zukunft wird die IT hier einem starken Wandel unterzogen sein. Unsere Kunden erwarten vermehrt IT Services „on demand“ und nicht nur IT Produkte ab Lager. Das Produkt hinter dem Service wird zwar benötigt, ist aber nicht genügend. Es zeigt sich somit dasselbe Bild wie bei den Prozessen. Und genau das macht den neuen Charakter der IT aus. Es geht nicht mehr in erster Linie darum, welche Produkte im Rechenzentrum und beim Benutzer auf dem Schreibtisch stehen, sondern welchen Service wir ihm bieten können. Denken Sie nur an die aufkommenden Clouds. Die HW und die SW ist plötzlich nicht mehr interessant. Wir nutzen lediglich die Services, die die Cloud uns bietet. Das ist die Ablage und der Austausch von Dateien, das Senden und Erhalten von E-Mails, usw. Ein ähnlicher Trend ist bei einigen SW Herstellern zu sehen. Office 365 kann man nicht mehr als Produkt kaufen. Man kann es nur noch als Service nutzen. Dasselbe gilt auch für die Creative Suite von Adobe.

XaaS wird die Zukunft sein. Das X steht dabei für irgendetwas, das als Service bezogen werden kann.

XaaS – Etwas as a Services

Sie kennen alle die verschiedenen Begriffe:

• Software as a Service

• Plattform as a Service

• Infrastructure as a Service

Diese drei zusammen ergeben dann auch den Begriff SPI (SaaS, PaaS, IaaS). Weiter kennen wir aber auch schon:

• SaaS : Storage as a Service

• CaaS : Communication as a Service

• NaaS : Network as a Service

• MaaS : Monitoring as a Service

Ich rate aber zur Vorsicht mit solchen Modeausdrücken. Nur weil etwas XaaS ist, ist es nicht plötzlich gut. Nur wenn der Service-Gedanke dahinter konsequent umgesetzt und auf den Kunden ausgerichtet ist, entsteht der gewünschte Nutzen. Wenn einfach das gewöhnliche bisherige Outsourcing als Service bezeichnet wird, bleibt es einfaches Outsourcing. Das muss deshalb nicht schlecht sein. Es wird aber mit dem neuen Namen auch nicht besser.

Zukunft des Service Management

In den kommenden Jahren wird sich die IT Landschaft massgeblich verändern. Dass man IT Infrastruktur Leistungen nicht mehr selbst erbringt, sondern einkauft hat sich in den vergangen Jahren bereits stark verbreitet. IT Infrastruktur wird immer mehr kommerziellen Produkt, das irgendwo eingekauft werden kann. Daraus entstanden ist der Trend der Cloud. Die ganze Thematik rund um den Datenschutz ist zwar noch nicht gelöst, aber der Trend ist kaum mehr aufzuhalten. Vor allem jüngere Generation nutzen vermehrt Cloud Services aller Art und setzen damit ein „Fait accompli“.

Flexibilität

Eine weitere massive Veränderung ist die immer häufiger geforderte Flexibilität und Agilität an die IT Services.

Der Hype der Qualitätsanforderungen ist vorbei. Der steigende Kostendruck und die zunehmenden Anforderungen an die Flexibilität werden einen negativen Einfluss auf die Qualität der IT-Services haben. Ich glaube jedoch, dass die Qualität auch in Zukunft ein wichtiger Erfolgsfaktor bleiben und daher nicht beliebig absinken wird. Die Kosten für „Commodity-Services“ werden noch weiter sinken, jedoch werden diese durch die erhöhten Anforderungen kompensiert. Die gesamten IT-Kosten werden damit nicht mehr wesentlich kleiner. Jedoch werden die Anforderungen an die Flexibilität und die Agilität massiv steigen. Und so wird sich die Balance zwischen Kosten, Qualität und Flexibilität zu Gunsten der Flexibilität verschieben.

Serviceverständnis

Mit dem bestehenden ITIL Verständnis können die neu entstandenen IT Service Konzepte nicht mehr effizient und entsprechend den Erwartungen der Kunden abgedeckt werden. Das heisst aber nicht, dass alle Prozesse über Bord geworfen werden müssen. Jedoch muss das Grundverständnis massgeblich ändern und die Prozesse müssen neu darauf ausgerichtet werden.

Beispiel Serverbetrieb

Diese Problematik lässt sich gut am Betrieb von Servern zeigen. In der Vergangenheit hat die interne IT einer Firma die Server selbst aufgebaut und betrieben. Der Betrieb war qualitativ zwar hochstehend aber auch teuer und träge. Typischerweise wurden einige ITIL Prozesse detailliert umgesetzt und stufenweise verfeinert.

In der Zwischenzeit sind grössere Provider (Google, Amazone, Microsoft, …) bereit, diese Services zu einem Bruchteil der Kosten und vor allem auch viel schneller zu liefern. Die Systeme sind nur noch virtuell. Sie können damit sehr einfach redundant aufgebaut und voll automatisch bereit gestellt werden. Jeder kann sich heute für wenig Geld mit der Kreditkarte einen vollständigen Web-Server mit PHP, SQL usw. innert Minuten bereitstellen lassen. Er bezahlt monatlich nur solange er diesen Service auch nutzt.

Eine interne IT hat nicht die kleinste Chance einen solchen Service zu diesen Konditionen zu liefern. Hat sie damit keine Daseinsberechtigung mehr? Wenn sie in Konkurrenz zu diesen Providern auftreten will, wird sie es sicher sehr schwer haben. Sie kann sich aber diese Provider zu Nutze machen und als Bindeglied zwischen Kunde und Provider einen entscheidenden Beitrag leisten. Aber die Betonung liegt auf „Beitrag“.

Daher geht es nächsten Blog um die Wertschöpfung der IT.

Wertschöpfung der IT

Wertschöpfung der IT

Ein professioneller Provider ist in der Lage einen Infrastruktur, Plattform oder Applikationsservice „out oft he box“ standardisiert, schnell und zuverlässig zu liefern. Die Bezeichnungen dafür gehen von IaaS, PaaS nach SaaS bis hin zu Cloud. Dahinter steckt aber immer dasselbe. Es ist ein standardisierter Service, der für viele Kunden in gleicher Weise erbracht und daher schnell bereitgestellt und günstig betrieben werden kann. Früher hätte man das einfach als Outsourcing bezeichnet.

Solche Services decken aber noch nicht die Bedürfnisse des Kunden ab. Sie können sich das als Kraftwerk vorstellen, das Energie in grossen Mengen erzeugt und diese als 400 Kilovolt ins Stromnetz einspeist. Das ist ein hoch standardisiertes Produkt. Nur können Sie als Kunde nichts damit anfangen. Sie benötigen 230 Volt, 50 Herz, zu Hause an der Steckdose, abgesichert auf 10 Ampere mit einem Fehlerstromschutzschalter als Personenschutz. Zwischen dem Produzenten der Leistung und Ihnen als Kunde braucht es dafür einen Integrator. Jemand, der das hergestellte und gelieferte Produkt für Sie, auf Ihre Bedürfnisse zugeschnitten bereit stellt und zu Ihnen nach Hause liefert. Zudem muss das Licht, der Kühlschrank und die Heizung integriert werden.

Und hier entsteht die Wertschöpfung der IT Abteilung. Sie kauft sich auf dem Markt die Leistungen ein, die sie für den Service benötigt und integriert die Umgebung des Kunden darin. Sie ist in der Lage, die technische Sprache der Provider in die Sprache des Kunden umzusetzen und bildet das Interface. Das bedingt aber, dass ein Umdenken stattfindet. Unabhängig davon, ob sie die Infrastrukturservices selbst erzeugt oder einkauft, muss sie diese angepasst auf die Businessprozesse des Kunden erweitern. Oft ist die Welt des Kunden sehr komplex. Er hat diverse Systeme, die ineinander greifen und Daten aus verschiedenen Quellen untereinander austauschen. Zudem sind die Daten oft das eigentliche Kapital des Kunden und müssen sehr vertraulich behandelt werden. Damit muss die Schlüsselgewalt über die Zugriffe auf seine Daten beim Kunden bleiben und darf nicht einfach an einen globalen Provider weiter gegeben werden. Das ist ein Umstand, der im Übrigen viel zu wenig beachtet wird.

In der passiven Form wird die interne IT mehr und mehr von den Providern „verdrängt“. Sie muss, wenn sie überleben will, sich immer mehr in Richtung des Kunden orientieren.

Aktiv betrachtet will Sie dem Kunden vermehrt Services auf hohem Niveau anbieten und damit den Kunden optimal unterstützen. Sie muss sich dazu von den unteren Schichten des Service-Stacks (Technologie und IT-System Management) lösen und sich auf die oberen Schichten konzentrieren.

Man kann sich gut vorstellen, dass sich die IT damit immer mehr mit dem Business vereint. Die „alte Welt“ in der es IT und Business nebeneinander gab und in der die IT eine Sprache verwendete, die das Business nicht verstand und daher nur wenig Einfluss auf die IT hatte, wird sich auflösen. Es entsteht eine „Welt“ in der die IT Teil des Business ist. Agile Produkte Teams werden zusammen Businessanforderungen basierend auf standardisierten Plattformen schnell und pragmatisch umsetzen.

Einige Firmen versuchen zur Zeit Teams bestehend aus Business, Applikationsentwicklung und IT Operation in so genannten „Produkt-Teams“ zusammenzufassen. Dies wird oft auch „Dev-Ops“ genannt.

Dieses Thema greift der kommenden Artikel auf.