Bildquelle: Bildquelle: Pexels / Foto-ID 669615 / https://www.pexels.com/photo/669615/ / C00 Lizenz
Ein Pilot klingt nach wenig Risiko. Ein Fachbereich möchte eine neue Lösung ausprobieren, ein Team testet ein Tool, eine Cloud-Umgebung ist schnell angelegt und der Service soll erst später offiziell bewertet werden. Für die IT-Strategie ist genau dieser Moment kritisch. Was als Versuch startet, kann nach wenigen Wochen schon Nutzer, Daten, Schnittstellen und Erwartungen binden.
Service-Portfolio-Management bedeutet, IT-Services nicht nur technisch zu betreiben, sondern bewusst zu entscheiden, welche Angebote entstehen, wachsen, ersetzt oder beendet werden. Für ITSM-Generalisten ist das wichtig, weil jeder neue Pilot später Fragen an Service Desk, Betrieb, Sicherheit, Kostenstelle und Provider-Steuerung auslösen kann. Ein Pilot ohne Kostenrahmen ist deshalb kein harmloser Test, sondern eine offene Portfolio-Entscheidung.
Ein Pilot ist ein begrenzter Praxistest, bevor ein Service dauerhaft eingeführt wird. Er soll prüfen, ob Nutzen, Aufwand, Risiko und Betrieb zusammenpassen. Damit diese Prüfung ehrlich bleibt, braucht der Pilot vor dem Start einen Kostenrahmen, einen verantwortlichen Owner und eine klare Entscheidung nach dem Test.
Ein Pilot verbraucht mehr als nur Lizenzkosten
Die offensichtlichen Kosten sind meist leicht zu nennen: Testlizenz, Cloud-Verbrauch, Beratertag oder Einrichtungsaufwand. Im Betrieb entstehen aber weitere Aufwände. Jemand muss Zugänge anlegen, Daten klassifizieren, Anfragen beantworten, Berechtigungen prüfen, Sicherheitsfragen einordnen und Ausfälle erklären. Wenn diese Arbeit nicht im Pilotbudget steht, wirkt der Test billiger, als er tatsächlich ist.
Besonders gefährlich wird es, wenn der Pilot bereits produktiv genutzt wird. Dann ist die Rückfrage nicht mehr nur, ob das Tool gut funktioniert. Es geht auch darum, wer Support leistet, welche Servicezeiten gelten, ob eine Störung priorisiert wird und wer bei Kostenanstieg entscheidet. Ohne diese Fragen wächst ein Schattenservice im Portfolio, bevor er offiziell genehmigt wurde.
Die Freigabe braucht eine Betriebsfrage
Eine saubere Pilotfreigabe fragt nicht nur: Dürfen wir das testen? Sie fragt zusätzlich: Was passiert, wenn der Test erfolgreich ist? Wird daraus ein neuer Service, eine Erweiterung eines bestehenden Services oder eine bewusst beendete Erprobung? Diese Anschlussfrage zwingt dazu, Kosten, Nutzen und Betriebsfolgen früh zu benennen.
Praktisch reicht oft ein schlanker Freigabeblock im Ticket oder Portfolio-Board. Dort stehen Ziel des Piloten, erwarteter Nutzen, Budgetrahmen, geplanter Zeitraum, fachlicher Owner, technischer Ansprechpartner, betroffene Daten, grobe Betriebsfolge und Entscheidungstermin. Das ist keine Bürokratie um der Bürokratie willen. Es verhindert, dass ein Test nach Ablauf weiterläuft, nur weil niemand zuständig ist, ihn zu bewerten oder abzuschalten.
Budgetgrenzen machen die Entscheidung sichtbarer
Ein Pilot muss nicht perfekt durchkalkuliert sein. Gerade frühe Tests enthalten Unsicherheit. Trotzdem braucht er eine Grenze. Das kann ein monatlicher Maximalbetrag, ein Verbrauchsalarm, ein Stundenkontingent oder ein klares Ende der Testlizenz sein. Entscheidend ist, dass jemand aktiv entscheiden muss, bevor aus dem Versuch ein dauerhafter Aufwand wird.
Diese Grenze hilft auch dem Fachbereich. Wenn Kosten offen auf dem Tisch liegen, wird der Nutzen konkreter diskutiert. Braucht die Organisation wirklich einen neuen Service? Reicht eine Anpassung im bestehenden Tool? Ist der Nutzen groß genug, um Betrieb, Support und Sicherheitsprüfung zu tragen? Ohne Budgetgrenze wird die Diskussion oft zu spät geführt.
So prüfst Du Pilotkosten vor der Freigabe
- Gibt es einen fachlichen Owner, der Nutzen und Weiterführung verantwortet?
- Ist ein technischer Ansprechpartner für Betrieb, Zugänge und Störungen benannt?
- Steht ein Budgetrahmen für Lizenz, Cloud-Verbrauch, Beratung und internen Aufwand im Ticket?
- Gibt es ein Enddatum oder einen verpflichtenden Entscheidungstermin?
- Ist festgelegt, wer bei Kostenüberschreitung stoppt, verlängert oder eskaliert?
- Ist beschrieben, welche Support-Erwartung während des Piloten gilt?
- Ist klar, wie Daten, Berechtigungen und Schnittstellen nach dem Test zurückgebaut werden?
Diese Prüfung passt besonders gut zu Cloud-Tests, neuen ITSM-Tools, Automatisierungsplattformen, KI-Helfern, Reporting-Lösungen und Fachbereichsanwendungen. Überall dort ist der Start leicht, aber die spätere Übernahme in den regulären Betrieb deutlich anspruchsvoller.
Der Entscheidungstermin ist wichtiger als die perfekte Kalkulation
Der größte Fehler ist nicht eine ungenaue Schätzung. Der größere Fehler ist ein Pilot ohne nächsten Entscheidungspunkt. Dann läuft der Test weiter, weil Nutzer ihn praktisch brauchen, weil niemand die Abschaltung verantworten will oder weil die Kosten einzeln noch klein wirken. Im Portfolio entsteht dadurch eine stille Bindung.
Die bessere Regel lautet: Jeder Pilot startet mit Kostenrahmen, Owner und Entscheidungstermin. Danach darf er wachsen, geändert oder beendet werden, aber nicht unbemerkt in den Dauerbetrieb rutschen. So bleibt der Test ein bewusstes Instrument der IT-Strategie und wird nicht zum versteckten Service ohne Budgetfreigabe.
Quellen und Stand: Quellenprüfung am 27.07.2026. Einordnung zu Service-Portfolio-Management nach AXELOS/PeopleCert Service Portfolio Management, zu Change- und Betriebsfolgen nach Atlassian Change Management und zu Kostenplanung im Cloud- und IT-Betrieb nach FinOps Foundation Planning and Estimating.
Bildquelle: Pexels / Foto-ID 669615 / https://www.pexels.com/photo/669615/ / C00 Lizenz
