Von Susan Connor*

In konventionellen Software-Umgebungen gleicht die Aufgabe, Unternehmensmodell und Informationssystem konsistent zu halten, einer Sisyphusarbeit. Erst die Objekttechnik (OT) mit ihrer modifikationsfreundlichen Architektur verspricht den Anwenderunternehmen die Flexibilitaet, die notwendig ist, um jede Aenderung der Geschaeftsprozesse umgehend im System abzubilden.

Fertigungsunternehmen werden jeden Tag mit dem Begriff der Reaktionsfaehigkeit konfrontiert. Die Mitarbeiter in Marketing und Vertrieb verlangen fortschrittliche Produkte, besseren Lieferservice, hoehere Qualitaet, niedrigere Preise. Sie fordern: Reagiert schnell! Denn der Kunde verlangt dasselbe. Waere es nicht wunderbar, wenn das Fertigungsunternehmen mit demselben Wunsch an die Lieferanten seiner Informationssysteme herantreten koennte und der Software-Anbieter antworten wuerde: "Kein Problem!"?

Reaktionsfaehigkeit ist eine der grundlegenden Forderungen, die an moderne Informationssysteme gestellt werden, denn sie sollen die Ablaeufe im Unternehmen abbilden. Und wie wir alle wissen, aendern sich diese taeglich.

Traditionelle Informationssysteme beruhen auf einem Unternehmensmodell, das bereits bei Inbetriebnahme des Systems der Vergangenheit angehoerte. Der Prozess des Umschreibens oder der Code-Umstellung war immer langwierig, teuer und fehlertraechtig (vgl. Abbildung 1). In jedem Unternehmen werden Horrorgeschichten ueber die Implementierung voellig neuer Systeme erzaehlt. Und welche Muehen muessen wir nicht auf uns nehmen, um diese immer wieder auf den aktuellen Stand zu bringen!

Kann die Objekttechnologie (OT) diese Situation verbessern? Ja, denn das wahrhaft Geniale an der OT ist die ihr zugrundeliegende Architektur, die es ermoeglicht, dass sich das Verhalten von Objekten einfach aendern laesst. So ist das System in der Lage, staendig neue Ablaeufe und Vorgehensweisen widerzuspiegeln. Dabei erlaubt es das Prinzip der Einkapselung, jedes modifizierte Objekt separat auszutesten. Auf diese Weise ist sichergestellt, dass sie erwartungsgemaess funktionieren und keinen Einfluss auf die unveraendert bleibenden Bereiche des Systems ausueben.

Diese Architektur verspricht uns, dass sich das System stets parallel zum Unternehmensmodell entwickelt. Ja, das System kann die Entwicklung des Modells sogar ein wenig vorwegnehmen, indem es neue Vorgehensweisen unterstuetzt, bevor diese effektiv werden. Dank der OT liegt der Flaschenhals bei einem Projektplan zur Einfuehrung neuer Unternehmensstrategien nicht mehr - wie bisher - bei den Informationssystemen.

Zudem bereitet uns die OT-Architektur auf ein weiteres Phaenomen vor: Im gleichen Masse, wie sich die Geschaeftstaetigkeit ausweitet, werden auch die Informationssysteme immer komplexer. Die Objekttechnologie ermoeglicht es, diese Komplexitaet von der Handhabung der Objekte fernzuhalten. Und was noch wichtiger ist: Sie erlaubt es dem Informationssystem, mit dem Unternehmensmodell mitzuwachsen.

Die zunehmende Komplexitaet ergibt sich beispielsweise daraus, dass bislang eigenverantwortliche nationale Unternehmen einem europaweiten Management der Schluesselfunktionen unterstellt werden. In diesem Fall muss das System, das eine solche Strategie unterstuetzen soll, in seinem Funktionsumfang wachsen.

Die folgende Liste laesst sich beliebig fortfuehren: Activity-based Costing (Kostenrechnung auf Aktivitaetsbasis), Quick Response (schneller Kundenservice), Just-in-time-Fertigung.

Alle diese Funktionen dienen einer Verbesserung von Verwaltung und Geschaeftsfuehrung, erfordern aber eine staendig wachsende Informationsinfrastruktur zur Unterstuetzung des Managements.

Aber was kostet es nun, wenn ein Unternehmen bei seinem Informationssystem auf Objekttechnologie bauen will? Nun, der Aufwand ist betraechtlich - und aus der Sicht der Systementwicklung fallen die meisten Kosten gleich zu Beginn des Projekts an. Das Design eines objektorientierten Systems ist immer noch zum einen Teil Wissenschaft und zum anderen Kunst.

Hat die Entwicklung aber erst einmal den kritischen Punkt erreicht, so sind betraechtliche Produktivitaetssteigerungen moeglich - und zwar in vier Bereichen:

- bei Qualitaetssicherung und Support;

- bei der Ausnutzung der Rechnerkapazitaeten;

- bei der Programmierung und

- beim Systemeinsatz durch den Endbenutzer.

In puncto Programmierung ist eine Produktivitaetssteigerung allerdings erst moeglich, wenn eine bestimmte Menge wiederverwendbarer Objekte zur Verfuegung steht, die zudem in Klassenbibliotheken eingeteilt sein muessen.

