Viele denken bei Modellierung im Requirements Engineering sofort an UML, Diagramme, Symbole und Notationen. Doch echte Modellierung beginnt nicht erst beim Zeichnen, sondern bereits bei der Frage, welche Sicht auf die Realität ein Modell überhaupt zeigen soll.
WeiterlesenChatGPT, Copilot und Co. sind in vielen Unternehmen angekommen. Erste Anwendungsfälle wurden identifiziert, Mitarbeitende sammeln Erfahrungen und die Erwartungen an Künstliche Intelligenz sind hoch.
Trotzdem bleibt der große Produktivitätsschub häufig aus.
Daten werden exportiert, manuell in Chatbots kopiert und die Ergebnisse anschließend wieder zurück in bestehende Systeme übertragen. Was zunächst innovativ wirkt, entwickelt sich schnell zu einem zusätzlichen Arbeitsschritt.
Die Folge: KI unterstützt einzelne Aufgaben, verändert aber nicht die eigentliche Wertschöpfung.
Die entscheidende Frage lautet deshalb nicht mehr:
„Können wir KI nutzen?“
Sondern:
„Wie schaffen wir den Übergang von einzelnen Experimenten zu echter, nachhaltiger Automatisierung?“
Genau hier beginnt die Reise von der heutigen „Prompt-Welt“ hin zu produktiven KI-gestützten Prozessen und langfristig zu Agentic AI.
Teil 6: Gesund statt groß – Warum Systeme nicht wachsen, sondern reifen sollten
Mehr ist nicht reifer. Mehr ist nicht besser. Mehr ist oft: schädlicher
Wenn wir in unseren Coachings ein System analysieren, sehen wir oft beeindruckende Zahlen: Tausende Zeilen Code. Dutzende Module. Hunderte Funktionen.
Und dann die Fragen, die niemand gern beantwortet:
Was davon wird wirklich gebraucht?
Was davon ist dokumentiert, gewartet, getestet – und verstanden?
Warum KI das Requirements Engineering nicht verdunkelt, sondern neu ausleuchtet
In der industriellen Fertigung wird seit Jahren über sogenannte „Lights-out-Fabriken“ oder „Dark Factories“ diskutiert. Gemeint sind Produktionsumgebungen, in denen Maschinen nicht nur fertigen, sondern auch planen, optimieren und anpassen, weitgehend ohne menschliches Eingreifen.1 Was lange futuristisch klang, ist inzwischen Realität.
WeiterlesenIn unserer Arbeit mit Produktteams, System Engineers und Requirements Engineers begegnet uns eine Frage immer wieder – und sie ist fast schon ein Reflex:
„Was sind euere Anforderungen an das System?“
Die Intention ist gut. Die Wirkung oft fatal. Denn: Die Mehrzahl aller Projekte scheitert nicht an der Technik – nicht an Java-Versionen, Container-Setups oder Testabdeckung. Sie scheitert daran, dass Anforderungen geschrieben werden, bevor überhaupt klar ist, was wirklich gebraucht wird.
Willkommen im Requirements Engineering, wie wir es nicht mehr brauchen.
