Problemorientiert: Erkenne typische D365 Projektprobleme frühzeitig und leite schnell wirksame Gegenmaßnahmen ein – bevor kleine Lücken zu echten Go-Live-Risiken werden.
1Unklare Requirements – FDD/IDD fehlt
Wenn Requirements zu generisch formuliert sind, entstehen systematisch Lücken zwischen dem, was das Business braucht, und dem, was das System liefert. Diese Lücken werden oft erst beim User Acceptance Test (UAT) oder schlimmer: beim Go-Live sichtbar.
Lösung: Requirements in FDD (Functional Design Documents) und IDD (Integration Design Documents) strukturieren. Jedes Requirement bekommt Beispiele, Edge Cases und direkt abgeleitete Testfälle.
- Workshops konsequent dokumentieren – kein Verbal-Commit ohne schriftliches Artefakt
- Traceability herstellen: Requirement-ID → Config/Code → Test Case
- Definition of Done pro Requirement definieren und einhalten
Kannst du für jedes Requirement direkt einen Testfall ableiten? Wenn nicht, ist das Requirement noch nicht testbar – und damit nicht ready für die Umsetzung.
2Keine Traceability
Ohne Traceability steigt der Rework-Aufwand dramatisch. Änderungen können nicht gezielt nachverfolgt werden – jede Anpassung an einer Stelle erzeugt potenziell unbekannte Auswirkungen an anderer Stelle.
Die Lösung ist eine durchgängige Verknüpfung: Requirement-ID ↔ Config/Code ↔ Test Case ↔ Defect. Das ist kein bürokratischer Aufwand – es ist das Fundament für planbare Qualität und schnelle Stabilisierung.
- Jedes Requirement erhält eine eindeutige ID, die durch alle Artefakte referenziert wird
- Konfigurationsänderungen sind mit Requirement-IDs verknüpft
- Test Cases verweisen auf die Requirements, die sie abdecken
- Defects sind direkt mit Test Cases und Requirements verbunden
3Testing kommt zu spät
In vielen D365 Projekten beginnt das Testing erst, wenn Konfiguration und Entwicklung abgeschlossen sind. Das ist zu spät. Fehler, die in frühen Phasen entstehen, sind in späten Phasen zehnmal teurer zu beheben.
Shift-left Testing bedeutet: Testfälle und Testdaten werden parallel zu den Requirements definiert – nicht danach. Regression vor jedem Release verhindert, dass bereits gelöste Probleme erneut auftauchen.
- Testfälle werden parallel zu FDD/IDD erstellt
- Testdaten-Sets werden früh versioniert und gepflegt
- Regression ist Pflicht vor jedem Sprint-Review und Go-Live
4Datenmigration unterschätzt
Datenmigration ist der häufigste Go-Live-Killer in ERP-Projekten. Datenqualitätsprobleme, die erst beim Cutover sichtbar werden, können den Betriebsstart verzögern oder komplett verhindern.
Lösung: Datenqualitäts-Regeln (DQ-Regeln) früh definieren, Mapping-Reviews regelmäßig durchführen, Dry Runs in der Testumgebung etablieren und ein detailliertes Cutover-Runbook vorbereiten.
- DQ-Regeln und Validierungslogik vor erster Migration definiert
- Mapping-Dokumente reviewed und freigegeben
- Mindestens 2 Dry Runs in Nicht-Produktivumgebung durchgeführt
- Cutover-Runbook mit Zeitplan, Verantwortlichkeiten und Rollback-Plan vorhanden
KIWie MCP & Agents helfen
MCP (Model Context Protocol) und Agents ermöglichen es, konsistente Projektartefakte zu erzeugen und zu verwalten: FDD/IDD-Dokumente, Testfälle, Runbooks und Traceability-Matrizen werden strukturiert und versioniert erstellt – mit nachvollziehbaren, auditierbaren Outputs.
Das reduziert manuelle Aufwände erheblich und stellt sicher, dass kein Artefakt verloren geht oder inkonsistent wird. Agents können zudem Lücken in der Traceability automatisch identifizieren und melden.