Kernkompetenzen
Fünf Kompetenzbereiche mit konkreten Beispielen aus der Praxis.
Prozessarchitektur & Digitalisierung
Bestehende Abläufe analysieren, optimierte Soll-Prozesse designen und als digitale Lösung end-to-end umsetzen.
Einen Prozess nicht nur dokumentieren, sondern tiefgreifend verstehen, hinterfragen und in eine digitale Form überführen, die messbar besser funktioniert als das Original. Digitalisierung als präzises Werkzeug für operative Exzellenz.
Der geschlossene Prozess-Regelkreis
Ausgangslage
In vielen Industrieunternehmen sind Prozesse klassisch in statischen Dokumenten wie Word oder Visio definiert. Die operative Ausführung verteilt sich auf E-Mails und ERP-Eingaben. Die Messbarkeit der Prozesseffizienz ist dadurch erschwert, da strukturierte Daten zur Auswertung fehlen.
Ein geschlossener Regelkreis aus drei digitalen Bausteinen.
Digitales Turtle-Diagramm
Turtle-Diagramme sind ein Standardwerkzeug im Qualitätsmanagement (IATF 16949) zur Prozessdefinition. Die implementierte digitale Variante geht weit über das statische Original hinaus. Sie ermöglicht kollaborative Versionierung mit parallelen Child-Versionen. Stakeholder befüllen diese, der Process Owner führt sie zusammen (Merge). Die Prozessdefinition wird vom einmaligen Dokument zum lebenden, nachvollziehbaren Vorgang.
Digitalisierter Freigabe-Workflow (Engineering -> Arbeitsvorbereitung)
Ein konkreter Anwendungsfall ist der Freigabeprozess zwischen Engineering und Arbeitsvorbereitung. Dieser lief über E-Mails und ERP-Eingaben, was systembedingte Reibungsverluste und fehlendes Tracking mit sich brachte.
- › Relevante ERP-Daten werden automatisch in den Vorgang geladen für eine schnelle Entscheidungsgrundlage
- › Bekannte Reibungspunkte sind proaktiv gelöst (integrierte Templates, vordefinierte Stakeholder-Auswahl, 1-Click Outlook-Web-Integration mit Kontextdaten)
- › Neue Reibungspunkte können von Mitarbeitern direkt gemeldet und nach Auswertung in die KPI-Erfassung aufgenommen werden
- › Der gesamte Ablauf wird visuell als Kanban-Board gesteuert (Neu -> In Arbeit -> Erledigt -> Archiviert)
- › Ein Vorgang gilt erst als abgeschlossen, wenn der Nutzer ihn bewertet hat (Gut / In Ordnung / Schlecht, inklusive Angabe von Zeitverlusten)
- › Diese erfassten Bewertungen fließen als messbare KPIs direkt zurück in das Turtle-Diagramm
Knowledge Base & RAG
In EntwicklungDie strukturierten Daten aus den Prozess-Versionen und Workflow-Ausführungen bilden die Basis für eine Knowledge Base. Durch die kontextuelle und geordnete Datenstruktur von Beginn an eignet sich das System ideal für Retrieval-Augmented Generation (RAG). Konkret bedeutet das: Fragen wie "Welche Probleme hatten wir beim letzten Mal mit der Freigabe für Projekt X?" lassen sich fundiert beantworten, weil die Daten nicht in E-Mail-Verläufen vergraben sind.
Prozess definieren (Turtle) -> Prozess ausführen (Webapp-Workflow) -> Prozess messen (KPIs, Ratings, Zeitverluste) -> Prozess verbessern (zurück zum Turtle). Dieser Regelkreis läuft produktiv und generiert mit jedem Durchlauf bessere Daten.
Datengetriebene Steuerung
Entscheidungen auf Basis von Daten ermöglichen. Von der Datenquelle bis zum Dashboard.
Daten aus operativen Systemen extrahieren, aufbereiten und gezielt visualisieren. Entscheidungsträger erkennen Engpässe auf einen Blick. Nicht nur Reports bauen, sondern die richtigen Fragen stellen und die Infrastruktur schaffen, die belastbare Antworten liefert.
Vom ERP-System zum Entscheidungswerkzeug
Ausgangslage
Ein ERP-System enthält alle operativen Daten. Aber Zugang, Aufbereitung und abteilungsübergreifende Nutzung dieser Daten erfordert eine eigene Infrastruktur.
Eine Daten-Pipeline vom ERP bis zum Shopfloor.
Die Pipeline
Die ERP-Daten (AP+, MSSQL) dienen als Quelle. Eine read-only Schatten-Datenbank stellt sicher, dass das produktive ERP-System durch Abfragen nicht belastet wird. Ein automatisierter Python-ETL-Job synchronisiert die relevanten Daten in PostgreSQL. Django verarbeitet die Daten als Backend, Vue 3 mit ECharts visualisiert sie als interaktive Dashboards und Planungstools.
Shopfloor-Dashboards
Sechs Abteilungen arbeiten mit abteilungsspezifischen Dashboards, vom Engineering bis zur Maschinen-Programmierung.
- › Ist/Soll-Vergleich der Ressourcen-Arbeitszeit pro Projekt und Baugruppe
- › Verlaufskurve: liegt das Projekt im erwarteten Bereich oder weicht es ab
- › Kommentarfunktion mit Audit-Charakter, einsehbar für Stakeholder
Kapazitätsplanung
Planung der produktiven Abteilungen mit Engpass-Erkennung. Dashboard mit Auslastungskurve pro Abteilung und Gesamtübersicht. Nicht freigegebene Projekte können als Simulation eingeplant werden, um Kapazitäten bereits im Angebotsprozess zu prüfen.
- › Zweistufiges Versionierungssystem: Hauptversionen bei Änderunge der Rahmenbedingungen (Termin / Budget), tägliche Snapshots als Minor-Versionen für lückenlose Nachvollziehbarkeit
- › Neue Projekte werden automatisch aus dem ERP erkannt
- › Projektleiter gibt die Planung mit Deadline frei, Abteilungsleiter planen ihre Ressourcen direkt in der WebApp
- › Algorithmen für Schnellzuteilung (Gleichmäßig, ASAP, ALAP) mit automatischer Berücksichtigung von Urlaub, Feiertagen und Verteilzeit
- › Bei geänderten Rahmenbedingungen: neue Hauptversion, betroffene Abteilungsleiter werden automatisch zur Neuplanung aufgefordert
- › Kanban-Boards für Projektleiter und Abteilungsleiter
- › Automatisierte Benachrichtigungen via MS Teams
- › Temporäre Mitarbeiter-Ausleihe zwischen Abteilungen
- › Separate Planung interner Projekte, differenziert im Dashboard sichtbar
Projektleiter und Abteilungsleiter treffen Entscheidungen auf Basis aktueller Daten statt auf Basis von Rückfragen und Schätzungen. Engpässe werden frühzeitig sichtbar, Planungsänderungen sind nachvollziehbar.
Supply Chain & Operations
Materialfluss, Lieferketten und operative Abläufe end-to-end steuern. Vom Lieferanten bis zur Montage.
Das operative Rückgrat. Ware muss zum richtigen Zeitpunkt am richtigen Ort sein, Engpässe müssen früh erkannt werden, und die gesamte Kette muss als System verstanden werden, nicht als Summe von Einzelschritten.
Transparenz über die gesamte Materialversorgungskette
Ausgangslage
Beschaffung, Lager und Montage arbeiten mit denselben ERP-Daten, aber in getrennten Sichten. Die externe Materialversorgung (Lieferanten) und die interne (Lager bis Montage) waren nicht als zusammenhängende Kette sichtbar. Verzüge wurden oft erst spät erkannt, Eskalationen liefen informell.
Zwei WebApp-Module, die die Kette durchgängig abbilden.
SCM Tracking (Externe Materialversorgung)
Die ERP-Daten werden als Baumstruktur dargestellt: Gerät → Baugruppe → Artikel. Diese hierarchische Sicht existiert im ERP nicht und macht Abhängigkeiten sofort erkennbar. Für jeden Artikel werden Bedarfstermin und Liefertermin ausgewertet. Hyperlinks von der WebApp ins ERP stellen sicher, dass Notizen und Ergänzungen dort erfasst werden, wo sie hingehören (Single Source of Truth).
- › Ampelsystem: Grün (Liefertermin vor Bedarfstermin), Orange (1-4 Arbeitstage Verzug), Rot (mehr als 4 Arbeitstage Verzug)
- › Bei Eskalationen werden relevante Abteilungen (Beschaffung) automatisch benachrichtigt
- › Stakeholder können Verzüge bewusst genehmigen, was die Benachrichtigung pausiert. Bei weiterem Überschreiten wird sie automatisch reaktiviert
- › KPIs: Liefertreue pro Lieferant, Material-Qualität pro Lieferant, interne Materialverfügbarkeit
Internes Material-Tracking (Lager bis Montage)
Die interne Seite der Kette. Baumstruktur als Basis, ergänzt durch interaktive Suche nach Artikelnummer oder Name.
- › Montage-Mitarbeiter erstellen Kommissionieraufträge auf Baugruppen-Ebene direkt in der WebApp
- › Das Lager wird automatisch benachrichtigt
- › Bei der Materialausgabe werden Artikel in der WebApp gescannt, das System prüft die Vollständigkeit
- › KPIs: Durchlaufzeit Lager-Kommissionierung, Qualität Lager-Kommissionierung
Die gesamte Materialversorgungskette ist durchgängig sichtbar, vom Lieferanten bis zur Ausgabe an die Montage. Verzüge werden systematisch erkannt und eskaliert statt informell kommuniziert. Die KPIs liefern eine belastbare Grundlage für die Bewertung von Lieferanten und die Optimierung interner Abläufe.
Change Management & Führung
Menschen durch Veränderung führen und neue Arbeitsweisen nachhaltig verankern.
Technische Lösungen sind nur so gut wie ihre Akzeptanz im Alltag. Neue Tools und Prozesse durchzusetzen reicht nicht. Sie müssen so eingeführt werden, dass Teams sie als Verbesserung erleben, nicht als Mehraufwand.
Veränderung verkaufen, nicht verordnen
Ausgangslage
Den Ist-Zustand der Mitarbeiter optimieren und die neuen Arbeitsgänge als Teil des Pakets mitliefern. Wer merkt, dass seine tägliche Arbeit leichter wird, akzeptiert auch neue Elemente wie Bewertungen, KPIs oder strukturierte Workflows.
Frühe Einbindung statt fertiger Übergabe
Key User aus jeder Abteilung werden bereits in der Entwicklungsphase eingebunden. Sie benennen die konkreten Schmerzpunkte aus ihrem Arbeitsalltag und testen frühe Versionen. Das hat zwei Effekte: Die Lösung passt besser, weil sie auf echten Anforderungen basiert. Und die Key User werden zu Multiplikatoren, die das Tool in ihren Teams vertreten, weil sie es mitgestaltet haben.
Niedrige Einstiegshürde
Neue Features werden nicht als separates System eingeführt, sondern in bestehende Abläufe integriert. Beispiel Kapazitätsplanung: Abteilungsleiter haben vorher in Excel geplant. Die WebApp bildet denselben Vorgang ab, ergänzt ihn aber um automatische Berücksichtigung von Urlaub und Feiertagen, Schnellzuteilungs-Algorithmen und eine Versionierung. Der Kern der Tätigkeit bleibt vertraut, der Mehrwert ist sofort spürbar.
Abholung dort wo die Leute arbeiten
Automatisierte Benachrichtigungen laufen über MS Teams, nicht über ein zusätzliches Tool. Direktlinks führen aus der Benachrichtigung in die relevante WebApp-Funktion. Dokumentation ist direkt aus der WebApp aufrufbar und verlinkt auf Docmost mit integrierter Suchfunktion. Jeder Klick weniger zwischen Benachrichtigung und Aktion senkt die Hürde.
Transparenz und Standards schaffen
Kanban-Boards machen den Bearbeitungsstand für alle Beteiligten sichtbar. Workflows definieren klare Zuständigkeiten und Abfolgen. Das reduziert Rückfragen und informelle Abstimmungen. Verbindlichkeit entsteht nicht durch Kontrolle, sondern durch Sichtbarkeit.
Neue Arbeitsweisen werden angenommen, weil sie den Alltag vereinfachen. Die Bewertungsfunktionen, KPI-Erfassung und strukturierten Workflows kommen als natürlicher Bestandteil der verbesserten Prozesse mit, nicht als zusätzliche Pflicht.
Eigeninitiative & Umsetzungsstärke
Komplexe Probleme erkennen, eigenständig das richtige Werkzeug finden und eine produktive Lösung bauen.
Eigenständige technologische Weiterentwicklung generiert direkten Mehrwert. Wer sich neue Methoden selbst erschließt, liefert Lösungen, bevor ein Auftrag formuliert ist. Alle zuvor beschriebenen Systeme entstanden aus genau diesem Antrieb: nicht als Vorgabe, sondern aus proaktiv erkanntem Bedarf im Tagesgeschäft.
Von Null zum produktiven System
Ausgangslage
Fachliches Prozesswissen trifft auf das Ziel, eine technische Lösung zu schaffen. Die Brücke dazwischen: die Bereitschaft, sich die nötigen Entwicklungswerkzeuge selbst zu erarbeiten.
Agentenbasierte Softwareentwicklung als Methode
Die WebApp wurde nicht klassisch programmiert. Sie ist mit KI-Coding-Assistenten (Claude Code, OpenAI Codex) entwickelt. Das erfordert eine eigene Arbeitsweise.
- › Anforderungen so strukturieren, dass KI-Agenten sie umsetzen können
- › Architekturentscheidungen treffen (Technologieauswahl, Datenbankdesign, API-Struktur)
- › Ergebnisse prüfen, iterieren, Qualität sicherstellen
- › Den gesamten Stack verstehen, auch ohne jede Zeile selbst geschrieben zu haben
- › Die aktuelle WebApp läuft in der zweiten Iteration. Die erste Version deckte Architekturfehler auf, die zweite wurde mit diesem Wissen von Grund auf neu konzipiert
- › Qualitätssicherung: Code-Review-Agenten prüfen Änderungen, tiefgründige technische Dokumentation ist Pflicht
- › Ergebnis: produktive Fullstack-Anwendungen (Django, Vue 3, PostgreSQL), die im operativen Tagesgeschäft mit nachweislichem Erfolg eingesetzt werden
Infrastruktur und DevOps
Parallel zur Anwendungsentwicklung wurde die gesamte Infrastruktur eigenständig aufgebaut. Ein Homelab-Server (Proxmox, Ubuntu Server VM) dient als Test- und Entwicklungsumgebung und betreibt alle Services containerisiert über Docker mit Traefik als Reverse Proxy. Lokale LLMs (Ollama, Open WebUI) laufen auf einer separaten Workstation für Entwicklung und Experimente.
RAG-Pipeline: Systematische Weiterentwicklung
In EntwicklungAls methodisches Lernprojekt entstehen zwei RAG-Pipelines auf Basis etablierter Benchmark-Datensätze: FinanceBench (SEC-Finanzberichte) und IBM TechQA (technische Support-Dokumentation). Lokal, ohne Cloud-APIs, auf einer dedizierten Workstation (AMD Threadripper 3960X, 2x NVIDIA RTX A5000 24GB, 128GB RAM, CachyOS Linux).
- › Systematisches Vorgehen: Hypothesen formulieren, Experimente durchführen, Ergebnisse messen und dokumentieren
- › A/B-Testing lokaler Modelle gegen Cloud-Modelle (Claude, GPT, Llama) auf identischen Retrieval-Ergebnissen
- › Technologien: pgvector, Hybrid Search, Embedding-Modelle, Cross-Encoder Reranking, LLM-as-Judge Evaluation
- › Ergebnisse, die mit deutlich größeren Cloud-Systemen mithalten können
Über die Technik hinaus: RAG als Architekturentscheidung
In EntwicklungRAG ist kein fertiges Produkt, das man installiert. Es ist eine Architekturentscheidung mit Tradeoffs, die vom konkreten Anwendungsfall abhängen: Welche Daten liegen vor? Wie strukturiert ist das Corpus? Welche Anforderungen gibt es an die Datenverarbeitung (Open-Source-Modelle halten Daten im Unternehmen, Closed-Source-Modelle senden sie an externe Anbieter)? Welche Genauigkeit ist akzeptabel, und wie wird sie gemessen?
- › Embedding-Modelle arbeiten auf Wortähnlichkeit, nicht auf inhaltlichem Verständnis. Welche Retrieval-Techniken funktionieren, hängt stark von der Domäne und der Datenstruktur ab
- › Hypothese: Selbstverbessernde Pipeline durch Human-in-the-Loop. Die generierte Antwort ist ein Entwurf, ein Mensch validiert anhand der mitgelieferten Quellpassagen. Bestätigte Antworten werden in einen kuratierten Wissensbestand überführt. Der Validierungsschritt ist klein, aber der Hebel ist groß: aus einer ungefähren Antwort wird gesichertes Wissen
- › Das aufgebaute Wissen ist direkt übertragbar, etwa für den geplanten Aufbau einer prozessgestützten Knowledge Base im operativen Umfeld
Problem erkennen -> Anforderung strukturieren -> KI-Agent einsetzen -> Review & Iteration -> Produktives System. Die RAG-Entwicklung findet abseits des Tagesgeschäfts statt, das aufgebaute Wissen ist direkt übertragbar.