Die Auswahl und Einfuehrung von betriebswirtschaftlicher Standardsoftware bedeutet fuer viele Unternehmen eine Herausforderung, die sie alleine nicht bewaeltigen koennen. Sie wenden sich an Berater, die haeufig auf ein bestimmtes Produkt fixiert sind und es so weit wie moeglich an die Beduerfnisse des Anwenders anpassen. Vielen Unternehmen passt jedoch das Softwarekleid ihres Consultants nicht.

Von Ernst Wilken*

Rauf mit der Effizienz, runter mit den Kosten - das sind die primaeren Ziele, die Standardsoftware erreichen soll. Individuelle Loesungen, die vor Jahren entwickelt wurden, haben sich ueberlebt, Neuentwicklungen erscheinen zu aufwendig.

Die Personalkosten in der DV-Abteilung sind fuer viele Manager nicht mehr akzeptabel, der Mainframe gilt als teuer, und die Chance, durch die Einfuehrung von Standardsoftware die Organisation zu straffen und effizienter zu gestalten, lockt manches Unternehmen. Das Client-Server-Zeitalter unterstuetzt den Reorganisationstrend. Endlich bietet sich die Chance, in der Datenverarbeitung das nachzuholen, was in den Unternehmen auch sonst laengst umgesetzt wird: das Beseitigen von Hierarchien zugunsten eigenverantwortlicher "foederalistischer" Einheiten.

Damit wird die technische Frage relevant, auf welches Betriebssystem zu setzen ist. Auf Unix? Wenn ja, von welchem Hersteller? Auf die AS/400 oder auf PC-Netze? Und was passiert mit dem Mainframe und den Datenbestaenden? Keine leichten Fragen, zumal der immer schnellere technologische Wandel zusaetzlich fuer Verwirrung sorgt. Unter Software-Anbietern scheint die Loesung klar: Unix sagen die einen, AS/400 die anderen - als Front-ends ein paar PCs, und fertig ist die Client-Server-Welt. Auf den ersten Blick eine einfache und klare Strategie, doch wenn man genauer hinschaut, handelt es sich um eine Loesung mit Haken und Oesen, die vor allem das verursachen duerfte, was der Anwender vermeiden will: Kosten.

Tabula rasa ist nur selten sinnvoll

Es ist nicht unbedingt billig, die alte DV-Umgebung komplett abzureissen und neu wiederaufzubauen. Das mag fuer ein Unternehmen sinnvoll erscheinen, das in der Rezession die Mitarbeiterzahl und damit auch die Anforderungen an die Datenverarbeitung drastisch zurueckgefahren hat. Doch selbst fuer solche Firmen lohnen sich tiefergehende Ueberlegungen, wie sie die neuen Moeglichkeiten der Technik nutzen koennen.

Den zentral orientierten Mainframe gegen ein neues, ebenfalls zentralistisches System unter Unix auszutauschen macht wenig Sinn - auch dann nicht, wenn sich dieses System mit einigen PCs "garnieren" laesst. Schliesslich geht die Entwicklung weiter, und in ein paar Jahren kommt dann vielleicht tatsaechlich das Betriebssystem heraus, das Unix endgueltig abloest.

Man sollte sich vielmehr bewusst machen, was Client-Server- Architektur im Ausbauzustand eigentlich heisst: Die freie Verteilbarkeit der Anwendungen und Daten auf verschiedene Systemebenen. Dabei haben die individuellen Beduerfnisse von Unternehmen absoluten Vorrang: Applikationen laufen in den Abteilungen je nach Anforderung auf dem PC, unter Unix, auf einer AS/400 oder einem Mainframe. Dasselbe gilt fuer die Datenhaltung.

Durch diese Brille betrachtet wird schnell deutlich, wie vielfaeltig die Moeglichkeiten sind, eine heterogene DV-Architektur im Unternehmen aufzubauen. Mit welcher Standardsoftware das geschehen kann, ist zunaechst einmal zweitrangig. Bevor man sich diesem Thema intensiv widmet, sollte man an die Bedarfsanalyse gehen.

Spaetestens in dieser Phase greifen viele Unternehmen auf externe Berater zurueck, die die Firma genau unter die Lupe nehmen, Arbeitsablaeufe analysieren und Verbesserungen vorschlagen. Die Ausrichtung auf ein bestimmtes Softwareprodukt wird oft schon jetzt festgelegt. Die meisten Berater kennen das eine oder andere Produkt besonders gut oder binden sich sogar fest an einen Hersteller.

Die Folge: Diese Berater beginnen damit, den Betrieb des Kunden an eine vorgesehene Software anzupassen, statt ein Produkt auszuwaehlen, das sich nach den Unternehmensablaeufen richtet. Sie missachten dabei die Erfahrung und Kreativitaet in den Fachabteilungen und der DV, sie versaeumen es, im Zusammenspiel mit der Unternehmensberatung eine Problemerkennung und -loesung zu erarbeiten.

