Spaetestens dann, wenn sich Unternehmen an ihre Standardsoftware fuer Betriebswirtschaft und Logistik nicht mehr herantrauen, weil das System unueberschaubar geworden ist, beginnen die Probleme. Karl Schmitz* unternimmt in seinem Beitrag den schwierigen Versuch, die Kriterien fuer brauchbare Standardsoftware genauer zu beschreiben. Um es nicht bei der Theorie zu belassen, wird der Autor zum September dieses Jahres in loser Folge einige Produkte fuer die CW besprechen.

Rund 85 Prozent der deutschen Grossfirmen sind SAP-Anwender. In der Tat, SAP hat Massstaebe gesetzt. Die Standardisierung der Software- Unterstuetzung fuer wiederkehrende betriebliche Ablaeufe, das Ende der Daten-Schnittstellen-Wirtschaft, die konsequente Durchgaengigkeit, aufgrund derer von (fast) jeder aggregierten Zahl auf die Urbelege oder Elementarereignisse zurueckgegriffen werden kann, das sind historische Errungenschaften. Dass sie heute State of the art sind, ist zweifelsohne ein Verdienst des Walldorfer Software-Unternehmens.

Der amerikanische Designspezialist Don Norman bezeichnet die grosse Versuchung, ein Programm mit immer mehr Funktionen anzureichern und moeglichst jedem Kundenwunsch nach noch einem Extrastueck von Funktionalitaet zu entsprechen, als "schleichende Seuche der Leistungsmerkmale". An dieser Stelle liegt das Problem von SAP, und hier ist Umkehr geboten, denn die Programmsysteme drohen an ihrer wachsenden Komplexitaet foermlich zu ersticken. Bereits Umstellungen von einem Software-Release zum naechsten nehmen Groessenordnungen von nur noch schwer zu managenden Projekten an.

Kaum jemand wagt es danach noch, das einmal muehsam eingerichtete System veraendern zu wollen, denn zu abschreckend ist der drohende Aufwand. Und nach der Einfuehrung verabschiedet sich mit den Consultants oft auch ein Grossteil des Wissens um die Einrichtung des Systems.

Absage an alle proprietaeren Tendenzen

Eine heute zu verwendende Standardsoftware sollte fuer ihr Einsatzgebiet eine kompakte Grundfunktionalitaet aufweisen, erweiterbar und anpassbar sein und eine hohe Durchlaessigkeit zwischen den Teilfunktionen bieten. Selbstverstaendlich sollte sie vermeiden, den Kunden vom Hersteller abhaengig zu machen. Mit anderen Worten: Sie hat allen proprietaeren Tendenzen eine Absage zu erteilen und sich durch eine offene Architektur auszuzeichnen, die es auch erlaubt, Produkte anderer Hersteller zu integrieren.

Die Software muss verteilbar sein - beispielsweise auf verschiedene Organisationseinheiten - und dabei ebenfalls ein organisationsuebergreifendes Arbeiten ermoeglichen. Unter dem Gesichtspunkt der Benutzerfreundlichkeit ist zu fordern, dass sie dem Benutzer gewissermassen als roten Faden eine Art "innere Dramaturgie" bietet, die mit hohem Selbsterklaerungsgrad deutlich macht, wie die Programmfunktionen zu handhaben sind. Schliesslich sind auch die Kosten des Softwaresystems zu beachten, nicht nur fuer die Implementierung, sondern auch fuer den laufenden Betrieb. Im folgenden sollen diese Anforderungen ausfuehrlicher erlaeutert werden.

Der Leistungsumfang einer Standardsoftware muss die im jeweiligen Anwendungsgebiet gefragten Grundfunktionen unterstuetzen. Es soll sich um ein ueberschaubar bleibendes Softwaresystem handeln, das nicht alle denkbaren Varianten, Spezialisierungen und Ergaenzungen bereits vorhaelt, sondern es ueber Erweiterbarkeit und Anpassbarkeit erlaubt, die Geschaeftsprozesse zutreffend abzubilden und zu unterstuetzen. Was dabei unter der Grundfunktionalitaet zu verstehen ist, richtet sich nach dem jeweiligen Anwendungsgebiet.

