0

Multi Service Providing – eine Medaille mit zwei Seiten

Überschätzte Managementdisziplin oder nur falsch verstandene Governance?

Multi Service Providing ist eine Disziplin für Leistungs- und Lösungsbieter, die sich am Markt als Provider positionieren. Das gilt für interne und externe Multi Service Provider (kurz: MSPs) gleichermaßen. MSPs arbeiten in aller Regel für viele Kunden und bieten hierbei mehrere Leistungen an. Diese lassen sich auch bundeln, sodass ganze Gewerke quasi aus einer Hand von Endkunden bezogen werden. Einheitliche Preisstrukturen und standardisierte Service Level runden die Angebote ab.

Eine tolle Sache für Unternehmen – die Abnehmer dieser Leistungen. Immer öfter greifen IT-Organisationen darauf zurück, die erkannt haben, dass „commodity IT“ weder wettbewerbsdifferenzierend noch förderlich für das eigene Geschäft ist. Das Marktsegment „Service Providing“ wächst überdurchschmittlich. Immer mehr Anbieter drängen auf dem Markt. Trotz PC-Absatzflaute – die IT sortiert sich neu und Leistungsanbieter sowie Nutzer profitieren gleichermaßen. Industrie 4.0, Digitalisierung und Arbeitsteilung können beginnen: Es ist angerichtet, würde man meinen, wenn da nicht die andere Seite, die Leistungsempfänger wären.

Sucht man nach Methoden oder Modelle, so stolpert man in diesem Zusammenhang über Einträge wie „Service Integration and Management“. Auch bekannt als SIAM oder über „Cloud Computing“ bzw. „Managed Services“, eine Weiterentwicklung von Outsourcing. Bleiben wir mal bei Outsourcing und blicken auf die Entwicklung von IT-Auslagerungen der letzten drei Dekaden zurück:

Was bisher geschah

Als ehemalige Rechenzentrumsleiter eines SAP-Systemhauses für den Geschäftsbereich „SAP Outsourcing“ hatte ich schon weit vor der Jahrtausendwende mit Service Level Agreements (SLAs) und Kunden zu tun, die notorisch unzufrieden waren. Und natürlich war wegen der Standleitung und noch in den Anfängen steckenden Virtualisierung, um nur zwei Aspekte anzuführen, alles viel zu teuer. Hinzu kam die Unverständlichkeit der Handelnden über die Entscheidung der Oberen, ausgerechnet den SAP-Betrieb auszulagern.

Interessant wurde es jedoch, als ich eines Tages zum Quartalreview von einem Kunden eingeladen war und einem Externen gegenüber saß. Dessen Aufgabe, so seine Vorstellungsrede, bestand beim Kunden darin, uns und eine weitere externe Firma, die die Modulberatung übernommen hatte, zu koordinieren. Interessant war zudem, dass dieser Mensch einer Stabsstelle „IT-Governance“ vorstand, die aus mehreren internen Mitarbeitern bestand und direkt an den IT-Leiter berichtete. Dieser hatte erkannt, dass mit Auslagerungen die externen Diensteanbieter mit den eigenen Betriebsabteilungen koordiniert werden müssen. Er sah es als seine Steuerungsaufgabe an und übertrug die Frühform des Provider Managements einer eigens dafür gebildeten Arbeitsgruppe.

Kurz nach der Jahrtausendwende hofften viele Anbieter, mit dem Application Service Providing (kurz ASP) das schlechte Image des Outsourcing-Modells zu verdrängen. Auch mein damaliger Arbeitgeber beauftragte mich, ein geeignetes Geschäftsmodell zu entwickeln. Es wurde ein kurzes Aufflackern, denn noch immer drückten die Kosten und die Vielschichtigkeit von Vorstellungen in den Funktionen das Interesse an ASP-Angeboten. Kaum einer unserer Kunden war für ASP zu begeistern. Im Nachhinein schätze ich ein, dass niemand ernsthaft an einen ASP-Erfolg geglaubt und daran mit entsprechendem Eifer gearbeitet hatte.

Denn schon in den 1990-er Jahren propagierten Analysten vom „Computing im Netz“ und meinten damit das gemeinsame Nutzen von Hardware. Zu der Zeit entwickelten sich Standards wie Service-orientierte Architektur, auch als SOA bekannt, und Konzepte zum Verbund zur gemeinsamen Nutzung von Ressourcen (Grid).

