Herauslösen eines Geschäftsbereichs aus einem Unternehmen – Konzept zum SAP S/4HANA Carve-out Projekt

Das Herauslösen eines Geschäftsbereichs aus einem Unternehmen, bringt sowohl organisatorische als auch technische Herausforderungen mit sich. Aus der Sicht der SAP-Projektleitung, werden die wesentlichen Schritte in diesem Artikel am Beispiel Einkauf, Bestandsführung und Rechnungsprüfung veranschaulicht.

Ergänzend wird eine Mischform der klassischen und modernen Projektmethodik skizziert, die an die üblichen 5 Phasen des Projektmanagementinstituts (PMI) bzw. die 6 Phasen der SAP Activate Projektmethodik (vgl. SCRUM) angelehnt ist. Aufgrund der klaren Zieldefinition (Lösungen), direkten Zuordnung von Verantwortlichen und Planbarkeit (Zeit & Kosten), wird gerne ein Teil der Wasserfallmethode beibehalten. Einzelne Projektphasen können dann dennoch in Sprintzyklen untergliedert und Änderungen bzw. neue Anforderungen im Backlog aufgenommen werden. Während der Sprintplanung werden die ursprünglich geplanten Arbeitspakete sowie im Backlog neu hinzugekommen Inhalte konkretisiert, indem man Arbeitspakete bildet (Work Packages), diese in Work Items untergliedert, eine Aufwandsschätzung vornimmt (T-Shirt Sizing) und Verantwortliche zuweist.

Üblicherweise wird auch in den Einführungsprojekten nicht SAP Activate mit Focused Build nach Best Practice-Vorgabe umgesetzt, da die vollständige Umsetzung recht aufwändig und teuer ist. In einem Carve-out-Projekt kommen wenig neue Entwicklungsumfänge dazu, daher ist diese Vorgehensweise selten anzuraten. Die meisten Unternehmen nutzen weder Focused Build noch Focused Run im Solution Manager; auch weil dessen Ablaufdatum mittlerweile bekannt ist. Der Autor reduziert es daher auf einen praktikablen Ansatz.

Projektauftakt und Projektplanung

Der Projektauftakt und die Projektplanung, beinhalten ähnliche Aspekte. Innerhalb der SAP Activate-Projektmethodik wird dies sogar in drei Projektphasen untergliedert (Discover, Prepare und Explore). Üblicherweise wird ein Project Charter für das Gesamtprojekt erstellt und nicht weiter untergliedert, sodass Umfänge eines Teilprojekts auch deshalb nur grob dargestellt werden können und eine gewisse Flexibilität hinsichtlich der gewünschten Triangel (Zeit, Umfang & Kosten) muss ohnehin mitgebracht werden. Die Vorbereitungsmaßnahmen bis zum Projektauftrag (Projektauftakt), werden innerhalb der Projektplanung weiter konkretisiert. Letztlich geht es in den ersten Phasen darum, möglichst konkret Ziele, Meilensteine, Projektumfänge, Stakeholder, Teammitglieder, Tools, Kosten (Budget) und Vorgehensweisen festzulegen, ohne alle konkreten Informationen und Lösungen für einige Herausforderungen detailliert zu kennen. Im Folgenden soll eine Anregung geboten werden, welche Aspekte mindestens Berücksichtigung finden müssen.

Klärung der Projektorganisation