Das Gebot der Sparsamkeit bei der Funktionalitaet hat einen sehr praktischen Grund: Funktionen aendern sich in einem Betrieb bekanntlich wesentlich schneller als die Daten oder Objekte, mit denen sie zu tun haben. Ein uebermaechtiges funktionales Softwaresystem wird daher in das Problem hineingeraten, staendig an veraenderte Markt- oder Benutzeranforderungen angepasst und ergaenzt werden zu muessen. Ueber kurz oder lang ist dann das aufwendige Redesign des gesamten Systems faellig. Eine knappe, aber fuer das Kerngeschaeft ausreichende Funktionalitaet ist also gefragt.

Wie bereits dargestellt, ist die Einfuehrung sehr komplexer Software oft ein Unterfangen, das an die Grenzen dessen stoesst, was ein Unternehmen managen kann. Wichtig ist deshalb, dass sich Standardsoftware moeglichst schnell produktiv nutzen laesst. Die Software sollte modulweise und innerhalb der einzelnen Module schrittweise einfuehrbar sein.

Die Einfuehrung wird extrem erschwert, wenn die ganze Firma schon bis ins letzte Detail vorgedacht sein muss, ehe die Arbeit mit Unterstuetzung der neuen Software beginnen kann. Dadurch wird der Einfuehrungsprozess in die Laenge gezogen. Viel Zeit vergeht mit Abwarten, ob die Herstellerfirma bereit und in der Lage ist, auf die geaeusserten Anwenderwuensche einzugehen. Immerhin erhoehen diese Wuensche als erweiterte Funktionen des Gesamtsystems dessen Komplexitaet. Vorzuziehen waere eine Software, die einen schnellen produktiven Start erlaubt und Verfeinerungen sowie Differenzierungen waehrend des spaeteren Betriebs ermoeglicht.

Das Softwaresystem muss flexibel, erweiterbar und anpassbar sein. Diese Flexibilitaet bezieht sich sowohl auf die Funktionalitaet als auch auf den Workflow und die individuelle Auslegung. Anwender muessen den Grundfunktionen ihres Systems entsprechend ihren individuellen Anforderungen neue Funktionen hinzufuegen koennen - und zwar moeglichst, ohne dass in den Code der Anwendung eingegriffen werden muss.

Mit solchen Ergaenzungen hat die Anwendung immer noch die Anforderungen einer "Mission-critical Application" zu erfuellen, so dass aus Standardsoftware in partiellen Anwendungsgebieten eine unternehmensspezifische Loesung wird. Die dazu benoetigte Entwicklungsarbeit muss sich in Grenzen halten.

Damit das gesamte Softwaresystem schnell anpassbar ist, gilt es folgende Voraussetzungen zu erfuellen:

1. Die Datenbasis des Grundsystems hat zugaenglich und offen zu sein. Darueber hinaus sollte sie eine fuer Benutzer ohne Programmierausbildung verstaendliche Navigation erlauben.

2. Die Module des Standardsystems muessen Interfaces bieten, die sich an standardisierten Normen orientieren. So koennen andere Softwareprodukte mit dem System problemlos kommunizieren.

3. Das Unternehmen muss, solange noch keine echten Software-Objekte des Geschaeftslebens als modellierbare Halbfertigprodukte verfuegbar sind, ueber eine leistungsfaehige Entwicklungsumgebung verfuegen. Ueber geeignete Prototyping-Methoden sind die Benutzer von Beginn des Entwicklungsprozesses an einzubeziehen.

Der komplette Workflow im durch die Software unterstuetzten Arbeitssystem sollte differenzieren zwischen einem die harten Geschaeftsregeln repraesentierenden Teil und einem Teil, der frei definierbar ist und zur Laufzeit des Systems veraendert werden kann. Dies leisten am besten Softwaresysteme, die in Objekttechnik realisiert sind und den Benutzern hauptsaechlich die Objekte ihrer taeglichen Arbeit sowie die Botschaften und Methoden, auf die diese Objekte reagieren koennen, zur Verfuegung stellen. Diese Systeme bieten die Festlegung der Funktionalitaet nicht in Form eines "verdrahteten" Programmcodes, sondern ueberlassen die Ablaeufe den Benutzern. Man sollte insbesondere darauf achten, dass eingerichtete Arbeitsfolgen auch wieder aufgeloest werden koennen. Dies alles wiederum muss ohne die Zuhilfenahme von Consultants und Programmierern moeglich sein.

