Wer die "Grenzen der Standardsoftware" aufzeigt, sollte das Thema von mehreren Seiten beleuchten. Grenzen sind immer mit der Raum- und Zeitkomponente in Verbindung zu bringen, um die Dynamik und den eigenen Standpunkt in der mehrdimensionalen Betrachtung herauszufinden.
Die sinkenden Hardwarepreise der letzten Jahre haben zu einer Gewichtsverlagerung in den IT-Budgets geführt. Damit stehen die Software-Entwicklungs- und Wartungskosten noch stärker auf dem Prüfstand. Sobald Unternehmen eine gewisse Breite an betriebswirtschaftlichen Grundfunktionen benötigen, führt sie der Weg zwangsläufig in die integrierte Informationsverarbeitung.
Die erfolgreichsten Hersteller betriebswirtschaftlicher Software mußten diesem Trend folgen, weil der Markt ihnen das abverlangte. Die Standardsoftwarehersteller haben also die Grenzen ihrer Software funktional erweitert. Davor war es für die Fachbereiche eines Unternehmens Usus, sich unabhängig voneinander für eine Software zu entscheiden, die auf ihre Bedürfnisse zugeschnitten war. Solange der Markt nicht mit ausgereifter integrierter Software aufwarten konnte, war dieses Verhalten legitim, heutzutage muß man derartige Entscheidungsprozesse als äußerst bedenklich einstufen. So entstandene Insellösungen sind in Unternehmen mit kritischer betriebswirtschaftlicher Breite über Schnittstellen zusammengewachsen.
Heute bezeichnet man auch Softwarepakete als Tools, die auf ein bestimmtes betriebswirtschaftliches Thema ausgerichtet sind. Selbst wenn die heutigen Werkzeuge Schnittstellen zu anderen Tools haben, wie zum Beispiel Microsoft-Anwendungen, handelt es sich nur um betriebswirtschaft- liche Insellösungen. Bei offenen Schnittstellen ist ferner zu bedenken, daß die Aneinanderreihung von Tools mit Informationsverlusten einhergeht und für die integrierte Geschäftsprozeßverarbeitung denkbar ungeeignet ist.
Hier liegt das Dilemma der Werkzeuge, die in ihrem Anwendungsfokus den direkten Vergleich mit den Konkurrenten der integrierten Standardpakete nicht zu scheuen brauchen. Prozesse benötigen Informationen, um zu sinnvollen Ergebnissen zu kommen. Tools setzen sich ihre eigenen Grenzen durch ihren eingeschränkten Horizont. Erschwerend kommt hinzu, daß Werkzeuge, die auf unterschiedliche Ziele ausgerichtet sind, sich nur schwer synchronisieren lassen. Ein Finanz-Tool, das Kapitalbindung reduzieren soll, kann sich kaum mit einem Vertriebs-Tool verständigen, das die Kundenorientierung in den Vordergrund stellt. Wirft man beispielsweise nur einen Blick auf das Rechnungswesen, wird schnell deutlich, welche Verzahnung der betriebswirtschaftlichen Grundfunktionen notwendig ist.
Bei eigenentwickelter Software oder bei einem Software-Tool, das auf ein spezielles Kundensegment zugeschnitten ist, kann man im allgemeinen von einer schlanken Architektur ausgehen. Die Standardsoftwarehersteller haben den Anspruch, möglichst alle Kundentypen abzudecken, also den Dienstleister genauso wie die Industrie oder den Handel. Das läßt sich nur mit sehr flexiblen, das heißt vielseitigen, Einstellschrauben lösen. Mit der gewünschten Flexibilität wird unerwünschterweise eine gehörige Portion Komplexität erkauft.
Die Softwareriesen haben sich mit Tausenden von Tabellen und Programmen sowie mit Hunderten von Teilprozessen an die Grenze der Beherrschbarkeit ihrer Produktwelten heranmanövriert. Ein weiteres Übel liegt im modularen Design der Softwarepakete. Wenn man Softwaresysteme partiell aufteilt und sich dies in der Aufteilung der Entwicklergruppen widerspiegelt, dann kann das Zusammenspiel übergreifender Prozesse nicht die Quelle des Schöpfungsprozesses sein. Die Grenzen der Prozeßorientierung lassen sich an der Workflow-Fähigkeit der Softwareprodukte festmachen.
Aus der Dauer der Einführungszeit läßt sich ersehen, wie komplex ein Softwarepaket ist. Hier sei allerdings davor gewarnt, diesen Indikator als absolutes Vergleichsmaß zu verstehen. Zu viele andere Faktoren spielen bei der Einführungszeit auch noch eine Rolle.
Die Hersteller haben natürlich den Stolperstein Komplexität erkannt und versuchen, Lösungen zu finden, ohne dabei die Möglichkeiten des Systems einzuschränken. Flexibilität soll sich auch bei strukturellen Veränderungen in der Software abbilden lassen, schließlich ist sie für viele Unternehmen ein unbedingtes Muß.
Betriebswirtschaftliche Möglichkeiten innerhalb eines Softwaresystems modellorientiert abzubilden, reduziert zwar nicht die Komplexität, aber es schafft Transparenz, ist also ein Werkzeug, um das Problem in den Griff zu bekommen. Die Voreinstellung der Systeme auf bestimmte Branchentypen würde sich ebenfalls anbieten, doch wie viele Unternehmen dann in diese Schablonen passen oder gar passen wollen, sei dahingestellt.
Nicht zuletzt läßt sich durch die kontinuierliche Verbesserung der Customizing-Leitfäden Komplexität vereinfachen.
Daneben sind es oftmals die Unternehmen selbst, die Anwendungen verkomplizieren. Zu viele Unternehmen sind noch funktional ausgerichtet. So ist es üblich, daß ein Mitarbeiter für die Materialwirtschaft zuständig ist, während sein Kollege sich um den Vertrieb kümmert, der das Material in seinen Aufträgen anfordert.
Diese Aufteilung gilt für die Systembetreuung durch die Org/ DV wie für die Fachabteilungen. Die Schnittstellenprobleme der Fachabteilung lassen sich allerdings durch übergreifenden Workflow abfedern. Natürlich ist der Einwand gerechtfertigt, daß lange Prozeßketten nicht von Einzelpersonen gemanagt werden können. Wie so oft ist nicht die sture Anwendung eines Paradigmas (Funktions-/Prozeßorientiert) die beste Lösung, sondern auf die richtige Kombination kommt es an. Nicht wenige Unternehmen trennen mittlerweile den strategischen vom operativen Einkauf und binden letzteren stärker in den Vertriebsprozeß mit ein.
Redundanzen auf allen Ebenen reduzieren
Auf eine Möglichkeit, die die Komplexität von innen heraus angreift, ist noch ein genauer Blick zu werfen. Die SAP AG versucht zur Zeit, der Architektur des R/3-Systems ein neues Gesicht zu verleihen. Das Ziel dieses Umbaus besteht darin, die Komplexität erheblich zu reduzieren. Man bedient sich dabei der objektorientierten Philosophie und wendet diese auf betriebswirtschaftliche Zusammenhänge an. In einem ersten Schritt werden sogenannte Business-Objekte gebildet, die relevant für einen ganzheitlichen betriebswirtschaftlichen Zusammenhang sind.
Business-Objekte umfassen in der Regel mehrere Entitäten und Business-relevante Methoden. Sie verfügen zudem über klar definierte Schnittstellen und sind in eine gesamte betriebswirtschaftliche Objektarchitektur (Klassifizierung) eingeordnet.
Dieser neue Weg führt zu einem objektorientierten Prozeßdesign. Durch die Trennung von Objekt- und Prozeßwissen lassen sich Redundanzen auf allen Architekturebenen reduzieren.
So wie man bisher teilweise einzelne Module vermarkten konnte, so werden es in Zukunft diese Business-Objekte sein.
Die Standardsoftwarehersteller bieten natürlich weiterhin die komplette betriebswirtschaftliche Palette an, wenn auch mit einer veränderten Architektur. Sollte der Marktführer SAP mit dieser Entwicklung einen allgemeinen Trend für die integrierten Softwarepakete initiiert haben, be- wegen sich die Standardpakete möglicherweise wieder in Richtung Tool. Einen wesentlichen Unterschied darf man bei dieser Feststellung nicht unerwähnt lassen:
Die Aneinanderreihung der Business-Objekte ist nicht mit der herkömmlichen Aneinanderreihung von spezialisierten Tools vergleichbar. Alle Business-Objekte entstammen der gleichen betriebswirtschaftlichen Quelle und sind somit klar aufeinander abgestimmt.
Befürworter der neuen Strategie führen das Argument ins Feld, daß Standardsoftware stark vom Hersteller abhängig macht. Der Wechsel von einem integrierten Standardsoftwarehersteller zum nächsten ist nahezu utopisch, weil jede Kostenrechnung dagegen spricht. Auch der Austausch eines Moduls würde die Prozeßfähigkeit der betriebswirtschaftlichen Anwendungen erheblich beeinträchtigen. Natürlich hat auch jedes Unternehmen die Möglichkeit, Standardsoftware in Individualsoftware zu transferieren. Wie immer man das auch bewerten mag, so sollte man doch nicht vergessen, daß eine selbstentwickelte Software auch in die Abhängigkeit führt - und zwar vom eigenen Mitarbeiter.
Auch wenn man den hier vorgestellten Weg bereits vorsichtig als Trend ausmacht, bleibt trotzdem die Frage, ob die Business-Objekte der verschiedenen Hersteller überhaupt miteinander harmonieren. Es darf nicht vergessen werden, daß es kein genormtes betriebswirtschaftliches Datenmodell gibt, an dem sich die Hersteller orientieren wollen oder können.
Da sich Tools nur für betriebswirtschaftliche Spezialfälle eignen, stellt deren Verkettung keine Ideallösung dar. Tools haben somit heute besonders große Vermarktungschancen, wenn sie sich an Standardpakete anpassen und diese ideal ergänzen.
Vom objektorientierten Business-Design könnten Tool-Hersteller im besonderen profitieren. Zur Zeit macht es ganzheitlich betrachtet noch wenig Sinn, ein Modul eines integrierten Systems durch ein einzelnes Tool zu ersetzen.
Sobald objektorientierte Business-Objekte mit transparenten und offenen Schnittstellen zur Verfügung stehen, ließen sich diese in Einzelfällen durch Tools ersetzen. Sie müßten sich allerdings genauso wie das verdrängte Original in die jeweilige Objektarchitektur einfügen. Bei Preis- oder Leistungsvorteilen wird sich die Substitution auszahlen. Der Markt für betriebswirtschaftliche Software könnte dadurch in Bewegung geraten und das Oligopol der Global Player aufweichen.
Auch das Internet weist Standardsoftware in ihre Schranken. Amerikanische Marktforscher machten vor kurzem darauf aufmerksam, daß R/3 nicht internet-fähig sei. Natürlich ist R/3 genausowenig in Java geschrieben, wie das bei Konkurrenzprodukten der Fall ist.
Mittlerweile hat SAP jedoch eine Internet-Schnittstelle geschaffen, mit der sich Bestellungen im Internet erstellen lassen und R/3 übergeben werden können. Ein Kunde wird nie tiefer in die Logistik eines Unternehmens eingreifen können und dürfen, sondern er wird genau wie ein Lieferant einen begrenzten Zugang erwarten, der seinen Bedürfnissen entspricht. Diskussionen um die Internet-Fähigkeit von Software, wenn nur ein Prozent des Funktionsumfangs benötigt wird, sind ohnehin fehl am Platz. Die Wahrscheinlichkeit, daß Sicherheitsrisiken im Internet/Intranet auch in den nächsten zwei Jahren noch bestehen werden, machen diesbezügliche Diskussionen vollends überflüssig.
Die zunehmende Globalisierung in den letzten Jahren, die Einführung des Euro und das Jahr 2000 haben europäische Konzerne verstärkt dazu bewegt, integrierte Standardsoftware mit internationalem Profil in ihre IT-Strategien mit einzubeziehen. Zuwachsraten von 30 bis 100 Prozent, die die Anbieter 1996 verbuchen konnten, sprechen eine deutliche Sprache.
Kurzum: Noch setzen sich die großen betriebswirtschaftlichen Softwarepakete ihre eigenen Grenzen. Solange sich die Hersteller auf Innovationen konzentrieren, anstatt auf Wettbewerbsschutz zu setzen, werden sie bis auf weiteres noch in der aktiven Rolle bleiben dürfen.
ANGEKLICKT
Die Softwareriesen haben sich mit Tausenden von Tabellen und Programmen sowie Hunderten von Teilprozessen an die Grenze der Beherrschbarkeit ihrer Produktwelten manövriert. Das Manko der Komplexität haben die Hersteller durchaus erkannt. Aber wie die nötige Flexibilität retten und gleichzeitig die Komplexität reduzieren? Ein neuer Weg führt zu einem objektorientierten Prozeßdesign, das durch die Trennung von Objekt- und Prozeßwissen die Reduzierung von Redundanzen auf allen Architekturebenen ermöglicht. Konkret bedeutet dies, daß sich die Softwarepakete sozusagen "wieder in Toolrichtung" bewegen.
*Peter Klukas ist bei der AEG Lichttechnik (Philips), Springe, in der Organisation und Datenverarbeitung beschäftigt.