• Entwicklungs- und Projektdokumentation: Projektplan, Cutoverplan, Test- & Statusberichte, Anforderungs- und Umsetzungsdokumentation bzgl. Change Requests (CRs), Tracking (RICEFW-Backlog, Risks & Change Requests) etc. Insbesondere ist auch aufzunehmen, was vorhanden ist und ob diesbezüglich eine Redokumentation gewünscht ist. Also falls Entwicklungs- und Testdokumente gänzlich fehlen bzw. bei CRs angepasst werden sollen. Der Projekt- und Cutoverplan wird ggf. nur für das Gesamtprojekt erstellt, kann in großen und komplexen Projekten jedoch auch weiter untergliedert werden. In größeren Projekten ist zudem auch eine Onboardingdokumentation anzuraten sowie ein vordefinierter Prozess. In agilen Projekten erfasst man z.B. im Backlog die Umfänge inkl. Aufwandsschätzung und untergliedert Arbeitspakete (Work Packages) weiter in Work Items, um diese Teammitgliedern zuzuweisen (Sprintplanung). Viele Anregungen und Vorlagen bzgl. Dokumentation finden Sie über den Hyperlink. Die üblichen Fehler zum Wissensmanagement im Allgemeinen vermeiden Sie, wenn Sie den Artikel dazu lesen.
• Meetings und Regeltermine: Statusmeetings bzgl. Gesamtprojekt, Teilprojekt, Tests (UATs), Cutover, Arbeitspaketen (Datenobjekte, Entwicklungsumfänge, Prozessabbildungen usw.) und Einzelgesprächen (nicht nur mit Stakeholdern). Wünscht der Kunde eher eine selbständige Arbeitsweise oder möchte er gem. der agilen Vorgehensweise viele Meetings mit detailliertem Tracking von Teilergebnissen (Work Packages & Items)? 
• Systemlandschaft und Tools: Festlegung der Projektsystemlandschaft (Systeme, Transportwege, Schnittstellen usw.) und in welchen Tools das Projekt abgewickelt wird (SolMan, Jira, SharePoint, Teams etc.). Zudem sind softwareseitige Tools bzw. Projektbeschleuniger (Migration Cockpit, LSMW, CrystalBridge, SmartClone etc.) und ggf. auch Zusatzaufwände festzuhalten (Schulungen in Enable Now, Testautomatisierung via Suxxesso etc.). So kann z.B. eine vierstufige Systemschiene zum S/4HANA-System als parallel Projektsystemlandschaft aufgebaut werden (Entwicklung, Qualitätssicherung, Vorproduktion und Produktion), was auch der SAP Activate und Focused Build Vorgesehensweise entspricht.
• Stakeholder & Team: Erstellung von Organigrammen so weit bereits möglich, Definition der Zuständigkeiten und Entscheidungsträger etc. Während das Project Charter üblicherweise diesbezüglich noch übersichtlich bleibt, erfolgt im Rahmen der weiteren Planung die Personalkonkretisierung. Zum Onboardingprozess sollte daher auch die Organigrammanpassung gehören. Details zum systematischen Stakeholder-Management finden Sie im verlinkten Artikel; aufgrund der Relevant sollte mindestens der Abschnitt gelesen werden.
• Projektmethodik: Während der Festlegung dieser Teilaspekte, kristallisiert sich auch eine Projektmethodik heraus. Definieren Sie einen weniger akademischen und eher kosteneffizienten Ansatz mit einer gewissen Flexibilität und reflektierender Mehrwertbetrachtung.
• Teilprojektumfang: Eine erste Grobaufnahme für den Projektauftrag kann anhand des Modulumfangs (siehe Projektumsetzung) erfolgen. Während der Projektplanung wird dieser wiederum als Grundlage für die Detailworkshops genutzt. Die Workshops mit Anwendern können um eine Systemanalyse bzgl. Prozesskonfiguration und RICEFW (bzgl. Entwicklungen, Schnittstellen Formulare etc.) ergänzt werden, um vergessene Umfänge proaktiv anzusprechen und zu vermeiden.
• Abgrenzung des Teilprojekts: MRP, ATP, Kontenfindung, User usw., damit Umfänge nicht in zwei Teilprojekten gleichzeitig eingeplant werden.
• Klärung von Integrationsaspekten: Qualitätssicherung innerhalb der Beschaffung beim Wareneingang bzw. bzgl. Lieferanten (QM), platzgenaue Wareneingangsprozesse (EWM), Streckenbestellungen (SD), Verwendung des Dokumentenmanagementsystems (DMS), Fremdbearbeitung (PP), ePP/DS, JIS, JIT etc. Auch um zukünftige Integrationstests gemeinsam planen zu können und frühzeitig Aufwände und Seiteneffekte im Blick zu haben.