Ein individuelles Customizing schliesslich soll den Endbenutzern die Anpassung an ihren persoenlichen Arbeitsstil ermoeglichen und dabei so viele Freiheitsgrade zulassen, wie es unter Beachtung der Geschaeftsregeln des Unternehmens und der Human-Interface- Richtlinien fuer das Softwaresystem praktikabel ist.

Integration und Durchgaengigkeit

Die Integration von Software meint die horizontale Verbindung von Programmen unterschiedlicher Anwendungsbereiche untereinander, ohne Medienbrueche und sogenannte Daten-Schnittstellen zwischen den Systemteilen. Durchgaengigkeit dagegen bezeichnet vertikal die Moeglichkeit, von jeder zusammengefassten Information aus auf die Ebene der Urereignisse, Vorgaenge oder Belege herunterzukommen, aus denen sich die urspruenglich vorgefundene Information zusammensetzt.

Die Schreckensvision schlecht oder gar nicht integrierter Software ist noch allzu praesent. Eine Vielzahl von Daten-Schnittstellen verursacht Probleme, mit deren Loesung sich Heerscharen von Personen beschaeftigen. Dies zu vermeiden ist ein wichtiges Anliegen. Integration kann man sehr einfach realisieren - indem man naemlich in allen Anwendungsbereichen mit der Software nur eines Herstellers arbeitet. Allerdings bezahlt man dies mit einer hohen Abhaengigkeit von ebendiesem einen Hersteller sowie mit dem Verzicht auf die bereichsbezogen jeweils beste Loesung.

Mindestanforderung ist die offene Datenstruktur

Man wird nicht erwarten koennen, dass die Software eines Herstellers in allen Anwendungsbereichen top ist. Das Offenhalten der Option auf die jeweils beste bereichsbezogene Loesung bleibt wichtig. Die "integrierte", von einem Hersteller angebotene Anwendungssoftware hat also auch die Nagelprobe zu bestehen, dass sie Softwarepakete anderer Hersteller "integrieren" kann.

Als Mindestanforderung an die eingesetzte Standardsoftware muessen offengelegte Datenstrukturen betrachtet werden. Wenn alle Anwendungsprogramme ihre Daten zum Beispiel in einem einheitlich organisierten Datenbanksystem ablegen, dann ist die horizontale Integration der Anwendungen bereits ein gutes Stueck vorangekommen.

In dem Masse, in dem sich die Objektorientierung durchsetzen wird - und daran besteht kein Zweifel, gestritten wird nur ueber das Tempo dieser Entwicklung -, in dem Masse wird auch die bessere Verbindbarkeit von Anwendungssoftware vorangetrieben. Dann werden die heute noch gegebenen Vorzuege herstellerspezifischer Integration schnell verblassen. Mit anderen Worten: Der "Alles- aus-einer-Hand"-Vorteil schmilzt dahin.

Die datenbankorientierte Integration von Anwendersoftware bietet ebenfalls eine gute Voraussetzung fuer die zweite Forderung: die nach Durchgaengigkeit der Software. Es ist leichter, beispielsweise den auf einem Kostenstellenkonto angefallenen Betraegen bis in die Details nachzugehen, wenn die Informationen sozusagen unter einem Dach organisiert sind.

Damit soll keineswegs einem neuen Zentralismus das Wort geredet werden. Gefordert wird vielmehr die logisch einheitliche Struktur der Information, deren physikalische Speicherung nach voellig anderen Kriterien organisiert werden kann - getreu dem Motto: Daten sollten dort gespeichert werden, wo sie am meisten gebraucht werden. Die vorhandene Informationsbasis muss dabei allen im System realisierten Funktionen zur Verfuegung stehen. Auf die in der Datenbasis abgebildeten Grundereignisse beziehungsweise Basisvorgaenge soll von jeder Stelle des Systems aus zurueckgegriffen werden koennen.

Die Zeit der proprietaeren, den Anwender in der Abhaengigkeit des Systemanbieters haltenden Systeme geht ihrem Ende entgegen. Deshalb hat das Softwaresystem Hardware-unabhaengig zu sein. Es muss auf einer genuegend breiten Systemplattform lauffaehig und nicht an proprietaere Betriebssysteme gebunden sein. Es sollte auch keine eigenen oder von existierenden Standards abweichenden Programmiersprachen, Dienstprogramme und Tools verwenden.