Solche Berater schieben Firmen den "Standard" quasi wie einen Filter vor. Aus gutem Grund. Oft sind Standardsoftware-Produkte wenig flexibel, wenn es um die Anpassung an unterschiedliche Organisationsformen geht.

Diese Produkte zwingen schliesslich den Anwender, seine Organisation in einem gewissen Mass der Software - und damit zwangslaeufig der Organisation anderer Benutzer, die das gleiche Produkt einsetzen - anzugleichen. Der Anspruch, durch individuelle, problembezogene Loesungen Wettbewerbsvorteile aufzubauen oder zu sichern, geht verloren.

Die Problemanalyse und ein daraus resultierendes Pflichtenheft ist im Vorfeld der Entscheidung fuer ein Softwareprodukt unverzichtbar. Auf keinen Fall sollte man, wie es in der Praxis immer wieder vorkommt, ein fremdes Pflichtenheft einfach uebernehmen.

Sachargumente fallen oft unter den Tisch

Dass der Auswahl von Standardsoftware eine gruendliche Marktanalyse vorangehen muss, ist wohl selbstverstaendlich. Schliesslich geht es in der Regel um sehr viel Geld. Doch in der Praxis werden Entscheidungen zu oft aus dem Bauch getroffen. Sachargumente fallen unter den Tisch. Dabei gibt es durchaus mehr gute Gruende fuer eine genaue Analyse als die Tatsache, dass die Software zum Unternehmen passen sollte.

Ein Argument ist sicher die Portierbarkeit. Selbst wenn ein Anwender zunaechst eine einheitliche Systemumgebung anstrebt, wird er frueher oder spaeter vor der Entscheidung stehen, in andere Umgebungen umzusteigen oder diese zu integrieren. Denn die Zeiten der absolut marktbeherrschenden Technologien sind vorbei. Warum sollte man sich den Weg verbauen, Produkte eines anderen Herstellers einzusetzen, wenn der ein wesentlich besseres Preis- Leistungs-Verhaeltnis bietet?

Auch der technologische Wandel laesst sich mit Anbietern, die ihre Flexibilitaet bewiesen haben, besser bewaeltigen. Schliesslich ist selbst Unix kein Betriebssystem fuer die Ewigkeit.

Ein ebenfalls wichtiges Kriterium bei der Auswahl ist die Flexibilitaet der Software. Nicht das Unternehmen sollte sich der Software, sondern die Software dem Unternehmen anpassen.

Ein einfaches Beispiel macht deutlich, warum das so wichtig ist: Die Rechnungspruefung ist heute Bestandteil vieler Pakete; sie arbeitet in der Regel integriert mit der Finanzbuchhaltung und der Kostenrechnung. Nun waere es wuenschenswert, dass sich die Rechnungen nicht nur in der Beschaffung, sondern auch unabhaengig in der Finanzbuchhaltung oder der Kostenrechnung bearbeiten lassen. Das gilt etwa fuer Dienstleistungs- oder Mietrechnungen, bei denen es keinen Wareneingang gibt und die somit in der Beschaffung nichts zu suchen haben.

In den gaengigen Programmen ist dies in der Regel nicht vorgesehen. So entfaltet sich ein komplizierter Ablauf mit Bestellanforderung, Bestellung, Bestellnummer, Bestellverfolgung etc. - nur weil beispielweise ein Servicemann zum Warten des PCs gerufen wurde. Viel sinnvoller waere es, die Rechnungspruefungsfunktionen zu verteilen und damit einen Papierkrieg, wie er heute immer noch an der Tagesordnung ist, zu verhindern.

Standardsoftware sollte flexibel mit individuellen Anwendungen oder Fremdsoftware zusammenspielen. Schliesslich hat man nur selten das Glueck, dass sich alle Produkte eines Anbieters gleichermassen fuer das eigene Unternehmen eignen oder dass alle noetigen Funktionalitaeten wirklich abgedeckt sind. Daher muss die eingesetzte Standardsoftware ueber eine entsprechende Schnittstellen-Technik verfuegen, ueber die sich andere Programme integrieren lassen. Diese Schnittstellen muessen im Standard enthalten sein - sonst beginnt der Anpassungsaufwand von neuem.

Natuerlich ist es angenehm, wenn man alle Softwareprodukte "aus einer Hand" bezieht. Verfolgt der Hersteller jedoch keine offene Integrationspolitik, ist man schnell wieder dort, wo man eigentlich nie wieder hinwollte: in einem proprietaeren Abhaengigkeitsverhaeltnis.

