Der Einsatz von Referenzmodellen bei der Einführung von Standardsoftware im Rahmen einer Beratungstätigkeit

Der Begriff Referenzmodell läßt sich nur schwer abgrenzen. Er wird in unterschiedlichen Zusammenhängen mit unterschiedlichen Bedeutungen verwendet. Beispiele sind:

• das ISO/ OSI Basis- Referenzmodell für die Kommunikation offener Systeme,
• das Reference Model of Open Distributed Computing (RM- ODP)
• das SAP R/ 3- Referenzmodell. Ziel dieser Arbeit ist es, zunächst eine Definition für die Bezeichnung Referenzmodell, wie sie im Kontext der Unternehmensmodellierung verwendet wird, zu finden.

Ausgehend von einer solchen Begriffsbestimmung läßt sich ein Klassifikationsschema für Referenzmodelle finden. Dieses ist Grundlage für die Integration möglicher Typen von Referenzmodellen in den Prozeß der Erstellung und Einführung von Standardsoftware. Ausgehend von Erfolgsfaktoren und Anforderungen bei der Einführung von Standardsoftware schließt sich eine grobe Marktanalyse an, in der bestehende Produktvarianten in das entwickelte Klassifikationsschema eingeordnet werden.

Ausgehend von dieser Analyse des Ist- Marktes schließt die vorliegende Arbeit mit einem groben Vorschlag für die Entwicklung einer objektorientierten Methodik zur Erstellung objektorientierter Referenzmodelle sowie einer Betrachtung der Marktchancen eines solchen Produktes.

Der Begriff Unternehmensmodellierung setzt sich aus den beiden Teilen Unternehmen und Modellierung zusammen.

Modellierung ist „die Tätigkeit des Abbildens eines Ausschnitts der Wirklichkeit in ein Modell ..“ [HeinRoith95, S. 353] oder in den Worten von Ferstl/ Sinz „die methodisch geleitete Tätigkeit der Erstellung von Modellen“ [FeSi98, S. 117]. Zentrales Ziel einer Modellierung ist also die Erstellung eines Modells. Der Begriff Modell wird im Lexikon der Wirtschaftsinformatik wie folgt definiert:

„Modell:

1. Im allgemeinen Sinne jede vereinfachende Abbildung eines Ausschnitts der Wirklichkeit (Beschreibungsmodell), wobei trotz aller Vereinfachung Strukturgleichheit oder zumindest Strukturähnlichkeit zwischen Wirklichkeit und Abbildung gefordert wird.
2. In der Betriebswirtschaftslehre wird zwischen Erklärungsmodell und Entscheidungsmodell unterschieden. Erklärungsmodelle sind Theorieteile, Entscheidungsmodelle sind für den Entscheidungsträger in der Praxis entwickelte Hilfsmittel zur Ermittlung optimaler Alternativen.
3. In der Wirtschaftsinformatik wird im Zusammenhang mit Methodenbanksystemen unter einem Modell eine Menge von Methoden zum Problemlösen verstanden" [HeinRoith95, S. 353].

Hieraus lassen sich vier Aspekte bzw. Arten von Modellen ableiten:

Der Untersuchungsgegenstand im Rahmen der Modellierung ist also in Anwendung der ersten obigen Definition die Wirklichkeit. Die Unternehmensmodellierung beschäftigt sich demnach in Anwendung des Modellbegriffs mit der Abbildung eines Ausschnittes von Unternehmen oder allgemeiner von Organisationen in einer dieser vier Modellarten.

Diese Abbildung in einem Beschreibungsmodell kann sich sowohl auf real existierende Unternehmen beziehen, z. B. als Organisationshandbuch mit einer Beschreibung der Aufbauorganisation, als auch Ideal- bzw. Sollzustände beschreiben, z. B. die Beschreibung eines idealen Geschäftsprozesses. Die Erstellung solcher Beschreibungsmodelle ist ein recht komplexes Problem und wird deshalb oft in Teilschritte zerlegt, die für sich genommen eine einfach zu beschreibende Handlungsanweisung bzw. Technik darstellen.

Die Beschreibung solcher kreativen oder nach exakten Regeln aufgebauter Techniken, „die beschreiben, wie die Ergebnisse zu erzeugen sind,“ [BaBrOe95, S. 16] lassen sich unter dem Begriff Entscheidungsmodelle subsumieren. Entscheidungsmodelle sind z. B. die lineare Programmierung (exakte Regeln) oder aber Empfehlungen für das Finden von Objekten in der Realwelt wie sie Coad/ Yourdan in der Objektorientierten Analyse (OOA) beschreiben (kreativ). Ein Großteil der Ergebnisse von Techniken beruht jedoch auf Erfahrung, dem fachlichem Wissen und der Innovationsfreude der im Prozeß der Unternehmensmodellierung Beteiligten. Dies läßt sich oft nicht durch konkrete Regeln, oder Algorithmen automatisieren (vgl. [BaBrÖs95, S. 17]).

Ein Problemlösungsmodell (z. B. das Wasserfallmodell) beschreibt ein Vorgehen, das durch Ausführung verschiedener Entscheidungsmodelle unter Entwicklung eines Beschreibungsmodells ein konkretes, meist unstrukturiertes Problem löst.