Auch diese Ansätze waren nur Zwischenschritte auf dem Weg zur eigentlichen neuen Stufe der Informationsverarbeitung, dem Cloud-Computing. Denn einhergehend mit dem fortschreitenden Reifegrad der Virtualisierung entwickelten sich mit (u.a.) Digital Subscriber Line (DSL) digitale Kommunikationstechnologien. Die Kosten für den Bezug entfernter IT-Leistungen ließen sich deutlich reduzieren.

Für die unternehmensinternen IT-Bereiche brachen in der ersten Dekade des neuen Jahrtausends Stück für Stück gewohnte Arbeitsumgebungen weg. Plötzlich sollte man Dienstleister sein, bitte schön so gläsern wie möglich, sich mit externen Anbietern vergleichen und -wenn möglich- besser sein. Wobei nie klar wurde, was mit „besser“ denn konkret gemeint war. Als IT-Manager verlangte ich zu der Zeit von meiner Geschäftsführung ein eindeutiges Mandat an die IT zu formulieren. Von den Fachbereichen erwartete ich klar spezifizierte Anforderungen, damit mein Team überhaupt eine Chance hatte, die Erwartungen zu erfüllen.

Hilfe nahte mit dem ITIL-Framework und einer unglaublichen Welle von Projekten, Schulungen und Systembeschaffungen. Die Flucht nach vorne wurde begleitet von einer neuen organisatorischen Einheit, dem Service Desk und einem Berg von Berichten, die den (internen) Kunden belegen sollten, wie gut man „die IT im Griff hat“. Die Geschichte hat bis heute einen entscheidenden Haken: Für die Kennzahlen in den Reports interessiert sich in den Fachbereichen niemand so richtig. Es sei denn, mehr oder minder sinnhafte Vorgaben aus Benchmarks oder Qualitätsanforderungen verlangen das.

Während die Supportprozesse als betriebsnah ausgelegt und mit Hingabe implementiert und verbessert wurden, fristeten die Steuerungsprozesse ein Schattendasein. Obwohl schon in der V2 der Best Practices Library enthalten und Bestandteil der korrespondierenden Norm ISO/IEC 20000, begeisterten sich für die Relationship Prozesse nur wenige IT-Organisationen. Mit fatalen Folgen, wie sich in den letzten Jahren immer mehr zeigte: Neben dem „Ping-Pong“-Spiel zwischen Dienstleistern rieben sich die IT-Bereiche an der ausufernden Schatten-IT.

Service Provider Management und Service Integration

Bereits seit etwa 2010 adressiert die Vorgehensweise „Serviceintegration und Management“ IT-Bereiche, die eine ganze Reihe von Dienstleistern managen müssen. Exakt hier beginnt das Problem: Die SIAM-Prozesse und Methoden bilden eine Schnittmenge bekannter Frameworks wie ITIL und COBIT und stellen die zentrale Rolle der „Service Integration“ heraus.

Warum spreche ich von einem Problem?

Für eine „klassisch“ organisierte Unternehmens-IT führt die Umsetzung dieser Methode zu einem weiteren Layer im Aufbaumodell; gemäß den Empfehlungen zu einer Stabsstelle. Das hilft schlussendlich nur IT-Managern, die sich über „direct reports“ hinsichtlich des Lieferantenmanagements berichten lassen. In der Realität sitzen Stabsstellen direkt neben dem CIO oder sind im Büro am Ende des Gangs zu finden.

SIAM ist aber nicht böse. Das “Service Integration and Management” entfaltet gerade dort seine größten Wirkeffekte, wo das Geschäftsmodell der Unternehmens-IT dem (Multi Service Providing) angepasst wurde. Im Blog des Kollegen Andenmatten findet sich dazu folgende Einordnung: „SIAM ist dabei einerseits eine spezialisierte Fähigkeit mit entsprechend vorausgesetzten Skills, kann aber auch als Funktion innerhalb der Service Provider Organisation eingerichtet werden. Grundsätzlich stellt SIAM frei, ob diese Funktion intern geleistet oder aber auch von einem externen SIAM-Provider bereitgestellt werden kann.“

