1

Der Provider wird’s schon richten und warum das keine gute Idee ist!

Kann ich dem Provider das Service-Management überlassen? Diese Frage ist nicht einfach zu beantworten, insbesondere, wenn Du die Sichtweise des Business einnimmst. Ich versuche Dir und mir Argumente an die Hand zu geben, warum ein Service-Management intern sinnvoll - aus meiner Sicht notwendig - ist.

Kommt Dir der Satz „Das muss der Provider machen“ bekannt vor?

Ich höre ihn zumindest immer wieder in letzter Zeit. Heute möchte ich versuchen Dir und mir Argumente an die Hand zu geben, warum dem nicht so ist.

Wann höre ich den Satz?

Meist dann wenn es darum geht, was die interne IT-Abteilung leisten soll. Viele wünschen sich, dass alles was mit IT-Betrieb zu tun hat, vom Provider erledigt wird. Alles, inklusive Service-Management, Monitoring, Reporting – das Unternehmen gibt nur noch die Governance und damit Regeln vor.

Kommt Dir soweit bekannt vor? Ja?

Das schwierige daran ist, dass die Argumente aus Sicht desjenigen stichhaltig sein müssen, der den Satz postuliert. Und das macht es schwierig. Unterschiedliche Personen haben unterschiedliche Motivationen. Diese gilt es für Dich zu ermitteln.

Dein Gegenüber

Du darfst Dich also mit der Welt und den Gedanken Deines Gegenübers beschäftigen. Argumentiere nicht gleich, sondern sprich mit ihm oder ihr. Stelle Fragen.

Mmmh, ich merke grad, was ich letztens falsch gemacht habe. Ich habe gleich angefangen zu argumentieren. Also, Tipp aus erster Hand: Falsche Strategie. Stelle Fragen, versuche zu verstehen. Und selbst wenn Du es nicht für Dich nachvollziehen kannst, geben Dir die Antworten genügend Hinweise, wie Du später Deine Argumente aufbauen kannst.

Dein Gesprächspartner vermittelt Dir, was ihm wichtig ist. Seine Ziele und Werte. Du darfst dann sehen, wie Deine Argumente ihn dabei unterstützen die Ziele zu erreichen und seinen Werten treu zu bleiben.

Kommen wir zu möglichen Argumente. Ich möchte Dir ein paar Ideen geben, warum es sinnvoll ist ein internes Service-Management aufzubauen, auch wenn vieles oder alles der Leistung durch Provider erbracht werden.

Governance

Lass uns mal mit dem Begriff Governance starten. Ich habe Wikipedia befragt und in der Definition folgende drei Sätze gefunden: „[Governance], bezeichnet allgemein das Steuerungs- und Regelungssystem im Sinn von Strukturen (Aufbau- und Ablauforganisation) einer politisch-gesellschaftlichen Einheit wie Staat, Verwaltung, Gemeinde, privater oder öffentlicher Organisation. Häufig wird es auch im Sinne von Steuerung oder Regelung einer jeglichen Organisation (etwa einer Gesellschaft oder eines Betriebes) verwendet. Der Begriff Governance wird häufig unscharf verwendet.“

Besonders der letzte Satz ist sehr zutreffend.

Als Ingenieur werde ich hier gleich hellhörig: Steuern und Regeln beinhaltet auch sofort Messen. Nur das was ich messen kann, kann ich auch steuern. Stichwort Regelkreis.

Auch dazu habe ich bei Wikipedia nachgeschlagen: „Als Regelkreis wird der in sich geschlossene Wirkungsablauf für die Beeinflussung einer physikalischen Größe in einem technischen Prozess bezeichnet. Wesentlich hierbei ist die Rückführung des aktuellen Wertes an den Regler, der einer Abweichung vom Sollwert kontinuierlich entgegenwirkt (negative Rückkopplung).“

Mehr Elektrotechnik wird es heute nicht – versprochen.

Denn andere haben diesen Regelkreis schon für uns in Richtung Betriebswirtschaft transformiert. Dort sprechen wir dann vom „betrieblichen Regelkreismodell“.  Der hat das gleiche Prinzip: Planen, Steuern, Ausführen, Überwachen. Ein ganz konkreter Vertreter dieses Modells ist der überall so beliebte PDCA-Zyklus – Plan, Do, Check, Act. Nichts anderes als ein Regelkreis.

