Skill Gap kennen
Eine strukturierte Bewertung bestehender und erforderlicher Cloud-Fähigkeiten — differenziert nach Rollen, mit konkreten Priorisierungen zu Beginn.
Workforce Transformation & Capability Empowerment
Zuletzt aktualisiert am
STACKIT
Workforce Transformation & Capability Empowerment
Technologie ist nur das Fundament, die Belegschaft entscheidet über den Erfolg: von der Skill-Gap-Analyse über den Betriebsrat bis zur Zertifizierung.
Workforce Transition und Rollenentwicklung
Analyse bestehender IT-Rollen, Identifikation von Qualifizierungslücken und Begleitung der Mitarbeiter beim Übergang in neue Cloud-Rollenprofile.
People first — Technology folgt
Abschnitt betitelt „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
Abschnitt betitelt „Die drei Transitionsszenarien“
Szenario 1: Upskilling — Bestandsmitarbeitende entwickeln
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Praktische Umsetzung“-
Bestandsaufnahme der aktuellen Rollen — Welche Kompetenzen sind vorhanden, welche fehlen? Wo gibt es Überschneidungen mit zukünftigen Cloud-Rollen?
-
Frühzeitige Einbindung des Betriebsrats — Proaktiv informieren, bevor Entscheidungen fixiert werden. Den Qualifizierungsplan als zentrales Element vorstellen.
-
Einzelgespräche — Jede betroffene Person verdient ein persönliches Gespräch über ihre Entwicklungsperspektive, keine generische E-Mail.
-
Qualifizierungsvereinbarungen abschließen — Schriftlich, mit Zeitplan und Ressourcen. Nicht als Kontrollinstrument, sondern als gegenseitige Verpflichtung.
-
Lernzeit strukturell verankern — Ohne explizit geschützte Lernzeit kommt es zur Qualifizierung nicht. Im Tagesgeschäft wird das Lernen systematisch verdrängt.
-
Fortschritt sichtbar machen — Regelmäßige Check-ins und öffentlich sichtbare Erfolge (Zertifizierungen, neue Projektverantwortlichkeiten) stärken das Engagement.
Anbindung an Cloud Empowerment
Abschnitt betitelt „Anbindung an Cloud Empowerment“Die Qualifizierungsinhalte für die hier beschriebenen Rollen werden im Kapitel Cloud Empowerment als Sechs-Track-Modell erarbeitet. Workforce Transition und Qualifizierungsplanung sind zwei Seiten derselben Medaille — der organisatorische Rahmen hier, die Lerninhalte dort.
Betriebsrats-Partnerschaft & Qualifizierung
Partnerschaftliche Einbindung des Betriebsrats (§ 87 BetrVG), rechtssichere Strukturierung von schriftlichen Qualifizierungsvereinbarungen und Schutz von Lernzeiten.
People first — Technology folgt
Abschnitt betitelt „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
Abschnitt betitelt „Die drei Transitionsszenarien“
Szenario 1: Upskilling — Bestandsmitarbeitende entwickeln
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Praktische Umsetzung“-
Bestandsaufnahme der aktuellen Rollen — Welche Kompetenzen sind vorhanden, welche fehlen? Wo gibt es Überschneidungen mit zukünftigen Cloud-Rollen?
-
Frühzeitige Einbindung des Betriebsrats — Proaktiv informieren, bevor Entscheidungen fixiert werden. Den Qualifizierungsplan als zentrales Element vorstellen.
-
Einzelgespräche — Jede betroffene Person verdient ein persönliches Gespräch über ihre Entwicklungsperspektive, keine generische E-Mail.
-
Qualifizierungsvereinbarungen abschließen — Schriftlich, mit Zeitplan und Ressourcen. Nicht als Kontrollinstrument, sondern als gegenseitige Verpflichtung.
-
Lernzeit strukturell verankern — Ohne explizit geschützte Lernzeit kommt es zur Qualifizierung nicht. Im Tagesgeschäft wird das Lernen systematisch verdrängt.
-
Fortschritt sichtbar machen — Regelmäßige Check-ins und öffentlich sichtbare Erfolge (Zertifizierungen, neue Projektverantwortlichkeiten) stärken das Engagement.
Anbindung an Cloud Empowerment
Abschnitt betitelt „Anbindung an Cloud Empowerment“Die Qualifizierungsinhalte für die hier beschriebenen Rollen werden im Kapitel Cloud Empowerment als Sechs-Track-Modell erarbeitet. Workforce Transition und Qualifizierungsplanung sind zwei Seiten derselben Medaille — der organisatorische Rahmen hier, die Lerninhalte dort.
Cloud Empowerment
Aufbau einer dauerhaften Lernorganisation über geschützte Experimentierumgebungen (Sandboxes), Cloud Guilds und ein Cloud Champions Netzwerk.
Was dieses Kapitel für Sie bedeutet
Abschnitt betitelt „Was dieses Kapitel für Sie bedeutet“Cloud-Technologie wird gekauft. Cloud-Fähigkeit wird aufgebaut. Der Unterschied zwischen Organisationen, die die Cloud-Transformation erfolgreich abschließen, und solchen, die nach 18 Monaten frustriert zurückblicken, ist fast immer dieselbe Frage: Haben die Menschen gelernt, die Plattform wirklich zu nutzen?
Dieses Kapitel zeigt Ihnen, wie Sie Cloud-Fähigkeit systematisch aufbauen — mit einer strukturierten Lernarchitektur aus sechs Tracks, einer klaren Qualifizierungsstrategie für alle Rollen und einer organisatorischen Lerninfrastruktur, die nicht beim Projekt endet.
Sechs Lernpfade
Von Cloud Awareness für alle Mitarbeitenden bis hin zu spezialisierten Tracks für Security, FinOps und Architektur — jede Person erhält den Lernpfad, der zu ihrer Rolle passt.
STACKIT University & Zertifizierungen
STACKIT-eigene Lernplattform, empfohlene externe Zertifizierungen nach Tracks und ein realistisches Trainingsbudget für den Mittelstand.
Lernende Organisation
Sandbox-Umgebungen zum Experimentieren, Cloud-Gilden als Communities of Practice und das Cloud Champions Netzwerk als Multiplikator in die Teams.
Die Investition in Menschen — und warum sie sich lohnt
Abschnitt betitelt „Die Investition in Menschen — und warum sie sich lohnt“
Qualifikation ist Respekt
Abschnitt betitelt „Qualifikation ist Respekt“Wenn Organisationen in die Qualifikation ihrer Mitarbeitenden investieren, senden sie eine klare Botschaft aus: Sie sind Teil dieser Transformation, nicht ihr Opfer. Diese Botschaft ist der stärkste Change-Management-Hebel, den eine IT-Führungskraft hat.
Menschen, die wissen, dass ihre Fähigkeiten aktiv weiterentwickelt werden, sind offener für Veränderungen. Sie werden zu Botschaftern statt zu Skeptikern. Sie bringen Wissen in die Teams, das kein externer Berater je besser kennen wird: ihre eigene Organisation, ihre Geschichte, ihre Schwächen — und ihre Stärken.
Verbindung zu anderen Kapiteln
Abschnitt betitelt „Verbindung zu anderen Kapiteln“Cloud Empowerment ist die praktische Umsetzung des Kulturwandels und legt den Grundstein für alle Themen der technischen Adoption.
- Beginnen Sie mit der Skill-Gap-Analyse — Ausgangssituation vor der Maßnahmenplanung.
- Wählen Sie das richtige Trainingsmodell für Ihre Organisations- und Rollenzusammensetzung.
- Planen Sie Zertifizierungen als strukturierten Fähigkeitsnachweis.
- Etablieren Sie Sandbox und Communities of Practice als permanente Lerninfrastruktur.
Skill-Gap-Analyse
Systematische Erfassung vorhandener und fehlender Kompetenzen zur Definition individueller, rollenbasierter Ausbildungswege.
Warum die Skill-Gap-Analyse vor der Trainingsplanung steht
Abschnitt betitelt „Warum die Skill-Gap-Analyse vor der Trainingsplanung steht“Ohne eine Skill-Gap-Analyse ist das Ergebnis ein einheitliches Trainingsprogramm, das für die einen zu spezifisch und für die anderen zu allgemein ist. Die Analyse liefert die Grundlage für rollenspezifische Lernpfade und realistische Weiterbildungsbudgets.
Schritt 1: Rolleninventur
Abschnitt betitelt „Schritt 1: Rolleninventur“Eine vollständige Bestandsaufnahme aller IT-Rollen und deren Cloud-Anforderungen:
| Rollendomäne | Typische Positionen | Cloud-Zuständigkeiten | Anzahl Personen |
|---|---|---|---|
| Platform Engineering | Systemadministratoren, Platform Engineers | IaC, Landing Zone, Managed Services | [Anzahl] |
| Anwendungsentwicklung | Softwareentwickler, DevOps | CI/CD, Container, Cloud-native Patterns | [Anzahl] |
| Security & Compliance | Security Analysts, CISO-Office | IAM, Policy-as-Code, DevSecOps | [Anzahl] |
| Data & Analytics | Data Engineers, BI-Analysten | Managed Databases, Object Storage | [Anzahl] |
| Betrieb & SRE | IT-Betrieb, SRE | Observability, Incident Response | [Anzahl] |
| FinOps & Controlling | IT-Controller, Beschaffung | Cloud-Ökonomie, Tagging, Showback | [Anzahl] |
| Management & Architektur | IT-Führung, Enterprise Architects | Strategie, Governance, Kostenverantwortung | [Anzahl] |
Schritt 2: Vierdimensionale Kompetenzfeststellung
Abschnitt betitelt „Schritt 2: Vierdimensionale Kompetenzfeststellung“Die Beurteilung der Kompetenzen erfolgt in vier Feldern auf einer 1–4-Skala je Rollendomäne:
Bewertungsskala:
- 1 – Keine Kenntnis: Hat sich noch nicht mit der Technik beschäftigt
- 2 – Grundverständnis: Konzepte bekannt, keine praktische Erfahrung
- 3 – Praktische Erfahrung: Kann mit Unterstützung selbstständig arbeiten
- 4 – Experte: Kann andere anleiten, kennt Best Practices
| Kompetenzfeld | Beurteilungsfragen |
|---|---|
| Cloud-Grundlagen | Cloud-Service-Kategorien, STACKIT-Portfolio, Shared Responsibility |
| Fachliche Fähigkeiten | IaC schreiben, Kubernetes betreiben, Netzwerke konfigurieren |
| Security & Compliance | IAM-Konzepte, Least Privilege, DSGVO-Anforderungen |
| Cloud-Ökonomie | Kostenmodelle, Tagging-Standards, Optimierungshebel |
Schritt 3: Lückenmatrix
Abschnitt betitelt „Schritt 3: Lückenmatrix“Das Ergebnis der Bewertung ist eine Gap-Matrix — für jede Rollendomäne das Delta zwischen Ist-Zustand und Soll-Kompetenz:
| Rollendomäne | Cloud-Grundlagen | Fachliche Fähigkeiten | Sicherheit | Ökonomie | Priorität |
|---|---|---|---|---|---|
| Platform Engineering | Aktuell: 2 / Soll: 4 | Aktuell: 1 / Soll: 4 | Aktuell: 2 / Soll: 3 | Aktuell: 1 / Soll: 2 | 🔴 Hoch |
| App-Entwicklung | Aktuell: 2 / Soll: 3 | Aktuell: 2 / Soll: 3 | Aktuell: 1 / Soll: 3 | Aktuell: 1 / Soll: 2 | 🔴 Hoch |
| Sicherheit | Aktuell: 2 / Soll: 3 | Aktuell: 1 / Soll: 3 | Aktuell: 2 / Soll: 4 | Aktuell: 1 / Soll: 2 | 🟡 Mittel |
| IT Operations | Aktuell: 2 / Soll: 3 | Aktuell: 2 / Soll: 3 | Aktuell: 2 / Soll: 2 | Aktuell: 1 / Soll: 2 | 🟡 Mittel |
| Controlling | Aktuell: 1 / Soll: 2 | Aktuell: 1 / Soll: 1 | Aktuell: 1 / Soll: 1 | Aktuell: 1 / Soll: 3 | 🟡 Mittel |
| Management | Aktuell: 1 / Soll: 2 | Aktuell: 1 / Soll: 1 | Aktuell: 1 / Soll: 2 | Aktuell: 1 / Soll: 2 | 🟢 Gering |
Bewertungsmethoden
Abschnitt betitelt „Bewertungsmethoden“Option A: Selbsteinschätzung mit Kalibrierung Jede Person schätzt sich selbst anhand des 1–4-Schemas ein. Anschließend kalibriert die Teamleitung die Bewertungen. Schnell, aber mit der Gefahr der Überschätzung.
Option B: Strukturiertes Interview Ein CCoE-Mitglied oder ein externer Trainer führt 30-minütige Interviews mit je einer Person pro Rollendomäne. Repräsentativ, aber nicht umfassend.
Option C: Fachliche Bewertung Kurze Aufgaben (1–2 Stunden): IaC schreiben, Review einer IAM-Richtlinie, Berechnen eines Kostenmodells. Objektiv, aber zeitintensiv.
Empfehlung für die meisten Organisationen: Option A mit Kalibrierung durch die Teamleitung für die Erstbewertung. Nach 6 Monaten Schulung: Option C zur Messung des Fortschritts.
Output: Trainingsplan als direktes Ergebnis
Abschnitt betitelt „Output: Trainingsplan als direktes Ergebnis“Die Gap-Matrix fließt direkt in das Trainingsmodell ein:
- Rote Priorität → Tracks C/D als Pflichtschulung, sofortiger Sandbox-Zugriff
- Gelbe Priorität → Tracks B/C in den ersten 6 Monaten
- Grüne Priorität → Track A verpflichtend, B/C optional
Das 6-Track-Ausbildungsmodell
Durchführung strukturierter, rollenbasierter Trainingspfade der STACKIT University (von Cloud Awareness über Architektur und Security bis hin zu FinOps).
Warum sechs Tracks statt ein Universalkurs
Abschnitt betitelt „Warum sechs Tracks statt ein Universalkurs“Cloud-Kompetenz ist keine einheitliche Größe. Ein CIO braucht strategisches Verständnis, kein Terraform-Wissen. Ein Platform Engineer braucht Terraform-Tiefe, keine FinOps-Details. Ein IT-Controller braucht Cloud-Economics-Know-how, kein Kubernetes-Wissen.
Sechs rollenspezifische Tracks stellen sicher, dass jede Person genau die Skills erhält, die sie für ihre Cloud-Aufgaben benötigt — nicht mehr und nicht weniger.
Track A — Cloud Awareness (alle Mitarbeitenden)
Abschnitt betitelt „Track A — Cloud Awareness (alle Mitarbeitenden)“Zielgruppe: 100 % der IT-Mitarbeitenden + relevante Sparten + Führungskräfte Dauer: 4 Stunden (verpflichtend, innerhalb von 6 Monaten nach Einführungsstart) Format: Interaktiver E-Learning-Kurs + optional Live-Q&A
Lernziele:
- Was ist Cloud? Was ist Sovereign Cloud?
- Was bedeutet STACKIT für unsere Organisation?
- Wie verändert sich meine Arbeit — und was bleibt?
- Warum setzen wir auf STACKIT statt auf US-Hyperscaler?
STACKIT-Relevanz: STACKIT University Track A deckt diese Themen mit STACKIT-spezifischem Kontext ab.
KPI: Abschlussquote Track A — Ziel: 100 % in 6 Monaten
Track B — Cloud Practitioner (IT-Generalisten)
Abschnitt betitelt „Track B — Cloud Practitioner (IT-Generalisten)“Zielgruppe: IT-Mitarbeitende ohne Cloud-Spezialisierung, Projektleiter, IT-Beschaffung Dauer: 12–16 Stunden Format: Blended Präsenz/Online + erste Sandbox-Übungen
Lernziele:
- Das STACKIT-Produktportfolio verstehen (Compute, Storage, SKS, Managed DB, Object Storage)
- Cloud-Kostenmodelle: Pay-as-you-go, Reserved Instances, Kostenoptimierung
- Sicherheitsgrundprinzipien: IAM, Least Privilege, Shared Responsibility
- Erste praktische Erfahrung: STACKIT Konsole, einfache Ressourcen erstellen
STACKIT-Relevanz: STACKIT University Track B + Hands-on Lab in der STACKIT Sandbox
Track C — Cloud Engineer (Platform Engineers, DevOps)
Abschnitt betitelt „Track C — Cloud Engineer (Platform Engineers, DevOps)“Zielgruppe: Platform Engineers, Sysadmins in Transition, DevOps Engineers Dauer: 40–80 Stunden Format: Fachlicher Intensivkurs + Projektpraxisaufgaben
Lernziele und -inhalte:
| Modul | Inhalt | Hands-on |
|---|---|---|
| IaC mit Terraform | Grundlagen Terraform, STACKIT Terraform Provider | Deploy VPC + VM |
| STACKIT SKS | Managed Kubernetes, Cluster erstellen, Workloads deployen | App auf SKS |
| Netzwerkkonfiguration | VPC, Subnetze, Firewallregeln, Hub-and-Spoke | Landing-Zone-Netzwerk |
| CI/CD-Integration | GitHub Actions / GitLab CI mit STACKIT | Pipeline aufbauen |
| Observability | STACKIT Observability, Logging, Alerting | Alarm konfigurieren |
| IAM in der Praxis | Service Accounts, Workload Identity, RBAC | IAM-Setup |
Track-C-Abschlussprojekt: Deployment eines kompletten Workloads (Webapplikation + Datenbank) auf STACKIT — mit Terraform, in SKS, mit CI/CD-Pipeline, mit Monitoring und Tagging.
STACKIT-Relevanz: STACKIT University Track C + CKA-Vorbereitung + Terraform-Associate-Vorbereitung
Track D — Cloud Architect (Enterprise Architects, Senior Engineers)
Abschnitt betitelt „Track D — Cloud Architect (Enterprise Architects, Senior Engineers)“Zielgruppe: Enterprise Architects, Senior Cloud Engineers, Technical Leads Dauer: 40+ Stunden Format: Workshop-Format + Architektur-Review-Fälle
Lernziele:
- Landing-Zone-Design: Hub-and-Spoke, Multiprojekt-Topologie, CIDR-Planung
- Hochverfügbare Architektur-Patterns auf STACKIT
- Migrationsarchitektur: 6R-Strategie (Rehost, Replatform, Refactor, Repurchase, Retain, Retire)
- Kostenoptimierungsarchitektur: Right-Sizing, Reserved Instances, Serverless Patterns
- Multi-Service-Design: wie Compute, Storage, Datenbank und Kubernetes zusammenarbeiten
Track E — Cloud Security (Sicherheitsteams)
Abschnitt betitelt „Track E — Cloud Security (Sicherheitsteams)“Zielgruppe: Security Analysts, CISO-Office, Compliance Manager Dauer: 30–50 Stunden Format: Fachkurs + Compliance-Mapping-Workshop
Lernziele:
- STACKIT IAM Deep-Dive: Federation, RBAC, Service Accounts, PAM
- Policy-as-Code: Terraform Sentinel, Open Policy Agent
- DevSecOps: Security Scanning in CI/CD-Pipelines
- Regulatory Compliance in der Cloud: DSGVO/TISAX/BAIT in der Praxis
- Cloud Incident Response: Forensik, Eindämmung, Wiederherstellung
STACKIT-Relevanz: STACKIT IAM Produktschulung + CCSP-Vorbereitung
Track F — Cloud FinOps (Controlling, IT-Management)
Abschnitt betitelt „Track F — Cloud FinOps (Controlling, IT-Management)“Zielgruppe: IT-Controller, CFO-Office, IT-Management Dauer: 16–24 Stunden Format: Business-orientiertes Seminar + Dashboard-Workshop
Lernziele:
- Cloud-Kostenmodelle: CAPEX vs. OPEX, Reserved vs. On-Demand
- Umsetzung der STACKIT Tagging-Strategie
- Erstellung und Interpretation von Showback-Berichten
- Aufbau von Chargeback-Modellen
- Verbesserung der Budgetsteuerung und Prognosegenauigkeit
STACKIT-Relevanz: STACKIT Billing Dashboard Workshop + FinOps Foundation Practitioner Vorbereitung
Timeline des Schulungs-Rollouts
Abschnitt betitelt „Timeline des Schulungs-Rollouts“| Monat | Aktivität |
|---|---|
| Monat 1 | Start von Track A für alle IT-Mitarbeitenden; Sandbox-Zugriff für technische Rollen |
| Monate 2–3 | Track C erste Kohorte (Platform Engineers + DevOps) |
| Monate 3–4 | Track B für IT-Generalisten; Track E erste Kohorte (Security) |
| Monate 4–6 | Track D für Architekten; Track F für das Controlling |
| Monate 6–12 | Weitere Kohorten, Cloud-Gilden aktiv, externe Zertifizierungen |
Häufige Fehler
Abschnitt betitelt „Häufige Fehler“One-size-fits-all: Ein allgemeiner Cloud-Kurs für alle ist Zeitverschwendung.
Schulung ohne Anwendung: Track C ohne unmittelbar anschließendes Praxisprojekt in der Sandbox verdunstet innerhalb von 2 Wochen.
Schulungen unter Zeitdruck: Die Anweisung an Teams, Schulungen bei 100 % Produktionsauslastung durchzuführen, führt zuverlässig dazu, dass Schulungen nicht stattfinden.
STACKIT University & Zertifizierungen
Strukturierter Nachweis von Cloud-Fähigkeiten und Absicherung des Ausbildungsfortschritts durch standardisierte Zertifizierungsprüfungen.
STACKIT University
Abschnitt betitelt „STACKIT University“Die STACKIT University ist die STACKIT-eigene Lernplattform mit produktspezifischen Kursen, Hands-on Labs und plattformspezifischen Zertifizierungen.
Was die STACKIT University abdeckt:
- Das STACKIT-Produktportfolio im Detail (SKS, Object Storage, Managed DB, IAM, Networking)
- STACKIT-spezifische Best Practices
- Hands-on Labs mit realer STACKIT-Infrastruktur
- STACKIT-native Zertifizierungen
Integration in die Trainingstracks:
- Track A: STACKIT Cloud Fundamentals Kurs
- Track B: STACKIT Practitioner Kurs + erste Labs
- Track C: STACKIT Engineer Kurs + alle verfügbaren Labs
- Track D: STACKIT Advanced Architecture
Empfehlung: Zugang zur STACKIT University für alle IT-Mitarbeitenden ab Tag 1 der Einführungsphase einrichten. Kosten: Bestandteil der STACKIT Partnerschaftsvereinbarung, oft ohne zusätzliche Kosten.
Zertifizierung als Karrieresignal
Abschnitt betitelt „Zertifizierung als Karrieresignal“Zertifizierungen haben eine doppelte Bedeutung:
- Wissensnachweis: Strukturiertes Lernen und verifiziertes Verstehen
- Karriere-Signal: Öffentlich sichtbarer Nachweis der Fähigkeitsentwicklung
Empfehlung: Zertifizierungserfolge intern feiern (Intranet, All-Hands) — das motiviert andere und macht die Transformation sichtbar.
Praktische Schritte
Abschnitt betitelt „Praktische Schritte“- Zugang zur STACKIT University für alle IT-Mitarbeitenden einrichten
- Das Zertifizierungsbudget mit HR und Controlling abstimmen
- Die erste Zertifizierungskohorte für Track-C-Absolventen planen (Terraform Associate + CKA)
- Zertifizierungserfolge in internen Kommunikationskanälen feiern