Projektmanagement


Lessons Learned

Projektmanagement in SAP-Großprojekten

Björn Kibbel ist seit 1999 bei der innobis AG tätig. Als Manager Development und Integration Services analysiert er bankfachliche Geschäftsprozesse und die damit verbundenen Anforderungen an die IT-/SAP-Landschaft und übernimmt die Architekturberatung bei Banken.

Klassische iterative Projektmanagement-Methoden eignen sich nach wie vor hervorragend, um große komplexe Entwicklungsprojekte umzusetzen. Weiche Faktoren entscheiden über Erfolg und Misserfolg wie das Beispiel eines Finanzdienstleister zeigt.
  • Die Arbeitspakete müssen nach technischen und fachlichen Gesichtspunkten geschnitten werden
  • Projektmitarbeiter müssen bedarfsorientiert zwischen Komponenten- und Prozessteams während des Projektverlaufs wechseln
  • Iterationen sollten gut zwischen kurzer und langer Dauer abgewogen werden
  • Entwicklungsleiter und Architekt müssen in engem regelmäßigen Kontakt zu den Teams stehen, um den Projektüberblick zu behalten; das ist eine Fulltime-Aufgabe

Wie behält man bei einem SAP-Projekt mit einem Gesamtbudget im mittleren einstelligen Millionenbereich, einem reinen Entwicklungsvolumen von einigen tausend Tagen und rund 40 beteiligten Personen in einem Zeitraum von eineinhalb Jahren das Budget, die Qualität und Zeit im Griff? Noch dazu, wenn verschiedene Dienstleister und Auftraggeber in einem Projekt vereint sind und darüber hinaus noch teils unbekannte Technologien eingesetzt werden. Es sind im klassischen ProjektmanagementProjektmanagement einige weiche Faktoren, die dann über Erfolg oder Misserfolg entscheiden können. Alles zu Projektmanagement auf CIO.de

Finanzdienstleister überführt papierbasierte Antragsprozesse in elektronische Abwicklung

Das genannte Großprojekt bestand darin, bei einem Finanzdienstleister papierbasierte Antragsprozesse in eine elektronische Abwicklung zu überführen. Dazu wurde ein auf SAP-Systemen basierendes Online-Portal mit Zugriff auf die Back-End-Systeme entwickelt. Die Antragsdaten sollten mit der SAP-Formulartechnologie SAPSAP Interactive Forms by Adobe und dem SAP CDP-Produkt (Custom Development Project) 'SAP Online Antragsmanagement (OAM)' in das Back-End eingespielt werden. Alles zu SAP auf CIO.de

Nach Bewilligung der Anträge sollte es möglich sein, Geschäftsvorfälle wie Antragsänderungen oder Mittelabrufe vom Kunden zu prozessieren. Um die mit dem Antragsverfahren verbundenen Genehmigungsprozesse zu steuern, wurde das SAP Business Rules Framework (BRF) gewählt.

Mehrmonatige Fachkonzeptphase

Der Entwicklung war eine mehrmonatige Fachkonzeptphase vorausgegangen, in der parallel bereits die architektonischen Grundlagen und Datenverarbeitungskonzepte entwickelt wurden. Aufgrund der sehr hohen Sicherheitsanforderungen wurde eine mehrschichtige Architektur gewählt und mit Firewalls und Intrusion-Detection-Systemen entsprechend abgesichert.

Das Online Antragsmanagement basierte auf SAP NetWeaver Java, das Back-End wurde auf Grundlage von SAP EHP 6.0 mit CML (Loans Management; Darlehensverwaltung) entwickelt. Ein Application Layer auf ABAP-Basis (Advanced Business Application Programming) diente als 'Vermittler'.

Flexibler Schnitt der Arbeitspakete

Die Entwicklung des Online-Portals wurde in fünf Arbeitspakete unterteilt und der gleichen Anzahl an Teams übergeben. Eine große Gefahr beim Schnitt der Arbeitspakete besteht darin, sie vollständig voneinander abgegrenzt anzulegen. Dies geschieht dann besonders leicht, wenn man sie ausschließlich nach technischen Gesichtspunkten - beispielsweise nach System-Komponenten - schneidet.

Erfolgreicher ist die Planung von mindestens ein oder mehreren Teams, die einen fachlichen Prozess umsetzen. Diese Teams sind auf die Basis-Komponenten der anderen Teams angewiesen. Entstehen bei der Entwicklung der Komponenten Lücken in der fachlichen Abdeckung, werden diese von den Prozessteams aufgedeckt.

Da die Prozessteams in den ersten Iterationen noch keine System-Basis haben, auf der sie aufsetzen können, werden sie zu Beginn mit wenigen Ressourcen ausgestattet. Mitarbeiter aus den Komponententeams wechseln dann nach zwei bis drei Iterationen in die Prozessteams, sodass diese wachsen und die Komponententeams wieder kleiner werden. Das Know-how rund um die Komponenten wird so in die Prozessteams mitgebracht. Im oben genannten Praxisbeispiel wurden je ein Prozessteam für die Antragsanlage und die Abbildung der Geschäftsvorfälle gebildet.

Zur Startseite