Das bedeutet, dass der Auftraggeber, der der die Service-Governance vorgibt, auch für die Überwachung des Ergebnisses verantwortlich ist. Es ist wie mit Kindern, wenn Du denen Regeln vorgibst und diese merken, dass ein Verstoß auf Dauer keine Konsequenz hat, dann nehmen die Dich irgendwann nicht mehr ernst.

Unser bekanntestes Governancemodell in der IT heißt COBIT – ausgeschrieben Control Objects for Information and Related Technology. Die Betonung liegt hier auf Control Objects – übersetzt Steuerungsvorgaben. 

Damit das nicht eine COBIT-Episode wird, nur ganz kurz:  COBIT geht grundsätzlich von den Unternehmenszielen aus. Daraus werden die IT-Ziele definiert und daraus die Ziele für die sogenannten Enabler. Es wird beschrieben was getan werden soll und nicht wie.

Für alle Ebenen werden Mess- und Zielgrößen definiert, die Du diesmal von unten nach oben misst, um so den Regelkreis wieder zu schließen.

Will erneut sagen, dass derjenige, der die Regeln aufstellt auch dafür verantwortlich ist, dass diese vom Provider eingehalten werden. Du darfst, nein Du musst, Deine Provider aktiv steuern.

Hier besteht die Gefahr, dass eine philosophische Diskussion über unterschiedliche Governance-Verständnisse stattfindet. Deswegen sollte das nicht Dein einziges Argument sein.

Technik vs. Business

Ein aus meiner Sicht ganz wichtiges und auch kompliziertes Argument ist folgendes: Der Provider liefert technische Services – Dein Kunde, Dein Unternehmen braucht aber Business-Services.

Das Argument ist deswegen so kompliziert, weil für viele Führungskräfte nicht das I, sondern das T in IT dominiert. Ich sage immer, bei IT steht das I vorn und damit dominiert die Information. Und genau darum geht es.

Deine Provider liefern Dir technische Services. Du bekommst ein CRM-System, eMail, Drucker, DMS und was Du sonst noch so brauchst, um Rechnung zu erstellen, zu drucken und Eingangsrechnungen zu bezahlen.

Es ist Deine Aufgabe, eine funktionierende Unterstützung der Geschäftsprozesse sicherzustellen. Zumindest in meiner Welt. Der Geschäftsprozess Eingangsrechnung sieht vielleicht so aus:

Rechnung kommt per Post, wird gescannt, danach im DMS abgelegt, zur Freizeichnung weitergeleitet, in der FIBU erfasst und dann bezahlt.

Der oder die Provider sind verantwortlich für die Funktion der einzelnen Komponenten. Kein Provider wird die Verantwortung für die Funktion des Gesamtsystems übernehmen. Kann er auch nicht.

Outsourcings, die ich selber erlebt habe und die nach dem Modell „Der Provider wird’s schon richten“ funktionierten, hatte die Folge, dass sich eine umfangreiche, offiziell geduldete Schatten-IT entwickelte. Weil genau das Wissen und die Bemühung um die Geschäftsprozesse gefehlt hat.

Wenn Du es richtig angehst, dann hast Du keine Schatten-IT, sondern die notwendigen Prozesse und Werkzeuge, um die Providerleistung zu steuern und zu messen. Da bin ich ja doch wieder beim Regelkreis gelandet. Mmh.

Was Du bitte auch nicht vergessen darfst – Dein Provider hat Ziele, die gegenläufig zu Deinen sind. Das ist ganz normal. Der Provider versucht mit so wenig Aufwand wie möglich, so viel Gewinn wie möglich zu erarbeiten. Würde ich als Provider auch versuchen.

Du und Dein Unternehmen habt die Bestrebung, so wenig wie möglich, oder besser wie sinnvoll, für IT-Leistungen auszugeben. Auch das ist in Ordnung. Es muss sich nur irgendwo treffen. Beide dürfen ihr Gesicht wahren und der Provider darf durchaus angemessen verdienen. So lange Du eine angemessene Leistung für das Geld bekommst.

