Eine IT ist ein Unternehmen. Es produziert IT-Services. Jedes Unternehmen würde sein Kernprodukt in den Mittelpunkt seines Managements rücken. Wieso fokussieren IT-Mitarbeitende aber anstelle auf IT-Services lieber auf Projekte, Anwendungen, Datenbanken oder technische Infrastrukturen? 

Ein Grund ist sicherlich, dass die Kernprodukte der IT, nämlich digitale Produkte und Services, nicht gut „anfassbar“ sind – sie sind ja nichts weiter als auf IT-Funktionen beruhende Fähigkeiten, die dem Servicenehmer ermöglichen, sein Geschäft mit weniger Einschränkungen oder gesteigerten Möglichkeiten umzusetzen. IT-Services werden durch die Kombination aus IT-Infrastruktur einerseits und menschlichem Handeln andererseits ermöglicht. Sie sind weder ausschließlich Infrastruktur, noch identisch mit Applikationen. Sie sind sogar mehr als die Kombination aus beidem. Dass dieses „mehr“ nicht in die Fertigung einbezogen wird, führt zu den meisten bekannten Unzufriedenheiten der Servicenehmer mit ihren ITs. 

Viele Bemühungen, ein IT Service Management zu etablieren, führten oftmals zu einem kontraproduktiven starken Fokus auf Prozesse – typischerweise auch beschränkt auf die operativen Prozesse Incident, Problem, Change Management, und vielleicht noch Asset und Configuration Management. Diese sind wichtig, aber nicht sie alleine: Man kann heute viele ITIL-Umsetzungen sehen, die ganz ohne die Definition und Managebarkeit des zentralen Produkts, dem IT-Service (oder moderner formuliert: dem Digital Product) auskommen. Das war ganz klar nicht im Sinne der ITIL-Väter, die den gesamten Lebenszyklus der IT-Service als Kernprodukte gut gemanagt sehen wollten. Service Strategy und Service Design kommen allerdings in der Praxis nur selten vor. Und kategorisiert wird in den operativen Prozessen oftmals mit ausufernden Kategoriebäumen – und nicht etwa nach IT-Services, die durch Servicenehmer subscribed und unsubscribed werden können.  

Eher selten findet man in einer IT ein Servicemodell und eine Servicearchitektur vor, die alle intern wie extern erbrachten Services gleichartig dokumentiert, und diese von Idee und Demand, über Projekt und Sourcing, Request und Fulfillment bis hin zum Betrieb selbstverständlich als zentrales Produkt der IT referenzierbar, managebar und auswertbar macht. Auch fehlt häufig die horizontale Verantwortung eines Service Owners für seine IT-Services über den gesamten Lifecycle – also der moderne Digital Product Manager. 

Und sind Projekte Selbstzweck, oder dient nicht in Wahrheit jedes IT-Projekt ganz und allein dem Zweck, Digital Products/IT-Services zu entwickeln oder zu verändern? 

Die IT-eigene Toolwelt ist oftmals ein deutlich heterogener, großer Toolzoo, der eine einfache Handhabung und Auswertbarkeit der IT-Services entlang ihres Lifecycles für IT-Mitarbeiter fast unmöglich macht. Weit entfernt von einer durchgängigen Plattform mit einheitlichem Datenkonzept, Automatisierungsfähigkeit und einer modernen User Experience für Anwender und IT-Mitarbeitende. 

Kein Wunder also, dass Antworten auf eigentlich selbstverständliche IT-Management-Fragen wie die nachfolgenden oft nur unsicher und mit erheblichem Recherche- und Excel-Aufwand über viele Datenquellen, Beteiligte und Tools hinweg geliefert werden können: 

