1 - Inhalt [Seite 6]
2 - Über dieses Buch [Seite 10]
3 - Hauptakteure der Field Story [Seite 12]
4 - ERP: Eine Welt für sich [Seite 14]
4.1 - Was ERP-Großprojekte so besonders macht [Seite 14]
4.2 - Die Risiken von ERP-Projekten [Seite 17]
4.3 - Die Rolle des Leadership Coach im Projektumfeld [Seite 19]
5 - Die Initialisierungsphase [Seite 24]
5.1 - Von der Idee zum Projekt [Seite 24]
5.2 - Das Projektmandat [Seite 28]
5.3 - Systeme vs. Prozesse [Seite 32]
5.4 - Stakeholder-Management [Seite 34]
6 - Der Projektansatz [Seite 42]
6.1 - Eine Übersicht über die Herangehensweisen [Seite 42]
6.2 - Template oder Rollout? [Seite 43]
6.3 - Harmonisierung von Geschäftsprozessen? [Seite 46]
6.4 - Make or Buy? [Seite 48]
6.5 - Wie viele Go Lives? [Seite 55]
6.6 - Zentral oder dezentral? [Seite 59]
6.7 - Offshore oder onshore? [Seite 61]
6.8 - Die richtige Projekt Methodik [Seite 68]
6.9 - Wie viel Projektdokumentation muss sein? [Seite 70]
7 - Die Vorbereitungsphase [Seite 88]
7.1 - Übersicht [Seite 88]
7.2 - Der Lenkungsausschuss [Seite 88]
7.3 - Scoping oder: Wie Sie den Projektumfang festlegen [Seite 95]
7.4 - Zeitleisten- und Personalbedarfsplanung [Seite 105]
7.5 - Die Meilensteinplanung [Seite 110]
7.6 - Der Business Case: Lohnt sich Ihr Projekt? [Seite 113]
7.7 - Der Projektantrag: Basis der Projektgenehmigung [Seite 118]
7.8 - Die Budgetierung [Seite 120]
8 - Die Mobilisierungsphase - Der Startschuss [Seite 126]
8.1 - Wie Sie eine Infrastruktur schaffen [Seite 126]
8.2 - Wie Sie eine Projekt und Teamstruktur organisieren [Seite 127]
8.3 - Parallele Projekte: Wie stellen Sie die Template-Integrität sicher? [Seite 134]
8.4 - Wie Sie das Team vor Ort hochfahren [Seite 136]
8.5 - Prozess Spezialisten: Die Profis Ihrer Kunden [Seite 138]
9 - Die Blueprint Phase [Seite 148]
9.1 - Übersicht [Seite 148]
9.2 - Prozess Audit: Die Feststellung des Status Quo [Seite 148]
9.3 - Die Fit /Gap-Analyse: Was passt, was passt nicht? [Seite 151]
9.4 - Das V-Modell: Spezifikation der Neuprogrammierung [Seite 152]
9.5 - Rollen und Berechtigungen [Seite 154]
9.6 - Scope Change Management: Richtiger Umgang mit Änderungen [Seite 156]
9.7 - Die Abnahme des Blueprint [Seite 159]
10 - Die Realisierungsphase [Seite 166]
10.1 - Übersicht [Seite 166]
10.2 - Prozessanpassung und die Rolle von Change Management [Seite 168]
10.3 - Integration & Scope Change Management [Seite 170]
10.4 - Krisen, Eskalationen und Umgang mit Widerständen [Seite 172]
11 - Planung, Überwachung und Kontrolle [Seite 186]
11.1 - Rollierende Feinplanung und Fortschrittskontrolle [Seite 186]
11.2 - Budget Management und Project Controlling: Wie Sie die Kosten im Griff behalten [Seite 194]
11.3 - Risiko-Management [Seite 198]
11.4 - Motivations-Management: Wie Sie ein gutes Arbeitsklima schaffen [Seite 202]
12 - Konfiguration, Programmierung & Tests [Seite 204]
12.1 - Übersicht [Seite 204]
12.2 - Programmierung: Für Sie eine Black Box? [Seite 204]
12.3 - Der Unit Test: Prüfstand für das Entwicklungsobjekt [Seite 208]
12.4 - Der System-Test: Testfälle für größere Zusammenhänge [Seite 209]
12.5 - Der Integrationstest: Szenarien in der Prüfung [Seite 212]
12.6 - Test-Tools: Lohnen sich automatisierte Tests? [Seite 213]
13 - Datenbereinigung, Datenübernahme, Archivierung [Seite 214]
13.1 - Übersicht [Seite 214]
13.2 - Die Datenübernahme: Vom richtigen Umgang mit Alt-Daten [Seite 215]
13.3 - Die Datenbereinigung: So gehen Sie mit fehlerhaften Daten um [Seite 218]
13.4 - Der Life-Test: Prüfstand für die Datenübernahme [Seite 221]
13.5 - Der Stress-Test: Generalprobe für die Migration [Seite 223]
13.6 - Der Regressionstest: Prüfung von Altbewährtem [Seite 224]
14 - Training der Endanwender [Seite 226]
14.1 - Übersicht [Seite 226]
14.2 - Trainingskonzept: Das A und O für ein gutes Training [Seite 227]
14.3 - So setzen Sie die Trainingskonzeption um [Seite 230]
14.4 - Trainingsplanung und -verwaltung [Seite 232]
14.5 - Trainingsdurchführung und -überwachung [Seite 234]
15 - Letzte Vorbereitungen und Produktivstart [Seite 238]
15.1 - Übersicht [Seite 238]
15.2 - Der Abnahmeprozess [Seite 239]
15.3 - Die Planung des Produktivstarts [Seite 241]
15.4 - Die Planung der Anlaufunterstützung [Seite 242]
15.5 - Krisenmanagement: So meistern Sie Unplanbares [Seite 244]
15.6 - Der Produktivstart: Das System wird zum Leben erweckt [Seite 245]
16 - Support [Seite 246]
16.1 - Übersicht [Seite 246]
16.2 - Service Level Management: Wie Sie die Fehlerbehebung überwachen können [Seite 248]
16.3 - Loslassen: Übergabe an die Maintenance Abteilung [Seite 250]
16.4 - Lessons Learned: Lernen für das nächste Projekt [Seite 252]
17 - Glossar [Seite 255]
17.1 - Über den Autor [Seite 258]
17.2 - Danksagung [Seite 258]
18 - Literaturverzeichnis [Seite 259]
19 - Stichwortverzeichnis [Seite 260]
Support (S. 245-246)
Übersicht
Warum überhaupt eine Support-Phase? Bei der Einführung von SAPLösungen wie auch von Upgrade- oder anderen Veränderungsprojekten ist in den meisten Unternehmen ein Zusammenspiel von zwei ITOrganisationseinheiten zu beobachten:
• Der Projektorganisation: Sie führt das Projekt in allen bisher beschriebenen Phasen durch und ist zuständig für den so genannten „Post-Production-Support“, also die Phase unmittelbar nach dem Go-Live.
• Der Maintenance- oder Support-Organisation: Sie ist für die Anwenderunterstützung nach Abschluss des Projekts zuständig.
Ein Projekt hat ein definiertes Ende, das sich aus einem erwarteten Ergebnis zu einem geplanten Zeitpunkt unter Einhaltung eines vorgegebenen Budgets ergibt. Nach Erreichung dieses Ziels wird das Projekt aufgelöst, und seine Mitglieder werden aus der Verantwortung entlassen. Zu diesem Zeitpunkt muss der Staffelstab an eine andere Organisation übergeben werden, die von jetzt an die Verantwortung für die Arbeitsergebnisse des Projekts übernimmt. Bei SAP-Projekten ist dies nicht anders.
Der Übergang findet typischerweise am Ende der geplanten Support-Phase statt, die noch Teil des Projekts ist. Die Support-Phase dauert je nach Projektumfang typischerweise zwischen zwei und acht Wochen. In dieser Phase sind alle Energien darauf gerichtet, die Anwender bei der Nutzung der neuen SAP-Lösung zu unterstützen. Anders als im späteren Regelbetrieb ist die eingeführte Lösung zum Zeitpunkt des Produktivstarts häufig noch nicht bis in alle Details stabil. Um möglichen Schaden von den Geschäftsbereichen abzuwenden, müssen auftretende Fehler daher möglichst schnell erkannt und behoben werden. Typische Fehler, die während der Support-Phase auftreten können, sind z. B.:
• Anwender XY hat keine Berechtigung für Transaktion Z.
• Der Drucker im Gebäude 4711 ist nicht erreichbar.
• Auf dem Rechnungsformular abc fehlt die Postleitzahl.
• Die Ergebnisse des MRP-Laufs (Materialbedarfsplanung) sind fehlerhaft.
• Anwender XY hat noch keine Schulung besucht oder hat die Schulungsinhalte wieder vergessen.
• Fehlbedienung des Systems und anschließende Fehlerkorrektur.
Dies alles erfordert eine entsprechend geschulte Projektmannschaft sowie eingespielte und hinreichend kommunizierte Support-Prozesse, d.h., alle Endanwender in den Geschäftsbereichen müssen wissen:
• Wo kann ich die Inhalte der Schulungen nachlesen?
• Was sind die Antworten auf die häufigsten Fragen (FAQ)?
• An wen wende ich mich, wenn ich ein Problem habe?
• Gibt es ein Call Center, und welche Informationen werden von den Mitarbeitern dort benötigt?
• Wie beschreibe ich die Schwere des Problems?
• Mit welchen Antwortzeiten kann ich rechnen?
Viele Projektmanager begehen den Fehler, alle Aufmerksamkeit auf den erfolgreichen Produktivstart zu richten, was absolut verständlich und wichtig ist. Häufig reicht die Kraft und Energie auch einfach nicht für mehr. Die Supportphase ist aber der Zeitraum, in dem die Endanwender, also die breite Masse, zum ersten Mal mit der neuen SAP-Lösung und mit den Support- Prozessen in Berührung kommen. Hier muss sich das Projekt bewähren.