Deswegen ist es wichtig, bei der Auswahl von Standardsoftware dem Thema "Objektorientiertheit" volle Aufmerksamkeit zu schenken. Die DV-Entwicklung laeuft bekanntlich ganz allgemein in diese Richtung. Objektorientierte Programmierung ist eine Voraussetzung dafuer, dass sich die geschilderten Anforderungen auch erfuellen lassen.

Das zeigen die Beispiele "Rechnungspruefung" und Portierbarkeit: Nehmen wir eine heterogene Architektur, in der die Beschaffung auf einem PC, die Finanzbuchhaltung auf einer RS/6000 und die Kostenrechnung auf einer HP/9000 laeuft. Das Objekt "Rechnungspruefung" wird in allen drei Bereichen benoetigt. Waere es fest "verdrahtet", haette man hier Schwierigkeiten. Als eigenstaendiges Objekt laesst sich die Rechnungspruefung an alle drei Umgebungen anpassen und in die verschiedenen Anwendungen integrieren.

Auch bei den Schnittstellen bringt die objektorientierte Sichtweise erhebliche Erleichterungen. Ist dieser Bereich naemlich von vornherein als eigenstaendiges Objekt unabhaengig von der Anwendung konzipiert, laesst er sich viel leichter in den Standard uebernehmen. Objekte sind schliesslich auch beim Release-Wechsel einfach wiederverwendbar.

Entscheidend fuer die Software-Auswahl ist ausserdem die Migrationsfrage. Vor allem Mainframe-Benutzer, die Client-Server- Architekturen realisieren wollen, bewegt dieses Thema. Obwohl laengst totgesagt, gibt es natuerlich noch immer Grossrechneranwender - und nicht wenige wollen es zunaechst auch bleiben.

Wie schwierig das Migrationsthema ist, zeigt das prominente Beispiel von Mainframe-Benutzern, die zu rund 30 Prozent den Release-Wechsel ihres Standardsoftware-Anbieters aus Kostengruenden nicht mitmachen wollen. Dieser Release-Wechsel ist aber die Voraussetzung fuer die Migration in die Client-Server-Produktwelt desselben Herstellers. Diese Anwender wuerden von den Moeglichkeiten einer schrittweisen Migration profitieren.

Die Lizenzkosten fuer die neue Client-Server-Software bereiten diesen Kunden die geringsten Sorgen. Sie machen in der Regel hoechstens 25 Prozent der gesamten Projektkosten aus, die Hardware noch nicht einmal eingerechnet. Den Rest des Budgets verschlingen Beratung, Einfuehrung und Schulung.

Der Einfuehrungsaufwand von Client-Server-faehiger Anwendungssoftware ist nicht nur abhaengig davon, ob man auf die oft teure Hilfe eines Unternehmensberaters zurueckgreift oder die Probleme selbst beziehungsweise mit Hilfe des Anbieters bewaeltigt. Auch die Software selbst spielt hier eine entscheidende Rolle. Je nach Maechtigkeit des Systems kann sich die Implementierungsdauer erheblich verlaengern. Generell ist festzustellen, dass Systeme, die bereits vielfach installiert wurden, dazu tendieren, immer maechtiger zu werden. Denn in sie sind ueber Jahre hinweg immer wieder Aenderungen eingeflossen, die einzelne Anwender benoetigen und danach zum Standard avancierten, weil man sie fuer generell gut und wichtig befand. Haben solche Systeme zusaetzlich eine "zentralistische" DV-Vergangenheit, geraet die Einfuehrung aufwendig. Einfacher ist dagegen eine konsequent modularisierte Software zu implementieren, bei der sich etwa die Parametereingabe und Berechtigungsvergabe dezentral bewerkstelligen laesst.

Wenn der Standard zur Individual-SW wird . . .

Unterschaetzt wird oft auch der Adaptionsaufwand, der noetig ist, um Standardsoftware an die Unternehmensbeduerfnisse anzupassen. Selbst bei einer Finanzbuchhaltung, einer Anwendung also, die bereits durch die gesetzlichen Vorgaben stark "standardisiert" ist, sind in der Regel zehn Prozent der Applikation anzupassen. In der Fertigung kann es sogar passieren, dass etwa bei der Einfuehrung eines PPS-Systems die Summe der Anpassungen die 50-Prozent-Marke ueberschreitet. Hier ueberwiegt der "Nicht-Standard" gegenueber dem "Standard".

Um diese nicht unerheblichen Investitionen in die Adaption zu sichern, sollte man bei der Auswahl der Software darauf achten, dass die Anpassungen nach einem Release-Wechsel nicht verlorengehen. Diese Anforderung wird auch heute noch nicht von allen Anbietern erfuellt.

Bei der Einfuehrung oder Umstellung von Standardsoftware ist unbedingt zu beruecksichtigen, dass die gewaehlte Loesung offen genug fuer den technologischen Wandel ist und dem Anwender genuegend Entscheidungsspielraum fuer die Gestaltung seiner DV-Architektur laesst.