---
title: "Workforce Transition und Rollenentwicklung"
description: "Der organisatorische Personalübergang in Cloud-Rollen: Mitbestimmung des Betriebsrats, Betriebsvereinbarungen, Qualifizierungszusagen und die menschliche Seite der Cloud-Transformation."
sidebar:
  order: 6
  label: "Workforce Transition"
source_url: "https://framework.stackit.cloud/de/adoption/adapting-operating-models/workforce-transition/"
source_file: "docs/de/adoption/adapting-operating-models/workforce-transition.mdx"
---

## People first — Technology folgt

Cloud-Transformationen scheitern nicht an Kubernetes. Sie scheitern daran, dass die Menschen nicht wissen, welche Rolle sie in der neuen Welt spielen sollen, ob ihr Job sicher ist und ob ihre Erfahrung noch zählt.

Eine Workforce Transition ist kein HR-Projekt, das parallel zur technischen Migration läuft. Es ist eine Führungsaufgabe, die vor dem ersten technischen Schritt beginnt und nicht nach dem Go-Live endet.

## Die drei Transitionsszenarien

![Workforce Transition Übersicht](./files/workforce-transition-overview.svg)

### Szenario 1: Upskilling — Bestandsmitarbeitende entwickeln

Der gebräuchlichste und am meisten empfohlene Pfad. Erfahrene Mitarbeitende kennen die Geschäftsdomäne, die Prozesse und die interne Kultur. Cloud-Wissen ist lernbar — Domänenwissen nicht.

**Was eine Qualifizierungsvereinbarung beinhaltet:**

- Benennung der Zielrolle und des aktuellen Startprofils
- Timeline mit Meilensteinen (typisch: 6–18 Monate)
- Konkrete Qualifizierungsmaßnahmen (Schulungen, Zertifizierungen, Mentoring, Hospitation)
- Ressourcen: Lernzeit, Kostentragung, Urlaubsregelungen
- Beurteilungskriterien: Wie wird die Zielerreichung gemessen?
- Konsequenzen bei Nichterfüllung (für beide Parteien formuliert)

**In der Praxis gängige Rollenübergänge:**

| Startrolle            | Zielrolle                         | Typische Übergangsfrist |
| --------------------- | --------------------------------- | ----------------------- |
| Systemadministrator   | Platform Engineer                 | 9–12 Monate             |
| Netzwerkadministrator | Cloud Network Engineer            | 6–9 Monate              |
| Speicheradministrator | Cloud Storage & Backup Spezialist | 6–9 Monate              |
| IT-Projektleiter      | Cloud Product Owner               | 12–18 Monate            |
| Anwendungsentwickler  | Cloud-Native Developer            | 4–8 Monate              |
| IT-Controller         | FinOps Analyst                    | 6–12 Monate             |

### Szenario 2: Neue Mitarbeitende — neue Rollen, neue Leute

Einige Rollen existieren noch nicht in der Organisation und können nicht intern besetzt werden. Dies trifft häufig auf Platform Architects, Site Reliability Engineers und DevSecOps-Spezialisten zu.

**Was im Neueinstellungsprozess gilt:**

- Interne Ausschreibung vor externer — auch wenn die interne Erfolgswahrscheinlichkeit gering erscheint
- Eindeutige Rollenprofile, die den spezifischen STACKIT-Kontext beschreiben
- Realistische Gehaltsvorstellung: Cloud-Spezialisten sind Mangelware, der Markt ist umkämpft
- Einarbeitungsprogramm für Externe: Sie kennen die Cloud, aber nicht Ihre Organisation

### Szenario 3: Managed Service — Aufgaben auslagern

Für Bereiche ohne strategische Abgrenzung kann die Entscheidung getroffen werden, Aufgaben dauerhaft an einen Managed Service Provider zu übertragen. Dies hat arbeitsrechtliche Konsequenzen, die frühzeitig zu klären sind.

**Was zu klären ist:**

- Umfang der Aufgabenübertragung und die verbleibende interne Steuerungsfunktion
- Auswirkung auf betroffene Mitarbeitende: Versetzung, Weiterqualifizierung oder — als letztes Mittel — Entlassung
- SLA-Aufbau mit dem MSP: Was garantiert der Anbieter, woran wird gemessen?
- Austrittsklauseln: Was passiert, wenn sich der MSP ändert oder die Entscheidung rückgängig gemacht wird?

## Die häufigsten Fehler

**Fehler 1: Zu spät informiert.** Wenn Mitarbeitende Gerüchte über die Cloud-Migration hören, bevor sie offizielle Informationen erhalten, verliert man Vertrauen, das nur schwer wiederzugewinnen ist. Kommunizieren Sie frühzeitig, auch wenn noch nicht alle Fragen beantwortet werden können.

**Fehler 2: Qualifizierung als optional behandeln.** Wer Upskilling als Nice-to-have ansieht, bekommt weder qualifizierte Teams noch eine zukunftsfähige Cloud-Umgebung. Qualifizierung ist Investition, nicht Kosten.

**Fehler 3: Rollen zu technisch beschreiben.** Eine Stellenbeschreibung, die ausschließlich aus Listen von Technologien besteht, schreckt erfahrene Mitarbeitende ab, deren Domänenkompetenz sich nicht in einer Reihe von Zertifizierungen widerspiegelt.

**Fehler 4: Erfolgsmessung nur technisch.** Wer den Transformationserfolg ausschließlich an SLAs und Deployment-Häufigkeit bemisst, merkt zu spät, wenn Teams überlastet, frustriert oder intern abgelenkt sind.

## Praktische Umsetzung

<Steps>
1. **Bestandsaufnahme der aktuellen Rollen** — Welche Kompetenzen sind vorhanden, welche fehlen? Wo gibt es Überschneidungen mit zukünftigen Cloud-Rollen?

2. **Frühzeitige Einbindung des Betriebsrats** — Proaktiv informieren, bevor Entscheidungen fixiert werden. Den Qualifizierungsplan als zentrales Element vorstellen.

3. **Einzelgespräche** — Jede betroffene Person verdient ein persönliches Gespräch über ihre Entwicklungsperspektive, keine generische E-Mail.

4. **Qualifizierungsvereinbarungen abschließen** — Schriftlich, mit Zeitplan und Ressourcen. Nicht als Kontrollinstrument, sondern als gegenseitige Verpflichtung.

5. **Lernzeit strukturell verankern** — Ohne explizit geschützte Lernzeit kommt es zur Qualifizierung nicht. Im Tagesgeschäft wird das Lernen systematisch verdrängt.

6. **Fortschritt sichtbar machen** — Regelmäßige Check-ins und öffentlich sichtbare Erfolge (Zertifizierungen, neue Projektverantwortlichkeiten) stärken das Engagement.

</Steps>

## Anbindung an Cloud Empowerment

Die Qualifizierungsinhalte für die hier beschriebenen Rollen werden im Kapitel **[Cloud Empowerment](/de/adoption/cloud-empowerment/)** als Sechs-Track-Modell erarbeitet. Workforce Transition und Qualifizierungsplanung sind zwei Seiten derselben Medaille — der organisatorische Rahmen hier, die Lerninhalte dort.