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.


09.12.1983

Branchensoftware: Durch gemeinsames Engagement Kosten senken

Immer noch nutzen relativ wenige User die Möglichkeit, Software gemeinsam zu erstellen um somit die Entwicklungskosten niedrig zu halten. Daß viele Anwendungen sich nicht für ein breites Einsatzspektrum standardisieren lassen, ist bekannt. Bei Unternehmen innerhalb derselben Branche könnte die Situation jedoch anders aussehen. Müssen hier auch, wie Alfred Richter von der Hamburger Verbraucherbank AG bemerkt, gewisse Vereinheitlichungen hingenommen werden, so läßt sich dieser Nachteil durch individuelle Anpassungen doch in den meisten Fällen mildern. Dabei spielen allerdings Größe des Unternehmens und Art der Anwendung eine nicht zu unterschätzende Rolle: Je kleiner und überschaubarer die einzelnen Betriebe, desto eher ist ein gemeinsames Software-Engagement möglich. Je komplexer und größer die Aufgaben, desto problematischer wird die Sache. kul

Ernst-Günter Knüppel,

Leiter kommerzielle Anwendungsentwicklungen,

Audi NSU Auto Union, Ingolstadt

Zunächst sei festgestellt, daß zwischen Branchensoftware und Standardsoftware kein besonderer Unterschied besteht. Es geht hier um fremd erstellte Software, die generell anwendbar, leicht übertragbar sei und klare Schnittstellen zur besseren Anpassung haben sollte. Bei der Branchensoftware geht es lediglich um begrenztere Marktsegmente beziehungsweise Anwendungsgebiete.

Aus betrieblicher Sicht ist die Erwartungshaltung außerdem mit höherer Wirtschaftlichkeit verbunden, da solche Software wegen der Mehrfachverwendbarkeit meistens billiger als eigenerstellte und schneller verfügbar ist.

Daß dieser Markt zukunftsorientiert ist, unterstreicht auch das ständig steigende Angebot, wenngleich nicht übersehen werden darf, daß ein großer Teil der angebotenen Lösungen nur sehr geringe Installationszahlen aufweist (siehe ISIS-Katalog).

Die Gründe hierfür sind mannigfaltig. Da Standardsoftware nicht kundenspezifisch ausgelegt ist, gilt hier nach wie vor der Kernsatz, daß sich die betriebliche Organisation dem Softwarepaket anpassen muß und nicht umgekehrt. Sollte der zweite Fall stark ausgeprägt sein, steigt der Zusatz- und Implementierungsaufwand enorm und die Einsatzgeschwindigkeit sinkt, obwohl eine individuellere Lösung gleichzeitig größere Akzeptanz beim Nutzer hätte.

Der Einsatz von Standardsoftware dürfte auch um so schwieriger sein, je größer ein Unternehmen und damit die gewachsene Organisation und die zwangsläufig vorhandene EDV ist. Dies gilt natürlich nicht für systemnahe Software oder Tools wie Sortier-, Tabellen-, Grafikprogramme und dergleichen.

Nicht vergessen werden dürfen später zu bewältigende Wartungsprobleme, die um so größer sind, je mehr Faktoren wie Strukturierung und Dokumentation Wünsche oder Standards offen lassen. Sie können zwar durch Wartungsverträge sachlich, aber nicht in den Kosten gemildert werden.

Einige dieser Problemkreise dürften entschärft werden beim Einsatz von Branchensoftware, die stärker benutzerorientiert ist. Durch die laufenden Erweiterungen auf dem Hardwaresektor und das ständig verbesserte Preis-/Leistungsverhältnis werden solche Lösungen heute oft als schlüsselfertige Systeme angeboten und sind deshalb auch besonders für kleinere Betriebe interessant geworden. Für Großbetriebe sind sie trotzdem gut einsetzbar, sie lösen hier meist nur einen Dezentralisierungsvorgang aus.

Eine weitere Möglichkeit zur stärkeren Anwenderorientierung und damit verbesserten Akzeptanz sowie Konzentration der Mittel und damit zu größerer Wirtschaftlichkeit liegt in gemeinsamer Entwicklung und Nutzung von Standard-/Branchensoftware. Die Frage ist, wer stellt Grundsatzüberlegungen an oder gibt die Initialzündung - ein Unternehmen, ein Verband oder eine Behörde? Ist ein solches Vorgehen ohne entsprechende Normierung sinnvoll und möglich? Wie weit sind Firmen gewillt, durch Uniformierung der Abläufe beziehungsweise durch Mitwirkung von "Konkurrenz" möglicherweise vorhandene Wettbewerbsvorteile aufzugeben? Wo liegt die optimale Zahl der Beteiligten, um einerseits dem Anspruch von Standardsoftware zu genügen und andererseits nicht in Meinungen, Forderungen und Koordinationsproblemen zu ersticken?

