SH

Sascha Hess xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

 

	Strategische Wissens-Roadmap 2026
	ERP-Einführung - ohne Chaos
	Die 10 kritischsten Fehler — und wie Sie sie vermeiden

WAS SIE IN DIESEM KIT ERHALTEN:

1

10 Einführungsfehler Erkannt & vermieden — mit konkreten Gegenmaßnahmen

 

2

Projekt-Checkliste Von Anforderungsanalyse bis Go-Live — strukturiert

 

3

Datenmigrations-Guide Sauber migrieren ohne Datenverlust oder -chaos

 

4

Change Management Mitarbeiter mitnehmen — Widerstände auflösen

 

5

Go-Live-Notfallplan Was tun, wenn es am ersten Tag nicht läuft?

 

 

 

 

Alle Empfehlungen, Checklisten und Praxishinweise wurden sorgfältig erarbeitet. Da jede ERP-Einführung individuell ist, übernimmt der Autor keinerlei Haftung für Projektverzögerungen, Datenverlust, Systemausfälle oder sonstige Schäden. Validieren Sie alle Maßnahmen in Ihrer spezifischen Umgebung.

 

 

Die genannten Erfahrungswerte basieren auf realen ERP-Projekten in mittelständischen Unternehmen und stellen keine verbindliche Zusicherung dar. Tatsächliche Ergebnisse können je nach Unternehmensstruktur, Datenqualität und Projektorganisation abweichen.

 

 

Die Inhalte beziehen sich auf aktuelle Versionen von MACH, APplus und Microsoft Dynamics NAV / Business Central, Stand März 2026. Herstellerupdates können Abweichungen verursachen.

 

 

Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert. Weiterverkauf, Weitergabe an Dritte und öffentliche Veröffentlichung sind ohne schriftliche Genehmigung nicht gestattet.

 

 

Dieses Kit ist ein unabhängiges Werk und steht in keinerlei Verbindung zu den genannten ERP-Herstellern. MACH, APplus und Microsoft Dynamics sind eingetragene Marken ihrer jeweiligen Inhaber.

 

Eine ausführliche Version dieses Haftungsausschlusses befindet sich am Ende dieses Dokuments.

 

 

 

01  Einleitung

Warum ERP-Einführungen scheitern

02  Die 10 Einführungsfehler

Erkennen & vermeiden — bevor es zu spät ist

03  Anforderungsanalyse

Der Grundstein — richtig oder gar nicht

04  Datenmigration

Sauber migrieren ohne Überraschungen

05  Change Management

Menschen mitnehmen, Widerstände auflösen

06  Projektsteuerung

Scope, Budget, Zeit — die drei Feinde

07  Schnittstellen & Integration

Die unterschätzte Komplexität

08  Testmanagement

Wer nicht testet, testet live

09  Go-Live & Hypercare

Die heiße Phase meistern

10  30-Tage-Stabilisierungsplan

Nach dem Go-Live: schnell auf Kurs kommen

 

 

Einleitung

 

 

ERP-Einführungen gehören zu den komplexesten und risikoreichsten IT-Projekten, die ein mittelständisches Unternehmen durchführen kann. Studien zeigen: mehr als 50 % aller ERP-Projekte überschreiten Budget oder Zeitplan erheblich — viele scheitern vollständig. Und das nicht, weil die Software schlecht ist.

 

Das Problem liegt fast nie im System.

 

In über 20 Jahren ERP-Projekten bei mittelständischen Unternehmen — von produzierenden Betrieben über Logistiker bis zu Universitäten — zeigt sich immer wieder dasselbe Muster: Dieselben zehn Fehler, in immer neuen Variationen.

 

→  Anforderungen werden zu spät oder gar nicht schriftlich fixiert — das Projekt baut auf Sand.

 

→  Altdaten werden ungeprüft migriert — Datenmüll wandert ins neue System.

 

→  Mitarbeiter werden nicht eingebunden — und sabotieren das Projekt passiv.

 

→  Schnittstellen zu Drittsystemen werden unterschätzt — und sprengen Budget und Zeitplan.

 

→  Der Go-Live wird terminlich erzwungen — obwohl kritische Tests noch ausstehen.

 

Dieses Kit ist kein theoretisches Lehrbuch. Es ist ein kompaktes Praxishandbuch mit konkreten Checklisten, Frühwarnindikatoren und Sofortmaßnahmen — erarbeitet aus echten Projekten mit MACH, APplus und Microsoft Dynamics NAV / Business Central.

 