Projektumsetzung

Die SAP Activate-Projektphase Realize wird vom Projektmanagementinstitut (PMI) in die Teilaspekte Projektdurchführung und Projektcontrolling untergliedert, weshalb der Autor dies ebenso macht.

Projektcontrolling und Kommunikationsstrategien

• Stakeholder-Engagement: Etablierung einer regelmäßigen Kommunikationsstrategie, um Projektfortschritte zu verdeutlichen, Zugriff auf nötige Ressourcen zu bekommen, Verantwortlichkeiten festzulegen und im Rahmen des Risk & Change Managements Detailabweichungen abzuklären. Auch die Überwachung von Umfängen (CRs), Fristen und Kosten, sollte strukturiert erfolgen (z.B. Prozess bzgl. CRs, Statusberichte, Listen bzgl. WRICEF, Issues usw.) und regelmäßig abgestimmt werden.
• Change-Management: Organisatorische Änderungen, bzgl. zukünftigen Arbeitsumfänge und -abläufe, müssen über Workshops, Schulungen und eine zielgruppenabhängige Kommunikationsstrategie in den Konzern getragen werden. Abhängig von der Zielgruppe ist die Regelmäßigkeit und Kommunikationsform (schriftlich & mündlich) anzupassen bzw. abzustimmen. Die Projektdokumentation fällt in einem Carve-out Projekt relativ übersichtlich aus, da weniger neue Entwicklungs- und Testdokumente erstellt werden und dahingehend auf vorhandene Inhalte zurückgegriffen werden kann. Nötige Änderungen können ggf. in die Anforderungs-, Entwicklungs- und Testdokumentation (z.B. URS, GK, FK, TRS, FRS & TS) übernommen werden. Schulungen sollten die Ausnahme bleiben, da Prozesse an sich bekannt sind und eher in Workshops über zukünftige Zuständigkeiten diskutiert wird.
• Risikomanagement: Identifikation, Bewertung und Prävention potentieller Risiken, wie z.B. einzuhaltende Fristen (Puffer), Vorgaben (Kundenaudits, Compliance, DSGVO etc.), Datenverlust (Systembackup & Tests), nachträgliche Änderungsanforderungen (Fristen, Seiteneffekte & Aufwände), Engpässe (Spezialwissen, Parallelprojekte etc.) etc.
• Projektcontrolling: Es sind Prozesse, Dokumente und Zuständigkeiten zu definieren, um innerhalb der Triangel (Kosten, Zeiten & Umfänge) stets Transparenz auf unterschiedlichen Detaillierungsebenen zu erreichen. Wählen Sie einen praktikablen Ansatz, der Trackingkosten nicht unberücksichtigt lässt. Mikromanagement bewirkt selten schnellere Arbeitsfortschritte, sondern bindet zusätzlich Ressourcen. Seien Sie in den richtigen Bereichen konsequent (Eigenverantwortung) und nahbar. Haben Mitarbeiter das Gefühl, Sie können Ihre Herausforderungen offen schildern, dann können zeitaufwändige Prozesse und detaillierte Trackinglösungen auf ein sinnvolles Maß reduziert werden. Im Bereich SCRUM-Projektplanung und Projektdokumentation bekommen Sie einen Überblick, wie ein agiles Projekt aufgesetzt und dokumentiert werden kann (zzgl. Templates als Projektbeschleuniger).

Implementierung des Projektumfangs