Die Kombination aus Beschreibungsmodell, Entscheidungsmodell (Techniken) und Problemlösungsmodell (Vorgehensmodell) wird als vollständige Methode (z. B. ARIS, OOA) bezeichnet. Die Beschreibung einer Methode wäre wiederum ein Beschreibungsmodell.

Einen ähnlichen, leicht erweiterten Ansatz der Beschreibung einer Methode wählen Bach/ Brecht/ Österle in [BaBrÖs95, S. 17]. Dieser Ansatz läßt sich jedoch in die Terminologie von Beschreibungs, Entscheidungs- und Problemlösungsmodell überführen.

Abbildung 1: Die drei Bestandteile einer Methode

Der allgemeine Begriff Referenzmodell ist kein strikt abgrenzbarer Begriff. Eine Definition muß sowohl auf die Rolle eines Rahmenwerkes (ISO/ OSI- Basisreferenzmodell für die Kommunikation offener Systeme) als auch auf die Rolle von Referenzmodellen in der Unternehmensmodellierung (Referenzmodell in SAP R/ 3) eingehen.

So läßt sich der Begriff Referenzmodell zunächst aus der Modelldefinition ableiten, indem zusätzlich auf die Charakteristika Bezugnahme, Empfehlung und glaubwürdige Auskunft des Begriffs Referenz eingegangen wird.

Scheer (vgl. [Scheer97, S. 3]) hingegen zielt mehr auf den Charakter des Referenzmodells als Ausgangspunkt für die Entwicklung eines konkreten Modells ab und stellt damit den Zweck bzw. Nutzen von Referenzmodellen in den Vordergrund: „Unter einem Referenzmodell wird ein Modell verstanden, das als Ausgangspunkt für die Entwicklung auf konkrete Aufgabenstellungen bezogener Problemlösungen dienen kann“.

Das Wirtschaftsinformatiklexikon sieht den Referenzmodellbegriff über die Grenzen der Unternehmensmodellierung hinaus als ein Modell, „das einen gewollten oder geplanten Zustand eines Systems abbildet, an dem der gegenwärtige Zustand des Systems beurteilt werden kann (z. B. die Grundkonzeption als geplanter Zustand eines Anwendungssystems und der Istzustand desselben Anwendungssystem)“ [HeinRoith95, S. 102].

Konkrete Anwendung des so definierten Referenzmodellbegriffs stellt Hansen für den Bereich der Informatik vor: „Das DIN/ ISO- Basis- Referenzmodell für die Kommunikation offener Systeme (..) beschreibt ein allgemeines abstraktes Modell .. , d. h. es werden nur die wichtigsten Eigenschaften des Außenverhaltens funktional festgelegt“ [Hansen92, S. 650]. Eine Definition des Begriffs Referenzmodell muß diesen Aspekt mit einschließen.

Einen anderen Weg beschreitet Schütte indem er den Begriff Referenzmodell als Referenzinformationsmodell konkretisiert und darauf verweist, daß es sich im Kontext der Unternehmensmodellierung immer um den Begriff Referenzinformationsmodell handelt: „In der betrieblichen Praxis nehmen Referenzinformationsmodelle, die verkürzt als Referenzmodelle bezeichnet werden, einen hohen Stellenwert ein. Sie stellen allgemeingültige Repräsentationen von Wissen dar. Sie verfolgen den Zweck, nach der Adaption des Referenzmodells in einem individuellen Kontext eingesetzt werden zu können“ [Schü98, S. 64]. Eine ähnliche Definition trifft Scholz- Reiter und charakterisiert ein Referenzmodell durch die drei Aspekte (vgl. [Scho90, S. 31]):

• generelle Gültigkeit
• frei von individuellen Besonderheiten
• besteht aus den wesentlichen Eigenschaften

Eine allgemeine Definition des Begriffs Referenzmodell, die sowohl dessen Anwendung in der Unternehmensmodellierung als auch in der Rolle eines Rahmenwerkes charakterisiert trifft Schmalzl: „Anhand charakteristischer Eigenschaften wird ein Sachverhalt mit seinen gültigen Ausprägungsformen in einem Referenzmodell allgemein beschrieben. Ihren besonderen Wert erhalten Referenzmodelle, wenn daraus bei Kenntnis der Einflußparameter und Rahmenbedingungen nicht nur konkrete Ausprägungen abgeleitet werden, sondern das Referenzmodell auch als Vergleichsgröße der unterschiedlichen Endprodukte dienen kann“ [Schmalzl95, S. 206].

Da der Inhalt dieser Arbeit in den Bereich Unternehmensmodellierung einzuordnen ist, wird im folgenden der Begriff Referenzmodell im Sinne eines Referenzinformationsmodells benutzt, wie er von Schütte geprägt wurde: „Referenzmodelle können .. definiert werden als das Ergebnis einer .. Konstruktion eines Modellierers, der für Anwendungssystem- und Organisationsgestalter Informationen über allgemeingültig zu modellierende Elemente eines Systems zu einer Zeit als Empfehlungen mit einer Sprache deklariert, so daß ein Bezugspunkt für ein Informationssystem geschaffen wird“ [Schü98, S. 70]. Wesentliche Aspekte eines Referenzmodells sind somit:

• Allgemeingültigkeit
• beschränken sich auf wesentliche Eigenschaften
• dienen als Ausgangspunkt für die Adaption auf ein konkretes Informationsmodell
• haben Empfehlungscharakter