• Welche Digital Products/IT-Services haben wir im IT-Portfolio? 
• Welche Möglichkeiten für Rationalisierung und Vereinfachung sind vorhanden? 
• Was kostet uns jedes Digital Product/IT-Service in Betrieb und Wartung — basierend auf tatsächlichen IT-Ressourcen, Lizenzkosten, Personalkosten, Verträgen, etc.? 
• Wer hat welchen IT-Service bzw. welche Anwendung subscribed – also die Liste aller User/Subscriber pro Digital Product und ihre Zugriffsrechte und SLAs? 
• Wie gut ist die Leistung jedes IT-Service in Bezug auf das SLA und Erwartungen des Business? Welches sind aktuell die herausragenden Probleme, die gelöst werden müssen? 
• Wie nimmt das Business den Wert jedes IT-Service wahr? Wie zufrieden ist die Kundenseite mit dem erbrachten Service? 
• Welche Projekte und Initiativen sind pro IT-Service geplant (Funnel und In-Flight)? 
• Welche Anforderungen (oder User Stories) befinden sich für jeden IT-Service im Product Backlog? 
• Welche IT-Ressourcen (wie Server und Datenbanken) verwendet jedes Digital Product/jeder IT-Service/ (d.h. kennen wir das Servicemodell einer Anwendung in der CMDB)? 

• Welche Risiken und Herausforderungen haben wir mit jedem Digital Product/ jedem IT-Service? 
• Welches sind die geschäftlichen Anforderungen und Treiber (Demand) für neue oder zu modifizierende Digital Products/IT-Services (als Teil des Digital Product Backlog)? 

Eine IT Service Factory, die IT-Services (und nicht bloß ein Stück installierte Software oder Hardware) produziert, muss strategisch durch das IT-Management gefördert aufgebaut werden. Diese Aufgabe darf nicht „zufällig“, bottom-up, und verteilt über Abteilungen hinweg erfüllt werden, wie es häufiger Standard ist. 

Solche Einzelbemühungen zur Optimierung hier (Prozesse) wie dort (IT-Tools) sind aller Ehren wert, erreichen aber fast nie das Ziel, dass eine durchgängige und Transparenz ermöglichende „Fertigungslinie“ für IT-Services Ende-zu-Ende etabliert wird. Fast nie gibt es die durchgehende Verbindung von EAM, Portfolio Management und Business Demand am Anfang des Lebenszyklus bis hin zur ausgerollten Servicehierarchie mit ihren (Application) Server-, Datenbank- und Storage-Instanzen in einer serviceorientierten CMDB. 

IT4IT™ als offene Referenzarchitektur der Open Group stellt einen Blueprint für den funktionalen Aufbau einer solchen IT-Fertigungslinie dar. Neben allen Funktionen, die entlang des Lebenszyklus von Digital Products/IT-Services notwendig sind, werden auch alle benötigten Steuerungsdaten und ihre Datenflüsse klar. Auf dieser Basis lässt sich der Ist-Zustand erheben, die Handlungsfelder erkennen und priorisieren, IT-Tools konsolidieren und somit der Zoo verringern, und es lässt sich eine Roadmap zur strategischen Umsetzung einer wirklich durchgängigen IT-Fertigungslinie ableiten. 

Die IT4IT™-Architektur hat ihre Gültigkeit unabhängig vom Integrationsgrad von Entwicklung und Betrieb (DevOps), oder davon, ob IT-Service-Releases agil oder nach Wasserfall projektiert und produziert werden. 

Das zunehmend notwendig werdende Multiprovider-Management wird auf dieser Basis ebenfalls vereinfacht: Der IT4IT™-Blueprint erlaubt die klare Festlegung der Verantwortungsteilung über Funktionen (wer führt sie aus, der Provider, oder die interne IT?) wie über benötigte Daten (welche Partei mastert sie?). 

So lässt sich der IT-Service in den Mittelpunkt rücken, und die IT macht ihre Produktion intern wie über alle Lieferanten hinweg steuerbar – wie es jedes andere produzierende Unternehmen auch tun würde. 

Bitte sprechen Sie uns an. Wir ebnen gern den Weg zur Transformation Ihrer IT hin zu einem modernen IT Service Provider. Wir starten beispielsweise mit einem IT4IT™ Baseline Assessment, das den Ist-Zustand Ihrer IT dokumentiert. Auf dessen Basis entwickeln wir gemeinsam eine Roadmap für die Fortentwicklung in für Sie sinnvollen Schritten, bei deren Umsetzung wir Sie gern begleiten. Nutzen Sie unsere über 25-jährige Erfahrung mit IT-Organisationen fast jeder Branche und Größenordnung.