Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.01.1990 - 

Manchmal eignet sich auch die Software des Konkurrenten

Die Altemative: anpassen anstatt neu entwickeln

*Rolf Giersch ist geschäftsführender Partner der Wiese und Partner Unternehmensberatung GmbH in Hamburg.

Auch bei der Individualsoftware muß das Rad nicht immer wieder neu erfunden werden. Bei einer Reorganisation im DV-Bereich lohnt sich der Blick zur Konkurrenz, denn deren Software taugt vielleicht auch für die eigenen Belange. Sie zu kaufen, so Rolf Giersch*, kann im Vergleich zur Eigenentwicklung bis zu 20 Prozent Kosten sparen.

Die Arbeitsabläufe in Versicherungsunternehmen gleichen sich in weiten Bereichen, insbesondere in spartenübergreifenden Funktionen. Diese Erkenntnis legt den Gedanken nahe, bei Reorganisationsvorhaben im DV-Bereich nicht grundsätzlich neue Systeme zu entwickeln, sondern auch zu prüfen, ob Anwendungssysteme, die bei anderen Unternehmen im Einsatz sind, für das eigene Haus nutzbar gemacht werden können, um damit den Ent- wicklungsaufwand zu reduzieren.

Die bisherigen Erfahrungen der Gesellschaften mit der Übernahme fertiger Software sind allerdings nicht immer ermutigend. Hauptursachen für das Scheitern waren:

- das Fehlen eines Konzeptes für die inhaltliche und technische Anpassung an die eigene Systemumgebung,

- mangelnde Anwender-Akzeptanz für ein System, das nach den Bedürfnissen eines anderen Unternehmens entwickelt und ausgestattet wurde - zumal wenn eine ausreichende Unterstützung der Geschäftsleitung fehlte,

- keine ausreichende Prüfung der Verträglichkeit mit der hauseigenen DV -Umgebung,

- wenig Unterstützung durch den Verkäufer.

Mit der Fertigstellung des im August 1988 in Produktion übernommenen neuen Inkassosystems hat die Versicherungsgruppe Deutscher Ring in Hamburg bewiesen, daß der erfolgreiche Einsatz fertiger Pakete bei richtiger Vorgehensweise möglich und wirtschaftlich interessant ist. Erfolgreich, weil die Anwendung vom Haus akzeptiert wurde, und wirtschaftlich interessant, weil die Kosten gegenüber einer Eigenentwicklung urn rund 20 Prozent niedriger lagen.

Die DV-Entwicklung des Deutschen Rings soll zu einem konzernübergreifenden Gesamtsystem führen. Dafür werden alle Anwendungen (Kundeninformationssystem Inkasso, Bestände, Vertrieb) neu entwickelt und zusammengefügt. Es wurden Richtlinien für eine einheitliche, maschinell unterstützte Entwicklungsumgebung (Hard- und Software) formuliert, und eine Planung mit inhaltlichen Schwerpunkten und einer Realisierungs-reihenfolge vorgenommen. Damit war der Rahmen für die einzelnen Entwicklungen abgesteckt.

Die Planung sah zunächst den Neuaufbau der zentralen Anwendungen Kundendatenbank und Inkasso vor. Bei der Entwicklung der Kundendatenbank wurden Erfahrungen bezüglich Budget- und Terminverhalten gesammelt. Dies führte zu Überlegungen, wie die Vorgehensweise bei weiteren Projekten verbessert werden könnte, damit sich die Planungssicherheit bezüglich Kosten und Terminen reduziert.

Jedes größere Projekt wird beim Deutschen Ring in Phasen abgewickelt. Die Aktivitäten werden abgrenzbaren Zeitabschnitten zugeordnet und die Teilziele definiert, die mit Abschluß einer Phase erreicht sein sollen. Der Ring hat dafür ein Phasenkonzept mit vordefinierten Aktivitäten und maschineller Unterstützung der projektbegleitenden Dokumentation entwickelt, das auch Maßnahmen zur Qualitätssicherung umfaßt.

Die Kosten sollen reduziert werden

