Warum KI im Ingenieurbüro?
KI ist überall – und natürlich diskutieren auch wir Systems Engineers, wie wir sie sinnvoll im Arbeitsalltag nutzen können. Doch einfach meinen kompletten Prozess in eine KI kippen und sagen „mach mal“? Das hat nicht funktioniert.
Mein Ziel mit dem KI‑Projekt
Ich möchte herausfinden:
- Welche Schritte meines Lastenheft-Prozesses lassen sich von KI unterstützen?
- Wie muss ich meine Arbeitsweise anpassen, damit KI wirklich nützlich ist?
- Wo liegen die Grenzen, wo bleibt die menschliche Expertise unersetzlich?
Die sechs Teile meiner KI‑Reise
Ich nehme dich in mehreren Episoden mit:
- Zielklärung – Was will ich mit KI überhaupt erreichen?
- Erkenntnisse aus dem ersten KI-Agenten – Was hat funktioniert, was nicht?
- Der zweite Agent: Richard Anford – Der „Anforderungsschreiber“
- Die Prüfung – Ein Konsistenz-Agent bewertet die Ergebnisse
- Mein Fazit – Was kann KI wirklich leisten, was (noch) nicht?
- Optionaler Vergleich – Was passiert, wenn jemand anderes das gleiche Problem mit einer anderen Agenten-Architektur löst?
Ich arbeite im RE traditionell mit meiner bewährten Fünf‑Schritte-Methode, um zu einem freigegebenen Lastenheft zu kommen:
- Erfassen
- Sortieren
- Füllen
- Prüfen
- Freigeben
Meine Frage: Wo kann KI sinnvoll unterstützen?
- Erfassen: Ja, KI kann helfen → Dokumentefresser
- Sortieren: Nein, das bleibt individuell und kundenspezifisch
- Füllen: Ja, hier soll Agent „Richard Anford“ aktiv werden
- Prüfen: Ja, ein Konsistenz-Agent kann unterstützen
- Freigeben: Nein, das bleibt ein menschlicher Entscheidungsschritt
Ich brauche drei KI-Agenten, die jeweils definierte Aufgaben übernehmen.
Agent 1: Der Dokumentenfresser
Dieser Agent analysiert Dokumente, extrahiert Inhalte und bereitet sie so auf, dass ich:
- schneller die relevanten Punkte erkenne
- Redundanzen finde
- Lücken identifizieren kann
- und später strukturiert sortieren kann
Eine Darstellung meines System Footprint – aber diesmal vollgepackt mit gelben Notizzetteln, so wie wir sie in einem echten Workshop einsetzen würden.
Der System Footprint als Startpunkt
Im ersten Schritt geht es ums Erfassen.
Und das mache ich ganz traditionell: mit dem System Footprint und einem Workshop.
- Benutzer & Stakeholder
- Anwendungsfälle
- Hauptfunktionen
- Komponenten & Liefergegenstände
- Schnittstellen
- technische Einschränkungen
- und natürlich im Zentrum: das Nutzerversprechen
Der Footprint ist die Basis für jedes Kundenprojekt – und auch für meinen KI‑Testlauf.
Beispielprojekt: NeoCharge AmpereCube
Für das KI-Projekt habe ich ein Beispielprodukt genutzt:
Eine fiktive, KI-generierte Wallbox namens NeoCharge AmpereCube.
Ein System Footprint voller gelber Zettel, die alle Anforderungen, Funktionen und Limitierungen darstellen, die wir im Workshop gesammelt haben.
Wie geht es weiter?
In der nächsten Episode und im nächsten Blogartikel zeige ich:
- Wie der Dokumentefresser die Workshop‑Ergebnisse weiterverarbeitet
- Welche Probleme dabei aufgetreten sind
- Wo KI überraschend gut funktioniert
- und wo sie noch komplett versagt
Ich verspreche: Es bleibt spannend – und sehr praxisnah.
Meine Tools
LangDock – Multi-Modell KI
Obsidian: Notizen-Werkzeug
Markdown: Sprache die in Obsidian genutzt wird
Klicke hier, um Ihren eigenen Text einzufügen
Klicke hier, um Ihren eigenen Text einzufügen