WAS SIE IN DIESEM KIT ERWARTEN DÜRFEN ■  10 Einführungsfehler — Die häufigsten Ursachen für ERP-Projektfehler — mit konkreten Gegenmaßnahmen. ■  Datenmigrations-Guide — Schritt-für-Schritt von der Datenanalyse bis zum produktiven Import. ■  Change-Management-Leitfaden — Wie Sie Mitarbeiter gewinnen statt verlieren. ■  Go-Live-Notfallplan — Was tun, wenn es am ersten Tag schiefläuft? ■  30-Tage-Stabilisierungsplan — Strukturierte Nachbetreuung für einen stabilen Betrieb.

 

ZIEL DIESES KITS Nach dem Lesen und Umsetzen dieses Kits kennen Sie die kritischen Stolpersteine — und haben konkrete Werkzeuge, um sie zu umgehen. Kein Projekt ist risikofrei. Aber mit der richtigen Vorbereitung wird aus einem riskanten Projekt ein beherrschbares.

 

Die 10 Einführungsfehler

 

 

Diese zehn Fehler kosten in ERP-Projekten die meiste Zeit, das meiste Geld und die meisten Nerven. Die gute Nachricht: Alle sind vorhersehbar — und alle sind vermeidbar.

 

 

Der häufigste und teuerste Fehler. Anforderungen werden mündlich kommuniziert, nicht dokumentiert oder nur oberflächlich aufgenommen. Das Ergebnis: Das System wird gebaut — aber nicht das, was gebraucht wird.

 

GEGENMASSNAHME:

 

✓  Anforderungen schriftlich in einem Lastenheft fixieren — vor Vertragsunterzeichnung.

✓  Jeden Prozess als Ist-Ablauf dokumentieren, dann den Soll-Ablauf definieren.

✓  Fachabteilungen aktiv einbinden — IT allein kennt die Prozesse nicht.

✓  Priorisierung: Muss / Soll / Kann — nicht alles ist gleichgewichtig.

 

FRÜHWARNZEICHEN: - "Das versteht sich doch von selbst" - "Das macht das System sicher automatisch" - "Das klären wir später im Projekt" → Sofort stoppen und schriftlich klären.

 

 

 

Altdaten werden als "sauberer" angenommen als sie sind. Die Migration wird auf die letzte Phase verschoben — und dann wird der Zeitplan gesprengt. Erfahrungswert: Datenmigration kostet 30-40 % des gesamten Projektaufwands.

 

GEGENMASSNAHME:

 

✓  Datenmigration ab Tag 1 als eigenes Teilprojekt führen.

✓  Datenqualitätsanalyse im Altsystem vor Projektstart.

✓  Mindestens 3 Migrationstestläufe vor dem produktiven Go-Live.

✓  Klare Verantwortlichkeit: Wer bereinigt welche Daten bis wann?

 

FAUSTREGEL DATENMIGRATION: Geplanter Aufwand  × 2,5 = Realistischer Aufwand Geplante Dauer     × 2,0 = Realistische Dauer

 

 

 

Fachbereichsleiter und Key User werden "nebenbei" ins Projekt eingebunden — neben ihrem Tagesgeschäft. Ergebnis: Entscheidungen verzögern sich, Workshops werden abgesagt, Testphasen verkürzt.

 

GEGENMASSNAHME:

 

✓  Key User mit mindestens 30 % ihrer Arbeitszeit für das Projekt freisstellen.

✓  Stellvertreterregelungen für das Tagesgeschäft organisieren.

✓  Projektbeteiligung in Zielvereinbarungen und Bewertung verankern.

✓  Projektleiter mit echter Entscheidungskompetenz ausstatten.

 

 

Jede Besonderheit des Unternehmens wird als Sonderprogrammierung umgesetzt. Das ERP verliert seine Updatefähigkeit — und bei jedem Release wird es teurer.

 

GEGENMASSNAHME:

 

✓  Grundsatz: "Prozesse ans System anpassen, nicht umgekehrt" — wo immer möglich.

✓  Jedes Customizing-Requirement auf Notwendigkeit hinterfragen: Warum nicht Standard?

✓  Total Cost of Ownership für jede Sonderentwicklung berechnen (Erstaufwand × 3).

✓  Customizing-Register führen — für jeden Release-Zyklus prüfbar.

 

 

"Wir haben noch ein Warenwirtschaftssystem, eine Zeiterfassung, einen Webshop und ein BI-Tool." Jede dieser Schnittstellen ist ein eigenes Teilprojekt. Wird dies nicht erkannt, explodiert der Scope.

 

