Bitte wählen Sie die Bereiche, die Sie exportieren möchten:
Alle Python SchulungenSchulung MLOps und ML-Pipelines: Von der Entwicklung zur Produktion
Schulung MLOps und ML-Pipelines: Von der Entwicklung zur Produktion
Experiment Tracking, Feature Stores, automatisierte Trainings-Pipelines, Model Serving und Drift-Monitoring
3 Tage / S6941
Neues SeminarSchulungsformen
Offene Schulung
- 3 Tage
- 5 gesicherte Termine
- Köln / Online
- 2.030,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online
Inhouse-/Firmenschulung
- 3 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- 3 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Beschreibung
Data Scientists trainieren Modelle. Die besten Modelle landen in einem Jupyter Notebook auf dem Laptop der Data Scientistin. Irgendwann fragt jemand: „Können wir das in Produktion bringen?" Dann beginnt das Chaos: Das Notebook funktioniert nur auf Marias Rechner (andere Python-Version, andere Paketversionen). Die Trainingsdaten liegen in einem Ordner, der „data_v3_final_wirklich_final" heißt. Niemand weiß, welche Hyperparameter zum besten Ergebnis geführt haben. Und das Modell, das vor 3 Monaten 95 % Accuracy hatte, liefert in Produktion nur noch 78 % - weil sich die Eingabedaten verändert haben.
87 % aller ML-Modelle schaffen es nie in die Produktion. Nicht weil die Modelle schlecht sind, sondern weil der Weg vom Notebook zur Produktion kein Pfad ist, sondern ein Dschungel: fehlende Reproduzierbarkeit, fehlende Versionierung, manuelle Deployments, kein Monitoring, kein Retraining-Prozess.
MLOps ist die Disziplin, die diesen Dschungel in eine Autobahn verwandelt. Experiment Tracking (welcher Lauf mit welchen Parametern hat welches Ergebnis geliefert?), Daten- und Modell-Versionierung (welche Daten und welches Modell sind in Produktion?), automatisierte Pipelines (Training -> Validierung -> Deployment ohne manuelle Schritte), Model Serving (Modell als API bereitstellen, skalierbar, latenzarm), Monitoring (Data Drift und Model Drift erkennen, bevor die Vorhersagen schlecht werden) und Retraining (automatisch neu trainieren, wenn die Performance sinkt).
Dieses dreitägige Seminar ist kein Theorieseminar über MLOps-Prinzipien - es ist ein Hands-on-Workshop , in dem eine vollständige Pipeline aufgebaut wird. Am Ende läuft ein Modell in Produktion, wird überwacht und kann automatisch neu trainiert werden.
87 % aller ML-Modelle schaffen es nie in die Produktion. Nicht weil die Modelle schlecht sind, sondern weil der Weg vom Notebook zur Produktion kein Pfad ist, sondern ein Dschungel: fehlende Reproduzierbarkeit, fehlende Versionierung, manuelle Deployments, kein Monitoring, kein Retraining-Prozess.
MLOps ist die Disziplin, die diesen Dschungel in eine Autobahn verwandelt. Experiment Tracking (welcher Lauf mit welchen Parametern hat welches Ergebnis geliefert?), Daten- und Modell-Versionierung (welche Daten und welches Modell sind in Produktion?), automatisierte Pipelines (Training -> Validierung -> Deployment ohne manuelle Schritte), Model Serving (Modell als API bereitstellen, skalierbar, latenzarm), Monitoring (Data Drift und Model Drift erkennen, bevor die Vorhersagen schlecht werden) und Retraining (automatisch neu trainieren, wenn die Performance sinkt).
Dieses dreitägige Seminar ist kein Theorieseminar über MLOps-Prinzipien - es ist ein Hands-on-Workshop , in dem eine vollständige Pipeline aufgebaut wird. Am Ende läuft ein Modell in Produktion, wird überwacht und kann automatisch neu trainiert werden.
Finden Sie den richtigen Python Kurs aus unserem Portfolio.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit dem Verständnis des vollständigen ML-Lifecycle (Experiment -> Training -> Deployment -> Monitoring -> Retraining), der Fähigkeit, Experiment Tracking mit MLflow produktiv einzusetzen (Runs, Model Registry, Reproduzierbarkeit), der Kompetenz, ML-Pipelines zu bauen (automatisiertes Training, CI/CD für ML), dem Wissen über Model Serving (FastAPI, BentoML, Deployment-Strategien), der Fähigkeit, Model Drift zu erkennen und darauf zu reagieren (Evidently AI, Retraining-Trigger), einer funktionierenden End-to-End-MLOps-Pipeline (vom Experiment bis zum automatischen Retraining) und einer MLOps-Architektur für das eigene Projekt.
Details
Inhalt
Tag 1: Experiment Tracking, Reproduzierbarkeit und Feature Engineering
1. Das MLOps-Problem: Warum Notebooks nicht reichen
4. ML-Pipelines: Training automatisieren
7. Model Monitoring: Drift erkennen bevor es zu spät ist
MLOps-Architektur-Patterns (20 Min):
1. Das MLOps-Problem: Warum Notebooks nicht reichen
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- Der ML-Lifecycle: Daten sammeln -> Feature Engineering -> Modell trainieren -> Evaluieren -> Deployen -> Monitoren -> Retraining. In der Praxis: die ersten 3 Schritte passieren, der Rest nicht.
- MLOps-Reifegrade: Stufe 0 (manuell: Notebook, Copy-Paste, E-Mail an IT), Stufe 1 (Pipeline: automatisiertes Training, manuelles Deployment), Stufe 2 (CI/CD für ML: automatisiertes Training + Deployment + Monitoring), Stufe 3 (vollautomatisch: Drift erkannt -> Retraining -> Deployment ohne menschlichen Eingriff).
- MLOps vs. DevOps: Was ist gleich (CI/CD, Versionierung, Monitoring, Automatisierung)? Was ist anders (Daten als zusätzliche Dimension, Experiment Tracking, Feature Stores, Data/Model Drift)?
- Praxis-Übung: Demo-ML-Projekt (Churn Prediction) als Jupyter Notebook - alles manuell, nichts reproduzierbar. Die Probleme identifizieren: welche Datenversion? Welche Hyperparameter? Welche Python-Version? Funktioniert das Notebook auf einem anderen Rechner?
- Warum Experiment Tracking? Hunderte Trainingsläufe mit verschiedenen Hyperparametern, Features und Datenversionen - ohne Tracking ist nach einer Woche unklar, welcher Lauf das beste Ergebnis lieferte und warum.
- MLflow Tracking: Experiments, Runs, Parameter, Metriken, Artefakte loggen. MLflow UI: Läufe vergleichen, beste Konfiguration finden, Modelle als Artefakte speichern.
- MLflow Model Registry: Modelle versionieren (v1, v2, v3), Stages zuweisen (Staging -> Production -> Archived), Transitions mit Genehmigung.
- Weights & Biases als Alternative: Reichere Visualisierung, Team-Collaboration, Hyperparameter-Sweeps, System-Metriken (GPU-Auslastung). Cloud-basiert vs. Self-Hosted.
- Reproduzierbarkeit sicherstellen: Datenversion + Code-Version + Umgebung (Python, Pakete) + Hyperparameter + Zufalls-Seed = reproduzierbares Experiment. MLflow + Git + Docker/Conda als Kombination.
- Praxis-Übung: MLflow in das Churn-Prediction-Projekt integrieren: 5 Trainingsläufe mit verschiedenen Hyperparametern loggen, in der MLflow UI vergleichen, bestes Modell im Model Registry registrieren und auf „Staging" setzen.
- Daten-Versionierung: DVC (Data Version Control - Git für Daten), LakeFS (Git-artige Branches für Data Lakes). Warum Daten versioniert werden müssen: Modell v3 wurde auf Datenstand Januar trainiert, Modell v4 auf Februar - ohne Daten-Versionierung ist der Unterschied nicht nachvollziehbar.
- Feature Stores: Zentrale Speicherung von Features, die von mehreren Modellen und Teams genutzt werden. Feast (Open Source), Hopsworks, Tecton. Zwei Perspektiven: Offline Feature Store (für Training - historische Daten) und Online Feature Store (für Inference - aktuelle Werte mit niedriger Latenz).
- Feature Engineering für Produktion: Training-Serving Skew (Features werden im Training anders berechnet als in der Inference - der häufigste und gefährlichste MLOps-Bug). Lösung: Feature-Transformationen einmal definieren, für Training und Serving identisch ausführen.
- Praxis-Übung: DVC für das Churn-Projekt einrichten: Trainingsdaten versionieren, Datenänderung simulieren (neue Monatsdaten), neuen Trainingsstand als DVC-Version taggen. Feature Store mit Feast: 5 Features definieren, für Offline-Training und Online-Inference bereitstellen.
4. ML-Pipelines: Training automatisieren
- Warum Pipelines? Manuelles Training (Notebook öffnen, Zellen ausführen, Ergebnis prüfen) skaliert nicht. Pipelines automatisieren den gesamten Ablauf: Daten laden -> Preprocessing -> Feature Engineering -> Training -> Evaluation -> Modell registrieren.
- Pipeline-Frameworks: Kubeflow Pipelines (Kubernetes-nativ, DAG-basiert), MLflow Projects + Recipes (leichtgewichtiger, kein K8s nötig), Airflow + ML (allgemeiner Workflow-Orchestrator mit ML-Tasks), Metaflow (Netflix, Python-nativ), ZenML (MLOps-Framework, orchestrator-agnostisch).
- Pipeline-Design: Steps als wiederverwendbare Komponenten (Data Loader, Preprocessor, Trainer, Evaluator), Parameter-Passing zwischen Steps, Caching (unveränderte Steps nicht erneut ausführen), Trigger (manuell, zeitgesteuert, event-basiert).
- CI/CD für ML: Code-Änderung -> automatisch: Linting + Unit Tests + Integration Tests + Training auf Testdaten + Modell-Evaluation -> wenn besser als aktuelles Produktionsmodell -> Deployment. GitHub Actions oder GitLab CI als Pipeline-Runner.
- Praxis-Übung: ML-Pipeline für das Churn-Projekt bauen: 4 Steps (Data Load, Preprocess, Train, Evaluate), MLflow-Integration (jeder Run wird geloggt), Pipeline per Kommando ausführen. Dann: GitHub-Actions-Workflow, der bei Push auf main die Pipeline triggert.
- Serving-Optionen: Batch Inference (Vorhersagen für alle Kunden einmal pro Nacht - einfach, aber nicht echtzeitfähig), Online Inference (Vorhersage per API-Call in Millisekunden - für Echtzeit-Anwendungen), Streaming Inference (Vorhersage auf Event-Streams - für Kafka/Flink-Szenarien).
- Serving-Frameworks: FastAPI + uvicorn (einfachster Start: Modell laden, API-Endpoint definieren, fertig), BentoML (Modell-Packaging, API-Generierung, Containerisierung in einem Tool), Seldon Core (Kubernetes-nativ, Canary Deployments, A/B-Testing), KServe (Kubernetes, Serverless Inference, Multi-Framework), MLflow Serving (MLflow-Modelle direkt als REST API).
- Containerisierung: Modell + Dependencies in Docker-Container -> überall deploybar (lokal, Cloud, Kubernetes). Reproducibility: exakt dieselbe Umgebung in Entwicklung und Produktion.
- Skalierung: Horizontal (mehr Replicas bei mehr Last), GPU-Inference (für große Modelle), Batching (mehrere Anfragen bündeln -> GPU-Effizienz), Auto-Scaling (Kubernetes HPA oder Cloud-native Skalierung).
- Praxis-Übung: Churn-Modell als API bereitstellen: (1) FastAPI-Endpoint (10 Zeilen Code -> Modell läuft als API). (2) BentoML-Packaging (Modell + Dependencies -> Container -> deployen). (3) Testanfragen senden und Latenz messen. Load-Test: 100 gleichzeitige Anfragen -> skaliert die API?
- Deployment-Strategien: Shadow Deployment (neues Modell läuft parallel, bekommt echten Traffic, aber Ergebnisse werden nur geloggt - kein Impact auf Nutzer), Canary Deployment (10 % des Traffics an neues Modell, 90 % an altes -> Performance vergleichen -> bei Erfolg schrittweise erhöhen), Blue-Green (zwei identische Umgebungen, Traffic wird umgeschaltet - sofortiger Rollback möglich), A/B-Testing (zwei Modelle mit verschiedenen Features oder Algorithmen -> statistisch messen, welches besser performt).
- Rollback: Wenn das neue Modell schlechter ist -> sofort auf die vorherige Version zurückrollen. Model Registry (MLflow, SageMaker) macht das trivial: Production-Stage auf vorherige Version setzen.
- Praxis-Übung: Canary Deployment simulieren: Modell v1 (altes) und Modell v2 (neues) parallel deployen, Traffic-Split konfigurieren (90/10), Metriken vergleichen, v2 auf 100 % hochfahren oder zurückrollen.
7. Model Monitoring: Drift erkennen bevor es zu spät ist
- Warum Monitoring? Ein ML-Modell, das heute 95 % Accuracy hat, kann in 3 Monaten nur noch 75 % liefern - ohne dass sich am Modell etwas geändert hat. Der Grund: die Welt hat sich geändert (Kundenverhalten, Marktbedingungen, Saisonalität, Pandemie, neue Produkte).
- Data Drift: Die Verteilung der Eingabedaten ändert sich (Features haben plötzlich andere Werte als im Training). Erkennung: statistische Tests (Kolmogorov-Smirnov, Population Stability Index), Visualisierung (Feature-Verteilung Training vs. aktuell).
- Concept Drift: Die Beziehung zwischen Features und Target ändert sich (was früher Churn-Indikatoren waren, ist es heute nicht mehr). Schwerer zu erkennen, erfordert Ground-Truth-Feedback.
- Performance Monitoring: Wenn Ground Truth verfügbar (z.B. „hat der Kunde tatsächlich gekündigt?") -> Accuracy, Precision, Recall live messen. Wenn nicht verfügbar -> Proxy-Metriken (Prediction Confidence, Feature Drift als Frühwarnung).
- Monitoring-Tools: Evidently AI (Open Source, Drift-Reports und Dashboards), NannyML (CBPE - Confidence-Based Performance Estimation ohne Ground Truth), Whylogs (Lightweight Feature Logging), Grafana + Prometheus (Custom Metriken).
- Praxis-Übung: Evidently AI für das Churn-Modell einrichten: Drift-Report generieren (Training vs. aktuelle Daten), Data-Drift-Dashboard aufsetzen, Schwellenwert für Alert konfigurieren (PSI > 0.2 -> E-Mail-Benachrichtigung). Drift simulieren: Feature-Verteilung absichtlich ändern -> Alert auslösen.
- Retraining-Trigger: Zeitbasiert (jeden Monat neu trainieren - einfach, aber verschwendet Ressourcen wenn kein Drift), Drift-basiert (nur neu trainieren wenn Drift erkannt wird - effizienter), Performance-basiert (nur neu trainieren wenn Accuracy unter Schwellenwert fällt - ideal, aber erfordert Ground Truth).
- Continuous Training Pipeline: Drift erkannt -> neue Daten laden -> Feature Engineering -> Training -> Evaluation -> wenn besser als Produktion -> Deployment (automatisch oder nach Approval) -> altes Modell archivieren. Die vollautomatische ML-Pipeline.
- Datenqualitäts-Checks: Bevor ein Retraining startet: sind die neuen Daten vollständig? Gibt es Ausreißer? Fehlen Features? Great Expectations oder Pandera für automatisierte Datenvalidierung.
- Praxis-Übung: Retraining-Pipeline aufbauen: Drift-Alert -> Datenqualitätsprüfung -> Retraining -> Evaluation -> wenn besser als aktuelles Modell -> automatisches Deployment -> Notification. End-to-End durchspielen: Drift simulieren -> Pipeline läuft automatisch -> neues Modell in Produktion.
MLOps-Architektur-Patterns (20 Min):
- Einfach starten: Git + MLflow + FastAPI + Evidently - kein Kubernetes nötig, läuft auf einem Server. Für kleine Teams (1-3 Data Scientists).
- Skalieren: Kubernetes + Kubeflow/ZenML + Seldon/KServe + Feast + Evidently - für mittlere/große Teams (5+ Data Scientists, mehrere Modelle in Produktion).
- Cloud-Managed: SageMaker Pipelines (AWS), Vertex AI Pipelines (GCP), Azure ML Pipelines - weniger Eigenverantwortung, mehr Vendor-Lock-in.
- Build vs. Buy: Wann eigene Infrastruktur, wann Managed Services? Entscheidungskriterien: Team-Größe, Modell-Anzahl, Compliance, Budget, Cloud-Strategie.
- Phase 1 - Eigene MLOps-Architektur entwerfen (35 Min): Für das eigene ML-Projekt (oder vorgegebenes Szenario): ML-Lifecycle dokumentieren (welche Schritte, welche Tools), Toolauswahl treffen (Experiment Tracking, Pipeline, Serving, Monitoring), Deployment-Strategie wählen (Shadow/Canary/Blue-Green), Monitoring-Plan (welche Metriken, welche Schwellenwerte, welche Alerts), Retraining-Strategie (zeitbasiert/drift-basiert/performance-basiert).
- Phase 2 - Peer-Review (15 Min): Architektur vorstellen. Stresstest: „Euer Modell liefert plötzlich 30 % schlechtere Ergebnisse - wann bemerkt ihr das und was passiert automatisch?" „Eine Data Scientistin verlässt das Team - kann ihr Nachfolger das letzte Experiment reproduzieren?" „Das Training dauert 4 Stunden - was passiert wenn es mitten in der Nacht fehlschlägt?" „Zwei Data Scientists trainieren gleichzeitig dasselbe Modell mit verschiedenen Features - wie verhindert ihr Konflikte?"
Zielgruppe & Vorkenntnisse
- Data Scientists: Die Modelle in Jupyter Notebooks entwickeln, aber nicht wissen, wie sie diese reproduzierbar, versioniert und automatisiert in Produktion bringen.
- ML Engineers und Platform Engineers: Die ML-Infrastruktur für Data-Science-Teams aufbauen und betreiben.
- DevOps Engineers: Die CI/CD beherrschen, aber ML-spezifische Anforderungen (Daten-Versionierung, Experiment Tracking, Model Registry, Drift Monitoring) noch nicht kennen.
- Data-Science-Teamleiter: Die einen strukturierten MLOps-Prozess etablieren - statt Ad-hoc-Deployments per E-Mail.
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
 GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| Preisvorteil | ||
Dritter Mitarbeitende nimmt kostenfrei teil. Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet. Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen. | ||
| KOMPASS — Förderung für Solo-Selbstständige | ||
Solo-Selbstständige können für dieses Seminar eine Förderung via KOMPASS beantragen. | ||
| All-Inclusive | ||
Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Buchen ohne Risiko
| Rechnungsstellung |
Erst nach dem erfolgreichen Seminar. Keine Vorkasse. |
| Stornierung |
Kostenfrei bis zum Vortag des Seminars |
| Vormerken statt buchen |
Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 24.08.-26.08.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 02.11.-04.11.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 2027 | ||||
| 11.01.-13.01.2027 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 29.03.-31.03.2027 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 31.05.-02.06.2027 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
Inhouse-/Firmenschulung
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Nachbetreuung
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
FAQ für Offene Schulungen
Welche Schulungsform ist ideal für mich?
- Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
- Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
- Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
- Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.
Wie kann ich an einer Online Schulung teilnehmen?
Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.
In drei Schritten zum Online Seminar im Virtual Classroom:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- Formular ausfüllen und über den Button "Jetzt buchen" absenden.
Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.
Was ist ein Virtual Classroom?
Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.
Vorteile von Virtual Classroom:
- Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
- Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
- Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
- Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
- Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
- Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
- Sie sparen Reisekosten und Zeit
Welche gesicherten Termine gibt es?
- 24. Aug. - 26. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 02. Nov. - 04. Nov. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 11. Jan. - 13. Jan. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 29. Mär. - 31. Mär. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 31. Mai - 02. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
- Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
Shuttle-Service
Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.
Hotelreservierung
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Kostenfreies Storno
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Technik-Support
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.