Bildquelle: Pexels / Foto-ID 236705 / https://www.pexels.com/photo/236705/
Ein Pilotdienst beginnt oft harmlos. Ein Fachbereich braucht schnelle Hilfe, ein Tool wird testweise freigeschaltet, ein kleiner Prozess läuft außerhalb des normalen Portfolios. Gefährlich wird es, wenn dieser Test plötzlich echte Arbeit trägt, aber niemand den Wechsel in den Regelbetrieb entschieden hat.
Ein Pilotdienst ist ein begrenzter Test für einen neuen IT-Service, ein Tool oder einen Prozess. Er soll Erfahrung sammeln, Nutzen prüfen und Risiken sichtbar machen. Für ITSM-Generalisten ist die zentrale Frage nicht, ob ein Pilot nützlich wirkt. Entscheidend ist, ab wann er verlässliche Zuständigkeit, Kostenklarheit, Support und Betriebsregeln braucht.
Der Teststatus schützt nur am Anfang
Ein Pilot darf kleiner, schneller und weniger formal starten als ein regulärer Dienst. Genau darin liegt sein Wert. Teams können prüfen, ob ein neuer Workflow trägt, ob Nutzer damit zurechtkommen oder ob eine technische Anbindung im Alltag funktioniert. Dieser Freiraum endet aber, sobald andere Prozesse davon abhängig werden.
Wenn Fachbereiche ihre Arbeit auf den Pilotdienst ausrichten, wenn Tickets dazu im Service Desk landen oder wenn Daten dauerhaft darüber laufen, reicht ein lockerer Teststatus nicht mehr. Dann entstehen Erwartungen, die der Betrieb erfüllen muss. Ohne klare Entscheidung bleiben Kosten, Sicherheit, Supportzeiten und Verantwortlichkeiten in einer Grauzone.
Das Portfolio muss den Kipppunkt sichtbar machen
Service-Portfolio-Management beschreibt, welche Services geplant, betrieben, verbessert oder beendet werden. AXELOS ordnet diese Sicht als Führungsinstrument ein, damit Organisationen Services nicht nur technisch, sondern nach Nutzen, Bedarf und Lebenszyklus steuern. Ein Pilotdienst gehört deshalb nicht dauerhaft in eine Nebenliste. Er braucht einen sichtbaren Status im Portfolio.
Der Kipppunkt ist erreicht, wenn der Pilot nicht mehr nur Erkenntnisse liefert, sondern produktive Wirkung hat. Ein internes Analysewerkzeug ist dann kein Experiment mehr, wenn Berichte daraus Entscheidungen vorbereiten. Ein Automatisierungsbot ist kein Nebenversuch mehr, wenn Tickets ohne ihn länger liegen bleiben. Eine kleine SaaS-Lösung ist kein Spielraum mehr, wenn sie Daten hält, die der Fachbereich im Alltag braucht.
Vier Fragen trennen Versuch und Regelbetrieb
Die erste Frage lautet: Wer besitzt den Dienst fachlich und technisch? Ohne Besitzer bleibt unklar, wer Prioritäten setzt, Änderungen freigibt und bei Störungen entscheidet. Die zweite Frage lautet: Welche Nutzer und Prozesse hängen bereits daran? Ein Pilot mit wenigen aktiven Nutzern kann trotzdem kritisch sein, wenn diese Nutzer einen wichtigen Ablauf tragen.
Die dritte Frage lautet: Welche Risiken wurden bisher nur geduldet? Dazu gehören Datenschutz, Berechtigungen, Backup, Anbieterabhängigkeit, Integrationen und Nachweise. Die vierte Frage lautet: Was passiert nach der Bewertung? Ein Pilot braucht ein Ende, eine Verlängerung mit Begründung oder den bewussten Übergang in den Regelbetrieb. Ohne diese Entscheidung wird aus temporärer Freiheit eine stille Betriebsschuld.
Regelbetrieb heißt mehr als Freigabe
IBM beschreibt IT Service Management als Steuerung von IT-Services über Planung, Bereitstellung, Betrieb und Verbesserung. Genau diese Kette fehlt bei heimlichen Dauerlösungen. Es reicht nicht, den Pilotdienst nachträglich offiziell zu erlauben. Der Dienst braucht ein Serviceziel, Supportmodell, Kostenstelle, Verantwortliche, Betriebsdokumentation und eine klare Änderungsspur.
Für den Service Desk ist besonders wichtig, wie Anfragen und Störungen aufgenommen werden. Gibt es einen verständlichen Namen für den Dienst? Gibt es Kategorien im Ticketsystem? Gibt es bekannte Fehlerbilder, Eskalationswege und Ansprechpartner? Wenn diese Punkte fehlen, arbeitet der Support an einem Dienst, der organisatorisch noch gar nicht existiert.
Die Portfolioentscheidung darf unbequem sein
Manche Pilotdienste verdienen den Übergang in den Regelbetrieb. Andere sollten bewusst beendet werden, weil Nutzen, Risiko oder Kosten nicht zusammenpassen. Beides ist besser als ein stilles Weiterlaufen. Eine ehrliche Portfolioentscheidung schützt Teams vor dem Eindruck, dass jeder erfolgreiche Test automatisch ein neuer Pflichtdienst wird.
Atlassian beschreibt ITSM als Zusammenspiel von Menschen, Prozessen und Technologie, um IT-Services zu liefern und zu unterstützen. Ein Pilotdienst passt in dieses Bild erst dann sauber hinein, wenn nicht nur die Technik funktioniert, sondern auch Menschen, Abläufe und Zuständigkeiten geklärt sind. Der beste Zeitpunkt dafür ist nicht nach der ersten großen Störung, sondern vor dem Moment, in dem Nutzer den Test längst als selbstverständlich betrachten.
Praktischer Prüfpunkt für den nächsten Portfolio-Termin
ITSM-Teams sollten in jedem Portfolio-Review eine einfache Liste mitführen: Welche Pilotdienste laufen, wer nutzt sie, welche Daten oder Abläufe hängen daran, welcher Entscheidungszeitpunkt ist gesetzt und welche Option ist vorbereitet? Fortführen, beenden oder in den Regelbetrieb überführen. Diese Liste muss nicht lang sein. Sie muss aber verhindern, dass Tests in produktive Abhängigkeiten rutschen, ohne dass jemand die Betriebsverantwortung übernimmt.
Ein Pilotdienst wird zur heimlichen Dauerlösung, wenn er gebraucht wird, aber noch niemand ihn besitzen will. Genau an diesem Punkt muss das Portfolio sichtbar werden. Nicht als Verwaltungsübung, sondern als Schutz vor unklaren Kosten, ungesichertem Support und Entscheidungen, die erst fallen, wenn der Dienst schon kritisch geworden ist.
Quellen und Einordnung: AXELOS zu Service Portfolio Management, IBM zu IT Service Management, Atlassian zu ITSM. Stand der Quellenprüfung: 17.07.2026. Bildquelle: Pexels, Foto-ID 236705.
