Wie die IT Time-to-Market-Fähigkeit erreicht

Auf den Köder kommt es an

25.02.2005 von Dieter Pfaff
Wer als IT-Shop die Fachabteilung zufrieden stellt, hat viel erreicht. In vielen Fällen ist dieses anspruchsvolle Ziel auch mit vertretbarem Aufwand realisierbar. Voraussetzung ist aber, dass man nicht täglich das Ohr an die Server legt, dafür aber um so mehr seine Prozesse im Auge hat.

Services - und kundenorientiert. Dieser Ansatz muss einfach gut sein. Der Begriff Services signalisiert, dass es um etwas geht, das jemandem nützen soll. Der Anspruch "kundenorientiert" benennt dann auch gleich noch die Zielgruppe. Es handelt sich also um Dienstleistungen, die nach den Kriterien des Adressaten nützlich sein sollen. Es geht somit um die IT-spezifische Umsetzung des Satzes: "Der Köder muss dem Fisch schmecken und nicht dem Angler". Eine Forderung, die ebenso richtig wie schwierig umzusetzen ist. Will man Enttäuschungen vermeiden, ist erfahrungsgemäß eine sorgfältige Analyse notwendig. Um auf das eben zitierte Bild zurückzukommen: Die Welt der Fische ist dem Angler zwangsläufig verschlossen. So fällt ihm naturgemäß auch eine Beurteilung des Köders aus der Perspektive der Fische schwer. Heuristische Hilfestellung wäre nützlich.

An dieser Stelle sei die These gewagt, dass eine Standardisierung von Services und Prozessen zur Unter-stützung der Fachbereiche genau dieses leistet. Ein solches Vorgehen führt erstens zu niedrigen Kosten und zweitens zu besseren Services. Allerdings nur dann, wenn man es richtig macht. Doch was heißt eigentlich Standardisierung? Standardisierung wird gemeinhin als eine Domäne der Technik verstanden, und genau das wäre in diesem Zusammenhang die falsche Betrachtungsweise. Vor allem aber wäre sie nicht kundenorientiert. Der Kunde will in der Regel eine bestimmte Funktionalität, einen bestimmten Nutzen. Ihm ist es beispielsweise völlig egal, ob er sein "Word" direkt vom Desktop oder einer "Citrix"-Lösung bekommt. Warum ist das so wichtig? Ganz einfach: Biete ich als IT-Shop "nur" den Service "Word auf dem Screen des Mitarbeiters" an, habe ich alle Chancen, die entsprechende Lösung/ Applikation mit den geringsten Costs- of-ownership auszuwählen und zu implementieren. Lege ich mich bereits im Vorfeld technisch zu sehr fest, habe ich meine Möglichkeiten ohne Not eingeschränkt.

Als erstes ist also festzuhalten: Es kommt darauf an, die Services - also das, was der Kunde fühlt, sieht und in Anspruch nimmt - zu standardisieren. Nicht die Technik. Wir sollten uns deshalb auch nicht dadurch irritieren lassen, dass in der IT häufig technikgeprägte Produktbezeichnungen benutzt werden, um Services sehr komplexer Funktionalität zu beschreiben. Zudem sollten wir nicht vergessen, dass einer Fachabteilung, die etwa SAP möchte, das Produkt aus Walldorf von seinen rein technischen Komponenten her betrachtet eigentlich egal ist. Sie nutzt das Kürzel SAP lediglich, um ein ERP-System bestimmter Funktionalität so einfach wie möglich zu beschreiben. Ob SAP dann aber unter Windows, Solaris oder Linux läuft, ist der Fachabteilung, also dem Kunden, im Prinzip gleichgültig. Um an dieser Stelle einem Missverständnis vorzubeugen: Natürlich ist auch auf dieser Ebene Standardisierung sinnvoll und nützlich. Mit der besseren Strukturierung von Services und einem deutlich höheren Augenmerk auf die Kundenorientierung hat diese Art von Standardisierung jedoch nichts zu tun.

Der Markt liefert die Benchmarks

Was bedeutet dann aber die Standardisierung von Services genau? Nach meiner Überzeugung ist das Ideal der Standardisierung erreicht, wenn es einem IT-Shop als internen Dienstleister gelingt, einzelne Services marktkompatibel zu definieren. Das heißt, es muss der jeweilige Leistungsumfang festgelegt werden - insbesondere natürlich die Service Level Agreements (SLAs), so wie sie im Markt üblich sind. Möglichst unabhängig von Technik und den Infrastrukturen im Hintergrund, aber möglichst konkret in Bezug auf das, was der Kunde will. Wie macht man das? Ausschreiben ist ein guter Weg. Allerdings fordert das auch den Mut, gegebenenfalls extern am Markt einzukaufen, wenn eine wettbewerbsfähige Dienstleistung intern nicht darstellbar ist. Vor allem die konzerneigenen IT-GmbHs sollten sich ganz schnell an solche Vorgehensweisen gewöhnen. Sonst sind und bleiben sie lediglich eine gesellschaftsrechtlich verbrämte IT-Abteilung.

