Ziel, Bestand, Nutzen

Zuerst wird geklärt, was tatsächlich gebaut werden soll, welche Systeme und Daten dafür bereits vorhanden sind, und welchen Nutzen das Ergebnis für den Betrieb bringen soll. Diese drei Fragen werden in einem Durchgang beantwortet, bevor ein Angebot steht, nicht danach. So steht der erwartete Nutzen schon vor dem ersten Code fest, nicht erst am Ende der Umsetzung.

Machbarkeit, PoC, Kosten

Vor jeder Investition wird geprüft, was technisch tatsächlich möglich ist: Ein kleiner Proof of Concept zeigt es an der echten Aufgabe, nicht in einer Präsentation oder einem Whitepaper. Aus dem PoC ergibt sich eine belastbare Kostenschätzung für die volle Umsetzung. Erst danach fällt die Entscheidung, ob überhaupt gebaut wird.

Lieferung und Ansprechpartner

Vor dem Start steht fest, wer welchen Teil der Umsetzung liefert und wer auf beiden Seiten der Ansprechpartner für Rückfragen ist. Jede Aufgabe hat eine Person dahinter, keine geteilte Zuständigkeit ohne Namen. So ist von Anfang an klar, wen man bei einer Abweichung oder einer offenen Frage erreicht.
Zielbild zuerst
Zielbild und Nutzen stehen fest, bevor Sie Budget freigeben
Praxistest zuerst
die Kostenschätzung entsteht aus dem Test an Ihrer eigenen Aufgabe
Klare Zuständigkeit
jede Lieferung ist namentlich zugeordnet, mit festem Termin
Direkter Draht
genannte Ansprechpartner stehen auf jeder Seite vor dem Start fest

Wie aus dem Bedarf ein Plan mit Kosten und festen Ansprechpartnern wird

Ziel und Bestand klären 3 Schritte
01

Was gebaut werden soll

Am Anfang steht eine klare Beschreibung dessen, was tatsächlich gebaut werden soll: welches Problem gelöst wird, für wen, und in welchem Umfang. Diese Beschreibung wird schriftlich festgehalten, bevor irgendetwas geplant oder geschätzt wird, damit alle Beteiligten vom selben Ziel ausgehen.
02

Was bereits vorhanden ist

Bestehende Systeme, Daten und Prozesse werden erfasst, bevor etwas Neues entsteht: welche Anwendungen schon laufen, welche Daten bereits vorliegen und welche Teile der Aufgabe schon gelöst sind. So wird nichts doppelt gebaut, was es im Betrieb längst gibt.
03

Der erwartete Nutzen

Für jedes Vorhaben steht fest, welchen Nutzen es bringen soll, in Zeit, Geld oder Qualität, und wie dieser Nutzen gemessen wird. Der erwartete Nutzen wird vor dem Start festgehalten, nicht erst rückblickend behauptet, sodass sich das Ergebnis später daran messen lässt.
Machbarkeit und Kosten prüfen 3 Schritte
04

Technische Machbarkeit geprüft

Bevor investiert wird, wird geprüft, ob sich die Anforderung mit den vorhandenen Systemen und Schnittstellen überhaupt umsetzen lässt. Offene technische Fragen werden benannt und einzeln geklärt, statt sie in die Umsetzung mitzunehmen.
05

Proof of Concept an der echten Aufgabe

Ein kleiner Proof of Concept zeigt die Machbarkeit an der echten Aufgabe, mit echten Daten, statt an einer Präsentation. Das Ergebnis zeigt, ob der gewählte Ansatz trägt, bevor die volle Umsetzung beginnt.
06

Kostenschätzung für die volle Umsetzung

Aus dem Proof of Concept ergibt sich eine belastbare Kostenschätzung für die volle Umsetzung, mit Aufwand pro Baustein statt einer einzelnen Gesamtzahl. Diese Schätzung liegt vor der Entscheidung vor, nicht danach, und wird mit dem tatsächlichen Aufwand verglichen, sobald gebaut wird.
Wer welchen Teil liefert 2 Schritte
07

Wer welchen Teil liefert

Jede Aufgabe der Umsetzung bekommt einen Namen dahinter: wer sie liefert, bis wann, und wogegen das Ergebnis abgenommen wird. Diese Zuordnung steht schon im Plan fest, nicht erst, wenn eine Aufgabe liegen bleibt, und wird bei jeder neuen Aufgabe mitgeschrieben.
08

Eine Zuständigkeit pro Ergebnis

Für jedes Ergebnis gibt es genau eine zuständige Person, keine geteilte Verantwortung ohne Adresse. Das gilt für jede einzelne Lieferung, vom ersten Prototyp bis zur Übergabe, und wird im Plan neben der jeweiligen Aufgabe festgehalten.
Ansprechpartner und Übergabe 2 Schritte
09

Ein Ansprechpartner auf jeder Seite

Für Rückfragen steht auf beiden Seiten ein fester Ansprechpartner fest, nicht ein allgemeines Postfach. Wer bei einer Abweichung entscheidet und wer im Alltag erreichbar ist, wird vor dem Start benannt, mit Namen und direktem Kontaktweg, und im Plan festgehalten.
10

Übergabe mit klaren Kontakten

Der Plan verlässt die Fact-Gathering-Phase mit dem Zielbild, der Kostenschätzung und der Liste der Ansprechpartner auf beiden Seiten. Das ist, was die Umsetzung braucht, um ohne weitere Rückfragen zu starten, und was jede spätere Abweichung an einem Namen statt an einer Vermutung misst.

Häufige Fragen

Was übergibt ein Fact-Gathering-Durchgang konkret?
Drei Dinge. Einen Scaffold Contract, der den File Tree, den zuständigen Track pro Pfad und jedes gemeinsame Interface wörtlich festlegt, damit sechs Tracks parallel bauen. Eine Provenance-Aufzeichnung, die zu jeder Zahl das Artifact nennt. Und eine Drift-Liste, die aufführt, wo zwei Datenstände sich widersprechen, etwa ein veraltetes Manifest oder ein DNS Record, der auf eine Box zeigt, die uns nicht mehr gehört.
Was passiert mit einer Zahl, die keine Quelle hat?
Sie erscheint als gestalteter Empty State, mit der Begründung am Bildschirm, und das Provenance-Dokument hält fest, warum leer richtig ist. Bei einem Build wurden drei von fünf Datenfiles absichtlich leer ausgeliefert: Es gab keinen Test-Report-Generator, keine Korrespondenz mit der Gegenseite und nie eine gestellte Rechnung.
Funktioniert das nur auf einer Codebase?
Dieselben Reader laufen über Media Libraries, Dokumentenordner sowie Zeit- und Abrechnungsdaten. Ein zusammengeführtes Medien-Repository trägt die Provenance pro Pfad und die exakten Source Commits, und eine Billing Journey rekonstruiert ein Engagement aus dem Time Ledger, damit deklarierte und abgeleitete Stunden übereinstimmen. Eine Zahl ohne aufgezeichnete Session dahinter taucht nie auf.
Ist die Prüfung nach DSGVO und EU AI Act ein eigenes Projekt?
Sie läuft im selben Durchgang, bevor AI an Unternehmensdaten kommt. Geprüft werden die Systeme, die bereits in Production laufen, die Risikoklasse wird zugeordnet und die Stellen benannt, an denen personenbezogene Daten verarbeitet werden. Aufgaben mit personenbezogenen Daten werden markiert und geprüft. Heraus kommen Checklisten pro Stakeholder-Rolle und Onboarding-Material, damit auch Menschen außerhalb der IT damit arbeiten können.