Die Designphase nimmt bei Systemen mit OT-Basis sicher mehr Zeit in Anspruch als bei einem CASE-Tool. Die Produktivitaet der OT- Programmierer steigt jedoch mit zunehmender Erfahrung immer staerker an, waehrend das Produktivitaetsniveau bei CASE-Tools und 4GL-Produkten stets gleich bleibt (vgl. Abbildung 2).

Mit CASE erzeugte Programme bestehen meist aus einer Unmenge von Code. Anders jene in der OT-Welt: Der Unterschied zwischen vergleichbaren Anwendungen betraegt gaengigen Veroeffentlichungen zufolge mindestens zwei zu eins, moeglicherweise sogar zehn zu eins.

Die meisten Industriebeobachter nennen ein Verhaeltnis von 4,5 oder fuenf zu eins. Daraus resultiert eine bessere Ausnutzung der vorhandenen Rechnerkapazitaet.

Den Fuehrungskraeften, die nicht aus dem IS-Bereich kommen, liegt wohl vor allem der Nutzen fuer die Endanwender am Herzen. Die augenfaelligste Verbesserung, die diese unmittelbar betrifft, besteht darin, dass die eingesetzten Systeme exakt die derzeitigen Ablaeufe im Unternehmen abbilden: Keine Softwarespielereien, keine geheimen Listen mit den "echten" Bestaenden, keine doppelten Zahlen in den Spreadsheets, die dann auch nach neuesten Unternehmensstandards ausgelegt werden muessen.

Die Endbenutzer kuemmern sich nur noch um das Geschaeft - mit dem richtigen System und den besten Werkzeugen.

Das freundlichste System ist immer das eigene

Fuer anwenderfreundliche Systeme gibt es keine angemessene Definition. Jedem User ist das freundlichste System immer eines, das er schon gut kennt und so intensiv nutzt, dass er sich darin wohlfuehlt und produktiv damit arbeiten kann.

Also wird es zur Endbenutzerproduktivitaet beitragen, wenn die Lotus-Anhaenger in dem neuen System weiterhin mit "1-2-3" arbeiten und die "Excel"-Anwender nach wie vor ihr Lieblings-Spreadsheet nutzen koennen, die unerfahrenen User aber den Umgang mit einem Tabellenformular lernen, das ihnen von der Anwendung an die Hand gegeben wurde. Auch das ist ein Vorteil der OT-Architektur.

Nie wieder vollstaendige Systemimplementierung

Die groesste Produktivitaetssteigerung resultiert jedoch aus der Tatsache, dass im Unternehmen nie wieder eine vollstaendige Systemimplementierung erforderlich sein wird. Kann man einer solchen Behauptung Glauben schenken?

Ja, langfristig gesehen verspricht die Objekttechnologie genau das. Gesetzt den Fall, die richtigen Objekte stehen zur Verfuegung und die Fachkraefte wissen, wie objektorientierte Systeme zu aendern und zu erweitern sind, muss das Unternehmen nie mehr ein vorhandenes System durch ein vollkommen neues ersetzen, nur weil das alte sich nicht mehr an die aktuellen Gegebenheiten anpassen laesst.

Mit der Objekttechnologie laesst sich die Informationsinfrastruktur im Einklang mit den Geschaeftsablaeufen entwickeln. Und am Ende wird das Konzept der Reaktionsfaehigkeit nicht nur in den Systemen, die die Geschaeftsablaeufe steuern, sondern - im besten Falle - auch in der Geschaeftsphilosophie selbst sicher verankert sein.

OT: Hierum geht es ...

Objekte sind Kapseln, die Daten und Funktionen umfassen. Zudem sind sie in Bibliotheken gespeichert und in Klassen eingeteilt, die das Verhalten aller zugehoerigen Objekte festlegen. Diese Organisationsform ermoeglicht es, Objekte und Klassen separat zu testen. Objekte fuehren die ihnen eigenen Funktionen nur aus, wenn sie eine Standardnachricht von einem anderen Objekt erhalten. Deshalb hat die Aenderung eines solchen nicht den ueblichen Schneeballeffekt, mithin: keine Auswirkungen auf die Qualitaet des Gesamtsystems. Im Falle einer Aenderung ist - im Gegensatz zu 4GL- Programmen beziehungsweise CASE-Modellen - kein Neukompilieren oder -generieren des gesamten Systems erforderlich. Deshalb kann auf Aenderungsanforderungen schneller reagiert werden.

... und darum geht's nicht

Objekte sind keine Programmpakete mit einer Wrapper-Schicht drumherum, ergo eine Subroutine mit Marketing-gerechter Bezeichnung. Objekte sind auch keine Datensaetze oder Gruppen von Datensaetzen. Objekttechnologie laesst sich nur verwirklichen, wenn bei Null angefangen wird, denn die Architektur eines solchen Systems ist vollkommen anders als bei prozeduralen Sprachen. Um Objekttechnologie durchzusetzen, sind grosse Anstrengungen, viel Geld, hervorragende Talente und eine Engelsgeduld erforderlich. Objekttechnologie ist nicht einfach, aber der Aufwand lohnt sich.

* Susan Connor ist Vizepraesidentin bei der Marcam Corp. in Newton, Massachussetts.