Der Nutzen liegt, zumindest aus Sicht der Fachabteilungen, auf der Hand. Alle Services werden unmittelbar am Markt gebenchmarkt. Allein die Notwendigkeit von Vertragsentwürfen und Leistungsbeschreibungen, die ausschreibungsfähig sind, führt zu einem hohen Standardisierungsgrad. Gleichzeitig führt diese Vorgehensweise zur Unabhängigkeit von einzelnen Lieferanten - seien sie interne oder externe.

Wie können solche Services inhaltlich aussehen? Die Antwort ist relativ einfach. Es kann sich beispielsweise um den Betrieb von Desktop-Arbeitsplätzen handeln. Das wäre dann noch sehr infrastrukturnah. Es kann sich auch um einzelne Dienste wie Mail, Intranet oder die Unterstützung von Personalentwicklung und / oder Bewerbungsprozessen handeln. Oder aber den Betrieb einer Portal-Infrastruktur sowie eines "SAP SEM / BCS". Bei letzterem Szenario wird man sich allerdings mit dem Marktstandard schwer tun.

Zu klären bleibt allerdings die Frage, ob diese marktgängigen Services ausreichen, um alle Bedürfnisse der internen Kunden abzudecken? Möglicherweise laut die Antwort dann: Nein. Dann ist es jedoch die richtige Strategie, die Bedürfnisse so weit als möglich mit marktgängigen Standardpaketen abzudecken und darüber hinausgehende Anforderungen gesondert zu vergeben. Das ist besser, als große Universalpakete zu schnüren, die mit nichts vergleichbar sind.

An dieser Stelle ist bewusst von der "Vergabe" von Leistungen die Rede. Damit ist nicht ausgesagt, dass lediglich externe Lieferanten im Blickfeld sind. Gemeint ist vielmehr, dass die Kundenorientierung von Services auch intern die Definition eindeutiger Kunden-Auftraggeber-Beziehungen voraussetzt.

Wettbewerbsvorteile bleiben

Nach der Standardisierung von Services stellt sich zu Recht die Frage: Wo bleiben die standardisierten Prozesse? Ein Prozess ist mehr als die Summe von einzelnen Services. Ein Prozess ist die Integration von Services in beziehungsweise zu Abläufen. Hier sei die These erlaubt, dass in der absolut überwiegenden Zahl der Fälle Prozesse so standardisiert werden können, dass sie mit den genannten marktkompatiblen Services in Einklang zu bringen sind. Werden durch Verzicht auf die Anpassung an die viel zitierten "Besonderheiten" des eigenen Unternehmens Wettbewerbsvorteile verschenkt? Nach meiner festen Überzeugung "Nein", beziehungsweise nur in den seltensten Fällen. In der überwiegenden Mehrheit denkbarer Anwendungsszenarien führen der Markt und seine Lösungen zu besseren Ergebnissen als unternehmensindividuelles Bemühen.Wer sich allerdings sicher ist, bei Reisekosten, Personalabrechnung oder Materialbuchhaltung unternehmensindividuelle Vorteile realisieren zu können, der verbraucht am Ende viel Kraft auf Nebenkriegsschauplätzen.

Allerdings ergibt ein Bündel marktkompatibler Services noch keinen Prozess. Schließlich liegt es im fundamentalen Interesse des jeweiligen Unternehmens, über integrierte Prozesse zu verfügen und nicht eine Summe von Anwendern zu haben, die von Anwendung zu Anwendung stolpern. Die Lösung für dieses Problem lautet: Portal. Nur eine leistungsfähige Portal-Infrastruktur ermöglicht es, aus einzelnen Services "anywhere" and "anytime" verfügbare integrierte Prozesse zu modellieren. Solche Lösungen sind inzwischen verfügbar. Man darf allerdings nicht den Investitionsaufwand in die entsprechende Infrastruktur scheuen.

Leistungsschub als Folge

Was haben wir mit kundenorientierten Services erreicht? Wir verfügen über eine Infrastruktur, mit der wir marktkompatible Services zu niedrigen Integrationskosten flexibel in Prozesse integrieren können. Möglichkeiten der Personalisierung und Rollenbasierung bieten eine weitere Basis für die kundenorientierte Gestaltung von Services. Die Services selber haben wir auf Basis marktüblicher Verträge bei unserem internen Dienstleister (teilweise auch extern) gekauft.

Diese Entwicklung führte einerseits zu einem Leistungsschub beim internen Dienstleister, der RAG Informatik GmbH, andererseits führte die marktkonforme Definition der Services zu einer Situation, in der weitere Verbesserungen nur noch durch die Skaleneffekte einer größeren Einheit zu realisieren waren. Deshalb haben wir die RAG Informatik GmbH zum Jahreswechsel veräußert. Die Geschäftsbeziehung wird nach den bisherigen Prinzipien weitergeführt.

War dies also letzten Endes eine Strategie des "sich selbst überflüssig Machens"? Meines Erachtens hat der CIO nur zwei Alternativen. Er treibt diese Entwicklung voran, und er ist es, der das auch seinem Vorstand vermittelt. Dann hat er alle Chancen, in der Tat Handelnder zu bleiben. Die Alternative bestünde darin, dass ein Beratungshaus diesen Job übernimmt. Und glauben Sie mir: Es bleibt genug zu tun - auch wenn man nicht täglich das Ohr an die Server legt.