Ob SIAM als Erweiterung oder eigenständiges Framework interpretiert wird, ist irrelevant. Viel entscheidender ist der Reifegrad von IT-Organisationen, sind die Fähigkeiten, den Kunden die zugesagten Leistungen anzubieten. Das Zusammenspiel von internen und externen Suppliern muss von den Beteiligten verstanden werden und gehört geregelt. Nur wenn die Organisation die Service Providing Governance beherrscht und vor allem externe Provider in der Rolle des Dienstleisters, des Lieferanten sieht, kann diese effektiv steuern.

Was meine ich damit genau?

Folgende grundsätzlichen Veränderungen betrachten wir beim idt als erforderlich, um erfolgreiche Dienstleistersteuerung zu etablieren:

1. Die Unternehmens-IT versteht sich selbst als Service Provider und hat sich danach ausgerichtet.
2. Hierbei bildet Service Brockerage das Geschäftsmodell der Unternehmens-IT und praktiziert Anwender-orientiertes „Utility Computing“.
3. Damit liefert die Unternehmens-IT standardisierte und skalierbare Dienste mit einem hohen Automationsgrad, verbrauchsabhängigen Verrechnungsmodellen.
4. Entsprechend bezieht die Unternehmens-IT „Commodity-Services“ von externen Dienstleistern, bündelt diese zu „end-to-end“-Angeboten in einem Leistungskatalog.
5. Für diese Koordinations- und Steuerungsaufgaben hat sich die Unternehmens-IT mit Kompetenzen wie „Service Architekt“ oder „Business Analyst“ verstärkt.

Jede einzelne dieser Forderungen bedingt radikale Schnitte. Wem das nicht klar ist, wird in seinem Unternehmen weiterhin angreifbar bleiben und vor allem auf der Ausgabeseite negativ wahrgenommen werden.

Für uns beim idt ist Dienstleistersteuerung eine der wichtigen Teildisziplinen im Service Brockerage und damit Kern der Service Providing Governance. Damit Multi Service Management gelingt, empfehlen wir folgende Überlegungen anzustellen und sich mit nachfolgenden Themen zu beschäftigen:

• Verstehe das Geschäftsmodell „Service Brockerage“ und interpretiere es richtig.
• Werde effizient und bleibe flexibel – „IT as a Service“ macht dich unsterblich.
• Bedenke: Ein Service Provider wird mit Vertragsabschluss zu deinem Supplier.
• Lerne die Spielregeln des Plattformgeschäfts – „two sided market“ Position.
• Akzeptiere es: Einen Service kann man nicht „managen“, Anbieter sehr wohl.

Fazit

Wer seine Überlebenschance in der Unternehmens-IT wahren will, muss sich den immer schnelleren und radikaleren Marktveränderungen anpassen. Schatten-IT zu verteufeln ist wirkungslos; die Fachbereiche vergleichen externe Angebote mit der Leistungsfähigkeit der eigenen IT und handeln.

Einher mit den Veränderungen wandeln sich die Rolle und Aufgaben des CIOs bzw. des IT-Leiters erheblich. Er wird immer mehr zum Koordinator und Steuerer, zum Moderator und Berater und/oder zum Businesspartner und Lieferanten von „utility services“.

Dem Multiservice Provider Management wird bei all den Veränderungen eine der wichtigsten Aufmerksamkeiten zuteil: Der Steuerung und der Qualitätssicherung externer Lieferanten und deren Leistungen. Methoden wie SIAM helfen beim Aufbau entsprechender Kompetenzen und benötigter Organisationseinheiten. Das idt kann hierbei Dreh- und Angelpunkt bei Einzelinitiativen bzw. komplexen Projektvorhaben sein.

Angebot des idt

Nicht jede Unternehmens-IT ist automatisch „ready for service providing“, nur weil es SIAM oder ein paar tolle Ideen gibt. Um die o.g. Voraussetzungen zu erreichen, wartet jede Menge Arbeit auf IT-Manager.

Um einen Status, eine Stärken-Schwächen-Analyse und einen Empfehlungskatalog für Maßnahmen zu erhalten, bieten wir den kompakten, jedoch wirkungsvollen „Digital Readiness Check“ an. Dieser umfasst die Bereiche:

• Outsourcing Governance/Sourcing Strategie der Unternehmens-IT
• Organisatorischer/personeller Status Quo (Stärken/Schwächen in der Unternehmens-IT)
• Aktueller Reifegrad (Organisation, Prozesse, Kompetenzen) und Entwicklungspotential der Unternehmens-IT
• Aktuelles Contract- und Supplier Management, Sichtung von Verträgen und Vereinbarungen