Ein IT-Projekt mit KI – Entwicklungsprozess, Werkzeuge und Ergebnisse

Wie wir mit KI arbeiten – und was dabei entstanden ist

Warum es diese Seite gibt

Bei Resultment wird unter Federführung von Michael Brokmann mit künstlicher Intelligenz gearbeitet – nicht als Versuch, sondern im laufenden Betrieb. Diese Seite zeigt beides: wie dabei vorgegangen wird und was auf diese Weise bereits entstanden ist. Sie ist der Beleg für eine Aussage, die sich sonst schwer nachweisen lässt – dass sich mit KI nicht nur erproben, sondern liefern lässt.

Es handelt sich um ein internes IT-Entwicklungsprojekt der Resultment GmbH. Alles hier Gezeigte ist im laufenden Betrieb entstanden – kein Konzept, keine Studie.

Was hier zu holen ist

Die Vorhaben sind sehr verschieden – Belege verarbeiten, Verstreutes zusammenführen, täglich Quellen sichten, Webauftritte betreiben. Gemeinsam ist die Art der Aufgabe: wiederkehrende Arbeit, die sich erst rechnet, wenn sie ohne Aufsicht zuverlässig läuft. Eines fällt heraus – die Testsuite: Sie prüft, ob das Übrige noch trägt, und meldet, wo sie selbst nichts prüft. Daran zeigt sich, was sich heute abgeben lässt und wo die Grenzen liegen.

Keine dieser Aufgaben ist besonders. Es sind dieselben, die in vielen Unternehmen liegen bleiben, weil sich der Aufwand von Hand nicht rechnet. Die Verfahren dahinter sind nicht auf einzelne Fälle zugeschnitten, sondern auf die Art des Problems – und damit auf vergleichbare Aufgaben anderswo übertragbar. Und das ist nicht am Reißbrett entstanden. Jede Regel in diesem Prozess geht auf einen konkreten Vorfall zurück – einen Test, der falsch grün war; eine Zusicherung, die ihren Nachweis verlor; zwei Sitzungen, die sich gegenseitig überschrieben.

1

WIE

Der Prozess

Anforderungen als eigene Vorgänge. Ein Vorgangsfluss mit fünf Stufen und zwei Toren, an denen ein Mensch entscheidet – Freigabe und Abnahme. Vorgangsverwaltung in Jira, Wissen in Confluence. Zwei Testebenen: End-to-End- und Smoke-Tests über die echte Naht und eine Regression für den Bestand. Verifikation vor jeder Abnahme, ein Auslieferungs-Tor, das bei Rot blockiert, und tägliche Prüfläufe im Betrieb.

Anforderungen als eigener Vorgangstyp – dauerhafte Zusicherung statt Erledigungsvermerk
Fünf Statusstufen, zwei menschliche Tore: Freigabe und Abnahme
Refinement vor der Umsetzung, Entscheidungen zur Abstimmung statt still getroffen
End-to-End- und Smoke-Tests über echte Einstiegspunkte · Regression für den Bestand · Fall-Register
Verifikation als Bedingung, nicht als Absicht – belegt am Vorgang
Auslieferung blockiert bei rotem Test; Betrieb prüft täglich still nach
Vereinbarungen schriftlich: ein versioniertes Regelwerk für die Zusammenarbeit

Der Ablauf – und wie weit er trägt

Anforderung umgesetzt

Fachliches Refinement umgesetzt

Beauftragung umgesetzt

Architektur / Technisches Refinement in Planung

Umsetzung umgesetzt

Verifikation in Umsetzung

Abnahme umgesetzt

Auslieferung in Umsetzung

Betrieb umgesetzt

Zum Prozess →

2

WER

Die Rollen

Gearbeitet wird rollenbasiert – nicht „die KI macht das schon“. Jede Rolle eines echten IT-Projekts ist benannt und einer Besetzung zugeordnet: Mensch, KI-Agent oder deterministischer Code. Was noch niemand ausfüllt, steht als offen da. Dazu Personas, gegen die Inhalte kalibriert werden.

29 Projektrollen, benannt und zugeordnet – von Product Owner bis Revision
Drei Besetzungsarten: Mensch, KI-Agent und deterministischer Code
6 der 29 Rollen sind heute nicht besetzt
Personas als Zielgruppen-Stellvertreter, gegen die Inhalte geprüft werden

Zu den Projektrollen →

3

WAS

Die Ergebnisse

Was in diesem Prozess und mit diesen Rollen entstanden ist: Werkzeuge, wiederverwendbare Bauteile und daraus zusammengesetzte Lieferergebnisse – in drei aufeinander aufbauenden Ebenen.