In der ersten Phase wurde nach diesem Konzept der Istzustand analysiert und die Anforderungen an das neue System zusammengetragen (Grobsollkonzept). Auf der Basis dieser Ergebnisse wurden weitere Schritte überlegt. Die Aktivitäten dieser Phase sind also unabhängig davon durchzuführen, ob eine Eigenentwicklung oder der Kauf fertiger Systeme erfolgen soll.

Ausgangspunkt war die Vorgabe des Vorstandes, die geschätzten Kosten einer kompletten Eigenentwicklung erheblich zu reduzieren. Mit dieser Zielsetzung und der Nebenbedingung, die für das Gesamtsystem formulierten Standards zu beachten, wurden durch eine Ausschreibung externe Firmen aufgefordert, entsprechende Angebote abzugeben. Die vorgelegten Angebote beinhalteten eine Palette von Vorschlägen, die alle die Verwendung fertiger Systemteile bis zum Einsatz eines kompletten fertigen Systems vorsahen. Dies kann als Hinweis darauf gewertet werden, daß nur mit dieser Vorgehens-weise die geforderten Kosteneinsparungen realisierbar erschienen.

Die Wahl fiel schließlich auf die Unternehmensberatung Wiese und Partner aus Hamburg, die bereits im Bereich Versicherungen und Banken tätig ist und schon Erfahrungen in der Umsetzung komplexer Anwendungssysteme gesammelt hat. Das Angebot der Unternehmensberatung sah vor, das Inkassosystem der Württembergischen Feuerversicherung zu verwenden.

Der Kauf des fertigen Paketes ging in mehreren Schritten vonstatten. Zunächst wurde nur die Dokumentation bis hin zu den Programmvorgaben erworben, allerdings mit einer Option auch die maschinellen Programme zu kaufen.

Auf folgende Punkte war dabei besonders zu achten:

- Funktionsumfang: Abgleich mit den im Grobsollkonzept beschriebenen Funktionen.

- Anpassungsfähigkeit des Systems: Eindeutige Definition von Schnittstellen; modularer Aufbau der Programme, damit der Anschluß an eigene Systeme gelingt, und die Besonderheiten des Deutschen Rings berücksichtigt werden konnten.

- Entwicklungsumgebung im verkaufenden Unternehmen: Die Lauffähigkeit komplexer Systeme kann wesentlich von der Systemumgebung abhängen (Tabellensystem, Standardmodule, Dialogsteuerung); eine Verträglichkeitsprüfung mit der Zielumgebung ist daher unerläßlich

- Gestaltung der Zusammenarbeit mit dem Verkäufer: Lieferbedingungen; Unterstützung durch Mitarbeiter des Verkäufers

- Maschinelle Verfügbarkeit der Systemdokumentation

- Vertragliche Regelungen über den zu liefernden Systemumfang, den Aktualitätsgrad der Kaufversion und notwendige Hilfestellungen

- Festlegung der sonstigen Aktivitäten, wie Erstübernahme der Altdaten bei Produktionsbeginn des neuen Systems

- Dokumentation

- Kosten.

Wichtig war, daß die Kaufverhandlungen schon unter Beteiligung der externen Berater stattfanden, die das System kannten und so Besonderheiten regeln konnten. Die anschließende Zusammenarbeit zwischen allen Beteiligten verlief dann auch problemlos.

Differenziertes Vorgehen beim Inkassosystem

Zunächst muß man sich von der Erwartung lösen, es reiche, das fertige Paket EDV- technisch zu installieren, und die Mitarbeiter ein bißchen zu schulen um dann in Produktion zu gehen. Das mag bei kleinen, überschaubaren Standardanwendungen und Tools reali- sierbar sein; bei komplexen Anwendungen wie dem Inkassosystem muß jedoch differenzierter vorgegangen werden. So sind in den meisten Fällen Abläufe zu schaffen, die eine Übernahme der bestehenden Daten in das neue System vornehmen. Die Aktivitäten dafür sind weitgehend unabhängig vom eigentlichen Anwendungssystem, sollten aber auf jeden Fall im Rahmen des Projekts miterledigt werden.