Doch egal wie lang die Kette solcher Fragen sein mag, eine gemeinsame Entwicklung sollte nur unter klar geregelten Bedingungen erfolgen:

- Prüfung der Wirtschaftlichkeit,

- sorgfältige Analyse und phasenweises Vorgehen,

- straffes Projektmanagement und klare Abgrenzung,

- genügend Kapazität bereitstellen, um vertretbare Projektlaufzeiten zu erreichen.

Gerd Uertz,

Org./DV-Leiter, Deutsche Bausparkasse AG, Darmstadt.

Das Angebot an Branchensoftware ist auch heute noch mehr als dürftig. Sieht man sich auf dem Markt nach einem Softwarepaket um und hat ein passendes gefunden, so scheitert in der Regel die Übernahme und die Installation dieses Paketes an den hausspezifischen Hard- und Softwarebedingungen.

Das nächste Problem liegt in der Anpassung an die organisatorische Umwelt des eigenen Hauses. Ein solches Anwendungspaket wird in der Regel von einem Anwender für seine Bedürfnisse unter Berücksichtigung seiner Soft- und Hardware-Komponenten und seiner organisatorischen Umwelt en wickelt. Aber welcher Anwender ist schon bereit, seine Organisation drastisch zu ändern, nur um ein Softwarepaket im eigenen Haus nutzen zu können. Die Kosten, die der einzelne User bei der Entwicklung einsparen kann verliert er auf der anderen Seite für die Anpassung.

Trotzdem bin ich der Meinung, daß man in Richtung gemeinsamer Branchensoftware hinarbeiten muß, denn gerade bei kleineren und mittleren Unternehmen werden die Entwicklungskosten einer gemeinsamen Anwendungssoftware von vielen getragen und der Kostenanteil pro Haus ist in jedem Fall niedriger als bei einer eigenen Entwicklung.

Die Voraussetzung für eine gemeinsame Branchensoftware muß jedoch so sein, daß in fachlicher Hinsicht ein gemeinsamer Nenner gefunden wird, damit die fachlichen Anforderungen voll abgedeckt sind. Der Prozeß der fachlichen Abstimmung bringt mit Sicherheit die meisten Probleme, da sich, ein gemeinsamer Nenner nur dann finden läßt, wenn jedes beteiligte Unternehmen zu Kompromissen bereit ist. In dieser Phase einer gemeinsamen Entwicklung muß mit einem erheblichen Reibungsverlust gerechnet werden.

Um eine Branchensoftware transparent zu entwickeln und die spätere Anpassung und Installation "problemloser" zu ermöglichen, sind bei einer gemeinsamen Entwicklung Schnittstellen zu allen eingesetzten Subsystemen unumgänglich.

Da die meisten Anwender DB- und DC-Systeme, sowie Textverarbeitung im Haus installiert haben, ist eine Anpassung einer solchen Software nur dann möglich, wenn die DB-DC-Schnittstellen genauestens spezifiziert und festgelegt sind. Das gleiche gilt für die Textverarbeitung, für das Archiv und sonstige Subsysteme denn gerade diese hausspezifischen Anwendungen müssen einerseits für alle bestehenden Fälle unverändert bleiben, und es ist andererseits undenkbar, daß ein User seine Datenbank nur wegen einer Anpassung an ein Software-Paket umstrukturiert oder gar einen neuen TP-Monitor einsetzen muß. Das Problem der Akzeptanz von Dialogsystemen ist jedem Anwender bestens bekannt. Laufende Änderungen des TP-Designs tragen bekanntlich nicht zu einer besseren Akzeptanz bei.

Genauso wichtig wie die Festlegung und Beschreibung der Schnittstellen ist die Dokumentation. Man muß sich bei Beginn einer gemeinsamen Entwicklung für ein einheitliches Dokumentationssystem entscheiden, damit sichergestellt ist, daß die beteiligten Anwender eine gemeinsame Sprache sprechen. Das Produkt muß, durch modularen und strukturierten Aufbau wartungsfreundlich und leicht erweiterbar, durch Anwendung von Tabellensteuerung flexibel in der Handhabung, durch Kommunikation mit DB-, DC-Systemen über spezielle Zugriffsmoduln, portabel auf unterschiedliche Systemumgebungen sein.