GEGENMASSNAHME:

 

✓  Schnittstellenlandkarte zu Projektbeginn vollständig aufnehmen.

✓  Für jede Schnittstelle: Verantwortung, Format, Frequenz, Fallback definieren.

✓  Schnittstellentests separat planen — vor den Integrationstests.

✓  Pufferzeit: +20 % Aufwand pro Schnittstelle einkalkulieren.

 

 

Tests werden am Ende "irgendwie" durchgeführt — ohne Testfälle, ohne Abnahmekriterien, ohne Fehlerdokumentation. Der Go-Live wird trotzdem gehalten.

 

GEGENMASSNAHME:

 

✓  Testkonzept als Pflichtlieferung im Projektplan.

✓  Testfälle aus den Anforderungen ableiten — 1:1-Abdeckung.

✓  User Acceptance Test (UAT) mit echten Anwendern, nicht nur IT.

✓  Go/No-Go-Kriterien schriftlich festlegen — und einhalten.

 

 

Das System ist fertig — aber niemand will es benutzen. Mitarbeiter empfinden das neue ERP als Bedrohung, nicht als Hilfe. Passive Sabotage und Schatten-IT entstehen.

 

GEGENMASSNAHME:

 

✓  Change-Management-Plan ab Projektstart — parallel zur technischen Arbeit.

✓  Kommunikationsplan: Was wird wann an wen kommuniziert?

✓  Frühzeitige Einbindung der Anwender in Design-Entscheidungen.

✓  Schulungskonzept: Rollen-basiert, nicht "einmal für alle".

 

 

Das Datum steht fest — und wird nicht angefasst, egal was im Projekt passiert. Kritische Fehler werden "für später" eingeplant. Das Ergebnis ist ein chaotischer Go-Live mit wochenlanger Nacharbeit.

 

GEGENMASSNAHME:

 

✓  Go-Live-Kriterien definieren — nicht Datum, sondern Qualität entscheidet.

✓  Ampel-System: Grün = Go-Live, Gelb = Entscheidung Führung, Rot = Verschiebung.

✓  Rollback-Plan vorhalten: Was passieren muss, damit wir zum Altsystem zurückkehren.

✓  Hypercare-Team einplanen: Wer ist die ersten 4 Wochen nach Go-Live verfügbar?

 

 

Einmalige Schulung kurz vor Go-Live — mit zu viel Inhalt in zu kurzer Zeit, ohne Übungsmöglichkeit. Nach dem Go-Live können viele Anwender die Grundfunktionen nicht bedienen.

 

GEGENMASSNAHME:

 

✓  Schulung in Phasen: Konzept-Schulung früh, System-Schulung kurz vor Go-Live.

✓  Schulungsumgebung mit realistischen Testdaten aufbauen.

✓  Rollen-basierte Schulungspläne: Einkauf lernt anderes als Buchhaltung.

✓  Quick-Reference-Cards für die häufigsten Prozesse — eine Seite pro Rolle.

 

 

Niemand weiß genau, wo das Projekt steht. Budget und Zeitplan werden nicht laufend überwacht. Die Überraschungen kommen am Ende — wenn es zu spät ist, gegenzusteuern.

 

GEGENMASSNAHME:

 

✓  Wöchentliches Projektstatusmeetingmit Ampel-Reporting.

✓  Earned-Value-Analyse: Ist-Aufwand vs. geplanter Fortschritt.

✓  Risikoregister pflegen — aktiv, nicht als einmalige Pflichtübung.

✓  Eskalationspfad definieren: Wer entscheidet bei Problemen auf welcher Ebene?

 

 

Anforderungsanalyse

 

 

Eine lückenhafte Anforderungsanalyse ist der Ursprung der meisten späteren Probleme. Jeder Euro, der hier gespart wird, kostet im Projektverlauf das Zehnfache.

 

 

Das Lastenheft ist das zentrale Dokument der Anforderungsanalyse. Es beschreibt, was das System leisten soll — nicht wie. Es ist die Grundlage für Angebote, Verträge und spätere Abnahmen.

 

Pflichtbestandteile eines Lastenhefts:

 

→  Unternehmensübersicht und Projektziele (messbar, nicht "modernes ERP")

 

→  Ist-Prozessanalyse je Abteilung — mit Mengengerüst (Belege/Monat, User-Anzahl)

 

→  Soll-Prozesse — mit Priorisierung Muss/Soll/Kann

 

→  Schnittstellen zu Drittsystemen — vollständige Liste

 

