Gemeinsam Software entwickeln

Mit SAP in wildem Wasser

Reppesgaard studierte in Hannover und arbeitete danach als Reporter und Moderator bei Hörfunk von Radio Bremen zu innen- und jugendpolitischen Themen und in den Bereichen Technologie und Wissenschaft. Seit dem Jahr 2000 lebt er in Hamburg, seit 2001 arbeitet er mit Christoph Lixenfeld im druckreif Redaktionsbüro zusammen.

Auch SAPs Tendenz, individuelle Unternehmensprozesse durch branchentypische, für Standardsoftware natürlich besser geeignete Abläufe ersetzen zu wollen, entzweite die Entwicklungspartner nicht - im Gegenteil: Etliche Postbank-Spezifika wurden im Konsens vereinheitlicht, weil die Postbank hofft, durch neue, schlankere Abläufe Geld zu sparen. Nur wenige Eigenheiten, etwa Produkte, die als Differenzierungsmerkmal angeboten werden, waren unverhandelbar. Insgesamt sind aber nur zehn Prozent der Gesamtlösung Postbank-spezifisch, der Rest ist Standardsoftware.

50 Prozent mehr Aufwand

Meta-Group-Experte Rüdiger Spies warnt die Unternehmen davor, Kosten und Personalressourcen derartiger Projekte zu unterschätzen. "Eine Entwicklungspartnerschaft ist etwa um 50 Prozent aufwändiger als ein vergleichbares Implementierungsprojekt", sagt er. Auch von zu engen Zeitplänen rät er Entwicklungspartnern ab: "Man muss notfalls auch ein halbes Jahr warten können." Doch selbst bei guter eigener Vorbereitung stellen die Beteiligten während des Projekts häufig fest, dass sich auch mit gemeinsam entwickelten SAP-Lösungen extrem spezialisierte Aufgaben nicht lösen lassen. Ein Beispiel ist die Einführung eines Patientenmanagementsystems an verschiedenen bayerischen Universitätskliniken. Herbert Seidel, Leiter der Abteilung MIT (Medizinisch-administrative Informationstechnologie) an der Münchener Uniklinik, beklagt Akzeptanzprobleme nach der Einführung der SAPSysteme "IS-H" (Industry Solution for Hospitals) für die Patientenabrechnung sowie "IS-H MED" für die Leistungs- und medizinische Dokumentation.

Viele Ärzte kamen mit der neuen Arbeitsoberfläche nicht zurecht und arbeiteten stattdessen stur mit den Altsystemen weiter. Die Beteiligten mussten die alten Oberflächen weiterleben und auf darunter liegende SAP-Datenbanken zugreifen lassen. Gelöst wird das Problem aktuell dadurch, dass das ehemals senatseigene Berliner Softwareunternehmen GSD seine zusammen mit SAP und T-Systems Austria entwickelte Software ISH*MED in den Universitätskliniken ausrollt. SAP selbst habe sich entschlossen, so GSD-Produktmanager Olaf Dörge, innerhalb der Kliniklösung "den medizinisch-klinischen Bereich nicht selbst weiterzuentwickeln".

Eine Lösung, drei verschiedene SAP-Berater

Ebenfalls vom Rechnungshof kritisiert wurde ein HR-System, das die Uniklinik München bereits seit Mitte der 90er-Jahre zusammen mit SAP entwickelt hat. Sehr spezifisch war daran die Abbildung der Dienst- und Einsatzplanung des Krankenhauspersonals, und wo es sehr speziell wird, machte auch in diesem Beispiel das SAP-System Probleme: "Die Schnittstellen der Software zur zentralen Bezügestelle der Bezirksfinanzdirektion funktionierten lange nicht", so Thomas Braun, Leitender Ministerialrat beim Bayerischen Obersten Rechnungshof. "Diese Schnittstellen mussten erst einmal programmiert werden, und zwar von drei unterschiedlichen externen SAP-Beratern."

Das entstandene HR-Modul für Kliniken ist laut Herbert Seidel von der Uniklinik München mittlerweile in das SAP-Standardbranchenpaket übernommen worden und läuft auch in Kliniken außerhalb Bayerns. Um das Geschäft mit der Software anzukurbeln, haben die Münchner sogar Präsentationen für die Kollegen aus anderen Krankenhäusern gemacht. Die Lizenzeinnamen aus dem Weiterverkauf fließen dennoch in die Kassen von SAP.

Bei so einträglichen Geschäftsbeziehungen kann man aber auch mal großzügig sein: Für die Präsentationen bekamen die Münchner von SAP immerhin Beratertage gutgeschrieben.

Zur Startseite