Relevante Organisationsdaten, Konfiguration, Schnittstellen, Kundenentwicklungen, Formulare und User werden in dieser Phase nachgebaut. Dies sollte bestenfalls vor dem ersten Migrationslauf vollständig umgesetzt sein und über Unit- und Funktionstests bereits ein gutes Qualitätslevel erreicht haben. Haben die Experten genug Zeit bekommen und professionell gearbeitet, wird der Anwendertest (UAT) reine Formsache. Eng geplante Budgets, Fristen usw. bewirken jedoch teilweise in den Projekten Mehraufwände und zusätzliche Migrationszyklen. Bei einem gut geplanten Carve-out Projekt, sollte der Migrationslauf in das Qualitätssicherungssystem erst erfolgen, wenn der Projektumfang aus Sicht der IT in bester Qualität vorhanden ist. Wenige im UAT festgestellt Abweichungen, sollten im geplanten Nachtest im „vorproduktiven“ System stattfinden. Man muss dann nicht das Qualitätssicherungssystem zurücksetzen (dessen Vorbereitung ist im Rahmen des Risikomanagements jedoch empfehlungswert), sondern kann im Rahmen des Mock-Cutovers direkt das vorproduktive System befüllen und danach in diesem System einen Nachtest (UAT) veranlassen.

Sowohl intern, als auch extern werden Projekte gerne optimistisch und eng geplant, daher sollten durch Flexibilität zur rechten Zeit Mehraufwände in vielen Abteilungen (IT & Business) vermieden werden. Extern gewinnen nur die Optimisten mit geschickter Vertragsgestaltung Projektausschreibungen und intern sind gerade Carve-out-Projekte keine Prestigeprojekte für die gerne Budget bereitgestellt wird, weshalb das Stakeholdermanagement eine wertvolle Fähigkeit ist und (leider selten gesehene) Kosteneinsparungen bewirkt. Zwei Migrationsläufe sollten, aufgrund der üblicherweise mittelmäßigen Projektkomplexität, völlig ausreichend sein.

Ohne Anspruch auf Vollständigkeit, wird am Beispiel des Moduls MM aufgezeigt, welche Teilaspekte eine Rolle spielen können. Anhand dieser übersichtlichen Darstellung können Sie sich dann den Details nähern bzw. eine Analogie zu anderen Modulen und der Gesamtprojektumsetzung ableiten.

• Organisationsstruktur: Werke, Lagerorte, Einkäufergruppen, Einkaufsorganisationen etc.
• Einkaufsprozesse: Herstellerteilebeschaffung, Dienstleistungsbeschaffung, Konsignation, Pipeline, Limitbestellungen, Lohnbearbeitung, Fremdbearbeitung, Rechnungspläne, Lieferpläne (JIS/JIT), Streckenbestellung, Intercompany, Umlagerung usw.
• Bestandsführung: Inventurverfahren, Kontenfindung, Bestandsarten usw.
• Rechnungsprüfung: Credit Memos, Toleranzen, Evaluated Receipt Settlement etc.
• Kundenentwicklungen: Programme, Apps, Formulare inkl. Firmenpassung, Workflows, Klassen usw.
• Weiterer MM-Umfang: Freigabeverfahren, Lieferantenbewertung, LIS-Konfiguration, Nachrichtenfindung (BRF+ bzw. NACE), Automatisierung bzgl. IV, Preisfindung (Konditionen und Schemata), Versionsverwaltung, Einkaufsverhandlungsblatt, Chargen, Seriennummern, Prognosen, Fabrik- und Planungskalender etc.
• Schnittstellen zu Systemen: Bspw. bzgl. Lieferantenkommunikation und Bezugsquellenfindung (Ariba, SRM, Fieldglass usw.) Über den Hyperlink findet man Details bzgl. EDI, ALE, XI/PI, REST, CSV, RFC, oData SOAP usw.
• Stamm- und Bewegungsdaten: Identifikation der relevanten Teilmenge der im Punkt 4 aufgeführten Daten, die migriert werden sollen.
• User: Rollen und Berechtigungen inkl. Benutzerparameter

Letztlich muss der Gesamtumfang des Moduls bzgl. Prozesskonfiguration und RICEFW, wie in der Projektplanungsphase aufgenommen, jetzt vollständig implementiert werden.

Migration und Anwendertests

