Vom validierten Umfang zu GO-LIVE READY.

Weil der Preis dem Umfang folgt und der Umfang erst nach Abschluss von Assess validiert ist. Danach wird EINE feste Implement-Gesamtsumme freigegeben und in Ihrem Konto angezeigt. Eine vorab veröffentlichte Zahl wäre ein Versprechen über einen unbekannten Umfang.

Nein. Die Messung eines laufenden Systems verlangt kein Folgeprojekt; sie kann sogar ergeben, dass keine Maßnahme nötig ist. Implement ist nicht der voreingestellte nächste Schritt.

Budgets brechen selten an einem großen Fehler, sondern an derselben sich wiederholenden Mechanik: Die Arbeit wird bepreist, bevor der Umfang geschrieben ist. Der Vertrag sagt Kapazität zu (Personentage), während der Umfang erst im Projektverlauf entsteht; jede neue Erkenntnis wird zum Änderungswunsch, jeder Wunsch zu weiteren Tagen. Drei typische Quellen: (1) nicht erfasste Prozesse — Neben-Tabellen, informelle Freigaben, ein abweichender Ablauf im Lager; (2) Datenmigration — Altdaten liegen nicht in der erwarteten Form vor, meist erst im Test sichtbar; (3) Entscheidungsverzug — eine offene fachliche Entscheidung lässt dieselbe Arbeit nach Entwicklungsbeginn zweimal machen. Alle drei führen auf dieselbe Ursache: Der Umfang wurde NACH der Zusage entdeckt. MindDX dreht die Reihenfolge um — der Preis baut auf einem validierten Umfang.

Fünf Vorbereitungen kommen vor jeder technischen Einrichtung. (1) Entscheidungs-Eigentümerschaft: Wer je Prozess entscheidet, muss schriftlich feststehen; ein Prozess ohne Namen bleibt mitten im Projekt stehen. (2) Datenzustand: Stammdaten (Kunden, Artikel, Bestand, Lieferanten) müssen bereinigt und fehlende Felder vorab bekannt sein — Migration misst man in der Vorbereitung, nicht im Test. (3) Prozessinventar: wie das Geschäft heute tatsächlich läuft, schriftlich, inklusive nicht erfasster Abläufe. (4) Umfangsentscheidungen: jede Lücke bereits entschieden als „anpassen / Prozess ändern / nicht im Umfang“. (5) Anwenderbereitschaft: welche Rolle welche Maske wie nutzt, geklärt vor der Schulung. Fehlen diese fünf, startet das Projekt trotzdem — der Umfang kommt dann später. Bei MindDX liegen die ersten vier in Assess, die fünfte in Implement.

Ein Blueprint ist die schriftliche Antwort auf die Frage „Was genau bauen wir?“ in einem ERP-Projekt: der Zielzustand der Prozesse, welche Systemfunktion jeden Prozessschritt abdeckt, die Fit/Gap-Entscheidungen und die Begründung jeder Entscheidung. Er ist keine Funktionsliste — Listen sagen, was gewünscht wird, ein Blueprint sagt, WIE es funktionieren wird. Ein guter Blueprint trägt drei Dinge zugleich: (a) den Ziel-Prozessablauf, (b) die zugehörige Systemkonfiguration, (c) was aus dem Umfang genommen wurde und warum. Das dritte wird am häufigsten übersprungen und ist am teuersten: ein nie notiertes „nicht im Umfang“ kehrt später als „vergessene Anforderung“ zurück. Bei MindDX ist der Blueprint das Ergebnis von Discover und der Eingang zu Implement — keine Präsentation, sondern das Dokument, auf dem die Umsetzung ruht.