Bereitstellung

Die Bereitstellung klärt, wie eine Lösung in den Einsatz kommt, und markiert damit den Übergang von „technisch bereit“ zu „im tatsächlichen Einsatz“. In dieser Phase werden Rollout-Strategien umgesetzt, Deployments durchgeführt, Kommunikations- und Schulungsmaßnahmen organisiert sowie Sicherheits- und Überwachungsmechanismen im Zielumfeld etabliert.

Die Qualität eines Projekts entscheidet sich hier nicht nur technisch, sondern auch darin, wie Veränderung in der Organisation eingeführt wird. Ein technisch einwandfreies System, das niemand richtig nutzen kann, weil Kommunikation und Schulung fehlten, verfehlt trotzdem sein Ziel.

Was in der Bereitstellungsphase geklärt wird

Vier Bereiche entscheiden über einen gelungenen Übergang in den Einsatz:

• Rollout-Strategie: Erfolgt die Einführung auf einen Schlag oder schrittweise und welche Nutzergruppen folgen zuerst?
• Deployment: Wie kommt die Lösung technisch in die Zielumgebung, wiederholbar und nachvollziehbar?
• Kommunikation und Schulung: Wer muss wann worüber informiert und worin geschult werden?
• Absicherung: Welche Monitoring- und Rollback-Mechanismen greifen, falls etwas schiefgeht?

Der technische Teil dieser Liste lässt sich meist gut planen. Der organisatorische Teil, vor allem Kommunikation und Schulung, wird dagegen regelmäßig unterschätzt, obwohl er über Akzeptanz oder Ablehnung der neuen Lösung entscheidet.

Wer typischerweise beteiligt ist

Der Betrieb führt das Deployment durch und richtet Monitoring für die Zielumgebung ein. Projektleitung und Change-Management planen Rollout, Kommunikation und Schulung, oft die aufwendigeren Aufgaben in dieser Phase. Das Entwicklungsteam bleibt in Bereitschaft, um in den ersten Tagen nach dem Go-Live schnell auf unerwartete Probleme reagieren zu können. Fachbereich und Key-User wirken häufig als Multiplikatoren, die neuen Kolleginnen und Kollegen den Umgang mit der Lösung erklären.

Typische Risiken

Wenn die Bereitstellung unterschätzt wird, kommt es zu holprigen Go-Lives, improvisierten Rollbacks und Irritation auf Seiten der Nutzer. Häufig ist das technische Deployment dabei der einfachere Teil, die organisatorische Einführung der schwierigere.

Was am Ende vorliegen sollte: Übergabe an die Wartung

Übergabeartefakt	Warum es zählt
Dokumentierter Rollout-Verlauf	Zeigt, was tatsächlich passiert ist, nicht nur was geplant war
Funktionierendes Monitoring	Ermöglicht, Probleme im Betrieb früh zu erkennen
Geschulte Nutzer und Support	Verhindert, dass jede Frage sofort eskaliert
Bekannte offene Punkte aus dem Rollout	Gibt der Wartung einen realistischen Startpunkt
Rollback- oder Notfallplan	Bleibt auch nach einem erfolgreichen Go-Live relevant

Fragen, die sich alle Beteiligten stellen sollten

• Existieren abgestimmte Konzepte für Kommunikation, Schulung und Unterstützung der Nutzer?
• Gibt es einen klaren Plan für den Fall, dass etwas schiefgeht, inklusive Rollback-Option?

Diese Fragen betreffen Projektleitung und Change-Management mindestens so sehr wie das Deployment-Team. Ein Rollout ohne Kommunikationsplan ist ein technisches Risiko mit menschlichen Folgen.

Im Beispiel: Ablösung des Ticketsystems

Bei unserem Beispiel zur Systemablösung wird in der Bereitstellung entschieden, ob ein Big-Bang-Rollout oder eine schrittweise Migration erfolgt, inklusive der dazugehörigen Kommunikations- und Trainingsmaßnahmen für Support, Vertrieb und alle anderen Nutzergruppen.