Hinsichtlich einer Klassifikation von Referenzmodellen (RM) besteht in der Literatur relative Einigkeit. Eine Unterscheidung von RM nach deren Aufgabenstellung bzw. nach dem modellierten Objektsystem in Softwarereferenzmodell (= Referenzanwendungssystemmodelle) und Branchenreferenzmodelle (= Referenzorganisationsmodelle) (vgl. [Schü98, S. 64]) wird einhellig zugestimmt.

Software- RM erlauben dem Anwender von (Standard-) Software auf einer der reinen programmtechnischen Ebene überlagerten abstrakteren Schicht Anpassungen vorzunehmen. Ziel dieses Anpassungsprozesses ist es ein konkretes Unternehmen, oder Teile dessen, mit seinen Daten, Funktionen und Prozessen sowohl in der Sprache der Problemdomäne als auch in der Sprache der Software nachvollziehbar abzubilden.

Branchen- RM hingegen sind nicht an eine spezifische Software gebunden, sondern sind allgemeingültige Unternehmensmodelle, die wiederum Ausgangspunkt für konkrete Unternehmensmodelle sein können. Zwei Ansatzpunkte hierbei sind die Modellierung von Best Practice Cases und Common Practice Cases.

Diese Klassifikation in zunächst zwei Typen wird oft um weitere Typen ergänzt. So schlägt Scheer zum Beispiel einen weiteren Typ der Vorgehens- Referenzmodelle vor.

„Je nachdem, welche Aufgabenstellung mit dem Einsatz von Referenzmodellen bearbeitet wird, können beispielsweise branchenspezifische Referenzmodelle, softwarespezifische Referenzmodelle oder Vorgehens- Referenzmodelle unterschieden werden“ [Scheer97, S. 3].

Grundlage dieser Arbeit sei eine Klassifikationsmatrix, die zunächst nach den Bestandteilen einer Methode unterteilt. Eine weitere Unterteilung ergibt sich durch die Klassifikation in allgemeine RM und gebundene RM. Allgemeine Referenzmodelle haben reinen Abbildungscharakter, wie z. B. Branchen- RM. Dagegen sind gebundene RM an eine bestimmte Software oder ein bestimmtes Verfahren gebunden wie z. B. ein Kostenstellenplan als Grundlage einer Kostenstellenrechnung. Sie bilden eine Schnittstelle zwischen Softwareterminologie und Realwelt.

Eine dritte Gliederungsebene ergibt sich durch Unterteilung der RM nach Spezialisierungsgebieten. Hier läßt sich ausgehend von Markttendenzen eine leicht erweiterbare Einteilung

• auf Spezialisierung auf primäre (Beschaffung, Produktion, Absatz) und sekundäre (Finanzierung, Controlling etc.) Funktionen der Unternehmung
• Branchen (Kreditwirtschaft, Maschinenbau etc.)
• Verfahren (Verschnittalgorithmus für Textil- und Papierbranche) (vgl. dazu [Mert97, S. 75ff.] bzw. [Schw97, S. 154])

Abbildung 2: Die Drei- Ebenen- Klassifikationsmatrix für Referenzmodelle

Ein Software- RM, wie es z. B. SAP mit dem R/ 3- Referenzmodell anbietet, würde sich als gebundenes RM mit dem Charakter eines Beschreibungsmodells in dieser Klassifikation wiederfinden. Seitens SAP gibt es sowohl eine Spezialisierung auf Funktionen, wie sie sich in der Bildung von Modulen (FI, MM) ausdrückt als auch eine Spezialisierung auf Branchen.

Standardsoftware (SSW) wird definiert als „Anwendungssoftware, die für den anonymen Markt entwickelt wird und bei deren Entwicklung daher die (prognostizierten) Anforderungen einer größeren Anzahl von Anwendern zugrunde gelegt werden“ [HeinRoith95, S. 488]. SSW hat also, ähnlich einem Referenzmodell, einen Charakter der Allgemeingültigkeit. Im Gegensatz dazu steht Individualsoftware, die eigens für einen jeweiligen einmaligen Anwendungszweck entwickelt wurde.

Die allgemeinen Konzepte für die Entwicklung von Software müssen um die Aspekte des Fremdbezuges erweitert werden. Beispielhaft sei dies hier anhand des Wasserfallmodells (vgl. [Pres92, S. 24ff]) nachvollzogen. Das Wasserfallmodell als relativ starre Abfolge der Phasen System Engineering, Analysis, Design, Code, Testing, Maintenance wird von Stahlknecht in [Stah97, S. 255] recht grob um eine Alternative erweitert. Für ihn besteht nach der idealer Weise mit der Erstellung eines Sollkonzeptes beendeten Phase der Analyse die Wahl zwischen anschließendem Design, Coding, Testing (Eigenentwicklung) und der Anschaffung von Standardsoftware (Fremdbezug).

Daraus ergeben sich drei Problem, die durch geeignete Techniken unterstützt werden müssen:

1. Entscheidung zwischen Eigenentwicklung und Standardsoftware
2. Auswahl einer SSW in der Analysephase
3. Anpassung der SSW an das Sollkonzept der Analysephase

