Die Entwicklung von Branchensoftware ist auch im Bereich der Small-Business-Systeme nicht stehengeblieben. Versuchten die Programmierschmieden noch vor einigen Jahren. Standardsoftware auf der Basis bestehender Betriebsorganisationen zu entwickeln, haben die hohen Anpassungskosten an spezielle Anwenderbelange zu neuen Ansätzen in den Programmstrukturen geführt. Der Notwendigkeit, mit ein und derselben Lösung unterschiedliche Organisationsabläufe abzubilden, werden sich auch Verfechter der alten Konzepte nicht länger verschließen können.
Die üblichen Standardprogramme für administrative und kommerzielle Bereiche - in Cobol oder RGP "straight forward" realisiert - erfordern bei Anpassungen an individuelle Anwenderwünsche stets mehr oder weniger radikale und kostenintensive Eingriffe in die Software. Unterschiedliche Programmstände pro Installation machen zudem für die Hersteller eine zentrale Maintenance unmöglich.
Nahm auch ein Großteil der MDT-Benutzer, vor allem DV-Einsteiger, diese Mißstände aus Unwissenheit oder "Respekt" vor der Datenverarbeitung einfach als gegeben hin, machten sich schon vor Jahren einige Anbieter zu dieser Problematik ihre Gedanken: "Wir mußten einen Weg finden, der weg von einer herkömmlichen Programmiersprache und hin zu einer Organisationssprache führt, mit welcher der Anwender seine Belange in einem Frage-Antwort-Dialog abbilden kann", meint dazu Klaus Focke, Leiter der Berliner Softwareproduktion von Nixdorf.
Einsteigen über Bausteine
Das Programm müsse sich an den Benutzer anpassen, zentral wartbar und zudem international einsetzbar sein. Zum Beispiel sei ein Fibu-Paket so aufzubauen, daß die weltweit unterschiedlichen Belange, die per Gesetzgeber vorgeschrieben sind, mit einer Lösung abgedeckt werden können.
Mit dem modularen Programmkomplex "Comet" für die 8870 haben die Paderborner versucht, dieses Familienkonzept zu realisieren: Der Anwender kann über einzelne Bausteine wie etwa Lohn und Gehalt, Lagerwirtschaft oder Bestellwesen einsteigen und seine Applikationen bei Bedarf mit den anderen Komponenten schrittweise erweitern.
Das Implementationswerkzeug "Chico" sorgt als Anpassungssoftware dafür, daß die individuelle Organisationsform des Unternehmens über Dimensions-, Ablauf- und Aufbereitungsparameter in das Programm einfließt.
So können beispielsweise die Feldlängen oder der Aufbau von Listen und Formularen ebenso vom Benutzer festgelegt werden wie Angaben über die Verfügbarkeitskontrolle seiner Lagerwirtschaft. Denn diese erfolgt bei dem einen Anwender eventuell nach dem Mindestbestand, bei dem anderen nach einer Eindeckungszeitrechnung.
Auch IBM versuchte schon vor Jahren, diesen verschiedenen Anforderungen gerecht zu werden. Mit dem "Modularen Anwendungs-System" (MAS) entwickelte der Marktführer seinerzeit für die /32 ein ähnliches Paket. Jedoch wurden hier noch die Benutzerfragebogen zur Organisation auf IBM-Großrechnern gespeichert, alle Feldlängen, Satzaufbauten und Listen angepaßt, und so ein individuelles System für den Kunden zurecht geschneidert.
Für den Einsatz auf der /34 wurde das Verfahren verfeinert. Mit MAS II wird in der Installationsphase vor Ort und bereits im Objektcode ein kundenspezifisches Mengengerüst aufgebaut. Während der Ausführung kann der Benutzer beliebig Funktionen vom Menü an- oder abwählen.
Besondere Rücksicht auf den Speicherplatz wurde indes nicht mehr genommen. Die Feldlängen sind "fix", entsprechende Satzlängen die Folge. Heinz-Gerhard Reibe, zuständig für Marketing und Entwicklung MAS II im IBM-Branchenzentrum, München, begründet diese Maßnahme:" Es zeigt sich - da die Systeme größer, der Hauptspeicher mehr und die Platten billiger werden -, daß möglichst kleine Sätze mit nur auf einen Kunden abgestimmten Funktionen nicht mehr notwendig sind. Ausschlaggebend sei bei dieser Art von Software die weitgehend eigenständige Personalisierung durch den Benutzer.
Die Simas-Pleite
Daß die Entwicklung solcher Softwareprojekte nicht immer problemlos durchzuführen ist, bewies die Siemens AG Anfang 1981 mit ihrer "Simas" -Pleite (siehe CW Nr. 46/81, Seite 1). Angelehnt an die MAS-Strategie der IBM sollte ein Anwendersoftwarekomplex geschaffen werden, der nahezu alle betriebswirtschaftlichen Belange eines Unternehmens abdecken konnte. Die Programme sollten modular aufgebaut und, bezogen auf die spezifischen Anwendungsfälle, maschinell zusammengefügt werden können.
Jedoch scheiterte das ehrgeizige Projekt nach mehrjähriger Entwicklungszeit am Kompetenz-Hickhack der Siemens-Manager, dem Bürokratismus und dem Konkurrenzgerangel beteiligter Softwarehäuser.
Doch auch bei denen, die es geschafft haben, im Small-Business-Bereich ansprechende Software zu entwickeln, ist noch nicht alles ausgegoren. Zwar versichert Big Blue, das Interesse an MAS II nicht verloren zu haben, jedoch werden spezielle Kundenwünsche, etwa nach dem Einsatz der weitverbreiteten "Chaotischen Lagerverwaltung", an kooperative Unternehmensberatungen delegiert.
Räumt Heinz-Gerhard Reibe sogar ein: "Natürlich kann es uns dadurch passieren, daß wir erst später feststellen, daß es Funktionen gibt, die eigentlich in das Originalpaket reingehört hätten."
Diskrepanz zwischen Miete und Kauf
Für den Kunden kann diese Tatsache ärgerlich werden, ist er doch gezwungen, sich das Originalpaket je nach Anwendung zwischen 180 und 300 Mark monatlich vom Marktführer zu mieten, die Zusatzfunktionen jedoch von den Unternehmensberatern zum Einmalpreis zu kaufen.
Bei Nixdorf sollen 1984 Erweiterungen speziell in den Bereichen Fertigungsautomation, Kapazitätsplanung und Kostenrechnung als "Comet-Top" auf dem Markt erscheinen.
Sonderfunktionen werden bisher durch die Nixdorf-Crew realisiert. Jedoch, so klingt es aus Anwenderkreisen, gehe die Anpassungsfreudigkeit teilweise so weit, daß erstmal gar nichts mehr gehe.
Sicher haben modulare Anwendungssysteme, insbesondere bei internationaler Einsatzfähigkeit, gute Zukunftsaussichten. Vor allem multinationalen Konzernen bietet sich durch diese Konzepte die Möglichkeit, identische Lösungen einzusetzen und damit den Engpaß zu umgehen, verschiedene Pakete stabil halten zu müssen.
Normale "Butter und Brot" -Anwendungen wie etwa die Lagerbuchhaltung sind heute kein Problem mehr, mit dem man sich softwaremäßig auseinandersetzen müßte. Wichtiger erscheint es, die Implementation, die Schulung und die Unterstützung beim Anlaufen solcher Systeme stärker zu automatisieren.