→  Technische Rahmenbedingungen (On-Premise / Cloud, Betriebssystem, Datenbankplattform)

 

→  Nicht-funktionale Anforderungen (Performance, Verfügbarkeit, Sicherheit)

 

→  Abnahmekriterien — wie wird gemessen, ob das System akzeptiert wird?

 

 

BEWÄHRTES WORKSHOP-FORMAT (je Fachbereich): Tag 1 (Vormittag):  Ist-Prozessaufnahme — was läuft heute wie? Tag 1 (Nachmittag): Schmerzpunkte identifizieren — was nervt täglich? Tag 2 (Vormittag):  Soll-Prozesse definieren — wie soll es laufen? Tag 2 (Nachmittag): Priorisierung und Abnahme der Ergebnisse   Teilnehmer: Fachbereichsleiter + 2 Key User + IT-Projektleiter Ergebnis:   Unterschriebenes Protokoll noch am selben Tag

 

 

 

Falle	Symptom	Gegenmaßnahme
"Das ist selbstverständlich"	Keine Dokumentation offensichtlicher Anforderungen	Alles aufschreiben — auch das Triviale
Wunschlisten-Denken	Anforderungen ohne Businesscase	ROI für jede Anforderung abfragen
Fehlende Entscheider	Workshops ohne Führungsbeteiligung	Sponsoren-Commitment vor Projektstart
Scope Creep	Neue Anforderungen nach Lastenheft-Freigabe	Change-Request-Prozess einführen

 

 

Datenmigration

 

 

Datenmigration ist das technisch und organisatorisch anspruchsvollste Teilprojekt jeder ERP-Einführung. Hier entscheidet sich, ob das neue System von Tag 1 an vertrauenswürdig ist — oder ob Mitarbeiter jahrelang dem System misstrauen.

 

 

PHASE 1 — ANALYSE (Wochen 1-4):   Datenquellen identifizieren und inventarisieren   Datenqualität je Objekt bewerten (Ampel: Grün/Gelb/Rot)   Migrationsstrategie je Objekt festlegen   Verantwortlichkeiten zuweisen   PHASE 2 — BEREINIGUNG (Wochen 4-12):   Dubletten identifizieren und zusammenführen   Pflichtfelder prüfen und befüllen   Referentielle Integrität herstellen   Business Rules validieren   PHASE 3 — MIGRATION (iterativ, 3 Läufe Minimum):   Lauf 1: Technische Machbarkeit prüfen   Lauf 2: Datenqualität validieren   Lauf 3: Performance und Vollständigkeit messen   Produktionslauf: Mit Abnahme und Protokoll   PHASE 4 — VALIDIERUNG:   Stichprobenprüfung durch Fachabteilungen   Summenabgleich (Salden, Bestände, Stammdaten)   Abnahmeprotokoll unterschreiben lassen

 

 

 

Objekt	Priorität	Typische Probleme	Aufwandsfaktor
Kundenstamm	Kritisch	Dubletten, fehlende Pflichtfelder	1,0×
Lieferantenstamm	Kritisch	Inkonsistente Bankverbindungen	0,8×
Artikelstamm	Kritisch	Fehlende Einheiten, doppelte Nummern	2,0×
Offene Bestellungen	Hoch	Teillieferungen, Rahmenverträge	1,5×
Offene Rechnungen	Kritisch	Saldenabgleich Buchhaltung	2,5×
Lagerbestände	Hoch	Inventur-Timing koordinieren	1,5×
Historische Belege	Niedrig	Großes Volumen, wenig Nutzen	0,5×

 

 

GOLDENE REGEL DER DATENMIGRATION Migrieren Sie niemals historische Daten, die niemand braucht. Jeder migrierte Datensatz kostet Geld — in Bereinigung, Migration und späterer Pflege. Fragen Sie: "Wird jemand diese Daten in 6 Monaten noch brauchen?" Wenn nicht: weglassen.

 

-- Beispiel: Datenqualitäts-Check Kundenstamm vor Migration SELECT     COUNT(*) AS Gesamt,     SUM(CASE WHEN Name IS NULL OR Name = '' THEN 1 ELSE 0 END) AS Kein_Name,     SUM(CASE WHEN PLZ IS NULL OR LEN(PLZ) <> 5 THEN 1 ELSE 0 END) AS Ungueltige_PLZ,     SUM(CASE WHEN Email IS NOT NULL              AND Email NOT LIKE '%@%.%' THEN 1 ELSE 0 END) AS Ungueltige_Email,     SUM(CASE WHEN Kundennummer IN              (SELECT Kundennummer FROM Kunden GROUP BY Kundennummer               HAVING COUNT(*) > 1) THEN 1 ELSE 0 END) AS Dubletten FROM dbo.Kunden_Alt;

 

 

 