Nicht anwendungsspezifische Standardfunktionen (beispielsweise Texterfassung) sollten mittels beliebiger, sich an Interoperabilitaetsstandards haltender Software realisierbar sein - zum Beispiel durch jedes verbreitete Textverarbeitungssystem. Offenheit ist eine wesentliche Voraussetzung fuer die Erweiterbarkeit. Es muss moeglich sein, Teile der Anwendung aus dem Standardsystem auszulagern, mittels Tabellenkalkulation oder Spezialprogrammen zu bearbeiten und die Ergebnisse dieses Prozesses wieder in das Standardsystem zurueckzubefoerdern. Selbstverstaendlich duerfen dabei nicht die leidigen Schnittstellen- Probleme vergangener Zeiten auftreten.

Ein wichtiges Motiv fuer die Wahl offener Systeme ist die Vermeidung von Abhaengigkeiten. Bereits Ende der 80er Jahre wollten Firmen die Einheitlichkeit ihrer Hardware- und Systemsoftware- Plattform durch Einkaeufe bei nur einem Hersteller - vorzugsweise dem Marktfuehrer - erreichen. Der Preis fuer diese Politik war ausserordentlich hoch: Bezahlt wurde mit der nahezu vollstaendigen Abhaengigkeit vom Hersteller.

Letztlich haben sich jedoch die Anwender erfolgreich zur Wehr gesetzt. So hat die Unix-Welle den proprietaeren Mainframe- Betriebssystemen die Grenzen des Erfolgs aufgezeigt. Bedauerlicherweise sind die Bemuehungen um die Normierungen der Schnittstellen von Anwendungssoftware - zu nennen ist hier in erster Linie die Open Applications Group (OAG) - noch nicht von vergleichbarem Erfolg gekroent. Doch ist im Bereich Standardsoftware eine aehnliche Entwicklung zu erwarten wie bei den Betriebssystemen. Herstellerunabhaengigkeit ist aber nur dann zu erreichen, wenn das anwendende Unternehmen in der Lage ist, fuer jeden Anwendungsbereich die jeweils beste Loesung einzukaufen.

K.-o.-Kriterium Verteilbarkeit

Diese Produkte muessen sich gemaess den individuellen Wuenschen erweitern oder anpassen lassen und sollten wie Bausteine zu einem integrierten Softwaresystems zusammengesetzt werden koennen. Diesem mit Durchsetzung der Objekttechnik selbstverstaendlich werdenden Weg gilt es heute so nahe wie moeglich zu kommen.

Traditionelle Systeme speichern die gesamte Anwendungsdatenbasis in einem einzigen Server, der dann schnell zum Engpass des Gesamtsystems wird (hohe Ressourcen, lange Wartezeiten, Ausfallrisiko). Daher ist die Verteilbarkeit der Software zu fordern. Dies ist um so wichtiger, je mehr sich Unternehmen von alten, eher zentralistischen Organisationsformen loesen und diese durch miteinander agierende kleinere Einheiten ersetzen. Ausserdem bietet die Verteilung den Vorteil, dass die Anwendungsbereiche ueberschaubarer und leichter steuerbar bleiben.

Hinter dem Wunsch nach Verteilbarkeit verbirgt sich nicht nur der nach einem verteilten Zugriff; es geht um echtes verteiltes Daten- Management, wobei das Basissystem Transaktionen abwickeln koennen muss, die Veraenderungen der Daten an verschiedenen Speicherorten betreffen koennen (vgl. Abbildung 1). Dadurch laesst sich die Gesamtmenge der Betriebsdaten so verteilen, dass die Daten dort physikalisch gespeichert sind, wo sie am meisten gebraucht werden, und dennoch ein einheitliches logisches System darstellen. Auf uebergeordneten organisatorischen Ebenen stehen dabei Informationen als konsolidierte Ergebnisse zur Verfuegung (vgl. Abbildung 2).

Umfangreiche freie Abfragen der Benutzer koennen ein Datenbanksystem stark belasten. Daher sollte das System in Verbindung mit der Datenverteilung Techniken der Replikation (aktualisierte Parallelhaltung von Teilbestaenden der Daten auf verschiedenen Rechnern) unterstuetzen. Rechnerintensive Auswertungen wuerden dabei das Dialogverhalten des Systems bei der Abwicklung des normalen Tagesgeschaefts (Transaktionen) nicht stoeren.