Die Entscheidung für oder wider SSW kann einerseits aufgrund allgemeiner Vor- und Nachteile von SSW gefällt werden ¹ oder aber auch als Ergebnis einer Analyse des SSW- Marktes. Die Auswahl einer SSW beruht auf einem Vergleich der Leistungsfähigkeit auf dem Markt verfügbarer SSW hinsichtlich abgebildeter daten-, funktions-, organisations- und prozeßorientierter Aspekte und dem entwickelten Sollkonzept ² . Hierbei können soweit zugänglich die mit der Software gebundenen Beschreibungsreferenzmodelle genutzt werden, da diese die Funktionalität der SSW auf einer betriebswirtschaftlichen Ebene beschreiben.

Die Anpassung der SSW an das Sollkonzept entspricht einer Parametrisierung des SSW- Systems. Analog zur Einführung von Systemsoftware, wie z. B. Unix Betriebssysteme kann dies in der Sprache der Software durch die Bearbeitung von Text-Parameterdateien geschehen. Diese Anpassung würde jedoch hinsichtlich Verständlichkeit, Nachvollziehbarkeit und Komfort nur Spezialisten zugänglich sein. Um diesem Problem aus dem Weg zu gehen wird mit SSW- Systemen ein Konfigurationsmanagementsystem ausgeliefert. Damit wird zwischen dem die Realwelt abbildenden Sollkonzept und dem SSW- System eine Beschreibungsebene eingefügt, die sowohl der Software als auch dem Benutzer verständlich ist.

Um den (einmaligen) Prozeß der Anpassung zu unterstützen, kann das Konfigurationsmanagementsystem auch ein an die Software gebundenes Problemlösungsmodell (Vorgehensmodell) beinhalten.

Abbildung 3: Der Wissensfluß bei der Abbildung des Unternehmens in der SSW

Eine in der Praxis anzutreffende Verfahrensweise spart die Entwicklung eines SSWunabhängigen unternehmensspezifischen Sollmodells ein. Somit ist keine Grundlage für die Auswahl eines SSW- Systems gegeben. Diese Entscheidung kann dann nur noch aufgrund einer allgemeinen Präferenz oder aber einer groben Marktanalyse gefällt werden oder wurde im Rahmen einer Unternehmensstrategie formuliert (z. B. systematische Einführung von SAP R/ 3). Das unternehmensspezifische Sollmodell wird gleich in der Beschreibungssprache der SSW entwickelt. Dies erzeugt allerdings den oft negativen Eindruck, daß zwar die SSW an das Unternehmen angeglichen wird, aber auch daß das Unternehmen an die mit der SSW verbundenen Beschreibungsreferenzmodelle angepaßt wird.

Vorteil eines solchen Vorgehens ist der geringere Aufwand, durch die Einsparung des Prozesses der Überführung des softwareunabhängigen Sollmodells in das softwarespezifische Sollmodell. Dieses Verfahren stellt hohe Anforderungen an das Software- gebundene Beschreibungsmodell und die Funktionalität der SSW hinsichtlich Allgemeingültigkeit oder aber Erweiterbarkeit.

Der Ursprung des Consulting (Beratungstätigkeit) liegt im Investitionsgütermarketing, insbesondere dem Verhalten der Nachfrager auf dem Investitionsgütermarkt. Zwischen Anbieter und Nachfrager etablierten sich Unternehmen, deren Produkt nicht das Investitionsgut an sich, sondern eine begründete Empfehlung für die Kaufentscheidung des Nachfragers ist.

Allgemeiner ist ein Consultant „eine Person oder Gruppe, die einer Organisation dort nicht oder nicht ausreichend vorhandenes Spezialwissen zur Verfügung stellt“ [HeinRoith95, S. 95]. Das ausgetauschte Gut ist eine Dienstleistung, deren Hauptleistung in einem Informationsgewinn seitens des Nachfragers resultiert. Eine Dienstleistung ist charakterisiert durch (vgl. [Meff90, S. 44]):

• abstrakte, immaterielle Leistung (z. B. Know- how eines Unternehmensberaters)
• nicht lagerfähige Leistung
• nur in Ausnahmefällen transportfähige Leistung
• oft individualisierte/ einmalige Leistung
• häufig personalintensive Leistung
• schwer standardisierbare Leistung

Die Hauptleistung eines Consultant liegt in der Vermittlung bzw. Anwendung von Spezialwissens. Damit ergeben sich drei Erfolgsfaktoren der Beratungstätigkeit, da dieses Wissen

• eine Bedeutung für den Kunden hat,
• vom Kunden als solches wahrgenommen werden und
• dauerhaft als Wettbewerbsfaktor bestehen können muß (Schützbarkeit) (vgl. [Back97, S. 30f]).

Die Bedeutung für den Kunden liegt vor allem in einem relativen Kostenvorteil gegenüber einer Aneignung des Spezialwissens seitens des Kunden. Der Aufbau dieses Spezialwissens im eigenen Unternehmen erfordert jedoch Zeit für einen Lernprozeß. Hingegen steht die externe Beratungsleistung sofort zur Verfügung.

Um diese Bedeutung dem Kunden zu verdeutlichen, bedarf es seitens der Beratungsgesellschaft einer Kommunikationspolitik, die dem Kunden in einer ihm verständlichen Sprache einen unverzichtbaren Nutzen verspricht.

Die Dauerhaftigkeit des Spezialwissens läßt sich z. B. durch einen ständigen Technologievorsprung gegenüber potentiellen Wettbewerbern sichern. Gerade in Märkten mit kurzen Innovationszyklen spielt hier der Faktor (Entwicklungs-) Zeit eine wichtige Rolle (vgl. [Töpf91, S. 167ff]).

