Ist Analyse / Feature Definition

Die Ist-Analyse prüft jede bestehende App: welche Funktionen schon vorhanden sind, welche nur halb genutzt werden und wo eine Lücke bleibt. Jede der fünf bewerteten Aufgaben bekommt daraus eine eigene Feature-Definition, bevor der erste Build beginnt. Die Reihenfolge richtet sich danach, welche Lücke sich am schnellsten schließen und beurteilen lässt.

Lösungsansatz definieren

Für jede Aufgabe entscheidet der Plan zwischen zwei Wegen: Low Code mit Claude Cowork oder Copilot Studio für Arbeit in Outlook, Excel und Teams, oder Pro Code als eigener Skill oder MCP Connector für alles, was kein Standardwerkzeug abdeckt. Aufwand und Betriebskosten werden für den gewählten Weg vorab geschätzt, damit die Entscheidung vor dem Build steht statt danach.

Abnahme und Erweiterung

Die Abnahmekriterien stehen fest, bevor der Build beginnt: wer das Ergebnis abnimmt, und was ein richtiges Ergebnis von einem falschen unterscheidet. Nach dem Go-Live behält der Kunde die Kosten jederzeit im eigenen Dashboard im Blick und kann jede Aufgabe von dort aus erweitern, ohne dass dafür ein neues Projekt aufgesetzt werden muss.
Bestehendes nutzen
was schon funktioniert, nutzt der Plan, bevor etwas Neues entsteht
Aufwand und Kosten
stehen auf dem Plan, bevor etwas freigegeben wird
Laufend korrigiert
jede Aufgabe geht für sich live, danach passt sich der Plan an

Ist-Analyse, Lösungsansatz und Abnahme für jede Aufgabe

Von der Ist-Analyse zur Feature-Definition 3 Schritte
01

Die Ist-Analyse beginnt mit dem bewerteten Blatt

Die Ist-Analyse übernimmt das Blatt aus der Discovery: fünf bewertete Aufgaben, jede mit Stunden pro Monat, einer Eignungssumme bis dreißig, einer führenden Route und einem Owner. Für jede Aufgabe prüft die Analyse zusätzlich, welche Funktion in den bestehenden Apps schon existiert und wo die Feature-Definition eine Lücke schließen muss.
02

Zuerst die Aufgabe mit der klarsten Feature-Definition

Die erste Aufgabe wird danach gewählt, wie schnell ihre Feature-Definition steht und sich beurteilen lässt: ein Owner, der ein richtiges Ergebnis erkennt, Systeme, die heute erreichbar sind, und ein Scheitern, das höchstens einen Nachmittag kostet. Die Ersparnis zählt erst an zweiter Stelle.
03

Die Feature-Definition ordnet sich nach Abhängigkeiten

Zwei Aufgaben mit derselben Feature-Lücke und demselben Connector werden gemeinsam eingeplant, zwei ohne Berührungspunkte laufen in beliebiger Reihenfolge. Die Sequenz folgt daraus, welche Aufgaben dieselbe Berechtigung oder dieselbe externe Entscheidung brauchen, mit einer Begründung an jeder Position.
Der Lösungsansatz: Low Code oder Pro Code 3 Schritte
04

Low Code oder Pro Code: die Entscheidung pro Aufgabe

Arbeit in Outlook, Excel oder Teams nimmt den Low-Code-Weg über Claude Cowork oder Copilot Studio. Was kein Standardwerkzeug abdeckt, wird Pro Code: ein eigener Skill oder MCP Connector, zeitlich begrenzt mit einer Entscheidung am Ende und einer festen Budgetobergrenze.
05

Amortisation für beide Lösungsansätze

Baseline, Zielwert und Differenz stehen für beide Wege in derselben Einheit: Stunden pro Monat. Ein Low-Code-Ansatz und ein Pro-Code-Build werden so direkt vergleichbar, und eine Aufgabe, die sich innerhalb eines Jahres nicht amortisiert, steht genau so auf dem Plan.
06

Baukosten und Betriebskosten je Lösungsansatz

