Eine Branchenlösung für Krankenkassen in Deutschland zu schaffen müsste für ein Softwarehaus eigentlich eine spannende Sache sein. Der Markt ist riesig, über 70 Millionen Versicherte werden von rund 320 gesetzlichen Krankenversicherungen (GKV) betreut. Trotzdem habe SAP nach ersten Gesprächen mit der AOK 1996 einen Rückzieher gemacht, erzählt Klaus Schmitt, der Geschäftsführer von AOK-Systems. Erst als die IT-Tochter der größten deutschen Krankenkasse Anfang 1999 gegründet wurde, um mit kasseneigenem Know-how die dringend benötigte Lösung zu schaffen, meldeten sich die Walldorfer zurück. Schmitt ließ sich auf den Deal ein, die komplexe Dreiecksbeziehung zwischen Versicherern, Gesetzgeber und Kunden gemeinsam abzubilden: "Wir haben kalkuliert, dass wir für die Entwicklung einer Individuallösung etwa 15 Jahre gebraucht hätten. Durch das Einbeziehen von SAP-Komponenten werden es nur etwa acht Jahre sein."
Schmitt ist in großer Gesellschaft: Immer wieder gehen IT-Entscheider ohne dazwischengeschaltete Berater strategische Entwicklungspartnerschaften mit SAP ein. Coca-Cola, Nestlé, die Lufthansa, Daimler-Chrysler, Infineon oder die Schweizer UBS AG arbeiteten mit den Walldorfern zusammen, statt von der Stange zu kaufen. Etwa 20 Großkundenprojekte hat SAP in den letzten vier Jahren in Angriff genommen. Mit welchen Unternehmen man dabei ins Boot steigt, ist immer eine strategische Vorstandsentscheidung. "SAP hat ein enormes Interesse daran, diese Projekte nicht scheitern zu lassen, denn sie sind der Schlüssel, um in bestimmte Märkte überhaupt hineinzukommen", meint Rüdiger Spies, Analyst der Meta Group Deutschland.
Doch nicht immer profitieren beide Seiten von den Kooperationen. Im Laufe der Zusammenarbeit mit der AOK kühlte das Klima zwischen den Partnern ab. Der erste Teil der Lösung, der seit dem 1. März dieses Jahres produktiv ist, managt sämtliche Daten der Versicherten, der Arbeitgeber und der Krankenhäuser. Das zweite Release, genannt "Claims 2.0", soll 2006 für die gesamte Abrechnung von Leistungen bereitstehen. Während der erste Teil der Lösung großenteils auf fertigen Standardkomponenten von SAP beruhe, so AOK-Systems-Geschäftsführer Schmitt, wurde der zweite Baustein gemeinsam entwickelt. Die sich rasch ändernden gesetzlichen Bestimmungen im Krankenversicherungsbereich abzubilden ist jedoch kompliziert.
Der Hang von SAP, auf derart vermintem Gelände Zeit und Geld zu verlieren, hielt sich in Grenzen. Das so genannte GKV Add-On wurde letztlich allein von AOK Systems entwickelt. Das Geschäft mit der Branchensoftware wird in Zukunft aber weitgehend ohne die AOK gemacht. Abgesehen vom GKV-Add-On verbleiben die Rechte an der Software und damit zukünftige Lizenzeinnahmen bei SAP. Wettbewerber Barmer hat die Software bereits gekauft, und Schmitt geht davon aus, dass "weite Teile der Entwicklung künftig sogar in privaten Versicherungen einsetzbar sind, weil sich die Arbeitsweisen der beiden Systeme weiter angleichen." Er sagt aber auch: "Wir selber könnten so ein System in der Größenordnung vermutlich gar nicht effektiv vermarkten."
Über so viel Bescheidenheit dürfte sich SAP-Deutschland-Geschäftsführer Michael Kleinemeier ein Loch in den Bauch freuen. Die IT-Tochter der größten deutschen Krankenversicherung räumt von sich aus das Feld und lässt SAP das Geschäft machen. Kleinemeier räumt freimütig ein, "dass wir bei strategischen Entwicklungsprojekten in der Regel die Vermarktung der entstandenen Lösungen allein übernehmen. Die meisten sagen ohnehin, dass der Verkauf der Software nicht ihr Kerngeschäft ist." Und Andrea Roesinger, Senior Vice President der Business Solutions Group Financial & Public Services, betont: "SAP entwickelt ja nicht nur für den Kunden, sondern will auch einen Nutzen für spätere Produkte haben."
Das aber ist der Kern vieler Interessenkonflikte, die bei der Konstellation SAP und Entwicklungspartner programmiert sind. Walldorf ist vor allem daran gelegen, Prozesse abzubilden, die übertragbar sind, während die Partner insgeheim hoffen, dass SAP für sie eine Individuallösung zimmert. Dabei sagt SAP-Geschäftsführer Michael Kleinemeier unmissverständlich: "Es macht keinen Sinn, sich in Individualprojekte reinziehen zu lassen. Dann sagen wir nein."
SAP-Lösung gefährdet Wettbewerbsvorteil
Nicht alle Unternehmen halten deshalb eine Entwicklungspartnerschaft mit SAP für erstrebenswert. Die Techniker Krankenkasse beispielsweise nutzt zwar SAP-Module out of the box für Standardanwendungen. Branchenspezifische Anwendungen entwickelt man aber lieber unter dem Namen TKeasy auf Java-Basis selbst, sagt IV-Leiter Dietmar Schröder. Er sieht bislang keinen Grund, den Walldorfern oder irgendjemand anderem tiefe Einblicke in die Abläufe und das Branchen-Know-how der Techniker zu gewähren: "Wir haben uns bewusst dagegen entschieden, um Wettbewerbsvorteile zu erhalten."
Die Karstadt Quelle AG hat dagegen keine Probleme damit, SAP tiefe Einblicke zu erlauben. Seit Mitte vorletzten Jahres entwickelt man gemeinsam ein Standard-Warenwirtschaftssystem für den stationären Einzelhandel. Schwerpunkt: Textilien und Sportartikel. Eine Win-Win-Situation, sagt Gesamtprojektleiter Christian Marzinzik: "SAP hat die Chance, mit dem Konkurrenten Retek gleichzuziehen. Das verpflichtet die Firma, penibel an den Projektterminen festzuhalten." Mitte Mai soll die Testphase der ersten neuen Softwarebausteine beginnen.
Während man bei Karstadt nichts über die Kosten und die Mannstärke des Projekts erfährt, wird am Beispiel Postbank deutlich, wie aufwändig die Kooperationsprojekte sind. Sie hat gemeinsam mit SAP einen Transaktionsplattform entwickelt, über die die Konten der eigenen Kunden sowie die der Dresdner und der Deutschen Bank geführt werden. "Diese Plattform ist das Herz der Bank", sagt IT-Vorstand Dirk Berensmann. An der Entwicklung waren allein auf Postbank-Seite bis zu 800 Personen beteiligt. Über 200 Millionen Euro kostete das Projekt. Das Gros der Summe entfiel dabei allerdings auf ein neues Rechenzentrum und andere Projektteile und wanderte nicht in die Taschen von SAP. Im Gegenteil, die Postbank hat so gut verhandelt, dass die Walldorfer die gesamten Entwicklungskosten trugen. "Wir bezahlen nicht den Preis, der eigentlich bei einem Integrations- oder Entwicklungsprojekt anfallen würde, sondern praktisch nur Lizenzkosten, die angefallen wären, wenn wir ein bereits existierendes Produkt eingesetzt hätten", freut sich Berensmann. Vor diesem Hintergrund schmerzt es ihn nicht, dass die Walldorfer möglicherweise bei anderen Projekten mit den hier gewonnenen Erfahrungen viel Geld verdienen.
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.