Ziel der Einführung von Software im allgemeinen und SSW im speziellen ist es eine erhöhte Effektivität in der Unternehmensleistung zu gewährleisten oder aber diese Unternehmensleistung überhaupt erst zu ermöglichen. Um dies effektiv zu gewährleisten, muß ein SSW- System von Anwendern akzeptiert und aktiv genutzt werden. Weiterhin lassen sich folgende Anforderungen an SSW aufführen (vgl. [Hein92, S. 90f]).

Verfahren und Vorgehensweisen bei der Einführung von Standardsoftware, die den dauerhaften Aufbau dieser Erfolgsfaktoren unterstützen und dem Kunden vermitteln, müssen Bestandteil jedes Einführungsprojektes sein. Die Implementierung von Software- gebundenen Problemlösungsmodellen oder die Nutzung von allgemeinen Vorgehensreferenzmodellen können hier unterstützend wirken. Die Verwendung von Software- gebundenen oder allgemeinen Beschreibungsmodellen kann vor allem hinsichtlich Richtigkeit, Wartbarkeit und langfristig auch hinsichtlich Wirtschaftlichkeit von Vorteil bei der Einführung und Nutzung von SSW- Systemen sein.

Eine Abschätzung des Marktpotentials von Referenzmodellen bzw. von Produkten, deren Hauptnutzen in einem integrierten Referenzmodell besteht, läßt sich nur schwer vornehmen. Es handelt sich um ein Investitionsgut und somit im Gegensatz zum Konsumgut um ein langlebiges Produkt, welches sich nur an eine kleine Zielgruppe richtet.

Das Marktpotential wird durch „die generelle Wirtschaftsentwicklung, die technologische Entwicklung und durch die Potentiale nachgelagerter Wirtschaftszweige und durch die Struktur des Außenhandels“ [Zent92, S. 285f] bestimmt.