Somit stellst Du als interne IT sicher, dass das Unternehmen die bestmögliche Leistung für das Geld bekommt.

Insider-Wissen

Jetzt möchte ich noch darauf eingehen, dass es nicht sinnvoll ist, dem Provider alle ITSM-Prozesse allein zu überlassen.  Während es beim Service Desk, Incident- und Problemmanagement möglich sein könnte, wird es im Change- und Demandmanagement schon fast unmöglich.

Selbst bei Störungen und Problemen, ist eine Mitwirkung interner Wissensträger sinnvoll. Wissen bezieht sich hier vor allem auf das Prozesswissen und das Wissen um die Verbindung von Geschäftsprozessen zur IT.

In den letzten Wochen sind viele Menschen auf mich zugekommen mit Ihren IT-Problemen. Häufig habe ich gesagt: „Das möchte ich mir gern bei Ihnen direkt anschauen!“ – wir haben einen Termin vereinbart und ich habe mir zeigen lassen, bei welchen Abläufen die Fehler auftreten. Und ich habe Fragen zum Prozess gestellt – mein Ziel: Ich möchte verstehen, was der Anwender macht und warum es für ihn ein Problem ist.

Das ist auch mit einem ausgelagerten Helpdesk möglich – aber auch braucht es jemanden intern, der diesen koordiniert. Dazu empfehle ich Dir das Interview mit Oliver Wildenstein .

Je weiter weg die ITSM-Prozesse von den Prozessen des Unternehmens sind, umso generischer werden sie und umso weniger fühlt sich der Nutzer verstanden. Umso weniger versteht der Provider die Relevanz.

So zumindest meine Theorie – was meinst Du dazu?

 

Weißt Du, was ich jetzt spannend fände? Wenn es auf diesen Beitrag eine direkte Widerrede gäbe. Das würde mich interessieren. Also, wenn Du Lust hast, dann zerpflücke meine Argumente und erkläre mir, warum  es sinnvoll ist, wenn der Provider alles im IT-Service-Management übernimmt.

Gern per eMail oder als Kommentar hier unter dem Beitrag!

 

Compliance

Zum Abschluss noch ein Punkt: Compliance. Nicht wenige Unternehmen sind zur Einhaltung spezieller Richtlinien wie beispielsweise der FDA (US Food and Drug Administration), GMP (Good Manufacturing Practices) oder dem Sarbanes-Oxley Act (kurz: SOX) verpflichtet.

Der Einhaltung der geltenden Gesetze ist jedes Unternehmen verpflichtet. Bei Zulieferern kommen dann noch die Regeln der Kunden dazu.

Dies bedarf eines Compliance-Managements im Unternehmen. Und weißt Du was Compliance übersetzt heißt?

Regeltreue

Genau, da bist Du wieder bei der Überprüfung, ob Deine Provider Deine Regeln einhalten. Fast alle Compliance-Regeln haben Auswirkung auf die IT. Dementsprechend, darfst Du die Einhaltung sicherstellen. Der nächste Auditor wird es bestimmt überprüfen.

 

Fazit

Ich fasse das Thema in zwei Punkten zusammen:

1. Schon alleine wenn ich Leistungen in Anspruch nehme, bin ich gut beraten, die Leistungserbringung zu kontrollieren. Habe ich Regeln, die für die Leistungserbringung verbindlich sind, so darf ich deren Einhaltung kontrollieren.
2. Soll das I in IT dominieren, so darfst Du für viele ITSM-Prozesse den Business-Teil übernehmen. Dein Provider liefert Dir technische Services. Er erbringt technischen Support. Häufig hat er keine Ahnung von Deinen Prozessen und deren speziellen Ausprägung. Das sind Deine Aufgabe und die Herausforderung bei der Definition der Prozesse zwischen Dir und den Providern.

Hast Du noch Argumente, die gegen „Der Provider wird’s schon richten.“ Sprechen? Oder hast Du Lust auf die Gegenrede? Über beides freue ich mich sehr.