Wichtig ist zunnächst. daß auch bei Verwendung fertiger Systemteile oder ganzer Systeme eine normale Projektplanung und -vorbereitung erfolgt. Alle für Großprojekte geltenden Spielregeln sind zu beachten. Dazu gehört insbesondere auch die Strukturierung der Projektarbeit durch ein Phasenkonzept. Allerdings war eine Ergänzung des vorhandenen

Projekt-Entwicklungskonzeptes notwendig, um die Aktivitäten aufzunehmen, die bei Verwendung einer Kauflösung anfallen. Diese Ergänzungen waren aber aufgrund der flexiblen Struktur des Vorgangskonzeptes problemlos möglich.

Die beste Methode sich mit einem fremden Anwendungssystem vertraut zu machen, besteht darin, die mitgelieferte Dokumentation durchzuarbeiten und sie dabei auf die eigenen Belange anzupassen. Dieses Verfahren fordert die Auseinandersetzung mit allen Funktionen und führt zu einem Abgleich mit dem zuvor entwickelten Grobsollkonzept.

So wenig Änderungen wie möglich

Als Grundsatz für Anpassungen gilt: so wenig Änderungen wie möglich, damit der Vorteil, ausgetestete Programme einsetzen zu können, nicht verlorengeht. Eine Reihe inhaltlicher und technischer Änderungen wurden allerdings nach entsprechender Diskussion als unumgänglich angesehen. Die Modifikationen wurden vor der Umsetzung mit Vertretern des Verkäufers diskutiert. Jede Änderung konnte so in ihren Auswirkungen sehr sorgfältig untersucht werden, so daß die Teile weiterhin zusammenpaßten.

Die Beibehaltung dieser restriktiven Haltung gegenüber Eingriffen während der gesamten Projektlaufzeit ist ein wichtiger Baustein für eine erfolgreiche Einführung fertiger Produkte. Sie stellt eine zentrale Maßnahme zur Qualitätssicherung dar.

Die wesentlichen Änderungen waren durch folgende Sachverhalte begründet:

- Das gekaufte Inkassosystem wurde mit dem Einsatzschwerpunkt "Sachenversicherung'' entwickelt. Der Deutsche Ring wird das System später aber auch für Lebens- und Krankenversicherungen einsetzen. Für diese Sparten gilt - anders als für Sachverträge, überwiegend monatliche Zahlungsweise und eine hohe Lastschriftquote. Beide Kriterien führten zu Änderungen in der Sollstellungsverarbeitung und im Mahnverfahren.

- Die Version der Württembergischen Feuerversicherung war mit dem Datenbanksystem lMS und dem TP-Monitor IMS/ DC in Cobol entwickelt worden. Für den Deutschen Ring wurde die Dialogsteuerung auf den Monitor CICS umgestellt. Die Umstellung konnte so erfolgen, daß die eigentlichen Dialog-Programme erhalten blieben und nur die übergeordnete Steuerung modifiziert wurde.

- In der Frage der Programmiersprache wurde auf den Standard des Deutschen Rings (PL/1) verzichtet und Cobol beibehalten. Allerdings wurde auf Cobol II umgesetzt, damit der Adreßspeicher jenseits der 16 MB-Grenze unter MVS/XA nutzbar wurde.

Organisation als wichtiger Faktor

Die bisherige Praxis hat die anfänglich bestehenden Vorbehalte gegen den Einsatz mehrerer Programmiersprachen nicht bestätigt. Gerade ein Unternehmen mit Standard-PL/1, das bei DV-Entwicklungen auch Kauflösungen berücksichtigen will, wird häufiger vor dieser Entscheidung stehen, da viele fertige Systeme in Cobol programmiert sind.

Nachdem alle Anpassungen beschrieben und abgestimmt waren, liefen die weiteren Phasen an, bis schließlich nach gut zwei Jahren Gesamtlaufzeit das neue Inkasso in Produktion gehen konnte.

Ein wesentlicher Faktor für das Gelingen der Anpassung war ihre Organisation. Das Inkassoprojekt wurde mit einem Projektleiter aus dem Anwenderbereich und einem externen Mitarbeiter als DV-Fachmann und Stellvertreter besetzt.