Change Management

 

 

Technisch perfekte ERP-Systeme scheitern an Menschen. Change Management ist kein "weiches Thema" — es ist ein handfester Erfolgsfaktor. Projekte ohne Change Management haben ein dreifach höheres Scheiternrisiko.

 

 

→  Angst vor Jobverlust: "Das System macht meinen Job überflüssig." → Offen thematisieren, konkret widerlegen.

 

→  Komfortzonen-Verlust: Jahrelang eingespielte Abläufe müssen neu gelernt werden. → Schulung und Zeit einplanen.

 

→  Informationsdefizit: Gerüchteküche füllt das Vakuum, wenn offizielle Kommunikation fehlt. → Kommunikationsplan umsetzen.

 

→  Fehlende Einbindung: "Mit mir hat niemand geredet." → Key-User-Konzept früh starten.

 

→  Schlechte Erfahrungen: "Das letzte IT-Projekt war auch ein Desaster." → Vertrauen durch Transparenz aufbauen.

 

 

KEY-USER-PROFIL:   ✓ Fachlich anerkannt im eigenen Bereich   ✓ Offen für Veränderungen (kein "das haben wir immer so gemacht")   ✓ Kommunikativ — kann anderen erklären   ✓ Freigestellt: mind. 30 % Projektzeit   ✓ Direkte Linie zum Projektleiter   KEY-USER-AUFGABEN:   → Anforderungen aus Fachbereich einbringen   → Tests durchführen und dokumentieren   → Schulungen für eigene Kollegen durchführen   → Erster Ansprechpartner bei Fragen nach Go-Live   → Feedback in Lenkungsausschuss einbringen

 

 

 

Zeitpunkt	Zielgruppe	Inhalt	Kanal
Projektstart	Alle Mitarbeiter	Warum ERP, was ändert sich	Townhall + Intranet
Monatlich	Betroffene Abteilungen	Projektfortschritt, nächste Schritte	Abteilungsmeeting
8 Wochen vor Go-Live	Alle Anwender	Schulungsplan, Zeitplan Go-Live	E-Mail + Aushang
2 Wochen vor Go-Live	Alle Anwender	Konkrete Änderungen je Rolle	Persönlich + Handout
Go-Live-Tag	Alle	Ansprechpartner, Helpdesk-Nummer	E-Mail + Aushang
Woche 1-4	Anwender	Feedback-Kanal, Fehlermeldungen	Ticketsystem

 

 

Projektsteuerung

 

 

Das klassische Projektdreieck ist bei ERP-Projekten besonders ausgeprägt: Wer an einer Ecke zieht, verändert die anderen. Gutes Projektcontrolling erkennt Abweichungen früh genug, um gegenzusteuern.

 

 

BEWÄHRTE PROJEKTSTRUKTUR:   Lenkungsausschuss (Monatlich)   └── Gesamtprojektleiter (Vollzeit ab 50-Tage-Projekten)         ├── Teilprojekt Technik (ERP-Basis, Server, Infrastruktur)         ├── Teilprojekt Datenmigration (eigenständig!)         ├── Teilprojekt Schnittstellen         ├── Teilprojekt Fachbereich (je Modul ein TP-Leiter)         └── Teilprojekt Change & Schulung

 

 

 

Status	Bedeutung	Maßnahme
🟢 Grün	Auf Kurs — Abweichung < 10 %	Weiter so
🟡 Gelb	Gefährdet — Abweichung 10-25 %	Eskalation an Projektleiter
🔴 Rot	Kritisch — Abweichung > 25 %	Lenkungsausschuss entscheidet

 

 

WICHTIG — SCOPE CREEP VERHINDERN Jede neue Anforderung nach Lastenheft-Freigabe ist ein Change Request. Kein Change Request ohne schriftliche Bewertung von Aufwand, Kosten und Zeitauswirkung. Kein Change Request ohne Freigabe durch den Lenkungsausschuss. Diese Disziplin rettet Projekte.

 

CHANGE-REQUEST-PROZESS: 1. CR schriftlich einreichen (Formular) 2. Bewertung durch Projektleitung (Aufwand, Kosten, Zeitplan) 3. Entscheidung Lenkungsausschuss: Annehmen / Ablehnen / Zurückstellen 4. Bei Annahme: Projektplan und Budget aktualisieren 5. Dokumentation im CR-Register

 

 

 