Für die Schätzung des Marktpotentials bieten sich zwei Verfahren an. Die „Census Method“, bei der das Marktpotential durch Addition der individuellen Potentiale aller möglichen Abnehmer abgeleitet wird. Und die „Market Survey Method“ bei der ausgehend von einer Kennzahl, die den Zusammenhang von Verkäufen in einer Abnehmergruppe und einer statistischen Größe darstellt, durch analoge Anwendung dieses Verhältnisses auf das Marktpotential der potentiellen Abnehmer geschlossen wird. Hierbei besteht das Problem eine geeignete Kennzahl zu finden, die möglichst stark mit dem Marktvolumen korreliert (vgl. [Zent92, S. 286]. Für den Bereich Referenzmodelle würde sich hier z. B. das Marktpotential von SSW- Systemen anbieten.

Eine sehr grobe und mit zahlreichen Fehlern behaftete Schätzung kann hier im Rahmen einer Sekundärforschung gegeben werden. Eine genauere Primärschätzung wäre mit einem der beiden oben genannten Verfahren möglich.

Ausgehend von den Kosten für die Datenverarbeitung aufgegliedert nach Kleinunternehmen, Mittelstand und Großunternehmen weltweit ergibt sich folgende Kalkulation:

Angaben in Millionen DM

Als sehr grobe Schätzung für das Marktpotential in Summe ergeben sich somit rund 120 Millionen DM. Dieser Wert hängt stark vom bewerteten Anteil des Produktes „Referenzmodell“ am Gesamtaufwand für SSW. Ein Erhöhung um ein Prozent würde das Marktpotential verdoppeln. Dies zeigt allerdings auch, daß das oben gewählte Verfahren nur sehr beschränkt interpretierbar ist.

Unabhängig davon zeigt sich, daß in mittelständischen Unternehmen das größte Marktpotential für SSW und Referenzmodelle liegt. Ein Produkt, welches hilft die Kosten für die Datenverarbeitung bzw. SSW zu senken hätte im Bereich mittelständische Unternehmen sehr gute Marktchancen.

In der gleichen Größenklasse liegt eine Abschätzung der Gartner Group. Sie beziffert das Marktvolumen des Bereiches Werkzeuge für das Business Process Reenginering für das Jahr 1997 mit 200 Millionen US- Dollar, mit einer Wachstumsrate von 30 Prozent [Vers98, S. 88]. Allerdings läßt sich der Bereich BPR nur schwer abgrenzen. so daß auch diese Zahl nur als grobe Schätzung für die Marktpotentiale von Referenzmodellen und Referenzmodellwerkzeugen dienen kann.

Der Markt für Referenzmodell wird von vier Hauptanbietern geprägt: SAP, IDS Prof. Scheer GmbH, BAAN und Oracle. Die Hauptanforderung an die Produkte dieser Firmen müssen sich in die Drei- Ebenen- Klassifikationsmatrix einordnen lassen.

Ausgehend von der Ebene „Methode“ läßt sich zunächst feststellen, daß jedes Produkt sowohl Beschreibungsmodell, Problemlösungsmodell und Entscheidungsmodelle (z. B. Simulation und Kostenplanung) unterstützt (vgl. dazu: [Sche97, S. 81ff]).

Während die Produkte von SAP, BAAN und Oracle mit den zugehörigen SSW-Systemen gebunden sind, ist das ARIS- Toolset der IDS ein allgemeines Referenzmodell- Werkzeug. Um ARIS auch in den Einführungsprozeß von SSW zu integrieren bietet die IDS Schnittstellen zu SSW- Systemen an (SAP) oder plant diese anzubieten (Oracle, BAAN vgl. [Sche97, S. 92f]).

Ein weiteres Verkaufsargument der einzelnen Anbieter ist die Zahl der unterstützten Methoden. So bietet ARIS z. B. die Möglichkeit die Methoden ERM, HIPO, SADT, SA, OMT nach Rumbaugh (rudimentäre Nutzung der grafischen Darstellungsformen) und eEPK zu nutzen. Wünschenswert wäre jedoch die Unterstützung einer Methodik, die es erlaubt eine konsistente Modellierung von Daten-, Funktions-, Organisations- und Prozeßsicht durchzuführen (vgl. [Sche95, S. 166]).

Seit einiger Zeit etablieren sich in der Unternehmensmodellierung objektorientierte Methoden, die die Konzepte der objektorientierten Programmierung auf die Unternehmensmodellierung übertragen. Objektorientierte Methoden (z. B. OMT, OOA) unterstützen eine konsistente Modellierung der verschiedenen Sichten und würden damit Nachteile bisheriger Methoden (z. B. SA, ERM) vermeiden. Obwohl sich objektorientierte Methoden für die Programmierung von Individualsoftware als geeignet erwiesen haben, werden sie jedoch nur selten konsequent für den Bereich SSW eingesetzt.

Abbildung 4: Objektorientierung- Funktionsumfangs- Matrix [Born98, S. 100]

Die objektorientierte Modellierung versucht die fehlende Integration verschiedener Sichten bei traditionellen Ansätzen zu vermeiden (vgl. [FeSi98, S. 125]). Zentrales Konzept objektorientierte Modellierungsmethoden ist das Objekt. Ein Objekt, bestehend aus Attributen und darauf operierenden Methoden (Funktionen), repräsentiert (abstrakte) Gegenstände bzw. Zustände. Die Interaktion zwischen den Objekten geschieht über Nachrichten.

Mit Sicht auf die Entwicklung von Individualsoftware haben sich diverse objektorientierte Methoden entwickelt. Beispielhaft seien hier verschiedene Aspekte der Objektorientierung anhand der Methode OMT von Rumbaugh dargestellt. Ein konkretes Werkzeug für die objektorientierte Referenzmodellierung muß diese Konzepte aufgreifen.

Die Methode OMT ist eine vollständige Methode, da sie sowohl Beschreibungsmodell, Problemlösungsmodell als auch Entscheidungsmodelle beinhaltet. Das Ergebnis einer objektorientierte Analyse mittels OMT ist ein Modell, welches aus den drei Sichten

• Objektmodell (= Daten- und Organisationssicht)
• Dynamisches Modell (= Prozeßsicht)
• Funktionales Modell (= Funktionssicht)

besteht. Die verschiedenen Sichten werden nicht unabhängig voneinander modelliert, sondern iterativ über schrittweise Verbesserung und Abstimmung entwickelt. Dieses Vorgehen unterstützt eine konsistente (Referenz-) Modellierung.

Eine zunehmende Objektorientierung in der Programmierung verspricht Bedarf nach objektorientierten Referenzmodellen und Werkzeugen um diese auf konkrete Unternehmensmodelle zu adaptieren. So ist zu erwarten, daß die Schnittstelle zwischen objektorientierter SSW und objektorientiertem Software- gebundenen Beschreibungsreferenzmodell durch die Nutzung der gleichen Methode erleichtert wird. Die Entwicklung leistungsfähiger objektorientierter Datenbanken erlaubt ein effiziente Speicherung solcher Modelle. So sind z. B. die Referenzmodelle von IDS und SAP schon heute in einer objektorientierten Datenbank gespeichert [Vers98, S. 88]. Der Übergang zum objektorientierten Referenzmodell ist aber noch nicht vollzogen. Für die Modellierung werden weiterhin traditionelle Methoden benutzt.

Sowohl das Problem zu langer Entwicklungszeiten umfangreicher SSW (Releasewechsel) als auch die zunehmende Spezialisierung von SSW auf Fachgebiete (z. B. Peoplesoft) werden zukünftig zu einer komponentenbasierten Systemarchitektur führen. Die Definition von Teilschemata, wie sie in der OOA von Coad/ Yourdan durch die Einführung eines Subject Layers vorgeschlagen wird, kann hier unterstützend wirken (vgl. [CoYo91, S. 106ff]). Die einzelnen Teilmodelle sind dadurch gekennzeichnet, daß sie möglichst wenig Schnittstellen nach außen haben, d. h. sie sind gut austauschbar. Für jede Komponente könnte ein Teilmodell existieren. Diese Teilmodelle ordnen sich jedoch in ein komplexes Referenzmodell ein. Die Einführung komponentenbasierter Software ist mit mehreren Problemen verbunden, z. B. den Problemen der Granularität und der herstellerübergreifende Schnittstellendefinitionen, .. ⁵.

Die mit der Einführung von Komponenten verbundene erhöhte Kommunikation zwischen den Komponenten könnte z. B. mittels CORBA- Technologie erfolgen. Die Einführung der BAPI- Technologie im R/ 3- System von SAP verfolgt diesen Weg. Sie soll die Kommunikation von Objekten (in der SAP- Terminologie: Business Objects) ermöglichen. Dies ermöglicht sowohl die Kommunikation innerhalb des R/ 3- Systems als auch die Kommunikation des R/ 3 Systems mit Fremdsystemen (vgl. [Kor97, S. 216]).

Die Gliederung großer Unternehmen in kleine schlagkräftige Einheiten, die untereinander vernetzt sind, erfordert eine Anpassung der DV an diese kleine Einheiten. So müßte ein monolithisches System bei Veräußerung bzw. Kauf kleiner Einheiten komplett angepaßt werden. Hingegen ermöglicht die Nutzung von Komponenten mit definierten Schnittstellen eine schnellere Anpassung der DVSysteme aneinander. Diese Flexibilität muß nicht auf relativ abgrenzbare Unternehmensteile beschränkt bleiben. So läßt sich die Aggregation der Funktionalität von Abteilungen (Büros) in Form von „dienstleistenden“ Objekten in SSW abbilden. Diese Objekte agieren dann in einem auf Prozeß-, Daten-, Funktionsebene vernetzen Unternehmen relativ eigenständig. Auf ähnliche Weise, durch die Aggregation ganzer Unternehmen aus Komponenten, ließen sich netzwerkartige Strukturen zwischen Unternehmen (z. B. Unternehmensnetzwerke klein- und mittelständiger Unternehmen) in SSW- Systemen abbilden.

Einerseits läßt sich die zukünftige technologische Entwicklung auf jungen und instabilen Märkten nur schwer vorhersagen andererseits hängen die Marktchancen eines objektorientierten Referenzmodells bzw. eines objektorientierten Referenzmodellierungswerkzeuges stark von dieser ab.

Ausgehend von einem schon lang anhaltenden Trend zur Objektorientierung in der Programmierung und in der Modellierung (z. B. UML) läßt sich vermuten, daß dieser Technologietrend anhält. Mögliche Verschiebungen der Markttendenzen auf dem Gebiet der Objektorientierung lassen sich z. B. dadurch abfangen, daß in der Unternehmensphilosophie der Wille zur Technologieführerschaft verankert und auch gelebt wird. Dies bindet die zur Verfügung stehenden Mittel für die Aufgaben der Forschung und Entwicklung. Unter Annahme begrenzter finanzieller Mittel ist es zu empfehlen den Vertrieb eines solchen Produkts nicht selbst vorzunehmen. Statt des schwierigen Aufbaus eines eigenen Vertriebsnetzes im Investitionsgütermarkt empfiehlt es sich, sich auf die Vertriebsstruktur eines oder mehrerer Systemhäuser oder aber größerer Consultingfirmen im Rahmen einer Kooperation zu verlassen.

Die Auswahl eines geeigneten Systemhauses erfordert besondere Sorgfalt, da damit einer der Erfolgsfaktoren der Beratungstätigkeit in die Hände eines fremden Unternehmens gegeben wird - die Kundenwahrnehmung (vgl. Kapitel 3.1). Der Faktor „Bedeutung für den Kunden“ kann langfristig nur über eine ständige Marktbeobachtung in Zusammenarbeit mit dem Vertrieb erreicht werden. Dritter Erfolgsfaktor ist die Schützbarkeit des Produktes gegenüber potentiellen Konkurrenten. Hier ist in der Technologieführerschaft ein geeignetes Mittel zu sehen um diesen Schutz zu gewährleisten. Hohen Aufwendungen für Forschung und Entwicklung und ein nicht zu unterschätzender Entwicklungszeitnachteil bauen eine Markteintrittsbarriere auf.

Das Kundenpotential besteht zunächst aus Großunternehmen, mittelständigen und kleinen Unternehmen. Insbesondere mit Blick auf den Erfolg von SAP in Großunternehmen und dem schleppenden Verkauf von R/ 3 in mittelständigen Unternehmen [Born95, S. 106] verspricht eine Konzentration auf mittelständige und kleine Unternehmen Erfolg. Mit Blick darauf, daß sich für den Bereich gut strukturierbarer Probleme (Finanzbuchhaltung, Produktionsprogrammplanung) traditionelle Ansätze als ausreichend erweisen, ist es zu empfehlen sich zunächst auf schwer strukturierbare Problembereiche zu konzentrieren (z. B. Forschung und Entwicklung, Dienstleistungssektor).

Die entwickelte 3- Ebenen- Klassifikationsmatrix läßt sich gut nutzen um existierende Produkte einzuordnen. Durch die Aufnahme der Ebenen „Methode“ und „Spezialisierung“ lassen sich auch weitere Ansätze der Referenzmodellierung entwickeln. Beispielhaft ist die Entwicklung einer objektorientierten Methode zur Referenzmodellierung erörtert worden.

Für eine genaue Analyse der Marktchancen eines solchen Produktes müßte ein konkretes Produkt in seinen Ansätzen entwickelt und getestet werden. Ein anschließende Untersuchung des Ist- Marktes im Rahmen einer Primär- Forschung ist nicht nur wünschenswert sondern auch notwendig. Insbesondere ein Vergleich der Vor- und Nachteile eines neuen Ansatzes mit etablierten Ansätzen der Referenzmodellierung (z. B. ARIS) muß erfolgen.

Eine exakte Strategie kann erst nach einer solchen Marktanalyse entwickelt werden. Ausgehend von dieser Strategie läßt sich dann ein Business Plan erstellen, der Grundlage für die praktische Anwendungen, z. B. im Rahmen einer Unternehmensgründung, sein kann.

ABBILDUNG 1: DIE DREI BESTANDTEILE EINER METHODE

ABBILDUNG 2: DIE DREI- EBENEN- KLASSIFIKATIONSMATRIX FÜR REFERENZMODELLE

ABBILDUNG 3: DER WISSENSFLUß BEI DER ABBILDUNG DES UNTERNEHMENS IN DER SSW

ABBILDUNG 4: OBJEKTORIENTIERUNG- FUNKTIONSUMFANGS- MATRIX [BORN98, S. 100]

[BaBrÖs95] Bach, V.; Brecht, L.; Österle, H.: Software- Tools für das Business Process Redesign. Baden- Baden 1995

[Back97] Backhaus, K.: Industriegütermarketing. München 1997

[Born95] Born, A.: Maß aller Dinge In iX 4/ 95 S. 92- 108.

[Born98] Born, A.: Baukastensysteme In iX 6/ 98 S. 98- 100.

[CoYo91] Coad, P.; Yourdon, E.; Object Oriented Analysis. Englewood Cliffs, New Jersey 1991

[EBIT98] EBIT GmbH München: EBIT- Referenzmodell für die NISrelevanten Geschäftsprozesse in EVU (Sparte Strom). Http:// www- a5. igd. fhg. de/ reuse_ m/ ebit_ kundeninfo2. html Januar 1998, Download: 22.11.1998

[FeSi98] Ferstl, O.; Sinz, E.: Grundlagen der Wirtschaftsinformatik Band 1. München 1998

[Hansen92] Hansen, H.: Wirtschaftsinformatik. Stuttgart, Jena 1992

[Hein92] Heinrich, L.: Informationsmanagement. München, Wien 1992

[HeinRoith95] Heinrich, L.; Roithmayr, F.: Wirtschaftsinformatiklexikon. München, Wien 1995

[Hirs90] Hirschberger- Vogel, M.: Die Akzeptanz und die Effektivität von Standardsoftwaresystemen. Berlin 1990

[Kor97] Kor, A.: Integration von Business Process Reengineering mit dem SAP- R/ 3- Prozeßmodell In Maicher, M.; Scheruhn, H. (Hrsg.): Informationsmodellierung. Wiesbaden (1998), 201- 225.

[Meff90] Meffert, H.: Marketing. Berlin 1990

[Mert91] Mertens, P.: Integrierte Informationsverarbeitung 1. Wiesbaden 1992

[Mert97] Mertens, P.; Ludwig, P.; Engelhardt, A.; Möhle, S.; Kaufmann, T.; Ließmann, H.: Mittelwege zwischen Individual- und Standardsoftware - Überblick zu ausgewählten Experimenten. In: Becker, J.; Rosemann, M.; Schütte, R. (Hrsg.): Entwicklungsstand und Entwicklungsperspektiven der Referenzmodellierung. (1997), 65- 79.

[Pres92] Pressman, R.: Software Engineering. New York 1992

[Sche95] Scheruhn, H.: Modellbau In iX 4/ 95 S. 160- 170

[Sche97] Scheruhn, H.: Integration von Referenzmodellen bei der Einführung betrieblicher Anwendungssysteme. In Entwicklungsstand und Entwicklungsperspektiven der Referenzmodellierung In: Becker, J.; Rosemann, M.; Schütte, R. (Hrsg.): Entwicklungsstand und Entwicklungsperspektiven der Referenzmodellierung. (1997), 80- 95.

[Scheer97] Scheer, A.: ARIS - House of Business Engineering: Konzept zur Beschreibung und Ausführung von Referenzmodellen. In Entwicklungsstand und Entwicklungsperspektiven der Referenzmodellierung In: Becker, J.; Rosemann, M.; Schütte, R. (Hrsg.): Entwicklungsstand und Entwicklungsperspektiven der Referenzmodellierung. (1997), 3- 15.

[Schmalzl95] Schmalzl, J.: Architekturmodelle zur Planung der Informationsverarbeitung von Kreditinstituten. Heidelberg 1995

[Scho90] Scholz- Reiter, B.: CIM - Informations- und Kommunikationssysteme. München, Wien 1990

[Schü98] Schütte, R.: Referenzmodellierung: Anforderungen der Praxis und methodische Konzepte. In Maicher, M.; Scheruhn, H. (Hrsg.): Informationsmodellierung. Wiesbaden (1998), 63- 84.

[Schw97] Schwarze, J.: Einführung in die Wirtschaftsinformatik. Herne, Berlin 1997

[Stah97] Stahlknecht, P.; Hasenkamp, U.: Einführung in die Wirtschaftsinformatik. Berlin, Heidelberg, New York 1997

[Töpf91] Töpfer, A.: Technologie- Marketing In: Töpfer, A.; Sommerlatte, T.: Technologie- Marketing. Landsberg/ Lech (1991) 163- 200.

[Vers98] Versteegen, G.: Kleiner Bruder In iX 6/ 98 S. 88- 90.

[Zent92] Zentes, J.: Grundbegriffe des Marketing. Stuttgart 1992