Die gemeinsame Entwicklung von Branchensoftware, bei unterschiedlicher Hardware und Software führt dann zu einem befriedigenden Ergebnis, wenn die einzelnen Phasen der Realisierung, vom Grobkonzept über das fachliche Feinsoll bis zum systemneutralen DV-Konzept genau festgelegt werden.

Alfred Richter,

Sprecher des Vorstandes der Verbraucherbank AG, Hamburg

Für die Bankbranche gibt es bereits ein lebendes Beispiel in der Gemeinschaftsentwicklung des Softwarepaketes Kordoba. Aus meiner externen Sicht ist dieser Weg interessant und kostengünstig für alle Institute, die sich aufwendige Eigenentwicklungen nicht leisten wollen.

Es kann aber nicht darüber hinweggesehen werden, daß in der Anwendung dieser Software gewisse Vereinheitlichungen entstehen müssen, die sich selbstverständlich durch individuelle Teilerweiterungen mildern lassen. Nach der Erfahrung und Überzeugung der Verbraucherbank ist eine Banksoftware durch die Anwendungstechnik bestimmt. Daß in ihr das spezifische Unternehmensmerkmal wiederkehren muß, halte ich für unverzichtbar. Dieses Kriterium wird auch künftig im Kreditgewerbe ein signifikantes Unterscheidungsmerkmal für die Kunden bleiben und sich hauptsächlich erst in einer vollen Anwendung durch die Kunden, also in der Kundenselbstbedienung, darstellen. Solange die Computeranwendung zur Unterstützung von Bankmitarbeitern dient, ist die Gefahr bei weitem nicht so groß, durch einheitliche Programme unternehmensspezifische Eigenheiten zu verlieren. Sie wird aber nicht zu übersehen sein, wenn der Kunde durch die Selbstbedienung direkt daraufhin geführt wird. Daher ist es für die Banken vermutlich als weiterer Schritt zur Selbstbedienung in einem qualifizierteren Bereich über Bargeldautomat und Kontoauszugsdrucker hinaus notwendig, Eigenentwicklungen zu betreiben. Allerdings kann es auch hier wiederum nützlich werden, gewisse Standardleistungen durch Gemeinschaftsentwicklungen zu fördern und so auch erschwinglich zu machen.

Friedrich Winkelhage,

Vorstandsmitglied der GMD - Gesellschaft für Mathematik und Datenverarbeitung mbH, St. Augustin

Schon die zweite Hälfte der 70er Jahre war gekennzeichnet durch die schnelle Entwicklung der technischen Grundlagen und Möglichkeiten der Informationsverarbeitung. Ferner spielte der wachsende innerbetriebliche Bedarf an DV-Anwendungen bei gleichzeitigem Mangel an qualifizierter interner Entwicklungskapazität und einem zu geringen Angebot von Standardlösungen am Markt eine Rolle. Dies war Anlaß für verschiedene Bemühungen kleiner und mittlerer Anwenderbetriebe, gemeinsam Standard-Anwendungssoftware ("Branchensoftware") zu entwickeln, die besser war als die seinerzeit auf dem Markt angebotene. In diesen Projekten wurde versucht, den damals wie heute typischen schrittweisen Ausreifungs- und Generalisierungsprozeß auf dem Wege von einer individuellen Softwarelösung zu einem Standardprodukt zu komprimieren und zu parallelisieren. Dabei wurde das "unternehmerische Risiko" der Produktentwicklung in den Abstimmungsprozeß der Entwicklungsgruppe verlagert. Die bisherigen Erfahrungen haben gezeigt, daß diese Aushandlungsprozesse zwischen individuellen Anforderungen und wirtschaftlichen Kompromissen zu kaum beherrschbaren Kostenkonsequenzen bei der Entwicklung führen.

Ich habe bereits vor vier Jahren nicht nur auf diese organisatorischen Schwierigkeiten sondern auch auf das Defizit im Bereich des Instrumentariums für die Softwareproduktion hingewiesen, das zudem in der Mehrzahl der Projekte nicht beherrscht und auch nicht akzeptiert wurde. Verschärft wurde dieses Problem noch durch das Fehlen von geeigneten, standardisierten Schnittstellen nicht nur zur Basissoftware, sondern vor allem für eine Integration zwischen den Anwendungsmodulen und für eine Anpassung an die Benutzer und die betriebliche Organisation.