Schnittstellen & Integration

 

 

Kein ERP-System steht allein. Die Integration in die bestehende Systemlandschaft ist in den meisten Projekten die größte technische Herausforderung — und wird dennoch systematisch unterschätzt.

 

 

Vor Projektstart ist eine vollständige Schnittstellenlandkarte zu erstellen. Erfahrungswert: Mittelständische Unternehmen haben im Schnitt 8-15 relevante Systemschnittstellen.

 

SCHNITTSTELLENINVENTAR-VORLAGE:   System A    ←→  ERP  Format   Frequenz  Richtung  Owner    Prio ───────────────────────────────────────────────────────────────── Webshop         BC   REST/JSON  Echtzeit  Bidirekt. IT       Krit. Zeiterfassung   BC   CSV-Import Täglich   → ERP     HR       Hoch Bankinterface   BC   SEPA/MT940 Täglich   Bidirekt. FiBu     Krit. BI-Tool         BC   SQL-View   Echtzeit  → BI      IT       Mittel Versand-SW      BC   CSV-Export Bei Bed.  ERP →     Logistik Hoch

 

 

→  Jede Schnittstelle braucht eine technische Spezifikation vor Entwicklungsbeginn.

 

→  Fehlerbehandlung immer mitdenken: Was passiert bei Verbindungsausfall? Bei Datenfehlern?

 

→  Logging ist Pflicht: Jede Übertragung muss nachvollziehbar sein.

 

→  Rollback-Fähigkeit: Kann eine fehlerhafte Übertragung rückgängig gemacht werden?

 

-- Beispiel: Einfaches Schnittstellenlog (SQL Server / Business Central) CREATE TABLE dbo.InterfaceLog (     LogID         INT IDENTITY PRIMARY KEY,     Zeitpunkt     DATETIME2 DEFAULT GETDATE(),     Schnittstelle NVARCHAR(100),     Richtung      NVARCHAR(10),   -- 'Import' / 'Export'     Datensaetze   INT,     Status        NVARCHAR(20),   -- 'OK' / 'Fehler' / 'Warnung'     Fehlermeldung NVARCHAR(MAX),     Dateiname     NVARCHAR(500) );

 

Testmanagement

 

 

Mangelndes Testmanagement ist der häufigste Grund für chaotische Go-Lives. Tests werden unter Zeitdruck abgekürzt — und die Fehler tauchen dann im Produktivbetrieb auf, mit echten Daten und echten Konsequenzen.

 

 

TESTPYRAMIDE ERP-EINFÜHRUNG:   UNIT-TESTS (Entwickler)   └── Einzelne Funktionen und Customizing-Entwicklungen   INTEGRATIONSTESTS (IT + Key User)   └── Prozesse end-to-end durch alle Systemteile   └── Schnittstellen mit allen angebundenen Systemen   USER ACCEPTANCE TESTS — UAT (Fachabteilung)   └── Alle Geschäftsprozesse mit realistischen Testdaten   └── Abnahme durch Fachbereichsleiter   LAST- UND PERFORMANCE-TESTS (IT)   └── Systemverhalten unter realer Last   └── Batch-Jobs und Nachtverarbeitung   NOTFALL- UND ROLLBACK-TESTS (IT)   └── Was passiert bei Systemausfall?   └── Rollback-Prozedur durchspielen

 

 

 

Kriterium	Grenze	Messung
Kritische Fehler offen	0	Fehlerliste UAT
Hohe Fehler offen	max. 3, mit Workaround	Fehlerliste UAT
UAT-Abdeckung	mind. 95 % der Testfälle	Testprotokoll
Schulungsquote	mind. 90 % der Anwender geschult	Schulungsnachweis
Datenmigrations-Abnahme	Unterschrieben	Abnahmeprotokoll
Rollback-Test	Erfolgreich durchgeführt	Testprotokoll IT

 

KEINE AUSNAHMEN BEI KRITISCHEN FEHLERN Kritische Fehler sind Fehler, die Kernprozesse blockieren: Buchungen können nicht abgeschlossen werden, Bestellungen können nicht ausgedruckt werden, Lagerbestände sind falsch. Ein einziger kritischer Fehler ist ein Grund für No-Go — ohne Ausnahme.

 

 

Go-Live & Hypercare

 

 

Die Wochen rund um den Go-Live sind die kritischste Phase des Projekts. Gute Vorbereitung, ein klarer Ablaufplan und ein eingespieltes Hypercare-Team entscheiden über Erfolg oder Chaos.

 

 

