# CRM-Go-live-Readiness-Plan Arbeitsvorlage für eine kontrollierte CRM-Einführung. Alle Beispielangaben sind ausdrücklich fiktiv und müssen durch geprüfte Angaben des eigenen Unternehmens ersetzt werden. Die Vorlage ist keine automatische Vollständigkeits-, Machbarkeits-, Datenschutz-, Kosten-, Termin- oder Rechtsfreigabe. ## 1. Dokumentsteuerung - Projekt: `[eigener Arbeitstitel]` - Pilotprozess: `[Start, Ende und geschäftliches Ergebnis]` - Zielsystem und Version: `[geprüfte Angabe]` - Geplanter Cutover: `[Datum und betrieblicher Zeitraum]` - Dokument-Owner: `[Rolle, keine private Kontaktangabe in öffentlichen Kopien]` - Letzte Aktualisierung: `[JJJJ-MM-TT, Uhrzeit, Zeitzone]` - Freigabestatus: `[Entwurf | im Review | Go | No-Go | verschoben]` - Verknüpfter Projektplan: `[interner kontrollierter Ablageort]` - Verknüpftes Risiko- und Entscheidungslog: `[interner kontrollierter Ablageort]` Fiktiver Kontext zur Orientierung: Die „Beispielwerke GmbH“ möchte einen einzelnen B2B-Leadprozess in ein neues CRM überführen. Die Namen, Systeme, Datenmengen und Entscheidungen dieses Beispiels beschreiben kein reales Unternehmen oder Kundenprojekt. ## 2. Entscheidungsrollen | Entscheidung | Accountable | Erreichbarkeit im Entscheidungsfenster | Stellvertretung | Status | |---|---|---|---|---| | Geschäftliches Go-/No-Go | Executive Sponsor | `[intern ergänzen]` | `[intern ergänzen]` | Offen | | Fachliche Prozessfreigabe | Process Owner | `[intern ergänzen]` | `[intern ergänzen]` | Offen | | Datenfreigabe | Data Owner | `[intern ergänzen]` | `[intern ergänzen]` | Offen | | Technische Readiness | Solution Owner | `[intern ergänzen]` | `[intern ergänzen]` | Offen | | Cutover und Rückfall | Betriebsverantwortung | `[intern ergänzen]` | `[intern ergänzen]` | Offen | | Support und Kommunikation | Support-/Change-Owner | `[intern ergänzen]` | `[intern ergänzen]` | Offen | Eine Rolle darf erst als besetzt gelten, wenn Entscheidungskompetenz, notwendige Information und Erreichbarkeit geklärt sind. Ein Name in einer RACI-Matrix allein genügt nicht. ## 3. Go-/No-Go-Zusammenfassung | Readiness-Bereich | Ampel | Kritischer Blocker? | Nachweis | Accountable | Maßnahme oder bewusster Restpunkt | |---|---|---|---|---|---| | Lösung und Release | Grau | Ungeklärt | `[Link/Referenz]` | Solution Owner | `[ergänzen]` | | Daten und Migration | Grau | Ungeklärt | `[Link/Referenz]` | Data Owner | `[ergänzen]` | | Prozess, Integration und Reporting | Grau | Ungeklärt | `[Link/Referenz]` | Process Owner | `[ergänzen]` | | Rechte, Sicherheit und Datenschutz | Grau | Ungeklärt | `[Link/Referenz]` | Zuständige Unternehmensrolle | `[ergänzen]` | | Menschen, Kommunikation und Support | Grau | Ungeklärt | `[Link/Referenz]` | Change-/Support-Owner | `[ergänzen]` | | Cutover, Rückfall und Betrieb | Grau | Ungeklärt | `[Link/Referenz]` | Betriebsverantwortung | `[ergänzen]` | Regel: Eine Gesamtampel darf keinen einzelnen kritischen Blocker verdecken. „Go mit Restpunkt“ benötigt Auswirkung, akzeptierenden Entscheider, tragfähigen Workaround, Owner und spätesten Entscheidungspunkt. ## 4. Lösung und Release - [ ] Der Releasekandidat ist eindeutig versioniert. - [ ] Produktive Konfiguration entsteht über den geprüften Releaseweg. - [ ] Nicht dokumentierte manuelle Änderungen wurden ausgeschlossen oder kontrolliert aufgenommen. - [ ] Kritische Defects sind geschlossen und erneut geprüft. - [ ] Akzeptierte Restpunkte besitzen Auswirkung, Workaround, Owner und Zielentscheidung. - [ ] Produktionsumgebung, Lizenzen, Speicher und relevante Kontingente wurden anhand aktueller Anbieterunterlagen geprüft. - [ ] Notwendige Secrets und privilegierte Zugänge werden kontrolliert bereitgestellt. - [ ] Monitoring, Alarmierung, Backup- und Wiederherstellungsanforderungen sind vorbereitet. **Nachweis:** `[Releaseprotokoll, technische Freigabe, Konfigurationsbaseline]` **Blocker-Regel:** Keine Umschaltung bei nicht reproduzierbarer produktiver Konfiguration, kritischem ungelöstem Fehler oder fehlender Kontrolle privilegierter Zugänge. ## 5. Prozess, Test und fachliche Abnahme - [ ] Der Pilot-Scope entspricht dem freigegebenen Projektauftrag. - [ ] Normale, ungültige und grenzwertige Ende-zu-Ende-Fälle wurden durchgeführt. - [ ] Betroffene Fachanwender haben den User Acceptance Test mit repräsentativen Daten ausgeführt. - [ ] Pflichtdaten, Zustände, Ausnahmen, Vertretungen und Berechtigungen wurden geprüft. - [ ] Kritische Reports und Prozessindikatoren entsprechen ihrer fachlichen Definition. - [ ] Testfälle besitzen erwartetes Ergebnis, tatsächliches Ergebnis und nachvollziehbaren Sign-off. - [ ] Defects wurden nach Schwere, Geschäftsrisiko und notwendiger Regression bewertet. - [ ] Nichtfunktionale Anforderungen wie Leistung, Bedienbarkeit, Operability und Sicherheit wurden angemessen geprüft. **Nachweis:** `[Testbericht, UAT-Protokoll, Defect-Log, Sign-offs]` **Blocker-Regel:** Kein Go-live, wenn ein kritischer Geschäftsprozess nicht kontrolliert abgeschlossen werden kann und kein bewusst freigegebener sicherer Workaround existiert. ## 6. Daten und Migration - [ ] Der unveränderte Ausgangsbestand ist gesichert und nachvollziehbar bezeichnet. - [ ] Der finale Scope enthält bewusste Ausschlüsse und Archiventscheidungen. - [ ] Feld-, Werte- und Beziehungsmapping ist versioniert und fachlich freigegeben. - [ ] Schlüssel, Fremdschlüssel, Dubletten- und Gewinnerregeln sind dokumentiert. - [ ] Pilotmigrationen enthielten normale und schwierige Fälle. - [ ] Mengen, kritische Felder, Beziehungen und reale Arbeitsfälle wurden validiert. - [ ] Änderungen seit dem Snapshot werden per Stopp oder kontrollierter Delta-Übernahme behandelt. - [ ] Reihenfolge abhängiger Objekte und erwartete Laufprotokolle stehen fest. - [ ] Fehler- und Ausschlusslisten besitzen Owner und fachlichen Entscheidungsweg. - [ ] Die alte Datenquelle wird nach dem Wechsel nicht unkontrolliert parallel weitergeführt. **Nachweis:** `[Migrationsbilanz, Mappingversion, Pilotprotokoll, Data-Owner-Sign-off]` **Blocker-Regel:** Keine finale Migration bei ungeklärten Schlüsseln, nicht validierten kritischen Beziehungen oder fehlendem Delta-Verfahren. Vertiefung: Der öffentlich verfügbare Leitfaden `/excel-ins-crm-migrieren` behandelt Quelleninventar, Datenmodell, Bereinigung, Mapping, Pilotimport, Validierung und Cutover ausführlicher. ## 7. Integrationen und externe Systeme - [ ] Führendes System, Richtung und Verantwortlichkeit sind je kritischem Objekt geklärt. - [ ] Produktive Zugänge, Lizenzen und Freigaben wurden kontrolliert vorbereitet. - [ ] Normalfall, ungültige Daten, Ausfall und Wiederholung wurden getestet. - [ ] Idempotenz oder eine passende Dublettenstrategie wurde geprüft. - [ ] Nutzer sehen relevante Fehler oder erhalten einen kontrollierten Klärungsweg. - [ ] Monitoring, Alerting, Triage und Eskalation sind im Betrieb besetzt. - [ ] Externe Ansprechpartner sind im Cutover-Fenster erreichbar oder Risiken wurden bewusst entschieden. - [ ] API-Grenzen, erwartete Volumen und relevante Leistung wurden mit realistischen Annahmen geprüft. **Nachweis:** `[Schnittstellenvertrag, Testprotokoll, Monitoringansicht, Betriebsfreigabe]` **Blocker-Regel:** Kein Go-live, wenn eine kritische Integration unbemerkt Daten verlieren oder einen Geschäftsprozess ohne sichtbaren Fehlerzustand abbrechen kann. ## 8. Rechte, Sicherheit und Datenschutz - [ ] Nutzerkonten, Rollen und Gruppen entsprechen der freigegebenen Zugriffsmatrix. - [ ] Lese-, Änderungs-, Export- und Admin-Rechte wurden mit repräsentativen Konten geprüft. - [ ] Nicht benötigte Test- und privilegierte Konten werden vor dem Start entfernt oder gesperrt. - [ ] Protokollierungs- und Aufbewahrungsanforderungen sind mit zuständigen Rollen des Unternehmens abgestimmt. - [ ] Auftragsverarbeitung und relevante Drittlandübermittlungen wurden vom Unternehmen geprüft. - [ ] Lösch-, Korrektur- und Auskunftsprozesse besitzen fachliche und technische Owner. - [ ] Schutzmaßnahmen für Vertraulichkeit, Integrität, Verfügbarkeit und Wiederherstellung sind eingeordnet. - [ ] Offene rechtliche Fragen werden nicht als technische Annahme oder automatische Produkteigenschaft behandelt. **Nachweis:** `[Rollenmatrix, Zugriffstest, Sicherheitsfreigabe, dokumentierte Datenschutzentscheidungen]` **Blocker-Regel:** Keine Freigabe bei unzulässiger Sichtbarkeit, ungeklärten privilegierten Zugängen oder fehlender Entscheidung zu einem kritischen personenbezogenen Datenbestand. ## 9. Training, Kommunikation und Support - [ ] Jede betroffene Rolle kennt den neuen Ablauf, ihren Startzeitpunkt und ihre Verantwortung. - [ ] Training nutzt reale Arbeitsfälle und kontrollierte Beispieldaten statt nur Menüs zu erklären. - [ ] Genügend Personen können kritische Tagesaufgaben und Ausnahmen selbst durchführen. - [ ] Champions, Supportkontakt, Triage und Eskalationsweg sind kommuniziert. - [ ] Support kennt Release, Prozess, bekannte Restpunkte und Rückfallweg. - [ ] Betriebsdokumentation und notwendiges Wissen wurden übergeben. - [ ] Kommunikationsereignisse vor, während und nach dem Cutover besitzen Owner. - [ ] Feedback und neue Anforderungen gelangen in einen priorisierten Backlog. **Nachweis:** `[Trainingsplan, Übungen, Kommunikationsplan, Supportübergabe]` **Blocker-Regel:** Kein Rollout für einen geschäftskritischen Nutzerkreis ohne erreichbaren Support und nachgewiesene Fähigkeit, die zentralen Arbeitsfälle auszuführen. ## 10. Cutover-Ablauf Jede Zeile benötigt exakte interne Zeitangabe, Responsible, Accountable, erwartetes Ergebnis und Prüfentscheidung. Die folgenden Zeilen sind nur fiktive Strukturbeispiele. | Reihenfolge | Arbeitsschritt | Responsible | Accountable | Entry-Kriterium | Erwartetes Ergebnis | Nachweis | Status | |---|---|---|---|---|---|---|---| | 01 | Änderungsstopp oder Delta-Erfassung aktivieren | Data Steward | Data Owner | Positive Go-Entscheidung | Keine unkontrollierten Änderungen | Protokoll | Offen | | 02 | Finalen Quell-Snapshot erzeugen und sichern | Migrationsteam | Data Owner | Kontrollierte Quelle | Eindeutig bezeichnete Sicherung | Prüfsumme/Referenz | Offen | | 03 | Produktiven Release bereitstellen | Umsetzungsteam | Solution Owner | Freigegebener Releasekandidat | Versionierte produktive Lösung | Deploymentprotokoll | Offen | | 04 | Daten in definierter Reihenfolge migrieren | Migrationsteam | Data Owner | Zielumgebung freigegeben | Importprotokolle je Objekt | Laufprotokoll | Offen | | 05 | Mengen, Felder und Beziehungen validieren | Data Steward und Fachteam | Data Owner | Import abgeschlossen | Freigegebene Migrationsbilanz | Sign-off | Offen | | 06 | Kritische Integrationen aktivieren und prüfen | Integrationsteam | Integration Owner | Daten freigegeben | Kontrollierte Datenflüsse | Monitoring/Test | Offen | | 07 | Rollen und Nutzerzugänge aktivieren | Administration | Betriebsverantwortung | Zugriffsmatrix freigegeben | Geprüfte Zugänge | Zugriffstest | Offen | | 08 | Ende-zu-Ende-Produktionschecks ausführen | Fachteam und Test | Process Owner | Kernkomponenten aktiv | Kritische Fälle funktionieren | Checkprotokoll | Offen | | 09 | Go, Rückfall oder kontrollierte Fortsetzung entscheiden | Benannte Entscheider | Executive Sponsor | Alle Prüfstände liegen vor | Dokumentierte Entscheidung | Entscheidungslog | Offen | | 10 | Nutzer informieren und Hypercare starten | Change und Support | Betriebsverantwortung | Betriebsentscheidung steht | Support und Kommunikation aktiv | Versand-/Supportnachweis | Offen | ## 11. Rückfallplan - Rückfallauslöser: `[konkreter kritischer Zustand, keine allgemeine Formulierung]` - Letzter sicherer Entscheidungspunkt: `[interne Zeitangabe und Abhängigkeit]` - Accountable für Rückfall: `[Rolle]` - Technische Rückfallschritte: `[versionierte interne Referenz]` - Umgang mit seit Go-live erzeugten Daten: `[Export, Abgleich, Aufbewahrung, Entscheidung]` - Reaktivierung oder Nutzung des Altsystems: `[geprüfter Weg]` - Kommunikation an Nutzer und externe Beteiligte: `[Owner und Vorlage]` - Prüfung nach Rückfall: `[Daten, Zugänge, Integrationen, Geschäftsbetrieb]` Ein Rückfallplan ist nur belastbar, wenn der Zielzustand nach Abbruch bekannt ist und neue Daten nicht unbemerkt verloren gehen oder in zwei Systemen auseinanderlaufen. ## 12. Hypercare und Betriebsübergabe - [ ] Triage trennt Defect, Bedienfrage, Datenproblem, Prozessentscheidung und Erweiterungswunsch. - [ ] Kritikalität, Owner, Reaktionsweg und Eskalation sind vereinbart. - [ ] Monitoring für Lösung, Integrationen, Fehlerwarteschlangen und Datenqualität ist aktiv. - [ ] Supportfälle und Nutzerfeedback werden regelmäßig gemeinsam bewertet. - [ ] Offene Projekt-Restpunkte wurden an dauerhafte Owner übergeben. - [ ] Admin-, Release-, Backup- und Wiederherstellungswissen liegt beim Betrieb. - [ ] Neue Anforderungen werden nach Geschäftsrisiko und Wert priorisiert, nicht still in Produktion umgesetzt. - [ ] Adoptionssignale prüfen vollständige Arbeitsfälle, Datenqualität und Prozesswirkung statt nur Logins. ### Erste Betriebsprüfung | Signal | Erwartung aus Projektauftrag | Beobachtung | Ursache oder Hypothese | Owner | Nächste Maßnahme | |---|---|---|---|---|---| | Vollständige Pilotfälle | `[eigene Erwartung]` | `[ergänzen]` | `[ergänzen]` | Process Owner | `[ergänzen]` | | Datenqualität | `[eigene Erwartung]` | `[ergänzen]` | `[ergänzen]` | Data Owner | `[ergänzen]` | | Aufgaben und Übergaben | `[eigene Erwartung]` | `[ergänzen]` | `[ergänzen]` | Fachteam | `[ergänzen]` | | Integrationsfehler | `[eigene Erwartung]` | `[ergänzen]` | `[ergänzen]` | Integration Owner | `[ergänzen]` | | Support und Feedback | `[eigene Erwartung]` | `[ergänzen]` | `[ergänzen]` | Support-/Change-Owner | `[ergänzen]` | ## 13. Finale Entscheidung - Entscheidung: `[Go | No-Go | verschoben | Go mit bewusst akzeptierten Restpunkten]` - Entscheidungszeitpunkt: `[JJJJ-MM-TT, Uhrzeit, Zeitzone]` - Geschäftliche Freigabe: `[Rolle und interne Referenz]` - Fachliche Freigabe: `[Rolle und interne Referenz]` - Datenfreigabe: `[Rolle und interne Referenz]` - Technische Freigabe: `[Rolle und interne Referenz]` - Betriebsfreigabe: `[Rolle und interne Referenz]` - Akzeptierte Restpunkte: `[Auswirkung, Workaround, Owner, Zielentscheidung]` - Nächster Review: `[interner Termin oder Auslöser]` Diese Vorlage dokumentiert den Entscheidungsweg. Die tatsächliche Freigabe bleibt Aufgabe der benannten Verantwortlichen des einführenden Unternehmens.