Die Datenmigration in das Qualitätssicherungssystem kann ggf. mehrfach erfolgen, indem man z.B. anhand einer zuvor erstellen Systemkopie bzw. eines Snapshots dieses auf den Stand vor der Migration zurücksetzt. Sie können damit bei Bedarf mehrere Test-, Migrations- und Nachbesserungszyklen in diesem System abbilden, bis Sie mit nahezu perfekter Lösung auf die nächst höhere Systemebene (vorproduktives System) wechseln. Auf dieser Ebene ist der Mock-Cutover im Fokus und Nachtests (UAT) sollten nur noch im geringerem Maße dort eingeplant sein. Im Projektmanagement lassen sich über Wellen mehrere Zyklen abbilden, welche wiederholende und nachbessernde Arbeitspakete beinhalten (noch unerledigte Arbeitspakete, Nachbesserungen von Fehlern, Änderungsanforderungen, Migration und Test). Anhand des MM-Moduls können weitere Module und die Vorgehensweise im Gesamtprojekt abgeleitet werden.

• Migrationstools: Neben den Lösungen des Herstellers (Migration Cockpit, LSMW, Massenpflege usw.), hat sich die SNP SE einen Namen gemacht, die sich mit Ihrem CrystalBridge-Migrationstool am Markt gegenüber vielen Konkurrenzprodukten bestens positionieren konnte. Details zur Lösung von SNP finden Sie im Artikelabschnitt Bluefield™ und weitere Tools zur Migration über den Hyperlink. Die neuste Lösung des Herstellers „Migration Cockpit“ wird über die Artikel Datenmigration, Migrationsobjektmodellierer und Migrationsobjekte inkl. Excelvorlagen erläutert.
• Migration der Stammdaten: Materialstämme, Geschäftspartner, Orderbücher, Einkaufsinfosätze, Quotierungen, Rahmenverträge (Kontrakte & Lieferpläne) usw.
• Migration der Bewegungsdaten: Bestellanforderungen, Bestellungen, Abrufdokumentation zu Lieferplänen, Anfragen, Angebote, Bestände usw. Teilweise reicht es offen Bewegungsdaten manuell erneut anzulegen und durch die Abstimmung mit dem Business diesen manuellen Aufwand stark zu reduzieren. Für die Bewegungsdatenmigration können SAP-Tools (LSMW usw.) verwendet werden, deren Funktionsumfang jedoch üblicherweise nicht ausreichend ist. Es werden daher oft Eigenentwicklungen genutzt bzw. es wird auf die diversen Community-Lösungen, wie z.B. ChristalBridge von SNP, zurückgegriffen. Alternative Migrationswerkezuge finden Sie über den Hyperlink.
• Datenarchivierung: Vollständige Systemkopie bzw. selektive Archivierungsstrategie zur Erfüllung von Aufbewahrungspflichten des Finanzamts, der Lieferkette sowie ggf. interner Vorgaben. So wird z.B. bei Lebensmitteln und Medikamenten eine Rückverfolgbarkeit der Inhaltsstoffe vorgeschrieben (GMP der FDA), sodass neben der Rechnung auch die Bestell- und Lieferdokumentation lückenlos nachvollzogen werden kann.
• Tests: Während man zunächst mit eigenen Testdaten innerhalb des Entwicklungsteams Funktionstests durchführt, werden Anwender- und Integrationstests (UAT) nach einem Migrationslauf und (nahezu) vollständiger Implementierung durchgeführt. Weitere Zyklen ermöglichen Nachtests. Es ist zu erwarten, dass bestehende Rollen und Berechtigungen der User übernommen werden und daher kein separater Rollentest erforderlich ist. Ein kurzer Smoketest sollte übrigens zusätzlich in einem guten Cutoverplan (Go-live) nicht fehlen, um bei den ad-hoc Realisierungen ein angemessenes Risikomanagement abzubilden. Der angesprochene Probelauf (Mock-Cutover) befüllt zudem ein vorproduktives System, welches letztmalig Nachtests im Rahmen des UATs gestattet. Details zum Testmanagement finden Sie in einem weiteren Artikel, in dem detaillierter auf die agile Projektmethodik SAP Activate und die Focused Build Lösung im Solution Manager eingegangen wird.