Kommen wir zur Benutzerfreundlichkeit. Die meisten der beispielsweise aus der Macintosh-Welt bekannten Kriterien wie intuitive Bedienbarkeit, hoher Selbsterklaerungsgrad der Software, einheitliche Befehlsstruktur, direkte Steuerbarkeit und unmittelbare Rueckkopplung an den Benutzer hinsichtlich der Wirkung seiner Aktionen sind seit dem Durchbruch von Windows mehr oder weniger zum Standard geworden.

Von einem benutzerfreundlichen Softwaresystem sollte man darueber hinaus verlangen, dass es eine "innere Dramaturgie" bietet - eine Orientierungshilfe fuer den Anwender. Das ist etwa bei Computerspielen der Fall, deren Bedienung auf Anhieb verstanden wird, ohne dass ein Handbuch studiert werden muss. Die auf die Loesung der jeweiligen Aufgaben bezogene Fachkenntnis des Benutzers sollte ausreichen, um das Programm handhaben zu koennen.

Dies setzt eine zutreffende, fuer den Benutzer sofort erkennbare Modellierung der Arbeitssituation beziehungsweise des Arbeitssystems voraus. Hierfuer ist die Grafikfaehigkeit des Benutzer-Interface von grosser Bedeutung. Von ihr muss jedoch auch tatsaechlich Gebrauch gemacht werden - etwa durch eine intuitiv verstaendliche Visualisierung der jeweils zu bearbeitenden Objekte und Ablaeufe. Bunte Fensterrahmen, Pulldown-Menues oder anklickbare Schaltflaechen allein stellen noch kein grafisches Benutzer- Interface dar.

Eine weitere Forderung betrifft die leichte und durchgaengige Navigierbarkeit durch das System. Gemeint ist, dass der Benutzer - moeglichst ohne auf die selbstverstaendlich kontextsensitive Hilfefunktion angewiesen zu sein - jede gesuchte Information auffinden und von jedem beliebigen Aggregierungsniveau dargestellter Informationen aus auch per Drill-down hinunterkommen kann auf die Elementarebene der im System dargestellten Ereignisse oder Vorgaenge.

Die Kosten der Implementierung einer Software sind neben den Aufwendungen fuer Hardware und Softwarelizenzen im wesentlichen durch die Dauer und Problematik des Einfuehrungsprozesses bestimmt. Ferner spielt eine Rolle, ob und in welchem Ausmass das einfuehrende Unternehmen die Hilfe Dritter, insbesondere von Consultants, in Anspruch nehmen muss.

Betriebskosten nicht vergessen

Die entscheidenden Fragen lauten also: Wie lange dauert der Einfuehrungsprozess? In welchem Ausmass muss externe Hilfe in Anspruch genommen werden? Ist gewaehrleistet, dass das Wissen der Consultants in der Firma bleibt, so dass die Softwarelandschaft permanent an die sich schnell aendernden externen wie internen Anforderungen angepasst werden kann? Wie hoch ist der entsprechende Qualifizierungsaufwand? Neben diesen Einfuehrungskosten sind die des taeglichen Betriebs zu betrachten. Sie haengen ab von der Komplexitaet des Softwaresystems sowie dem laufenden Aenderungs- und Anpassungsaufwand.

Letztendlich spielt auch die Position der Softwarefirma auf dem (Welt-)Markt eine wichtige Rolle - zumindest solange, wie die Austauschbarkeit von Anwendungsmodulen noch durch mangelhafte Standardisierung der Schnittstellen erschwert ist. Keine Firma moechte Investitionen in betraechtlicher Hoehe taetigen und dann erleben, dass wenige Jahre spaeter die Herstellerfirma vom Markt verschwunden ist. In diesem Zusammenhang ist auch wichtig, was die Herstellerfirmen fuer das Modernhalten der Software tun, ob also genuegend Aufwand fuer Forschung und Entwicklung betrieben wird.

* Karl Schmitz ist Gesellschafter der tse Gesellschaft fuer Technologieberatung und Systementwicklung mbH in Hamburg