Diese Konstruktion hat sich auch bei anderen Projekten bewährt, weil der natürliche Konflikt zwischen Anwendern und Entwicklern über den Funktionsumfang und die Ausgestaltung des Systems - und damit über die Kosten der Entwicklung - entschärft werden konnte. Der Anwender ist unmittelbar als Projektleiter beteiligt und muß so seine Wünsche auch bei der Realisierung mit verantworten.

Der Frage der Beurteilung von Anwenderwünschen kommt gerade beim Systemkauf - wie schon erwähnt - besondere Bedeutung zu. Der Deutsche Ring hat hier einen Weg eingeschlagen, der bisher in der Projektentwicklung nicht üblich war, sich aber als erfolgreich herausgestellt hat.

Bemerkenswert ist auch der Umstand, daß der Deutsche Ring für seine Projektaktivitäten eine eigene Hauptabteilung eingerichtet hat. Die Projekte berichten monatlich im sogenannten "Reviewboard" über den Arbeitsstand, die Budgetentwicklung und Probleme. Dem Board gehören die Vorstands- und Hauptabteilungsleiter der betroffenen Anwender und der Entwickler (einschließlich Rechenzentrum) ebenso an, wie die Vertreter der betriebswirtschaftlichen Abteilungen.

Das Gremium befindet auch über den Start und den Abschluß eines Projektes und seiner Phasen. Für die Detailsteuerung stehen maschinelle Planungstools zur Verfügung, mit denen ein Soll/Ist-Abgleich für Aufwände, Termine und Kosten vorgenommen werden kann.

Die Vorteile des Kaufs von fertigen Systemen gegenüber der Eigenentwicklung läßt sich am besten in Zahlen ausdrücken: Die Entwicklungszeit des Projektes bis zum Produktionsbeginn betrug rund 26 Monate. Der externe Aufwand lag bei 220, der interne Aufwand bei 120 Mannmonaten. Das bedeutete eine Aufwandserhöhung gegenüber der ursprünglichen Planung von etwa fünf Prozent. Die Verzögerungen hielten sich in Grenzen. Allerdings wurde der ursprünglich geplante Einführungstermin um eineinhalb Monate verschoben; das bedeutete eine Planabweichung von knapp sechs Prozent.

Wenn man berücksichtigt, daß mit diesem Aufwand ein System mit zirka 40 Dialog- und zirka 400 Batchprogrammen realisiert wurde, so sind sowohl der Gesamtaufwand als auch die Abweichungen als sehr gering anzusehen. Der Aufwand für eine Eigenentwicklung hätte nach unseren Berechnungen unter vergleichbaren Verhältnissen (Projektbesetzung, Projektverlauf) um etwa 1,9 Millionen Mark höher gelegen.

Bei diesem direkten Kostenvergleich ist allerdings anzumerken, daß

- Plankosten für Eigenentwicklung mit Istkosten für Kauf verglichen werden und mögliche Planabweichungen bei einer Eigenentwicklung daher nicht berücksichtigt werden können,

- die laufenden Wartungskosten bei einem gekauften System höher ausfallen können, wenn nicht alle Standards des Unternehmens eingehalten werden, und dadurch zum Beispiel eine Schnittstelle in zwei Versionen vorgehalten werden muß.

Aber auch bei Berücksichtigung dieser Punkte werden sich aus folgenden Gründen immer wesentliche Einsparungen bei Verwendung einer fertigen Anwendung ergeben:

- Das fertige System stellt für die Projektentwicklung einen Leitfaden dar, an dem sich die Mitarbeiter orientieren können.

- Für die wesentlichen Funktionen werden keine neuen Lösungen erarbeitet, sondern nur Anpassungen vorgenommen.

- Der Testaufwand wird durch Verwendung ausgetesteter Funktionsteile reduziert.

Fazit: Bei richtiger Auswahl des Paketes, entsprechender Hilfe bei der Umsetzung des Projekts und umfassender Motivation der Mitarbeiter sind erhebliche Kosten- und Zeiteinsparungen durch den Einsatz einer fertigen Anwendung möglich.