Vorbereitung und Umsetzung der Produktivsetzung

Die Deploy-Projektphase im Sinne der SAP Activate Projektmethodik rückt die Vorbereitung und Umsetzung des Go-Lives in den Fokus, welche in komplexeren Projekten auch schrittweise erfolgen kann (MVPs und Zielsystem bzw. Pilot und Rollouts).

Cutoverplan: Festlegung des minutengenauen Ablaufplans, d.h. der Arbeitsschritte und Verantwortlichkeiten. Schnittstellenwechsel, Delta-Migration, manuelle Bewegungsdatenübernahme, nötige Reporterstellung für Audits, Smoketest, Abnahme bzw. Rollback usw. sind wesentliche Bestandteile. Während Stammdaten nach Rücksprache mit dem Business (keine Stammdatenpflege ab Migrationsdatum) vollständig vorab migriert werden können, bezieht sich die Delta-Migration auf die Bewegungsdaten. Offene Bewegungsdaten werden zudem manuell angelegt und ebenso über die Absprache mit dem Business reduziert. Über ein Sicherheitskonzept können Zugriffe auf die jeweils relevanten Personen detailliert ausgesteuert werden, damit vermeidet man unbeabsichtigte Tätigkeiten seitens nicht involvierter Personen (Tagesgeschäft), Abweichungen von der Arbeitsreihenfolge usw. Sind z.B. Reports für Audits oder eine erste Qualitätskontrolle erforderlich, dann sollten vorab nicht Testschritte bzgl. des Smoketests durchgeführt werden. Im MM-Umfeld werden z.B. Bestände hinsichtlich Mengen und Werte mit der Ausgangssituation abgeglichen, um eine Entscheidungsgrundlage und ggf. ein Projektabschlussreporting vorzubereiten. Testdurchführungen ändern ggf. Mengen und Werte, aufgrund von Warenbewegungen. Neben der systemseitigen Austeuerung (Benutzersperrung/-freigabe), gehört dazu auch ein guter Kommunikationsplan wer wann mit wem in welchen Meetings spricht. Ggf. reicht ein durchgängiges Meeting mit definierten Anwesenheitszeiten und Events (Fertigstellung, Probleme usw.). Bzgl. MM sollte zudem geklärt werden, ob eine Aufnahme der aktuellen Bestände via Inventur sinnvoll ist und ein Domain-Cutoverplan zusätzlich benötigt wird. Die weitere Dokumentation ist bereits für einen möglichst realistischen Mock-Cutover vorzubereiten: Abnahmedokument (Sign-off), Raum- und Kontaktübersichten (inkl. Vertreter), Testfälle usw.

Risikomanagement: Neben der Planung des Smoketests als Grundlage für die Abnahme, sollte auch die negative Entscheidung vorbereitet werden. Für den Smoketest definiert man die Testschritte, welche kritische und während des Go-Lives vorgenommene Änderungen umfassen. Sollte die Abnahme negativ ausfallen, müssen ausreichend Zeit und nötige Arbeitsschritte (Rollback) analog eingeplant sein. Der Cutoverplan kann also über eine Verzweigung nach dem Abnahme-Meeting die jeweilige Fortsetzung des Go-lives in beide Richtungen detailliert planen. Auch die Rücksetzung des produktiven Systems auf den ursprünglichen Ausgangspunkt kann über Systemsnapshots/-kopien vorbereitet werden. Die erwähnte detaillierte Aussteuerung der Zugriffsrechte, ein guter Kommunikationsplan, durchdachte Reports und Testschritte, die Vertreterregelung usw. lassen diese Phase letztlich dann doch wieder unkritisch werden.