T-5 WOCHEN VOR GO-LIVE:   ■ Letzter Migrationstestlauf abgeschlossen   ■ UAT abgenommen und unterschrieben   ■ Alle kritischen Fehler behoben   ■ Schulungen abgeschlossen (mind. 90% der User)   ■ Produktivsystem provisioniert und getestet   ■ Rollback-Plan dokumentiert und geprüft   T-2 WOCHEN VOR GO-LIVE:   ■ Go/No-Go-Entscheidung durch Lenkungsausschuss   ■ Kommunikation an alle Mitarbeiter versandt   ■ Hypercare-Team zusammengestellt und informiert   ■ Helpdesk-Prozess definiert (Erreichbarkeit, Eskalation)   ■ Produktionsmigration geplant und abgestimmt   T-1 TAG VOR GO-LIVE:   ■ Altsystem in Read-Only-Modus (wenn möglich)   ■ Finaler Datenbankstand gezogen   ■ Produktionsmigration gestartet   ■ Hypercare-Team auf Bereitschaft   ■ Rollback-Entscheidungspunkt definiert (bis wann?)   T+0 GO-LIVE-TAG:   ■ Migration erfolgreich — Abnahme durch IT und Fachbereich   ■ Produktivsystem freigegeben   ■ Helpdesk aktiv und erreichbar   ■ Hypercare-Team präsent (vor Ort!)   ■ Stündliches Status-Update in den ersten 4 Stunden

 

 

→  Stufe 1: Anwender meldet Problem → Key User löst oder eskaliert (< 15 Min.)

 

→  Stufe 2: Key User kann nicht lösen → IT-Projektteam (< 30 Min.)

 

→  Stufe 3: IT kann nicht lösen → ERP-Berater (< 60 Min., Hotline-Vertrag!)

 

→  Stufe 4: Systembetrieb gefährdet → Rollback-Entscheidung Projektleiter (< 2 Std.)

 

30-Tage-Stabilisierungsplan

 

 

Der Go-Live ist nicht das Ende — er ist der Anfang des produktiven Betriebs. Die ersten 30 Tage entscheiden darüber, ob das System als Erfolg oder Misserfolg wahrgenommen wird.

 

VOR DEM START Hypercare-Team für 4 Wochen verbindlich einplanen. Tägliches Status-Meeting in Woche 1-2, danach wöchentlich. Fehlerliste täglich aktualisieren und priorisieren.

 

■ TAG 1-2: AKUTPROBLEME BEHEBEN

 

■  Stündliches Status-Update → täglich ab Mittag

■  Alle Fehler-Tickets aufnehmen und priorisieren

■  Kritische Fehler: sofortige Behebung oder Workaround

■  Key User als erste Anlaufstelle der Anwender

■  Hypercare-Team präsent — keine Remote-Only-Betreuung in Woche 1

 

■ TAG 3-5: ERSTE STABILISIERUNG

 

■  Fehlerliste: Kritisch / Hoch / Mittel / Niedrig kategorisieren

■  Workarounds für alle offenen hohen Fehler dokumentieren

■  Schulungsnachbedarf identifizieren — gezielte Nachschulungen planen

■  Performance-Monitoring: Antwortzeiten im Blick behalten

■  Datenmigrations-Nachläufer prüfen: Vollständigkeit aller Stammdaten

 

■ TAG 6-10: PROZESSE STABILISIEREN

 

■  Alle kritischen Fehler behoben

■  Schulungsnachholbedarf abarbeiten

■  Erste Periodenabschlüsse vorbereiten und begleiten

■  Schnittstellenmonitoring: Alle Übertragungen prüfen

■  Anwenderzufriedenheit messen — kurze Befragung

 

■ TAG 11-14: OPTIMIERUNGSRUNDE 1

 

■  Priorisierung der "Hohen" Fehler mit Fachbereich abstimmen

■  Quick-Wins umsetzen: kleine Verbesserungen mit großer Wirkung

■  Dokumentation aktualisieren: Änderungen gegenüber ursprünglichem Konzept

■  Übergabe an normalen IT-Betrieb vorbereiten

 

■ TAG 15-21: ÜBERGABE VORBEREITEN

 

■  Betriebshandbuch erstellen / aktualisieren

■  Eskalationspfade für Normalbetrieb definieren

■  Service-Level-Agreements mit ERP-Hersteller/Berater prüfen

■  First-Level-Support im eigenen Haus aufbauen (Key User)

■  Monitoring-Dashboards für laufenden Betrieb einrichten

 