Low Code trägt vor allem Lizenzkosten, Pro Code vor allem Modellnutzung pro Lauf und eine fixe Hosting-Zeile. Beide Zahlen, einmaliger Bauaufwand und monatliche Betriebskosten, stehen für den gewählten Weg auf dem Plan, bevor irgendetwas freigegeben wird.
Abnahmekriterien vor dem Build 2 Schritte
07

Jede Aufgabe geht einzeln in die Abnahme

Jede Aufgabe ist so geschnitten, dass sie allein live geht und zur Abnahme bereitsteht, bevor die nächste beginnt. Das kauft das Recht, sich billig zu irren: Eine Annahme, die den ersten Build nicht übersteht, wird bei der nächsten Aufgabe korrigiert.
08

Die Abnahmekriterien stehen vorab fest

Wer das Ergebnis heute abnimmt, schreibt die Kriterien vor dem Build: wie ein richtiges Ergebnis aussieht und was bei einem falschen Ergebnis passiert. Dieser Satz entscheidet, wann der Build aufhört, und an ihm wird die Abnahme gemessen.
Kostenkontrolle und Erweiterung im Dashboard 2 Schritte
09

Die Kosten laufen ab dem Go-Live im Dashboard mit

Sobald der Build läuft, zeigt das eigene Dashboard die Betriebskosten und die neue Baseline in Stunden pro Monat, jederzeit abrufbar statt erst am Monatsende. Die Differenz zur Schätzung ist die tatsächliche Ersparnis, sichtbar für den Kunden selbst.
10

Jeder Build öffnet die nächste Erweiterung

Was der letzte Build gezeigt hat, geht direkt in die nächste Position: welche Systeme wie erwartet liefen, welcher Schritt länger dauerte. Eine Erweiterung setzt an der bestehenden Aufgabe an, ohne dass dafür ein neues Projekt aufgesetzt werden muss.

Häufige Fragen

Worin unterscheidet sich das von der Discovery-Phase davor?
Die Discovery liefert Fakten, diese Phase liefert eine Entscheidung. Die Systemanalyse und eine einzige Session mit dem Büro zählen die wiederkehrenden Aufgaben, messen die Stunden pro Monat, bewerten jede Aufgabe gegen sechs Kriterien und weisen ihr eine führende Route zu. Diese Phase nimmt das bewertete Blatt und klärt, was als Nächstes kommt: welche Aufgabe im September gebaut wird und welche bis November wartet, und was jede im Betrieb kosten wird.
Wie lange dauert die Planung selbst?
Sie wird in Tagen gemessen. Die Arbeit liegt im Schätzen: jede Aufgabe in bekannte und in unbekannte Arbeit teilen, prüfen, ob die Systeme aus ihrer Route tatsächlich erreichbar sind, und die Abnahmekriterien von den Menschen schreiben lassen, die die Ergebnisse heute abnehmen. Heraus kommt ein Plandokument.
Was, wenn sich der Plan als falsch herausstellt, sobald der erste Build startet?
Genau deshalb geht jede Aufgabe einzeln live. Eine Annahme, die den ersten Build nicht übersteht, wird an der zweiten Position korrigiert, und die Reihenfolge wird nach jedem Build neu gelesen. Die Baseline und die Abnahmekriterien bleiben fest, denn beide wurden festgehalten, bevor irgendetwas gebaut wurde, und an ihnen wird die Nachmessung gelesen.
Ist das dieselbe Planung wie für ein Softwareprojekt?
Nein, und das ist Absicht. Ein Engineering-Plan legt einen Dateibaum fest, einen verantwortlichen Track pro Pfad und jedes gemeinsame Interface wortgleich, damit mehrere Build-Tracks gleichzeitig an einer Codebase arbeiten. Dieser Plan ordnet Büroaufgaben gegen die Systeme, die eine Firma schon betreibt, in Stunden pro Monat und Betriebskosten pro Monat. Wenn die Arbeit ein Build auf Ihrer eigenen Codebase ist, gilt die Seite Fact Gathering und Planning auf dem Engineering-Zweig.