Smoketest: Ein Kurztest bzgl. der während des Go-lives vorgenommenen manuellen Anpassungen (Schnittstellenumstellungen, manuelle Bewegungsdaten usw.) und verbleibenden Delta-Migration, ergänzt um generelle Reports zum Abgleich des Quellsystems mit dem Zielsystem (in MM Bestandsmengen und -werte). Bei einem Automotivezulieferer ist z.B. die EDI-Kommunikation wichtig und JIS/JIT-Lieferpläne, da Kommunikationsmängel zur Statusabwertung des Lieferanten führen können und Lieferengpässe teuer werden können. Präventive Maßnahmen im Rahmen des Risikomanagements, sollten derartige Themen aufgreifen. Neben guten Vorabtests, vollen Beständen, dem Smoketest usw. reduziert der formale Abnahmeprozess mit vorbereiteter Fallbackstrategie den Stress auf Frust bzgl. nötiger Mehraufwände und Wiederholungen im Projekt.

Mock-Cutover: Um den tatsächlichen Go-live zu proben, wird gerne ein sogenannter Mock-Cutover durchgeführt. Diesen nutzt man einerseits, um mit dem Team Arbeitsschritte zu trainieren und andererseits, um die Planung des richtigen Go-lives zu verbessern. Mängel bzgl. Zeitabschnitte, Reihenfolge, Vollständigkeit bzgl. Arbeitsschritte, Informationen und nötiger Abstimmungstermine, können damit aufgespürt und in den Go-live-Cutoverplan eingearbeitet werden. Aus dem Mock-Cutover geht ein vorproduktives System mit allen nötigen Daten und (fast allen) Einstellungen hervor, welches man zusätzlich für einen letzten Nachtest (UAT) nutzen kann.

Go-live Vorbereitung: Den Großteil der Daten ins produktive System übertragen, Anpassungen vorziehen so weit möglich usw. Alles was man im System bereits vorab erledigen kann, sollte man nicht auf den Go-live verschieben. Mit dem Business sollte man präventive Maßnahmen vereinbaren, sodass ein holpriger Folgetag nicht durch parallele Projekte/Themen erschwert wird und offene Belege (Bewegungsdaten) auf ein Minimum reduziert werden. Die Definition von Verantwortlichkeiten ggf. sogar inkl. Vertretung (Risikomanagement) und organisatorischen Gegebenheiten (Räume, Kontaktlisten, Testfälle mit Beispieldaten usw.), gehört ebenso dazu. Insgesamt ist die Kommunikation hochzufahren, damit alle informiert sind und sich vorausschauend verhalten.

Go-Live: Tja jetzt wird´s langweilig, denn eigentlich ist alles erledigt und muss jetzt nur noch abgespult werden. Das Risikomanagement ist derart durchdacht, dass selbst im „Katastrophenfall“ sich der Stress auf Frust bzgl. nötiger Mehraufwände und Wiederholungen beschränkt. Süßigkeiten, Cola und Kaffee bereitstellen und dann lassen Sie die perfekte Show beginnen.

Projektabschlusstätigkeiten

Systembereinigung und Hypercare

Bei der SAP-Activatephase Run in einem Carve-out-Projekt, ist der Anwendersupport weniger im Fokus, sondern eher die Systembereinigung. Man könnte über den Rückbau des verbleibenden Systems nachdenken und unnötige Daten und Einstellungen löschen bzw. zurückbauen. In anderen Modulen gibt es dazu sogar ggf. gesetzliche Vorgaben (DSGVO). Risiken und Kosten führen häufig dazu, dass man diesen Schritt auf das aller Notwendigste reduziert.

Projektabschlussbericht