An Lösungen für die seinerzeit aufgezeigten organisatorischen und technischen Probleme arbeiten wir noch heute. Dennoch hat sich die Situation verändert. Ich will versuchen einige Aspekte dieser Veränderung anhand von Zahlen aus unserer jüngsten Marktstudie zu verdeutlichen.

Betrachtet man die Nutzung eines eigenen Computers in den Betrieben verschiedener Größenklassen, zeigt sich, daß von den etwa 1,7 Millionen Betrieben mit weniger als 10 Beschäftigten erst etwa 3 Prozent ein eigenes DV-System nutzen; bei den rund 130000 Betrieben in der Größe zwischen 10 und 20 Beschäftigten sind es 14 Prozent, und unter den etwa 130000 Betrieben mit mehr als 20 Beschäftigten gibt es rund 55500 Betriebe mit einem eigenen DV-System. Für 1983 und 1984 kann damit gerechnet werden, daß etwa 20000 Betriebe pro Jahr erstmals ein eigenes DV-System installieren werden. Mehr als zwei Drittel dieser Betriebe dürften aus der Größenklasse mit weniger als 10 Beschäftigten kommen. Dieser Zuwachs an neuen Anwendern ist zwar niedriger als nach optimistischen Marktprognosen erwartet, aus diesen Zahlen wird jedoch das Ausmaß der Aufgabe deutlich, die Vielzahl der kleinen Betriebe, die heute noch kein eigenes DV-System nutzen, mit geeigneter Anwendungssoftware zu versorgen. Vor allem, wenn man die erheblichen Beratungs- und Ausbildungsnotwendigkeiten berücksichtigt, wird erkennbar, daß diese Aufgabe wohl kaum auf der Basis von Selbsthilfe einzelner Gruppen von Betrieben gelöst werden kann.

Im Bereich der Betriebe mit 20 und mehr Beschäftigten kann man bei einer "DV-Dichte" von 43 Prozent von einem zunehmend interessanten und funktionierenden Markt für Software sprechen. Eine kompetente Basis für die Entwicklung von Standard-Anwendungssoftware stellen dabei vor allem die etwa 17000 Betriebe mit einem DV-System zwischen 100000 Mark und einer Million Mark Kaufpreis dar, mit denen gerade die kleinen Softwarehäuser und Programmierbüros bevorzugt zusammenarbeiten.

Entsprechend den heute "branchenüblichen" Strategien dürften die Anbieter hier versuchen, in Kooperation mit Anwendern ausreichend breit einsetzbare Softwareprodukte zu entwickeln und anzubieten. Die damit teilweise verbundene Branchenspezialisierung wird das Angebot für Betriebe dieser Größe weiter verbessern.

Dagegen ist der Markt der Betriebe mit weniger als 20 Beschäftigten für die Softwareanbieter nur schwer erreichbar und wenig lukrativ, da die DV-Budgets dieser Betriebe klein sind und vor allem nach der Erstinstallation eines Systems nur geringes Folgegeschäft zu erwarten ist. Die kleinen DV-Budgets dieser Betriebe wirken in zweifacher Hinsicht als Barriere: sie lassen zum einen die herkömmliche Anpassung von Standard-Anwendungssoftware nicht zu und erlauben es auch nicht, daraus wesentlichen Beratungs- und Akquisitionsaufwand "mitzufinanzieren". Da die kleinen Softwareanbieter sich bevorzugt auf Kunden konzentrieren, die dauerhafte Geschäftsbeziehungen erwarten lassen, sind sie bislang an den sehr kleinen Betrieben als potentiellen Nachfragen nicht sehr interessiert. Daher wird sich ein Transfer der im Markt der mittleren Unternehmungen gewachsenen Organisationserfahrungen und der dort entwickelten Anwendungssoftware in diese Bereiche nicht ohne weiteres vollziehen.

Von den Ansätzen zur Überwindung dieses Problems können hier nur zwei angesprochen werden: In Einzelfällen zeichnen sich Wege einer "vertikalen" Versorgung ab, bei denen Verbände oder beispielsweise auch dominierende Lieferanten für die Entwicklung geeigneter Software für eine Branche oder eine Gruppe von kleinen Betrieben sorgen und auch den Vertrieb unterstützen. Wie breitenwirksam dieser Ansatz sein kann muß abgewartet werden. Ein weiterer, innovativer Ansatz zur Überwindung des Acquisitionsproblems könnten Informationstechnik-Zentren sein, in denen kleine Betriebe sich neutral und umfassend über das Informationstechnikangebot informieren und beraten lassen können.