■ TAG 22-28: LESSONS LEARNED

 

■  Projektabschlussmeeting mit allen Beteiligten

■  Lessons-Learned-Dokumentation: Was lief gut? Was nicht?

■  Verbesserungsmaßnahmen für zukünftige Projekte ableiten

■  Lob und Anerkennung für das Team — öffentlich!

■  Projekt formal abschließen und Übergabe dokumentieren

 

■ TAG 29-30: ABSCHLUSS

 

■  Abschlussbericht für Lenkungsausschuss

■  Offene Punkte in Wartungsvertrag überführen

■  Budget-Nachkalkulation — Soll/Ist-Vergleich

■  Erfolge kommunizieren: Was hat das neue System schon gebracht?

■  Roadmap für Phase 2 / Optimierungen planen ■

 

ERGEBNIS NACH 30 TAGEN Nach 30 Tagen ist das System stabil, die Anwender arbeiten produktiv, offene Punkte sind priorisiert und der Normalbetrieb ist übergeben. Das Projekt ist abgeschlossen — der kontinuierliche Verbesserungsprozess beginnt.

 

 

 

Die in diesem Dokument enthaltenen Informationen, Empfehlungen und Checklisten wurden nach bestem Wissen und Gewissen auf der Grundlage langjähriger praktischer Erfahrung erstellt. Dennoch kann keine Gewähr für die Vollständigkeit, Richtigkeit oder Aktualität der bereitgestellten Inhalte übernommen werden.

 

Der Autor übernimmt ausdrücklich keinerlei Haftung für unmittelbare oder mittelbare Schäden, einschließlich, aber nicht beschränkt auf: Projektverzögerungen, Datenverlust, Systemausfälle, Produktionsunterbrechungen oder entgangenen Gewinn.

 

Die Hinweise zu Vertragsgestaltung, Lastenheft und Abnahme ersetzen keine rechtliche Beratung. Für rechtsverbindliche Vereinbarungen ist ein Fachanwalt hinzuzuziehen.

 

Die genannten ERP-Systeme (MACH, APplus, Microsoft Dynamics NAV / Business Central) werden kontinuierlich weiterentwickelt. Funktionen, Menüpfade und Prozesse können in anderen Versionen abweichen.

 

Dieses Dokument und alle Inhalte sind urheberrechtlich geschützt. © 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten.

 

Microsoft Dynamics NAV, Business Central und Microsoft sind eingetragene Marken der Microsoft Corporation. APplus ist eine eingetragene Marke der Asseco Solutions AG. MACH ist eine eingetragene Marke der MACH AG. Alle anderen Produktnamen sind Eigentum ihrer jeweiligen Inhaber.

 

 

Es gilt ausschließlich deutsches Recht. Gerichtsstand ist, soweit gesetzlich zulässig, Weimar, Thüringen, Deutschland.

 

 

 

Sascha Hess ist Diplom-Biologe und IT-Professional mit über 20 Jahren Erfahrung in der Administration von ERP-, BI- und Datenbanksystemen. Er hat ERP-Projekte mit MACH, APplus und Microsoft Dynamics NAV in mittelständischen Unternehmen, an der Bauhaus-Universität Weimar und bei Energieversorgern begleitet — von der Anforderungsanalyse bis zum Go-Live.

 

Sein Ansatz verbindet naturwissenschaftliche Präzision mit pragmatischer IT-Erfahrung. Schwerpunkte: ERP-Einführungen, Datenmigration, SQL Server Performance-Tuning, Business Intelligence (Power BI, DeltaMaster) und IT-Interim-Management.

 

Web: www.xenosystems.de | E-Mail: info@xenosystems.de | Standort: Weimar, Thüringen / Remote

 

Service	Beschreibung
ERP-Einführungsberatung	Begleitung von ERP-Projekten (MACH, Dynamics NAV/BC, APplus) — Anforderungsanalyse, Datenmigration, Schulung, Go-Live-Support.
SQL Server DB Health Check	Professioneller Audit Ihres SQL Servers — Managementreport, Risikobewertung und Maßnahmenplan. Scope: 3-5 Tage.
BI-Dashboard-Aufbau	Power BI / DeltaMaster Dashboards inkl. ETL-Strecken und Data-Warehouse-Aufbau — für KMU ab 1 Woche Projektumfang.
KI-Readiness Assessment	Bewertung Ihrer Datenqualität, Systemlandschaft und Prozessreife für den KI-Einstieg — mit konkretem Fahrplan.
Interim IT-Management	Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, strategische IT-Ausrichtung.