Teil des Wissensmanagements ist unter anderem das Lessons Learned, wo Erfahrungen und Erkenntnisse festgehalten werden, die für die Optimierung zukünftiger Projekte genutzt werden können. Eine übersichtliche Zusammenführung der relevantesten Informationen zur professionellen Projektabwicklung, wie z.B. die erfolgreichen UAT-Testfälle (Abnahmen der Funktionsumfänge), Go-live-Reports und Sign-offs (Abnahme des Go-Lives), gehören ebenso zu den Projektabschlusstätigkeiten. In einigen Branchen, können dies sogar gesetzliche oder kundenseitige Anforderungen sein (FDA, Audits, ISO etc.). Reflektieren Sie die Triangel (Zeiten, Kosten & Umfänge), erstellen Sie eine Liste über ungeplante Herausforderungen und diskutieren Sie insbesondere diejenigen Themen, die zukünftig erneut auftauchen könnten. Legen Sie den Fokus auf Weiterentwicklung mit konkreten Lösungen und nicht Schuldzuweisungen oder unspezifischer Nörgelei.

Abschlussparty

Danksagungen und Abschlusspartys schaffen ein motivierendes Arbeitsumfeld und Teamgefühl.

Zusammenfassung und Resümee

Den eigenen Projektumfang klärt man systematisch von grob nach fein mit dem Business in Workshops, grenzt diesen mit anderen Teilprojektleitern gegenüber deren Umfängen ab und bespricht mit diesen zusätzlich Integrationsaspekte. Eine Systemanalyse (Prozesse und Schnittstellen) bietet weitere Anhaltspunkte, die man ggf. durchsprechen könnte und bietet eine erste Möglichkeit nötige Beispieldaten und Prozesse zu konkretisieren. Der Kern der Projektplanung ist damit bereits umrissen.

Die Übernahme der Konfiguration kann manuell erfolgen, während für die Datenmigration und Quellcodeübernahme auch Werkzeuge genutzt werden können. Bestenfalls sollte die Systemkonfiguration abgeschlossen sein, wenn die erste Datenmigration realisiert wird. Fehlende Einstellungen und Felder können Migrationsfehler verursachen. Bei der Datenübernahme werden üblicherweise mehrere Zyklen eingeplant, um zuvor festgestellte Fehler korrigieren und testen zu können. Diverse Ansätze (Systemkopien, Clone etc.) gestatten es Systeme zurückzusetzen und daher mehrere Migrations-, Entwicklungs- und Testzyklen durchzuführen. Innerhalb der Realize-Projektphase, können also iterativ wiederholende Abläufe (Wellen) geplant werden, um sich dem gewünschten Zielsystem zu nähern und eine finale Abnahme zu erreichen. Angelehnt an die aktuell beliebte Projektmethodik SCRUM, lässt sich dies durch Wellen, Sprints, Work Packages und Items auch an die agile Vorgehensweise anlehnen.

Üblicherweise ist auch ein Mock-Cutover anzuraten, um Arbeitsabläufe zu trainieren und die Cutoverplanung zu optimieren. Am Go-live-Wochenende sollte ein sogenannter Smoketest durchgeführt werden, um kritische Umstellungen (Schnittstellen) sowie Bewegungsdaten zu prüfen (Werte & Mengen) bzgl. Bestandsführung, offene Belege usw.). Üblicherweise kann man durch Absprache die Bewegungsdaten reduzieren und manuell übernehmen. Auch eine Kombination mit einer Inventur kommt vor, um Bestände direkt prüfen und übernehmen zu können.

Ein oft vernachlässigter letzter Projektschritt, könnte die Systembereinigung sein. Im Rahmen des Änderungsmanagements erklärt man in solchen Projekten weniger die Prozesse, sondern klärt vielmehr wer zukünftig für was zuständig ist. In großen Konzernen mit komplexen Systemumgebungen, kann der Carve-out in Rolloutprojekte aufgeteilt werden. Eine Untergliederung in Werke, Länder oder die Klassifikation in ähnliche Gegebenheiten der Systemlandschaft, reduziert Risiken, die Dauer und Komplexität. So weit möglich können ergänzende Änderungswünsche abgelehnt werden, insofern diese nicht zwingend erforderlich sind oder Synergieeffekte (Kosteneinsparung) überzeugen.

Digitaler Guide für die Abwicklung diverser SAP S/4HANA-Projekte