Information Engineering: Wirtschaftsinformatik im Schnittpunkt von Wirtschafts-, Sozial- und Ingenieurwissenschaften [Reprint 2018 ed.] 9783486787047, 9783486230635

Citation preview

Information Engineering Wirtschaftsinformatik im Schnittpunkt von Wirtschafts-, Sozialund Ingenieurwissenschaften

Herausgegeben von

Dr. Heidi Heilmann Universitätsprofessorin für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Stuttgart und

Dr. Lutz J. Heinrich o. Universitätsprofessor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Linz und

Dr. Friedrich Roithmayr o. Universitätsprofessor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Innsbruck

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Information Engineering : Wirtschaftsinformatik im Schnittpunkt von Wirtschafts-, Sozial- und Ingenieurwissenschaften / hrsg. von Heidi Heilmann München ; Wien : Oldenbourg, 1996 ISBN 3-486-23063-8 NE: Heilmann, Heidi [Hrsg.]

© 1996 R. Oldenbourg Verlag GmbH, München Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München

ISBN 3-486-23063-8

Information Engineering als Teildisziplin der Wirtschaftsinformatik Der wissenschaftliche Beitrag von Lutz J. Heinrich Lutz J. Heinrich ist der eigentliche Urheber dieses Sammelbandes. Auslöser war das Herannahen seines 60. Geburtstages im April 1996, ein Datum, das eine Ehrung in Form einer Festschrift nahelegte. Daß daraus keine Festschrift im üblichen Sinne geworden ist, geht wiederum auf Lutz J. Heinrich zurück: Er wünschte sich aus der Feder von Kollegen, Schülern und Weggefährten ein Werk, das wesentliche Aspekte des in der deutschsprachigen Literatur noch wenig gebräuchlichen Begriffes Information Engineering behandelt und damit entscheidend zum wissenschaftlichen Verständnis und Standort der Wirtschaftsinformatik beiträgt. Und schließlich hat er sich sogar bereitgefunden, als Mitherausgeber zu wirken und den einleitenden Beitrag „Information Engineering - eine Synopse" beizusteuern. Wie dort genauer nachgelesen werden kann, wurde der Begriff „Information Engineering" Anfang der 80er Jahre von C. Finkelstein und J. Martin in der englischsprachigen Wirtschaftsinformatik-Literatur eingeführt. Erstmals im deutschen Sprachraum übernommen haben ihn M. A. Curth und H. B. Wyss 1988 in ihrem relativ knappen und auf Finkelstein und Martin bezugnehmenden Buch „Information Engineering. Konzeption und praktische Anwendung". Alle in den darauf folgenden Jahren erschienenen, den Inhalt von „Information Engineering" präzisierenden und erweiternden Ausführungen stammen von Lutz J. Heinrich. Dies begann mit seiner Besprechung von J. Martins Büchern zum Information Engineering. Book I, Introduction (1989 bei Prentice Hall erschienen), hat Heinrich zeitgleich in den Heften 1/1990 der Zeitschriften „Information Management" und „Structured Programming" besprochen, in den Heften 4/1990 erschienen ebenfalls parallel Besprechungen von Book II, Planning & Analysis (1990). 1991 setzte sich Heinrich in Heft 3 der Zeitschrift Wirtschaftsinformatik unter der Rubrik „Das aktuelle Schlagwort" kritisch mit dem Begriff „Information Engineering" auseinander. Er erläuterte Sicht und Definition von J. Martin und leitete aus seiner eigenen Vorabdefinition von Information Engineering („Behandlung von Information mit ingenieurwissenschaftlichen Methoden") Präzisierung und Erweiterung ab. Kritik begründete er mit der zu starken Praxisorientierung von Martin, der zwar die zweckmäßige Verwendung von Methoden und Werkzeugen betrachte, die theoretischen Grundlagen der Methodenentwicklung aber eben so wenig wie die Neuentwicklung von Metho-

2

Vorwort

den, ihre Umsetzung in Werkzeuge und die Anwendung von Werkzeugen und Methoden untersuche, wesentliche wissenschaftliche Aspekte von Information Engineering also ausspare. Heinrich leitete bereits 1991 aus dieser Kritik seine eigene Definition ab: „Information Engineering (IE) ist eine Teildisziplin der Wirtschaftsinformatik, deren Erkenntnisobjekt die Methoden zur Gestaltung der Informationsinfrastruktur in Organisationen...ist. Sie erarbeitet die Grundlagen zur Erklärung der Aufgaben des Informationsmanagements und der Methoden zu ihrer Unterstützung..., paßt vorhandene Methoden an und entwickelt neue Methoden... und die zur Methodenanwendung erforderlichen Werkzeuge... Sie untersucht auch die Anwendung der Methoden und Werkzeuge in der Praxis, die durch einen ganzheitlichen, primär von 'oben nach unten' verlaufenden Ansatz gekennzeichnet ist, und setzt die Untersuchungsergebnisse zur Verbesserung der Methoden und Werkzeuge um". Diese im deutschsprachigen Raum erstmals dargestellte Sicht auf Information Engineering hat Heinrich in den Folgejahren in seinen im Verlag dieses Sammelbands erschienenen Lehrbüchern und Nachschlagewerken konsequent umgesetzt und mit Details gefüllt: • Insbesondere geschah dies im Rahmen seines Buches „Informationsmanagement", das (erstmals 1986 erschienen) 1995 in 5. Auflage auf den Markt gekommen ist und in einem über 200 Seiten umfassenden Kapitel „Methoden und Werkzeuge des Information Engineering" Grundlagen sowie strategisches, administratives und operatives Information Engineering ausführlich behandelt. • Ebenso wird Information Engineering im „Wirtschaftsinformatik-Lexikon" von Heinrich und Roithmayr (als erstes Wirtschaftsinformatik-Nachschlagewerk 1986 erschienen, inzwischen in der 5. Auflage von 1995 erhältlich), in den beiden Bänden von Heinrichs „Systemplanung" (erstmals 1975/6, inzwischen in 5. bzw. 6. Auflage 1994 erschienen) und in Lutz J. Heinrichs „Wirtschaftsinformatik - Einführung und Grundlegung" (1993) angesprochen. In diesen späteren Ausführungen würdigt Heinrich auch den Beitrag von Finkelstein zum Begriff des Information Engineering, u. a. dessen Unterscheidung zwischen der konventionellen, dv-getriebenen bottom up erfolgenden Vorgehensweise in der Praxis und dem unternehmensorientierten, geschäftsgetriebenen Top-down-Ansatz, den Finkelstein, Martin und Heinrich empfehlen. Nun wäre es erheblich zu kurz gegriffen, das wissenschaftliche Werk von Lutz J. Heinrich auf das Thema Information Engineering zu konzentrieren oder gar zu begrenzen. Seine als Allein-, Haupt- oder Mitautor veröffentlichten selbständigen Schriften umfassen einschließlich der oben schon genannten rund 20 Werke, angefangen von der Gestaltung des betrieblichen Berichtswesens und seinen damals weithin bekannten und genutzten Ausführungen zur Mittleren

Vorwort

3

Datentechnik in den 60er Jahren. Sein 1969 erschienenes Buch „Gemeinsame Computerbenutzung in der Industrie - Datenverarbeitung außer Haus" z.B. hat wesentliche Aspekte der späteren Outsourcing-Diskussion vorweggenommen. Seit Anfang der 60er Jahre hat Heinrich in der Summe über 100 Beiträge in Sammelwerken und Fachzeitschriften veröffentlicht, die gemeinsam ein sehr breites inhaltliches Spektrum der Wirtschaftsinformatik abdecken. Die Veröffentlichungen der beiden letzten Jahre 1994 und 1995 beispielsweise behandeln so unterschiedliche Fragen wie die „Leistungsbewertung von DatenbankServer-Systemen", „Diagnose der Informationsverarbeitung" und „Messen der Benutzerzufriedenheit - Instrument und Anwendungserfahrungen". Lutz J. Heinrich hat eine Reihe von Büchern herausgegeben und war über zusammengerechnet 30 Mannjahre hinweg Begründer und Mitherausgeber bekannter Fachzeitschriften: Angewandte Planung, Angewandte Informatik, Information Management, seit 1990 Wirtschaftsinformatik. Schließlich dürfen seine zahlreichen, über 70 Buchbesprechungen nicht unter den Tisch fallen, die im Gegensatz zu vielen anderen diesen Namen auch wirklich verdienen, weil sie „Prozeß und Ergebnis wissenschaftlichen Arbeitens überprüfen", die Dinge dabei sowohl positiv wie negativ unmißverständlich beim Namen nennen und so den Leser nachhaltig bei seiner Literaturauswahl unterstützen. Besonders hervorgehoben, nachdrücklich gefordert und selbst unternommen hat Heinrich in den letzten Jahren vor allem die empirische Forschung in Wirtschaftsinformatik und Information Engineering. Seine aktuellen Forschungsschwerpunkte sind neben Information und Kommunikation, Informations- und Kommunikationstechnologien in Wirtschaft und Verwaltung, Planung und Realisierung von Informatik-Projekten vor allem Information Engineering, Prozeß- und Workflow-Management sowie Management in Sozialen Organisationen. Diese umfassenden wissenschaftlichen Leistungen sind im Laufe eines Berufslebens entstanden, das 1955 mit dem Studium des Wirtschaftsingenieurwesens an der Technischen Universität Berlin begann, sich mit Promotion(1963) und Habilitation(1968) in Betriebswirtschaftslehre an der Universität Karlsruhe fortsetzte und in der Initiierung und Einrichtung des Stiftungslehrstuhls „Organisationstheorie und Datenverarbeitung" im Jahre 1970 an der Universität Karlsruhe einen ersten Höhepunkt erreichte. Im gleichen Jahr nahm Heinrich einen Ruf auf den Lehrstuhl für Betriebswirtschaftslehre der Universität Linz an. In den folgenden 25 Jahren hat er von dort aus die Entwicklung der Wirtschaftsinformatik als Wissenschaftsdisziplin und Studiengang im deutschsprachigen Raum maßgebend und nachhaltig beeinflußt. Er hat mehrere Rufe an andere Universitäten erhalten und abgelehnt, hat aber Gastprofessuren in Wien, Halle, Oxford/Großbritannien, Eugene/Oregon und Atlanta/Georgia übernommen. Er hat an der Universität Linz als Dekan der Sozial- und Wirtschafts-

4

Vorwort

wissenschaftlichen Fakultät gewirkt und zeitraubende, anspruchsvolle Aufgaben im Vorstand des Verbands der Hochschullehrer für Betriebswirtschaft e.V. und als Sprecher der Wissenschaftlichen Kommission Wirtschaftsinformatik dieses Verbandes erfolgreich wahrgenommen. Sein Einfluß auf die Entwicklung der Wirtschaftsinformatik insgesamt und an der Universität Linz wird spontan sichtbar, wenn man sich den Weg vom 1970 übernommenen „Lehrstuhl für Betriebswirtschaftslehre" in Linz zum heutigen Leiter des Lehr- und Forschungsschwerpunkts „Information Engineering" des Instituts für Wirtschaftsinformatik und -in Personalunion- zum wissenschaftlichen Leiter des Instituts für Personal- und Organisationsentwicklung in Wirtschaft und Verwaltung an der Universität Linz vor Augen führt. Dann wird auch bewußt, für wie viele Studierende, Diplomanden und Doktoranden, Lutz J. Heinrich in den letzten 35 Jahren Lehrer und Vorbild war, und in welchem Maße er als Berater und als gerichtlich beeideter Sachverständiger für Datenverarbeitung betriebliche Praxis und Rechtsprechung beeinflußt hat. Es ist bedauerlich, daß diese jahrzehntelange, breit angelegte Einflußnahme auf eine ganze wissenschaftliche Disziplin von der Praxisrelevanz und Dynamik der Wirtschaftsinformatik nur durch Zahl und Inhalt von Veröffentlichungen, Diplomen und Dissertationen, und -last not least- der Bereitschaft der Autoren dieses Sammelbandes, einen Beitrag zu leisten, gemessen werden kann. Offenbar besteht hier eine Methodenlücke, die es noch zu füllen gilt? Wer Lutz J. Heinrich als Lehrer oder Kollegen von seiner menschlichen Seite näher kennengelernt hat, war und ist immer wieder fasziniert von zwei Eigenschaftspaaren, die bei ihm durch eine unübliche Kombination ihrer Ausprägungen auffallen. Das ist zum einen die Verbindung von jungenhaftem Charme (der schon vor der Berufung nach Österreich sichtbar war, also nicht mit Anpassung an das Gastland erklärt werden kann) mit einem betont ungeduldigen Temperament, das angesichts der leider nie ganz vermeidbaren Pannen des Berufslebens auch vor sarkastischen Kommentaren nicht zurückschreckt. Zum anderen ist bewunderungswürdig die selten anzutreffene Kombination von Kreativität mit hoher Zuverlässigkeit, zwei Eigenschaften, die sicher eine wesentliche Voraussetzung für das sind, was Lutz J. Heinrich in den Jahrzehnten seiner wissenschaftlichen Arbeit angestrebt und erreicht hat. Und schließlich verdienen seine Schaffenskraft und sein Durchhaltevermögen eine besondere Hervorhebung: Sehr wenige Wissenschaftler haben so wie er grundlegende Werke zu einem in der Summe breiten Spektrum einer dynamischen Disziplin über Jahrzehnte hinweg immer wieder überarbeitet und in neuen, aktuellen Auflagen für Studierende, Kollegen und die Praxis bereitgestellt.

Vorwort

5

Zum aktuellen Anlaß seines 60. Geburtstages ist Lutz J. Heinrich von Herzen zu wünschen, daß er dies alles mit dem bisherigen Erfolg bei guter Gesundheit noch lange fortsetzen möge. Heidi Heilmann

Inhaltsverzeichnis Einleitung

9

Forschungskonzeptionen der Wirtschaftsinformatik Information Engineering - eine Synopse LutzJ. Heinrich

17

Zur Entwicklung der Forschungsmethoden und Theoriekerne der Wirtschaftsinformatik. Eine kombinierte Delphi- und AHP-Untersuchung Wolfgang König, Armin Heinzl, Marcus-Julian Rumpf, Ansgar von Poblotzki

35

Gedanken zur theoretischen Fundierung der Wirtschaftsinformatik und Versuch einer paradigmatischen Einordnung Franz Lehner

67

Was soll ein diplomierter Softwaretechniker können? Gustav Pomberger

87

Ansätze zu einer Methodik des Know-how-Engineering. Eine inhaltliche Auseinandersetzung - aber auch ein Beitrag zu einer wissenschafts theoretischen Diskussion für die Positionierung der Wirtschaftsinformatik Friedrich Roithmayr

101

Ansätze zur fachlichen Modellierung betrieblicher Informationssysteme - Entwicklung, aktueller Stand und Trends Elmar J. Sinz

123

Integration in der Wirtschaftsinformatik Die Integration der Aufbauorganisation in Workflow-Management-Systeme Heidi Heilmann 147 Integration Engineering: Konkurrenz oder Komplement zum Information Engineering? - Methodische Ansätze zur Integration von Informationssystemen Karl Kurbel, Claus Rautenstrauch

167

Integriertes Dokumenten- und Workflow-Management im Angebotsprozeß eines Maschinenbauunternehmens Peter Mertens, Stefan Morschheuser, Heinz Rauf er 193

8

Inhaltsverzeichnis

Business Engineering: Geschäftsstrategie, Prozeß und Informationssystem Hubert Österle

215

Architekturen für das Information Engineering August-Wilhelm Scheer

235

Facetten des Information Engineering Zur Frage der Angemessenheit des Ressourceneinsatzes für Forschung und Lehre (FuL) in Hochschulkliniken Gunar Baugut 263 Architektur regionaler Netzwerke in Rural Areas - Von Electronic Mail zu Electronic Mall? Manfred Pils

285

Reverse Engineering in der Datenmodellierung Thomas Prückler, Michael Schrefl

311

Strategisches Information Engineering mit einem Group Support System (GSS) Dietrich Splettstößer

331

Auf der Suche nach Metriken für das Information Engineering Heinz G. Schwärtzel, Rupert Fischer

353

Entity-Relationship-Modell und NR/T-Netze. Ein integrierter Ansatz zur Daten- und Ablaufmodellierung Wolffried Stucky, Peter Jaeschke, Andreas Oberweis

369

Umfassendes Qualitätsmanagement für das Information Engineering Ernest Wallmüller

397

Gestaltungsmöglichkeiten von kybernetischen Planungs- und Kontrollverfahren Eckart Zwicker

417

Schlagwortverzeichnis

431

Autorenverzeichnis

435

Einleitung Neunundzwanzig Autoren aus Wissenschaft und Praxis beleuchten erstmals in einem deutschsprachigen Sammelband in neunzehn Beiträgen das Jnformation Engineering" aus unterschiedlicher Sicht. Der Entwicklungsstand des Gebietes macht eine Gliederung der Beiträge in drei Cluster sinnvoll. • Forschungskonzeptionen der Wirtschaftsinformatik (Heinrich, König et al., Lehner, Pomberger, Roithmayr, Sinz). In diesem Cluster werden primär Beiträge mit wissenschaftstheoretischer Orientierung behandelt. • Integration in der Wirtschaftsinformatik al., Österle, Scheer).

(Heilmann, Kurbel et al., Mertens et

• Facetten des Information Engineering (Baugut, Pils, Schrefl Splettstößer, Schwärtzel et al., Stucky et al., Wallmüller, Zwicker).

et

al.,

Der erste Beitrag im Cluster Forschungskonzeptionen der Wirtschaftsinformatik - von Heinrich verfaßt - gibt eine Synopse über das Information Engineering, die er an Hand von Schriften oder Stellen über diesen Gegenstand „zusammengestellt" hat. Nach einem istanalytischen Ansatz leitet er zum Information Engineering als Wissenschaft über. Dabei verläßt er den Ansatz von Finkelstein und Martin, indem er die Einschränkung auf eine Methodik zur Lösung einer bestimmten Aufgabe um die Entwicklung und Anwendung von Methoden erweitert. Mit einem empirisch orientierten Forschungsansatz der Wirtschaftsinformatik versuchen König, Heinzl, Rumpf und von Poblotzki in ihrem Beitrag, Forschungsmethoden und Theoriekerne der Wirtschaftsinformatik zu orten. Im Mittelpunkt der Untersuchung steht die Frage, welche Forschungsgegenstände, Forschungsmethoden und Theoriekerne die Wirtschaftsinformatik in den nächsten 10 Jahren bearbeiten bzw. verwenden soll, um ihre Wettbewerbsposition gegenüber der Betriebswirtschaftslehre und der Informatik behaupten zu können. Lehners forschungskonzeptioneller Beitrag liegt darin, daß er ausgehend von Überlegungen zur theoretischen Fundierung der Wirtschaftsinformatik den Versuch einer paradigmatischen Einordnung unternimmt. Beginnend bei den Defiziten in der Theoriebildung der Wirtschaftsinformatik spannt er einen Bogen über die paradigmatische Ausrichtung hin zu einer Forschungsmethodik der Wirtschaftsinformatik. Wenngleich der Beitrag von Pomberger explizit nicht diesem Cluster zuzuordnen wäre, erfolgt dennoch eine Zuordnung, da Ausbildungsfragen in hohem Ausmaß durch forschungskonzeptionelle Fragestellungen mitbeeinflußt werden.

10

Einleitung

Pomberger greift in seinem Beitrag, ausgehend von der wirtschaftlichen Bedeutung der Software, die Thematik der Softwarekonstruktion auf. Im Mittelpunkt steht dabei die Frage nach dem Ausbildungsprogramm eines Softwaretechnikers. Begriffe wie Teamarbeit, Theorie, soziale und organisatorische Kompetenz sowie Projektarbeit kennzeichnen seinen Ausbildungsansatz. Daraus leitet er für die Ausbildung im Kernbereich Programmierparadigmen, Vorgehensmodelle, Gestaltungsprinzipien für Benutzerschnittstellen, Verteilungs- und Parallelitätsaspekte, Produktivitäts- und Qualitätssteigerungstechniken sowie Dokumentationsanforderungen ab. Roithmayr greift in seinem Beitrag das bislang in der Wirtschaftsinformatik nicht beleuchtete Thema des „Know-how-Engineering" auf. Ausgehend von einer forschungskonzeptionellen Positionierung (Begriffslehre) des Know-how leitet er methodische Ansätze ab. Er sieht eine enge Bindung zwischen Knowhow und virtuellen Organisationen. Neben einer inhaltlichen Diskussion geht es ihm vor allem darum, das Gebiet des Know-how-Engineering in der Wirtschaftsinformatik zu thematisieren. Der Beitrag mündet in dem Postulat, verstärkt verhaltensorientierte Aspekte in Engineeringprozesse einmünden zu lassen - also eine Paradigmenänderung. Schnittstellen finden sich zum Beitrag von Scheer, der Architekturen für das Information Engineering fordert, die nicht an einem einzigen Paradigma, wie z. B. der Prozeßorientierung, ausgerichtet sind, sondern bezüglich neuer Ansätze sowohl auf der betriebswirtschaftlichen Seite als auch der informationstechnischen Seite offen sind. Untersuchungsgegenstand der Wirtschaftsinformatik ist für Sinz das betriebliche Informationssystem im Sinne des informationsverarbeitenden Teilsystems einer Organisation. Generelles Untersuchungsziel ist die Analyse und Gestaltung betrieblicher Informationssysteme primär auf der Aufgabenebene und der Aufgabenträgerebene. Der zentrale methodische Gedanke liegt für ihn in der Modellierung betrieblicher Informationssysteme. Im Beitrag werden Ansätze zur fachlichen Modellierung der Aufgabenebene betrieblicher Informationssysteme unter dem Blickwinkel einer evolutionären Entwicklung analysiert. Integration gehört zu den zentralen Forschungsgegenständen der Wirtschaftsinformatik. Dementsprechend sind auch eine Fülle von Beiträgen diesem Cluster gewidmet. Die ganzheitliche, weitgehende Integration anstrebende Sicht auf Workflow Management muß die flexible Einbindung aufbauorganisatorischer Festlegungen und Regeln beinhalten. Heilmann modelliert am Beispiel eines Projekts, das am Softwarelabor der Universität Stuttgart läuft, ein Workflow-ManagementTool, das alternative Übernahme- und Anpassungsmöglichkeiten für die Anwender dieses Tools eröffnet. Die ganzheitliche Sicht, die unter anderem durch den Einsatz dieses Tools nicht nur für das Workflow-Management,

Einleitung

11

sondern auch für Revisionsaufgaben und Controllingaufgaben gegeben ist, wird vor allem durch die Entwicklung der Integrationsdimensionen (WorkflowManagement-Zyklus, Workflow-Management-Reichweite, Ressourcenintegration) erreicht. Auch der Beitrag von Kurbel und Rautenstrauch liegt im Kern dieses Clusters. Ausgehend von den Aussagen bei Mertens, daß das Erfinden neuer „Engineering"-Disziplinen heute eine Modeerscheinung in der Wirtschaftsinformatik ist, versuchen die Autoren zunächst eine Einordnung des Integration Engineering. Kernbegriffe dieser Einordnungsdiskussion sind Integration, Unternehmensdatenmodell, Geschäftsprozeß und Reengineering. Darauf aufbauend entwickeln sie Konzepte zum Aufbau integrationsfähiger Anwendungssysteme, in deren Mittelpunkt die Client-Server-Architektur steht. Schwerpunkt des Beitrags ist die Funktions- und Datenintegration, dargestellt an den eben angesprochenen Client-Server-Architekturen, sowie die Integration von (Daten-)Modellen aus der Anwendungssicht. Mit der Anwendungssystemintegration und der Modellintegration behandeln die Autoren zwei wichtige Objekte des Integration Engineering. Mertens, Morschheuser und Raufer stellen Dokumente stärker als alle anderen formatierten Datenbestände als Know-how-Träger im Industrieunternehmen dar. Was das Know-how betrifft ist eine Schnittstelle zum Beitrag von Roithmayr. gegeben, während in bezug auf Workflow interessante Synergien zum Beitrag von Heilmann, feststellbar sind. Die Autoren versuchen, der in der Fachliteratur vorherrschenden Formal- und Werkzeugorientierung zum Thema Dokumenten-Management-Systeme und Workflow-Management-Systeme dahingehend zu begegnen, daß sie an einem komplexen Praxisbeispiel die Möglichkeiten der Integration von Dokumenten- und Workflowmanagement verdeutlichen. Österle geht in seinem Beitrag vom Managementkonzept des Business Process Reengineering (Business Engineering) aus. Die Transformation der Industrie- in die Informationsgesellschaft betrifft nicht nur Prozesse im Sinne organisatorischer Abläufe, sondern auch die strategische Ausrichtung wie etwa Kundensegmentierung und die Marktleistungen, vor allem aber die Organisationsstruktur der Mitarbeiter. Das ingenieurmäßige Vorgehen auf Basis einer pragmatischen Methode gilt heute als Grundvoraussetzung für eine erfolgreiche Neugestaltung des Geschäfts und seiner Prozesse. Mit Hilfe des P R O M E T - A n satzes wird der Transformationsprozeß von der Industriegesellschaft zur Informationsgesellschaft unterstützt, eine Verbindung von Strategie, Prozeß und Informationssystem hergestellt, die Prozesse auf den Kundennutzen ausgerichtet, das Qualitätsmanagement unterstützt und die ergebnisorientierte Projektführung gewährleistet.

12

Einleitung

Theoretiker und Praktiker versuchen seit langem, Regelwerke für die Gestaltung von Informationssystemen zu verwenden. Scheer stellt den Architekturbegriff ins Zentrum seiner Überlegungen. Für die Lösung komplexer Probleme muß eine Architektur Methoden zur Verfügung stellen, die unterschiedliche Sichtweisen auf das Problem ermöglichen und Regeln definieren, die zur Zerlegung von Problemzusammenhängen und zur anschließenden Synthese von funktionsfähigen Gesamtlösungen dienen. Pläne, die aufzeigen, wie diese Zerlegungs- und Syntheseprozesse ablaufen, stellen einen Beitrag zur Qualitätssicherung der Ergebnisse dar. Am Beispiel der ARIS-Architektur zeigt der Autor die Zuordnung von Geschäftsprozessen zu den benötigten Informationstechnologien. Architekturen für das Information Engineering dürfen aber nicht an einem einzigen Paradigma, wie z. B. der Prozeßorientierung ausgerichtet sein, sondern müssen bezüglich neuer Ansätze sowohl auf der betriebswirtschaftlichen (vgl. Beitrag von Roithmayr) als auch auf der informationstechnischen Seite offen sein. Die Diskussion und die Beiträge im forschungskonzeptionellen Cluster zeigen den unterschiedlichen Entwicklungsstand von Information Engineering. Im dritten Cluster werden Facetten des Information Engineering behandelt. Ausgangspunkt für Baugut ist der Umstand, daß an Universitäten, die über eine medizinische Fakultät verfügen, etwa 50% der Mittel durch die Fakultät Medizin gebunden sind. Diese Konkurrenzsituation einerseits zwischen den Fakultäten, andererseits innerhalb der Fakultät in der Lehre und Forschung mit der stationären und ambulanten Krankenversorgung führt zu einem Begründungszwang. Der Autor entwickelt einen Evaluierungsansatz. Pils geht es in seinem Beitrag um die besonderen Aspekte der Planung und Implementierung von Netzwerken in „rural areas" (regionale Netzwerke). Eine interessante Themenstellung, die durchaus in Zusammenhang mit dem Denken in Regionen der EU gebracht werden kann. Wesentliche Erfolgsfaktoren liegen in der Verbesserung der bislang unbefriedigenden Telekommunikations-Infrastruktur, der Liberalisierung des Infrastrukturangebotes sowie einem geeigneten Regionalmanagement. Schrefl und Priickler stellen in ihrem Beitrag, nach einer kurzen Einführung in das Relationenmodell sowie das objektorientierte Datenmodell, einige Methoden zum Reverse Engineering von Datenaltlasten in ein objektorientiertes Datenbankschema vor und zeigen anhand eines Beispiels aus der betrieblichen Praxis die einzelnen Phasen des Reengineeringvorgangs. Group-Support-Systeme (GSS) haben sich in den letzten Jahren zu einem Forschungsschwerpunkt in der Wirtschaftsinformatik entwickelt. Splettstößer

Einleitung

13

gibt in seinem Beitrag neben einer Begriffsdiskussion eine Darstellung über Eigenschaften und Anwendungen eines GSS. Schwärtzel und Fischer gehen von der Erfahrung aus, daß allgemein akzeptierte Definitionen für das Gut „Information" nicht ausreichend verfügbar sind. Als Themen und Gebiete für Metriken sehen sie Durchdringungs- bzw. Verbreitungsgrad, Anteil an der Produktion/Dienstleistung, Grad der Vernetzung und Sichtbarkeit von Informationen, Benutzungskompetenz, Zugriffshäufigkeit auf Informationen, Bindung von Kapital in Informationstechnik, Aufwand für Informationstechnik sowie spezifische Kosten und spezifischer Ressourcenverbrauch. Stucky, Jaeschke und, Oberweis gehen in ihrem Beitrag ein generelles Problem bei der Entwicklung von Informationssystemen, nämlich die Beschreibung komplexer Objektstrukturen - z. B. von Dokumenten - und deren Berücksichtigung bei der Ablaufmodellierung an. Eine neuartige Variante höherer PetriNetze, die sogenannten NF^-Relationen/Transitionen-Netze, erlaubt die Modellierung von Abläufen unter Verwendung komplex strukturierter Objekte. Im Bereich der Datenmodellierung sind Entity-Relationship-Modelle ein gängiger Ansatz. Der Beitrag stellt eine Möglichkeit vor, beide Ansätze zur Modellierung von Daten und Abläufen in einem Unternehmen zu integrieren. Die komplex strukturierten Objekte der Ablaufschemata werden als Sichten auf ein globales Entity-Relationship-Schema definiert. Ausgehend von Beispielen versucht Wallmüller in seinem Beitrag Ursachenklassen von Problemen in der rechnergestützten Informationsverarbeitung aufzuzeigen. Es wird ein Lösungsansatz diskutiert, der auf drei Ebenen wirkt. Auf der operativen Ebene stehen die Prozesse und ihre Beherrschung im Zentrum der Betrachtung. Der Prozeßkontext wird auf strategischer Ebene durch Rahmenbedingungen für das Management, die Mitarbeiter und Technologien gestaltet. Auf der normativen Ebene werden Qualitätsaspekte durch eine Visionsbildung und deren Umsetzung in Form einer Politik und Zielen festgelegt. Zwicker setzt sich in seinem Beitrag kritisch mit der Auffassung auseinander, daß die Planung und die Kontrolle von Unternehmen nur in Form kybernetischer Planungs- und Kontrollsysteme realisiert werden soll. Er erläutert zunächst die Begriffe kybernetisches Planungs- und Kontrollsystem, beschreibt dann den Aufbau kybernetischer Planungs- und Kontrollsysteme, um schließlich eine Logik für die Planung und Kontrolle von Unternehmen zu beschreiben, die auf der Grundlage von Zielverpflichtungen beruht. Diese Planungsund Kontrollogik wird mit dem Konzept der kybernetischen Planung und Kontrolle verglichen.

14

Einleitung

Schließlich möchte ich an dieser Stelle meiner Sekretärin, Frau Manuela Fink, danken, die in besonders mühevoller Kleinarbeit alle Beiträge bearbeitet und für das optische Gelingen des Bandes einen nicht unwesentlichen Anteil geleistet hat. Friedrich Roithmayr

Forschungskonzeptionen der Wirtschaftsinformatik

Information Engineering - eine Synopse Lutz J. Heinrich Institut für Wirtschaftsinformatik, Universität Linz

1

Vorbemerkung

2

Zum Begriff Informatin Engineering

3

Publikationen zu Information Engineering 3.1 Information Engineering nach C. Finkelstein 3.2 Information Engineering nach J. Martin 3.3 Information Engineering bei anderen Autoren 3.4

4

Kommentierung der Befunde

Information Engineering als Wissenschaft

Literatur

18

1

Lutz J• Heinrich

Vorbemerkung

Synopse - auch Synopsis - meint im fachsprachlichen Sinn die "Zusammenstellung von Schriften oder Stellen über den gleichen Gegenstand" [BroWa], Gegenstand dieser Synopse ist Information Engineering (kurz: IE), und es werden daher "Schriften oder Stellen" (von Schriften) über diesen Gegenstand "zusammengestellt". Von der Zusammenstellung ausgehend wird danach gefragt, welche Bedeutung Information Engineering im Sprachgebrauch der Wirtschaftsinformatik hat, und welche ihm für die Zukunft zukommt bzw. zukommen kann oder zukommen sollte. Angesichts der Verbreitung, welche die Bezeichnung Engineering in der Wirtschaftsinformatik in jüngster Zeit gefunden hat, ist anzunehmen, daß es sich dabei nicht nur um eine der vielen Moden, sondern um einen Trend handelt [Mert95]. Jüngstes Beispiel für die Verbreitung ist [Öst95], der die bisher übliche Bezeichnung „Business Process Reengineering" zu „Business Engineering" verkürzt und darunter „die Neugestaltung der informatisierten Wirtschaft" [Öst 95,13] versteht, ohne dies näher zu erläutern und insbesondere ohne auf „Engineering" Bezug zu nehmen. Die Weiterführung der Synopse über eine "Zusammenstellung" hinaus endet im Ergebnis damit, eine inhaltliche Interpretation für Information Engineering zu geben, die über den üblichen, primär auf die Praxis der Wirtschaftsinformatik ausgerichteten Sprachgebrauch hinausgeht und dazu führt, Information Engineering als Bezeichnung für ein Teilgebiet der Wirtschaftsinformatik als Wissenschaft brauchbar zu machen. Diese Interpretation befindet sich in gewisser Übereinstimmung mit der, die implizit oder sogar explizit von den Autoren dieses Bandes verwendet wird. Auf dem Weg zu dieser Interpretation hin wird zunächst auf den Begriff "Information Engineering" so eingegangen, wie er von C. Finkelstein und J. Martin geprägt wurde, die ihn - soweit erkennbar - erstmals verwendet und die ihn verbreitet haben (Kapitel 2). Anschließend wird eine inhaltliche Beschreibung von Information Engineering auf Grund der "Schriften oder Stellen" (von Schriften) gegeben, wobei die wenigen einschlägigen Hauptquellen im Vordergrund stehen (Kapitel 3). Schließlich wird die angekündigte Interpretation gegeben (Kapitel 4). Trotz aller Zurückhaltung gegenüber der unreflektierten Verwendung von Anglizismen im Deutschen, die sich auch in der Fachsprache der Wirtschaftsinformatik [HeRo95] ausgebreitet haben, fällt es schwer, eine Übersetzung von Information Engineering mit gleicher oder ähnlicher Griffigkeit zu finden. Information bedarf keiner Übersetzung, wenn auch häufig einer Klärung oder Erklärung [Hein95a], und Engineering bedeutet - für sich betrachtet - Ingenieurwissenschaft oder Ingenieurwesen. Viele zusammengesetzte Begriffe wie Administrative Engineering (Verwaltungstechnik), Civil Engineering (Tiefbau), Electrical Engineering (Elektrotechnik), Mechanical Engineering (Maschinen-

Information

Engineering-

eine

Synopse

19

bau), Process Engineering (Verfahrenstechnik) und Industrial Engineering (mit der eingeführten Abkürzung IE und wohl am treffendsten übersetzt mit Wirtschaftsingenieurwesen) lassen einen Bedeutungsgehalt erkennen, der bestimmte 7ec/zm'£disziplinen im Zusammenhang mit Information anspricht. In analoger Weise Information Engineering mit Informationstechnik gleichzusetzen, wäre ganz unpassend; der Begriff ist im Deutschen anders besetzt. Dem Sinngehalt nahe kommt - in Anlehnung an die Gleichsetzung von Industrial Engineering und Wirtschaftsingenieurwesen Informationsingenieurwesen, eine im Deutschen (bisher) ungebräuchliche und nur wenig griffige Bezeichnung. Wir akzeptieren daher Information Engineering zunächst als Bezeichnung für ein Phänomen, das nachfolgend begrifflich erklärt und mit Inhalt ausgefüllt wird. Aus dem bisher Gesagten folgt, daß es um Information geht, und daß bei ihrer "Behandlung" ingenieurwissenschaftliche Methoden eine bedeutsame Rolle spielen. Was "Behandlung" meint und was "ingenieurwissenschaftlich" ist, soll im folgenden herausgearbeitet werden.

2

Zum Begriff Information Engineering

Der Begriff Information Engineering wurde unseres Wissens erstmals von C. Finkelstein, nach anderer Ansicht erstmals von J. Martin verwendet. Ersterer verweist auf "initial concepts of Information Engineering", die 1972 entwickelt und im Zeitraum zwischen 1976 und 1981 verfeinert wurden [Fink92,VIII]. Beide treten am Ende dieses Zeitraums mit einer gemeinsamen einschlägigen Publikation als Autoren in Erscheinung [MaFi81]. Seither, so führt C. Finkelstein weiter aus, wird Information Engineering verwendet, "to design and to build information systems that reflect the business needs of organizations more effectively than other techniques such as Business Systems Planning (BSP) or software engineering." Diese einführende Bemerkung läßt bereits die Zielrichtung und die Schwerpunkte erkennen: Es geht im Ergebnis um die Schaffung von Informationssystemen, die den Anforderungen der Geschäftsprozesse entsprechen, was durch eine stark methodenorientierte Vorgehensweise erreicht werden soll. Es wird behauptet, daß diese Aufgabe durch Information Engineering besser als durch andere Methoden erreicht wird (wir übersetzen "technique" hier und im folgenden mit "Methode" und schließen darin "Technik" im deutschsprachigen Sinn ein). Zwischen den Auffassungen von C. Finkelstein und J. Martin darüber, was Information Engineering ist, bestehen keine grundlegenden Unterschiede. Nach [Mart89,1 ] ist Information Engineering wie folgt definiert: "The application of an interlocking set of formal techniques for the planning, analysis, design, and construction of information systems, applied on an enterprise-wide basis or across a major sector of an enterprise." Die Merkmale dieser Definition sind:

20

Lutz J.

Heinrich

• Es handelt sich um formale Methoden. • Die Methoden bauen aufeinander auf und sind voneinander abhängig. • Die Methoden werden unternehmensweit (oder in wesentlichen Unternehmensbereichen) angewendet. • Gestaltungsobjekt der Methoden sind Informationssysteme. • Die Methoden unterstützen Planung, Analyse, Entwurf und Realisierung von Informationssystemen. In der (in der Regel) unternehmensweiten Anwendung der Methoden wird der Hauptunterschied zum Software Engineering gesehen, das durch die primär projektbezogene Methodenanwendung gekennzeichnet sei. Die Methoden des Information Engineering schließen die Methoden des Software Engineering ein, teilweise werden sie modifiziert und angepaßt. So wie Software Engineering in unterschiedlichen Unternehmen (sogar in unterschiedlichen Projekten) verschieden praktiziert wird, gibt es verschiedene Varianten von Information Engineering. Information Engineering ist daher "no rigid methodology", sondern "a generic class of methodologies" [Mart89,l]. Damit wird explizit zum Ausdruck gebracht, was aus der Definition bereits erkennbar war (insbesondere aus den Worten "interlocking set of formal techniques"), nämlich daß Information Engineering mehr ist als nur eine Menge von Methoden, sondern daß die Methoden so ausgewählt sind und so angeordnet werden, daß Information Engineering eine Anweisung zur folgerichtigen und zweckmäßigen Lösung der Aufgabe "Planung, Analyse, Entwurf und Realisierung von Informationssystemen" ist, mit anderen Worten: daß Information Engineering eine Methodologie oder - im Deutschen vermutlich treffender eine Methodik ist. "Methodik" schließt Vorgehensweisen, Modelle und Methoden ebenso ein wie Werkzeuge, mit denen die Methodenanwendung unterstützt oder erst ermöglicht wird. Unter Bezugnahme auf Werkzeuge (die als "automated techniques" bezeichnet werden) wird Information Engineering von [Mart89,l] wie folgt definiert: "An interlocking set of automated techniques in which enterprise models, data models, and process models are built up in a comprehensive knowledge base and are used to create and maintain data processing systems." Die in dieser Definition genannten Merkmale können durch die folgenden Eigenschaften präzisiert werden [Mart89,2]: • Information Engineering fördert den Top-down-Ansatz, der folgende Phasen durchläuft: Unternehmensweite strategische Informationsplanung, unternehmensweite Informationssystem-Planung, Analyse von Geschäftsbereichen, Informationssystem-Entwurf, Informationssystem-Realisierung und Informationssystem-Einführung.

Information

Engineering-

eine

Synopse

21

• Information Engineering unterstützt den Aufbau eines sich laufend weiter entwickelnden Bestands an Wissen über das Unternehmen, seine Datenmodelle, Prozeßmodelle und Informationssystem-Entwürfe. • Information Engineering ermöglicht die Entwicklung eines unternehmensweiten Gesamtkonzepts für das (so wörtlich) "computerisierte Unternehmen". • Information Engineering ermöglicht es, einzeln geschaffene Informationssysteme in das Gesamtkonzept einzufügen, innerhalb dessen sie unter Verwendung von Werkzeugen schnell weiterentwickelt und verändert werden können. • Information Engineering bezieht die Benutzer in jede der oben genannten Phasen ein. • Information Engineering unterstützt die langfristige Evolution der Informationssysteme. • Information Engineering hilft festzustellen, wie die Erreichung der strategischen Unternehmensziele durch IuK-Technologien unterstützt werden kann. Ohne Quellenangabe weist J. Martin darauf hin, wie Information Engineering "manchmal auch beschrieben" wird, nämlich als [Mart89,l] "An organizationwide set of automated disciplines for getting the right information to the right people at the right time." Diese - u.E. sehr treffende, wenn auch sehr abstrakte Erklärung wird von ihm nicht weiter kommentiert. Sie erinnert an die in der Logistik üblichen Erklärungen und ist daher geeignet, eine inhaltliche Verwandtschaft zwischen Information Engineering und Logistik anzudeuten, die zur Bezeichnung Informationslogistik führt. In [HeRo95] wird dafür folgende Erklärung angeboten: "Zusammenfassende Bezeichnung für alle logistischen Aufgaben, deren Zweck die raum-zeitliche Transformation von Information innerhalb eines Unternehmens (innerbetriebliche Informationslogistik) und zwischen mehreren Unternehmen (zwischenbetriebliche Informationslogistik) ist ('Die richtige Information in der richtigen Menge zum richtigen Zeitpunkt beim richtigen Benutzer.') " Da dieser Begriff in der Wirtschaftsinformatik nur selten verwendet wird, soll er zur weiteren Erklärung von Information Engineering nicht herangezogen werden. C. Finkelstein definiert wie folgt [Fink92,ll]: "Information Engineering is an integrated set of techniques, based on corporate strategic planning, which results in the analysis, design and development of systems which supports those plans exactly. Information Engineering is applied by managers and users with no knowledge of computers, but instead with an expert knowledge of their business - in conjunction with expert systems which provide rapid feedback to management for refinement of the strategic plans." Er betont den personalen Aspekt von Information Engineering, wenn er feststellt [Fink92,ll]: "The availability of managers and users with an expert knowledge of their business ...

22

Lutz J.

Heinrich

is an essential requirement." Von Managern und von Benutzern einerseits und von professionellen Entwicklern andererseits wird ausdrücklich Partnerschaft als Voraussetzung für erfolgreiches Information Engineering gefordert. Ein wesentliches Merkmal dieser Definition ist, daß Information Engineering auf der strategischen Unternehmensplanung basiert; nur deren Ergebnisse können zu einem Bedarf an neuen oder wesentlich veränderten Informationssystemen führen. Da in der Praxis auch Vorgehensweisen als Information Engineering bezeichnet werden, die "von unten nach oben" verlaufen, wird zwischen zwei grundsätzlich unterschiedlichen Ansätzen unterschieden. C. Finkelstein nennt den Ansatz der Praxis konventionelles oder dv-getriebenes Information Engineering [Fink92,13], Konventionelles Information Engineering geht von den bestehenden Funktionen oder Prozessen aus. "Modernes" Information Engineering ist unternehmensorientiertes, geschäftsgetriebenes Information Engineering (im Original als DP-driven bzw. business-driven bezeichnet). Es geht von den strategischen Unternehmenszielen aus und schreitet "von oben nach unten" fort, bis es bei den Funktionen und Prozessen angelangt ist, die implementiert werden bzw. sind. Mit anderen Worten: Modernes Information Engineering folgt dem Top-down-Ansatz, nicht dem Bottom-up- Ansatz. Wenn dazu aufgefordert würde, die zahlreichen Merkmale, über die bisher berichtet wurde, auf drei charakteristische Merkmale zu reduzieren, so sind dies u.E. die folgenden: Top-down-Ansatz, formale Methoden und Partnerschaft. Diese Feststellung ist für die Beurteilung anderer einschlägiger Publikationen, auf die im folgenden eingegangen wird, hilfreich.

3

Publikationen zu Information Engineering

Eines der Ziele dieses Beitrags ist es, Aussagen darüber zu machen, ob und wie die Bezeichnung Information Engineering in der Wirtschaftsinformatik verwendet wird, und mit welcher begrifflichen Erklärung dies erfolgt. Die Literaturrecherche konnte sich daher auf die deutschsprachige Literatur beschränken. Die "Klassiker" des Information Engineering konnten als bekannt vorausgesetzt werden (gemeint sind die Publikationen von C. Finkelstein und J. Martin). Die Vorgehensweise bei der Literaturrecherche kann mit folgenden Aktivitäten beschrieben werden: • Suche im Online-Katalog der Linzer Universitätsbibliothek und Österreichweit im Verbundsystem der Bibliotheken mit den Stichwörtern "Information Engineering" und "IE". • Suche in Inhaltsverzeichnissen, Literaturverzeichnissen und Schlagwortverzeichnissen aller Bücher zu den Themenbereichen Entwicklung von Informa-

Information

Engineering-

eine

Synopse

23

tionssystemen, Systemanalyse, Systemplanung, Software Engineering, Datenmodellierung, Informationsmanagement und ähnlichen Bezeichnungen im Bücherbestand der Linzer Universitätsbibliothek und der Fachbibliotheken Wirtschaftsinformatik und Informatik mit den Stichwörtern "Information Engineering" und "IE". • Suche in Fachzeitschriften nach einschlägig bezeichneten Beiträgen und in den Literaturverzeichnissen der Beiträge sowie in den Buchbesprechungen mit den genannten Themenbereichen mit den Stichwörtern "Information Engineering" und "IE" (Jahrgänge 1985 bis 1994). • Suche in Lexika der Datenverarbeitung, Informatik und Wirtschaftsinformatik nach den Einträgen "Information Engineering" und "IE". Das Ergebnis der Literaturrecherche ist insgesamt gesehen bescheiden. Es wurden nur wenige einschlägige deutschsprachige Publikationen (selbständige Schriften und Artikel in Fachzeitschriften und Sammelwerken) gefunden. Soweit in Inhaltsverzeichnissen (kaum) und in Schlagwortverzeichnissen (selten) die beiden Bezeichnungen oder eine davon verwendet werden bzw. wird, wird meist keine begriffliche Erklärung gegeben. Sogar Lexika der Wirtschaftsinformatik weisen keinen einschlägigen Eintrag auf (z.B. [Mert90], im Unterschied dazu [HeRo95], [Comp91]). Die geringe Verbreitung der Bezeichnung Information Engineering und die noch seltenere explizite Definition machen es zweckmäßig, die von C. Finkelstein und J. Martin angebotenen Inhalte anzugeben, was nur in sehr geraffter Form geschehen kann. "Zweckmäßig" deshalb, weil die Annahme realistisch ist, daß die gleichen oder zumindest im wesentlich gleichen Inhalte in der Literatur der Wirtschaftsinformatik unter anderer Bezeichnung bzw. angesichts der noch wenig ausgereiften Fachsprache der Wirtschaftsinformatik [Hein93,68ff.] - unter mehreren anderen Bezeichnungen geführt werden. Wir verwenden dazu die Quellen [Fink92], [Mart89], [Mart90a] und [Mart90b], 3.1

Information Engineering nach C. Finkelstein

C. Finkelstein beschreibt nach einer Einführung ("Introduction to Strategie Systems Development") zunächst Information Engineering Concepts, worunter einige der bekannten Methoden der Datenmodellierung und Prozeßmodellierung verstanden werden (z.B. ER-Diagramme, Normalisierung, Datenflußdiagramme). Im Kapitel Information Engineering Projects wird dann ein Phasenmodell entwickelt und erläutert [Fink92,123], Es werden die Phasen Analysis, Design und Generation unterschieden, die in Abschnitte oder Stufen untergliedert sind. Es wird zwischen strategischer, taktischer und operativer Ebene unterschieden. Für die strategische Ebene wird ein Ansatz eingeführt, der die Verbindung zwischen strategischer Unternehmensplanung und Informa-

24

Lutz J.

Heinrich

tionssystem-Planung herstellt. Damit wird u.E. ein entscheidend kennzeichnendes Merkmal für Information Engineering ganz deutlich, nämlich die Herstellung einer Brücke oder einer Verbindung zwischen strategischer Unternehmensplanung und Informationssystem-Planung (typische Bezeichnungen dafür sind bridge or link bzw. bridging or linking information systems to business success). Konsequenterweise folgt eine ausführliche Behandlung der strategischen Unternehmensplanung, bevor auf die strategische Ebene des Phasenmodells zurückgekommen wird ("Developing a Strategie Model"). Ausgehend vom Ergebnis der strategischen Unternehmensplanung wird "a schematic blueprint of the information and data needed to manage the organization" [Fink92,285] entwickelt, also das, was wir heute Informationsmodell nennen. Aus dem Informationsmodell wird die Organization Structure abgeleitet, und es werden für jede Struktureinheit Teilmodelle bestimmt, von denen aus auf der Ebene des Tactical Modeling fortgesetzt wird. Anwendungen und Datenbasen werden auf der taktischen Ebene identifiziert. Strategie Modeling und Tactical Modeling sind also darauf ausgerichtet, den zukünftigen Informationsbedarf des Unternehmens als Ganzes zu bestimmen und in Datenmodellen abzubilden; für beide ist der Top-down-Ansatz charakteristisch. Im Unterschied dazu befaßt sich Operational Modeling mit den bestehenden Informationsbedarfen und mit Informationssystemen, die in irgendeiner Form vorhanden sind und genutzt werden. Der Top-down-Ansatz kann durch den Sideways-in-Ansatz oder den Bottom-upAnsatz ersetzt werden. Trotz dieser Alternativen beim Operational Modeling ist aus dem Gesagten der Primat des Top-down-Ansatzes ebenso klar erkennbar wie die Datenorientierung. Schließlich wird auf der operativen Ebene die Entwicklung von Anwendungssystemen erläutert; auf die im Phasenmodell genannte Generation Phase wird nicht eingegangen. Wir interpretieren dies so, daß hierin keine Spezifika von Information Engineering gesehen werden. Nicht unerwähnt bleiben darf das Kapitel Information Engineering in Context, mit dem das Buch "by reviewing how each component of Information Engineering is used for strategic systems development" [Fink92,590] beschlossen wird. Wir zitieren hier wörtlich, weniger um auf die damit erzeugte Verwirrung hinzuweisen (auf 589 Seiten war von "Komponenten des Information Engineering" keine Rede), sondern primär deshalb, weil dieser Satz die strategische Ausrichtung von Information Engineering betont. Das Kapitel stellt die Schlüsselkonzepte von Information Engineering zusammenfassend dar, die in der kurzen Inhaltsbeschreibung nicht alle zum Ausdruck kommen konnten. Die Schlüsselkonzepte sind Information Engineering Phases ("Phasenmodell"), Information Engineering Architecture (Unterscheidung zwischen Daten und Prozessen einerseits sowie den verschiedenen Ebenen andererseits), Strategie Data Model ("Informationsmodell"), Process Modeling ("Geschäftsprozeß-

Information

Engineering-

eine

Synopse

25

Modellierung") sowie Business Model (Datenmodell und Prozeßmodell). Die Schlüsselkonzepte des Information Engineering sollen im Ergebnis mehr Produktivität und mehr Qualität "garantieren" als andere Methodiken bzw. als ein Vorgehen ohne Methodik. Die abschließenden Bemerkungen des Autors wollen wir im Original wiedergeben [Fink92,605]: "Information Engineering has evolved since its original development in the 70s, and its refinement during the 80s. It is now an integrated set of techniques which extend from strategic planning at the highest management levels to the analysis, design and implementation of information systems, decision support systems and executive information systems which implement the vision of management." In [Simo91] wird aus dieser klaren Aussage, die sinngemäß bereits in [Fink89] zu finden ist, ein "Methodenverbund" (diese Bezeichnung wird mehrmals wiederholt, kann also nicht zufällig gemeint sein), und es werden Aussagen angefügt, die in keiner Veröffentlichung von C. Finkelstein zu finden sind (z.B.: "Information ist als neuer Produktionsfaktor zu betrachten und analog zu Boden, Arbeit und Kapital zu berücksichtigen."). Der Satz: "Für die strategische Planung können Methoden und Techniken des Information Engineering eingesetzt werden" verkennt, daß strategische Planung wesentlicher Teil der Methodik ist. Die Buchbesprechung vermag über das bisher Gesagte hinaus keine Einsicht darüber zu vermitteln, was nach C. Finkelstein Information Engineering ist; mit der Reduzierung auf "Methodenverbund" wirkt sie eher desorientierend. 3.2

Information Engineering nach J. Martin

Aufgrund der Tatsache, daß die von J. Martin gegebene(n) Definition(en) mit der von C. Finkelstein angegebenen weitgehend übereinstimmt bzw. übereinstimmen, kann davon ausgegangen werden, daß auch die Inhalte nicht wesentlich voneinander abweichen. Die voluminösere, dreibändige Dokumentation von J. Martin (mit insgesamt rd. 1200 Seiten gegenüber rd. 600 Seiten) läßt allerdings mehr Breite und/oder Tiefe vermuten. Wir wollen dieser Annahme im folgenden nachgehen. Das Phasenmodell verwendet die Phasen Information Strategy Planning, Business Area Analysis, Systems Design und Construction', es wird bereits in Bd. I eingeführt [Mart89,13], hier nur kurz, in einem späteren Kapitel ausführlicher erläutert. Was in Bd. I folgt, ist leicht verständlicher Text, mit dem einerseits Eigenschaften von Information Engineering erläutert, andererseits einige Methoden, Modelle und Werkzeuge beschrieben werden (wie diagramming und data models sowie CASE und I-CASE). Zu den wesentlichen Eigenschaften gehören die Verwendung einer Enzyklopädie, die als "the heart of information

26

Lutz J.

Heinrich

engineering" bezeichnet wird [Mart89,14], die Partizipation der Endbenutzer sowie die Integration bzw. Synthese einer Reihe von Ansätzen wie strategische Planung, Datenorientierung, Werkzeugverwendung ("engineering-like tools") und Wiederverwendung, womit im Ergebnis das Erreichen einer höheren Produktivität gegenüber anderen Methodiken behauptet wird. Bd. II behandelt Planning and Analysis. Im Unterschied zu C. Finkelstein wird hier nicht "strategische Unternehmensplanung" ausgebreitet, sondern lediglich als Ausgangspunkt verwendet, um gleich auf die Phase Information Strategy Planning einzugehen. Alle wesentlichen Gesichtspunkte der strategischen Unternehmensplanung sind in die strategische Informatik-Planung eingebunden. Großer Wert wird auf die Darstellung von Tools for Information Strategy Planning gelegt, wobei es sich allerdings eher um Methoden und nicht um Werkzeuge handelt. Die aus der strategischen Planung resultierenden Aktivitäten werden herausgearbeitet, womit in die Phase Business Area Analysis übergeleitet wird. Datenmodellierung (auf Geschäftsbereichsebene) und Prozeßmodellierung sowie die Methoden zur Unterstützung dieser Aufgaben stehen im Mittelpunkt (im umfangreichen Anhang werden einige Methoden detailliert erläutert). Schließlich wird die Schnittstelle zum Systems Design angegeben. Bd. III ist den Phasen Systems Design und Construction gewidmet, wobei das in Bd. I gegebene Phasenmodell verlassen, Design und Construction nicht mehr erkennbar unterschieden, stattdessen aber eine weitere, mit Technical Design and Cutover bezeichnete Phase verwendet wird. Eine Reihe weiterer Themen, deren Einordnung in die angekündigte Information Engineering Methodology nicht immer erkennbar ist, wird abgehandelt (z.B. Information Centers, Decision Support Systems, Executive Information Systems), durchmischt mit der Darstellung weiterer Methoden (wie JRP und JAD, Timebox Methodology) und schließlich ergänzt mit einer Reihe von Themen unter der Überschrift Management and Migration (z.B. Migration und Reverse Engineering). Im Anhang sind einige der verwendeten Methoden näher erläutert. Zu den Zielen dieses Beitrags gehört es nicht, eine vergleichende Analyse der Quellen von C. Finkelstein und J. Martin anzustellen. Eine Schlußfolgerung, auf deren Begründung im Detail verzichtet werden muß, ist leicht erkennbar: Zwar sind beide Autoren von ihrem Ansatz her kaum unterscheidbar, doch werden sie dem Anspruch, Information Engineering als Methodik zu verdeutlichen (im Sinn von Anweisung zur folgerichtigen und zweckmäßigen Lösung der Aufgabe "Planung, Analyse, Entwurf und Realisierung von Informationssystemen", vgl. weiter oben), in unterschiedlicher Weise gerecht.

Information

3.3

Engineering-

eine

Synopse

27

Information Engineering bei anderen Autoren

Die Literaturrecherche, die für diese Synopse durchgeführt wurde, zeigte im Ergebnis nur wenige Quellen im deutschsprachigen Schrifttum, die sich explizit mit Information Engineering befassen, konkreter gesagt: die diese Bezeichnung verwenden, ihre Bedeutung erklären und mit Inhalt füllen. Wir müssen uns daher auch die Frage stellen, ob die Inhalte, wie wir sie aus den Schriften von C. Finkelstein und J. Martin kennen, im deutschsprachigen Schrifttum unter anderen Bezeichnungen geführt werden. Doch zunächst zu den "Bekennern" für Information Engineering. [Fish90] behauptet im Titel "Produktivität durch Information Engineering". Ihm geht es um "einen klaren Leitfaden" dafür, wie aus der vorhandenen "Fülle von Techniken" die ausgewählt und so eingesetzt werden können, die "aus unstrukturierten organisatorischen Gegebenheiten Schritt für Schritt ein funktionierendes Informationssystem" entwickeln helfen. "Dieses Buch soll einen Beitrag zur Lösung dieser Probleme leisten." [Fish90,V]. Weitere Äußerungen im Vorwort wie "praktischer Ratgeber", der dieses Buch sein soll, "InformationEngineering-Techniken", von denen es viele empfehlenswerte gebe, "Gelingen von Softwareprojekten im kommerziellen Bereich", womit kein strategischer Ansatz erkennbar ist, usw. bestärken aufkommende Zweifel darüber, ob hier eine Methodik angegeben wird. Zusammenfassend heißt es: "Die in diesem Buch beschriebenen Methoden werden nach dem folgenden Schema angewandt: • Phase 1 - Analyse des Ist-Zustandes einer Organisation mit Hilfe der strukturierten Interviewtechnik und einer Interviewdatenbank; Entwerfen eines aus 12 Modellprogrammen bestehenden Prototyps. • Phase 2 - Erstellen eines Prototyps bzw. Auswahl eines Softwarepakets, das der Funktionalität des Prototyps am nächsten kommt. • Phase 3 - Schrittweise Verfeinerung des Informationssystems mit Hilfe eines Designgremiums." Und weiter [Fish90,VI]: "Die Anwendung der Information-Engineering-Methoden nach diesem Schema ermöglicht eine ganzheitliche Gestaltung der betrieblichen InformationsiecftmTc." Und: "Auch Studenten und Dozenten der Wirtschaftsinformatik und angrenzender Wissenschaften erhalten mit diesem Buch einen Einblick in die Praxis der betrieblichen Informationsrec/im'A:." (Hervorhebungen durch den Verfasser). Hier scheint etwas gemeint zu sein, was nur wenig mit Information Engineering im Sinn der "Klassiker" zu tun hat. Der Inhalt erweist sich bei näherer Betrachtung in einigen Details nicht ganz so abwegig; immerhin werden einige der oben genannten wesentlichen Eigenschaften von Information Engineering, wenn auch nicht immer klar erkennbar oder ungenau, wiedergegeben ("Eine der wichtigsten Ideen des Information

28

Lutz J• Heinrich

Engineering ist das Konzept der ganzheitlichen Systemplanung." [Fish90,235]). Ein Literaturverzeichnis ist nicht vorhanden, und einschlägige Quellen werden auch nicht im Text angegeben, sodaß nicht erkennbar ist, ob sich der Autor auf Vorbilder stützt und welche dies sind. Ganz unpassend ist die zu diesem Buch vorliegende Rezension, die exemplarisch zeigt, daß Buchbesprechungen manchmal nur Wiederholungen von Aussagen der Autoren sind, ohne jede kritische Auseinandersetzung mit ihnen, und ohne daß die kritiklose Übernahme für den Leser erkennbar ist. Im vorliegenden Fall wird vom Rezensenten im Ergebnis behauptet, daß der Autor ein Buch vorgelegt habe, "das in theoretisch ausgereifter ... Form alle modernen Erkenntnisse des Information Engineering zusammenfaßt." Ein krasses Fehlurteil. [CuWy88] sind da schon ernster zu nehmen, jedenfalls im Ansatz. Die Autoren versprechen mit dem Untertitel "Konzeption und praktische Anwendung" beides, nämlich theoretische Grundlagen des Information Engineering und praktische Anleitungen für das Information Engineering zu liefern. Sie stellen einen Zusammenhang zwischen Informationsmanagement und Information Engineering her, gehen auf die bekannten Erklärungen von Information Engineering ein und beschreiben im wesentlichen den Top-down verlaufenden, unternehmensweit angelegten Prozeß der Identifizierung von Informationsbedarfen bis zur Nutzung und Pflege einschließlich Projektmanagement. Diese Beschreibung läßt ein voluminöses Werk vermuten, doch die Autoren begnügen sich mit einer Kurzfassung (228 Seiten), sodaß ihnen nichts weiter übrig bleibt, als viele zum Information Engineering gehörende Inhalte auszulassen und durch den Rest meist "im Galopp" durchzugehen. Immerhin, in [CuWy88] können wir die beiden "Klassiker" erkennen. [Rutw90] hat in einer Rezension behauptet, [CuWy88] beschäftigten sich "... mit den technologiebezogenen Aspekten dieser Ansätze, zusammengefaßt unter dem Begriff Information Engineering ..." (Hervorhebung des Verfassers), erwähnt aber im gleichen Satz das, was für die Autoren im Mittelpunkt steht, nämlich "... ingenieurmäßiges Vorgehen zur Konstruktion ...". Die Rezensentin spricht zusammenfassend vom "Bereich Information Engineering", nennt das Thema "zweifellos bedeutsam und innovativ" und bemängelt die nicht ausreichend ausführliche "konzeptionelle Darstellung des Information Engineering Konzepts". Eine Buchbesprechung also, die keine zusätzlichen Einsichten vermittelt, sondern eher verwirrend ist. Sie ist ein Beispiel dafür, daß sich Rezensenten "übernehmen", wenn sie Bücher besprechen, deren Materie sie selbst nicht ausreichend kennen. [CuWy88] rücken, wie gezeigt, Information Engineering in die Nähe von Information Management bzw. setzen beide miteinander in Beziehung. Dieser

Information

Engineering-

eine

Synopse

29

Hinweis war der Anlaß dafür, bei der Literaturrecherche auch Quellen zu berücksichtigen, die "Informationsmanagement" im Titel führen. In ihrer vergleichenden Buchbesprechung "Informationsmanagement" fanden [KöLu93] keinen erwähnenswerten Hinweis auf "Information Engineering", jedenfalls taucht diese Bezeichnung in ihrer Untersuchung nicht auf. Die "Teilaspekte des Informationsmanagements", die [KöLu93] zum Inhaltsvergleich verwenden, berücksichtigen nicht in erkennbarer Weise die wesentlichen Merkmale von Information Engineering. Die Durchsicht der in [KöLu93] untersuchten Bücher zeigt im Ergebnis, daß nur in [Hein92] die Bezeichnung Information Engineering verwendet wird, und zwar für den Teil von Informationsmanagement, der die Methoden (und Techniken) einschließlich ihrer Werkzeuge betrifft, mit denen die Durchführung der Aufgaben des Informationsmanagements unterstützt werden kann. Dies wird in [Hein95b] weitergeführt, und Information Engineering wird als methoden- und werkzeugunterstütztes Informationsmanagement behandelt. Da die projektbezogene Schaffung neuer und die Veränderung bestehender Informationssysteme Teil des Informationsmanagements ist ("administratives Informationsmanagement"), sind die Methoden und Werkzeuge zur Unterstützung dieser Aufgabe ebenfalls Information Engineering [Hein94], Ein inhaltlicher Vergleich dieser Position mit der von C. Finkelstein bzw. J. Martin zeigt im Ergebnis folgendes: • Information Engineering wird bei [Hein95b] dem Informationsmanagement untergeordnet, letzteres ist Methodik und Konzept, ersteres wird "nur" im Sinn von Methoden- und Werkzeugkasten zur Unterstützung der Aufgaben des Informationsmanagements verwendet. • Es besteht im wesentlichen die gleiche inhaltliche Spannweite des Ansatzes, die von der Anbindung der strategischen Planung der Informationsverarbeitung an die strategischen Unternehmensziele bis zu den Methoden und Werkzeugen reicht, mit denen einzelne Informationssysteme geschaffen bzw. wesentlich verändert werden. [Fink89] und [Fink92] einerseits sind gegenüber [Hein95b], [Mart89], [Mart90a] und [Mart90b] enger, weil bei ersteren Themenbereiche wie Einführung, Installation, Nutzung usw. nicht zum Phasenmodell gehören und auch nicht behandelt werden. • Unterschiede bestehen zwischen [Hein95b] und den anderen Quellen im angebotenen Methodenvorrat, der um selbst entwickelte, weiterentwickelte und angepaßte Methoden ergänzt ist. Das Schwergewicht liegt auf Methoden, mit denen die strategischen Aufgaben des Informationsmanagements unterstützt werden, also beim strategischen Information Engineering. Im Unterschied zu der aufgrund der Inhalte von [CuWy88] angenommenen und lediglich durch [Hein95b] bestätigten "Nachbarschaft" von Information Engineering und Informationsmanagement, unterstellt [Kurb93] ein inhaltliches Näheverhältnis zwischen Systemplanung, Systemanalyse, Software Engineering

30

Lutz J.

Heinrich

usw. auf der einen und Information Engineering auf der anderen Seite, wenn er Bücher zu diesen Themenbereichen in einer vergleichenden Buchbesprechung bearbeitet (als Vertreter von Information Engineering werden [Mart89], [Mart90a], [Mart90b] verwendet). Daß damit Unvergleichbares bewertend verglichen werden muß, geht aus den Einzelbesprechungen deutlich hervor (z.B. wenn es heißt: "Martin stellt auch ein durchgängiges Konzept vor - von der Informationsstrategie-Planung über Geschäftsbereichsanalysen, den Entwurf einzelner Informationssysteme bis hin zur technischen Realisierung .... Dabei ist die Behandlung von CASE-Methoden und -Werkzeugen voll integriert." [Kurb93,504]). Mit anderen Worten: Software Engineering ist explizit Teil von Information Engineering, was nachzuweisen nicht mehr erforderlich war. 3.4

Kommentierung der Befunde

Auf weitere Quellen, die als Artikel in Fachzeitschriften vorliegen und die "Information Engineering" meist nur als Bezeichnung im Titel führen, soll nicht näher eingegangen werden; sie führen zu keinen weiteren Befunden. Das Gleiche gilt für einschlägig bezeichnete Stellen, die in den Inhaltsverzeichnissen und Schlagwortverzeichnissen gefunden wurden. Zusammenfassend können die Befunde zu folgenden Aussagen geordnet werden: • Das von C. Finkelstein und J. Martin eingeführte Information Engineering als eine ganzheitliche Methodik der top-down geführten, ingenieurwissenschaftlich orientierten Planung und Realisierung von Informationssystemen hat in der deutschsprachigen Literatur unter dieser Bezeichnung kaum Resonanz gefunden (im Unterschied zur englischsprachigen Literatur, z.B. [Brat92], [Hare92], [Mont94], sowie auch in anderem, benachbarten Zusammenhang, z.B. [SoKu93], [Roll93]). • Soweit dies in wenigen Quellen der Fall ist, liegt eher eine Verkürzung des Ansatzes vor, selten eine Entsprechung und jedenfalls keine Fortführung und Erweiterung (z.B. [Fish90] und [CuWy88]). • Die Inhalte, die von beiden "Klassikern" des Information Engineering behandelt werden, finden sich im deutschsprachigen Schrifttum auf mehrere Themenbereiche verteilt, insbesondere Informationsmanagement, Systemplanung bzw. Systemanalyse u.ä. Bezeichnungen, Datenmodellierung und Software Engineering, auf zwei Themenbereiche aggregiert wohl am besten unter "Informationsmanagement" und "Informationssystem-Planung". Muß aus diesen Befunden geschlossen werden, daß "Information Engineering" eine veraltete, überholte Bezeichnung ist? Kann Information Engineering als Methodik nicht alles tragen, was seinem Anspruch nach dazu gehört? Insbesondere: Gibt es überhaupt Autoren, die in der Lage sind, diese Vielfalt zu fassen,

Information

Engineering-

eine

Synopse

31

zu ordnen und weiterzugeben? Angesichts der noch immer dramatisch schnellen Weiterentwicklung der Wirtschaftsinformatik, der Vielfalt der Details und der fehlenden Theorie im Sinn eines Bezugsrahmens, in den eine Fülle von wissenschaftlichen Aussagen eingeordnet werden kann, scheinen diese Zweifel berechtigt zu sein. Eine inhaltliche und methodische Neuorientierung, für die "Information Engineering" eine treffende Bezeichnung sein kann, scheint notwendig zu sein. Diese Neuorientierung kann in der stärkeren Betonung der wissenschaftlichen Aufgaben gegenüber der ausschließlichen Ausrichtung auf praktische Bedürfnisse bestehen.

4

Information Engineering als Wissenschaft

Information Engineering ist heute weitgehend praxisorientiert. Es geht davon aus, daß Methoden und Werkzeuge verfügbar sind, und daß es "nur noch" darum geht, sie zweckmäßig anzuwenden. Die Aufgabe der Methodenentwicklung und die der Umsetzung der Methoden in Werkzeuge wird nicht betrachtet, ganz zu schweigen von den theoretischen Grundlagen der Methodenentwicklung und der systematischen Untersuchung der Methoden- und Werkzeuganwendung. Diese eher wissenschaftlichen Aufgaben können aber nicht außer acht gelassen werden, wenn Information Engineering (auch) als Bezeichnung für eine Teildisziplin der Wirtschaftsinformatik (wie in [Hein93] vorgeschlagen) und ihrer wissenschaftlichen Institutionen (wie z.B. an der Universität Linz und an der Universität Bern) verwendet wird. Ein Rückgriff auf die eingangs gegebene Erklärung von Information Engineering als "die Behandlung von Information mit ingenieurwissenschaftlichen Methoden" kann als Ausgangspunkt für weiterführende Überlegungen dienen, da sie ausdrücklich auf "Wissenschaft" Bezug nimmt. Dies wurde u.W. erstmals in [Hein91] explizit zum Ausdruck gebracht. Nur in ihrer einfachsten Form ist Wissenschaft die Sammlung, Beschreibung und Systematisierung von Vorhandenem, so auch von "Methoden zur Behandlung von Information". Trotz der noch relativ jungen Geschichte der Wirtschaftsinformatik (oder gerade deswegen?) muß ihr wissenschaftlicher Charakter anspruchsvoller formuliert werden; dies ist in vielen Bereichen der Wirtschaftsinformatik mehr Zielsetzung als Realität. Die Anwendung von vorhandenen Methoden reicht nicht aus, auch wenn sie geordnet und systematisch erfolgt. Gefordert werden muß, daß die theoretischen Grundlagen der Methodenentwicklung erarbeitet werden und daß die Methoden- und Werkzeuganwendung wissenschaftlich untersucht wird. Merkmale einer Definition von Information Engineering als wissenschaftliche Disziplin sind daher: • die Erklärung von Information als wirtschaftliches Gut;

32

Lutz J.

Heinrich

• die Untersuchung vorhandener Methoden zur Informationsgestaltung; • die Entwicklung neuer Methoden zur Informationsgestaltung; • die Untersuchung der Zusammenhänge zwischen den Methoden; • die Umsetzung der Methoden in Werkzeuge; • die empirische Untersuchung der Wirkungen der Methoden- und Werkzeuganwendung. Eine Definition, welche diese Merkmale berücksichtigt, kann wie folgt lauten [Hein91,248]: "Information Engineering ist eine Teildisziplin der Wirtschaftsinformatik, deren Erkenntnisobjekt die Methoden zur Gestaltung der Informationsfunktion in Organisationen, insbesondere in Betriebswirtschaften, ist. Sie erarbeitet die Grundlagen zur Erklärung der Informationsfunktion und der Methoden zu ihrer Gestaltung ("Erklärungsaufgabe"), paßt vorhandene Methoden an und entwickelt neue Methoden, sowohl als Einzelmethoden als auch als Methodenverbund, und die zur Methodenanwendung erforderlichen Werkzeuge ("Gestaltungsaufgabe"); sie untersucht die Wirkungen der Anwendung der Methoden und Werkzeuge in der Praxis und setzt die Untersuchungsergebnisse zur Verbesserung der Methoden und Werkzeuge um." Aus dieser Definition lassen sich die beiden "Wurzeln" der Wirtschaftsinformatik erkennen, die Sozial- und Wirtschaftswissenschaften (insbesondere die Betriebswirtschaftslehre) und die Ingenieurwissenschaften (insbesondere die praktische Informatik). Die sozial- und wirtschaftswissenschaftliche Wurzel bringt Forschungsziele und Forschungsmethoden ein, die primär der Bewältigung der Erklärungsaufgabe dienen, die ingenieurwissenschaftliche Wurzel bringt Forschungsziele und Forschungsmethoden ein, die primär der Bewältigung der Gestaltungsaufgabe dienen. Weiter: Aus dieser Definition ist auch erkennbar, daß Wirtschaftsinformatik sowohl Realwissenschaft als auch Formalwissenschaft ist. Realwissenschaft ist Wirtschaftsinformatik, weil sie sich mit Ausschnitten der Wirklichkeit beschäftigt (die in der Definition als "Informationsfunktion in Organisationen" bezeichnet wird). Formalwissenschaft ist Wirtschaftsinformatik, weil zur Erklärung und Gestaltung formale Methoden verwendet werden. In der Bezeichnung "Information Engineering" meint Information das reale Phänomen und Engineering die ingenieurwissenschaftlich orientierte Gestaltung dieses realen Phänomens. Wir bezeichnen daher jede ingenieurwissenschaftliche Gestaltung von Information mit formalen Methoden als Information Engineering und verlassen damit die von C. Finkelstein und J. Martin eingeführte Einschränkung auf eine Methodik zur Lösung einer bestimmten Aufgabe. Gleichzeitig erweitern wir den Ansatz, indem wir nicht nur die Gestaltung mit Methoden meinen, sondern auch die Entwicklung und Anwendung von Methoden. Worauf wir letztlich abzielen

Information

Engineering-

eine Synopse

33

ist folgendes: Die Entwicklung und Anwendung einer Konstruktionslehre zum Bau von Informationssystemen und Informationssystem-Gesamtheiten ("Informationsinfrastrukturen"), die betriebswirtschaftlich, ingenieurwissenschaftlich und sozialwissenschaftlich geprägt ist. Anmerkung: Für die Durchführung der Literaturrecherche, die Herr A. Hansel übernommen hat, dankt der Autor.

Literatur [Brat92] Brathwaite, K. S.: Information Engineering. Vol. I: Concepts, Vol. II: Analysis and Administration, Vol. III: Development Issues. CRC Press, Boca Raton/FL 1992. [Brei91] Breitbart, G.: Buchbesprechung zu [Fish90], WIRT^IAFTSINFORMAHK 6/1991,557. [BroWa] Brockhaus-Wahrig: Deutsches Wörterbuch in sechs Bänden. F. A. Brockhaus und Deutsche Verlags-Anstalt, Wiesbaden bzw. Stuttgart 1980. [Comp91] Computerlexikon. Sybex, Düsseldorf 1991 (Übersetzung der engl. Originalausgabe: Dictionary of Engineering, Oxford University Press). [CuWy88] Curth, M. A., Wyss, H. B.: Information Engineering. Konzeption und praktische Anwendung. Hanser, München 1988. [Fink89] Finkelstein, C.: An Introduction to Information Engineering. AddisonWesley, Reading/MA 1989. [Fink92] Finkelstein, C.: Information Engineering. Strategie Systems Development. Addison-Wesley, Reading/MA 1992 (Reprint 1993). [Fish90] Fisher, D. T.: Produktivität durch Information Engineering. Vieweg, Braunschweig/Wiesbaden 1990. [Hare92] Hares, J. S.: Information Engineering for the Advanced Practitioner. Wiley, Chichester 1992. [Hein91] Heinrich, L. J.: Das aktuelle Schlagwort: Information Engineering. WIRISCHAFISINTORMAIIK 3/1991, 247 - 248. [Hein92] Heinrich, L. J.: Informationsmanagement. Planung, Überwachung und Steuerung der Informationsinfrastruktur. 4. Auflage, Oldenbourg, München/Wien 1992. [Hein93] Heinrich, L. J.: Wirtschaftsinformatik - Einführung und Grundlegung. Oldenbourg, München/Wien 1993. [Hein94] Heinrich, L. J.: Systemplanung - Planung und Realisierung von Informatik-Projekten (2 Bände). 6. Auflage (Bd. 1) bzw. 5. Auflage (Bd. 2), Oldenbourg, München/Wien 1994.

34

Lutz J.

Heinrich

[Hein95a] Heinrich, L. J.: Stichwort "Information", in Corstens, H.: Lexikon der Betriebswirtschaftslehre. 3. Auflage, Oldenbourg, München/Wien 1995. [Hein95b] Heinrich, L. J.: Informationsmanagement. Planung, Überwachung und Steuerung der Informationsinfrastruktur. 5. Auflage, Oldenbourg, München/Wien 1995. [HeRo95] Heinrich, L. J., Roithmayr, F.: Wirtschaftsinformatik-Lexikon. 5. Auflage, Oldenbourg, München/Wien 1995. [KöLu93] König, W., Ludwig, J.-Ch.: Vergleichende Buchbesprechung "Informationsmanagement". WIRTSCHAFISINKmiATK4/1993, 405 - 410. [Kurb93] Kurbel, K.: Vergleichende Buchbesprechung "Entwicklung von Informationssystemen - Systemanalyse, Software Engineering und benachbarte Gebiete". WIRTSCHAFISINFŒMA'nK 5/1993,499 - 506. [Mart89] Martin, J.: Information Engineering, Book I - Introduction. Prentice Hall, Englewood Cliffs/NJ 1989. [Mart90a] Martin, J.: Information Engineering, Book II - Planning & Analysis. Prentice Hall, Englewood Cliffs/NJ 1990. [Mart90b] Martin, J., Information Engineering, Book Construction. Prentice Hall, Englewood Cliffs/NJ 1990.

III:

Design

&

[MaFi81] Martin, J., Finkelstein, C.: Information Engineering. Vol. 1 and 2, Prentice Hall, Englewood Cliffs/NJ 1981. [Mert90] Mertens, P.: Lexikon der Wirtschaftsinformatik. 2. Auflage, Springer, Berlin et al. 1990. [Mert95] Mertens, P.: Von den Moden zu den Trends, in König, W. (Hrsg.): Wirtschaftsinformatik '95. Wettbewerbsfähigkeit, Innovation, Wirtschaftlichkeit. Physica, Heidelberg 1995, 25 - 64. [Mont94] Montgomery, S.: Object-oriented Information Engineering: Analysis, Design and Implementation. Acad. Press, San Diego/CA 1994. [Öst95] Österle, H.: Business Engineering. Springer, Berlin et al. 1995. [Roll93] Rolland, C. et al. (Ed.): Advanced Information Systems Engineering. Proceedings, 5th International Conference, CAiSE '93. Springer, Berlin et al. 1993. [Rutw90] Rutwalt, K.: Buchbesprechung zu [CuWy88]. WRTSCHAFISINFORMATK4/1990, 385 - 386. [Simo91] Simon, M.: Buchbesprechung zu [Fink89], HMD - Theorie und Praxis der Wirtschaftsinformatik 158/1991, 112- 113. [SoKu93] Solvberg, A., Kung, D. C.: Information Systems Engineering. An Introduction. Springer, Berlin et al. 1993.

Zur Entwicklung der Forschungsmethoden und Theoriekerne der Wirtschaftsinformatik. Eine kombinierte Delphi- und AHP-Untersuchung Wolfgang König, Armin Heinzl, Marcus-Julian Rumpf und Ansgar von Poblotzki Institut für Wirtschaftsinformatik, Universität Frankfurt am Main

Zusammenfassung 1

Einleitung und Problemstellung

2

Forschungsmethodik und Untersuchungsverfahren

3

Befunde 3.1 Zukünftige Forschungsgegenstände der Wirtschaftsinformatik und deren Verbindung zu Wissenschaftsprodukten und -markten 3.2 Zukünftige Forschungsmethoden der Wirtschaftsinformatik 3.2.1 Befragung nach der Delphi-Methode 3.2.2 Befragung nach der AHP-Methode 3.3 Zukünftige Theoriekerne der Wirtschaftsinformatik 3.3.1 Befragung nach der Delphi-Methode 3.3.2 Befragung zu Forschungsimperativen nach der AHPMethode

4

Interpretation der Befunde 4.1 Zur Reabilität und Validität der Ergebnisse 4.2 Zur inhaltlichen Interpretation der Ergebnisse 4.3 Zur „Vision" der Position der Wirtschaftsinformatik 4.4 „Fit" der Forschungsmethoden und Theoriekerne zu der gewünschten inhaltlichen Ausrichtung der Wirtschaftsinformatik

5

Zusammenfassung und Ausblick

Literatur Anhang

36

Wolfgang König, Armin Heinzl, Marcus-Julian

Rumpf, Ansgar von

Poblotzki

Zusammenfassung Von Mai bis September 1994 fand eine kombinierte Delphi- und AHP'-Untersuchung der Fragen statt, welche Forschungsgegenstände, Forschungsmethoden und Theoriekerne die Wirtschaftsinformatik in den nächsten zehn Jahren bearbeiten bzw. verwenden soll, um ihre Wettbewerbsposition gegenüber der Betriebswirtschaftslehre und der Informatik behaupten zu können. 23 Vertreter der Wissenschaft und 7 Vertreter der Praxis erarbeiteten über vier Runden eine gemeinsame Position 2 . Über Untersuchungsergebnisse bezüglich der zukünftig notwendigen Forschungsgegenstände wurde an anderer Stelle berichtet 3 . Der vorliegende Beitrag beschreibt die Methoden und Theoriekerne, die zur Erforschung der prognostizierten Inhalte notwendig sind. Abschließend erfolgt eine kritische Würdigung der zum Einsatz gekommenen Untersuchungsmethoden und ihrer Eignung für die vorliegenden Fragestellungen. Es zeigt sich u.a., daß diese Form von Gruppenbefragungen für derart qualitative und durch individuelle Einstellungen geprägte Erkenntnisgegenstände an Grenzen stößt. Dies wird sowohl durch statistische Testmaße als auch durch Kritik der Mitglieder des Panels deutlich. In Anbetracht der Wichtigkeit der bearbeiteten Fragen sollen in dem vorliegenden Beitrag die Daten offengelegt werden, um eine breite Diskussion der Aspekte zu unterstützen. Als wesentliches Untersuchungsergebnis ist - bei aller Zurückhaltung wegen der angesprochenen methodischen Probleme - festzuhalten, daß - im Gegensatz zu einem stabilen Konsens bezüglich der zukünftigen Forschungsgegenstände bezüglich der Forschungsmethoden und Theoriegrundlagen keine einheitliche "Vision" über die Positionierung der Wirtschaftsinformatik in der Wissenschaftswelt der nächsten zehn Jahre entwickelt wird. Vielmehr ist ein fragmentiertes und bisweilen auch lückenhaftes Bild der zukünftigen Forschungsmethoden und Theoriekerne der Wirtschaftsinformatik festzustellen.

1

Einleitung und Problemstellung

Die Wirtschaftsinformatik steht als Wissenschaftsdisziplin im Wettbewerb mit ihren "Mutterwissenschaften" Wirtschaftswissenschaften und Informatik. Wir gehen davon aus, daß die Wirtschaftsinformatik eine eigenständige Lehr- und Forschungsdisziplin darstellt, und daß die in der "Community" gepflegten

A n a l y t i c Hierarchy Process [Saaty 90],

D i e L i s t e der Mitglieder des Panel findet sich im Anhang.

Vgl. [KÖHEVP 95].

Zur Entwicklung

der Forschungsmethoden

und Theoriekerne

der Wirtschaftsinformatik

37

Forschungsgegenstände maßgebliche Entwicklungstreiber des Fachs darstellen. Forschungsgegenstände sind mit adäquaten Forschungsmethoden zu bearbeiten; diese wiederum basieren auf geeigneten Theoriekernen. Forschungsergebnisse und Lehrinhalte werden auf ressourcenmäßig begrenzten Märkten (z.B. Finanzmittel, Anzahl der Professuren/Mitarbeiter, Anzahl der Studenten) erarbeitet und angeboten, so daß es nahe liegt, das Denkmodell des Wettbewerbs der Untersuchung zugrundezulegen. Die Frage lautet also: Auf welche Forschungsgegenstände, Forschungsmethoden und Theoriekerne soll sich die Wirtschaftsinformatik in den nächsten zehn Jahren konzentrieren, um ihre Wettbewerbsposition gegenüber der Betriebswirtschaftslehre und der Informatik zu behaupten oder ausbauen zu können? Der Planungshorizont von zehn Jahren resultiert aus der Überlegung, daß sich der Wandel in wissenschaftlichen Disziplinen nicht rasch vollzieht. Promotionen, die einen wesentlichen Beitrag zum wissenschaftlichen Erkenntnisfortschritt leisten, dauern beispielsweise drei bis fünf Jahre. Auch DFG -Schwerpunktprogramme werden fünf Jahre gefördert. Von Mai bis September 1994 fand eine kombinierte Delphi- und AHP-Untersuchung der vorgenannten Fragen statt. 23 Experten aus der Wissenschaft und der sieben führende Vertreter aus der Praxis erarbeiteten über vier Runden eine gemeinsame Position. Von den 23 Vertretern der Wissenschaft sind 14 Wirtschaftsinformatiker, die anderen Mitglieder des Panels sind von Hause aus Betriebswirte, Informatiker oder Naturwissenschaftler. In [KÖHEVP 9 5 ] wird als Ergebnis bezüglich der Forschungsgegenstände dargestellt, daß sich die Wirtschaftsinformatik zukünftig stärker als eine Wissenschaft mit einem starken Bezug zur Organisationslehre versteht, um die Wettbewerbsposition der Wirtschaftsinformatik zu halten oder auszubauen. Die folgenden Rangplätze sehen die Wirtschaftsinformatik als eine Wissenschaft zur Gestaltung der Informationsverarbeitungsfunktion in Unternehmen (Querschnittsfunktion) sowie als eine Wissenschaft, die darauf abzielt, den Leistungsfaktor Information im Unternehmen geeignet einzusetzen. In dem folgenden Beitrag werden nun wichtige Untersuchungsergebnisse bezüglich der zur Erforschung dieser Gegenstände notwendigen Forschungsmethoden und Theoriegrundlagen ausgeführt.

38

2

Wolfgang König, Armin Heinzl, Marcus-Julian

Rumpf, Ansgar von

Poblotzki

Forschungsmethodik und Untersuchungsverfahren

In der vorliegenden Untersuchung werden die Delphi-Methode und die AHPMethode (Analytic Hierarchy Process) miteinander kombiniert 4 . Die DelphiMethode ist eine strukturierte schriftliche Befragung von Mitgliedern eines Panels. Nach einer offenen ersten Befragungsrunde, in welcher die Mitglieder des Panels ihre Grundsatzpositionen zu den Forschungsgegenständen, Forschungsmethoden und Theoriekernen darlegten, folgten drei weitere Runden, in welchen die von den Teilnehmern dargelegten Sachverhalte strukturiert und quantitativ sowie qualitativ bewertet wurden. Nach jeder Runde wurde seitens der Moderatoren eine Zusammenfassung der bisherigen Ergebnisse erstellt und an alle Mitglieder des Panels verteilt. Sachverhalte, zu welchen viele Anregungen von den Mitgliedern des Panels formuliert wurden, wurden in eine Delphi-Hierarchie gestellt, um den Überblick herzustellen und die Bewertung seitens der Mitglieder des Panels zu vereinfachen 5 . Mehrere Mitglieder des Panels sahen sich außerstande, eine allgemeine Diskussion über Forschungsmethoden zu führen. Ihrer Meinung nach könne die Relevanz von Forschungsmethoden der Wirtschaftsinformatik nicht unabhängig von Forschungsgegenständen bewertet werden. Dieser Gedanke wird im AHP-Ansatz aufgenommen, in dem die mit Hilfe der Delphi-Methode explorierten wichtigsten Forschungsgegenstände und Forschungsmethoden in Beziehung gesetzt wurden 6 . Der AHP-Ansatz ist eine Methode zur Entscheidungsunterstützung, mit der Abhängigkeiten von miteinander verbundenen Größen einer Entscheidung hierarchisch analysiert werden. Auf der untersten Hierarchieebene werden frei wählbare Entscheidungsparameter im Sinne von Handlungsalternativen spezifiziert 7 ; die oberste Ebene reflektiert das Generalziel des betreffenden Entscheidungsproblems. Die Zwischenschaltung weiterer Ebenen, die den entscheidungsrelevanten Realitätsausschnitt nach verschiedenen Dimensionen differenziert, eröffnet eine schrittweise Inbeziehungsetzung von Handlungsalternativen und Zielsetzungen, anstatt dem Entscheider eine unmittelbare Bewertung abzuverlangen, die von ihm ggf. als zu schwierig abgelehnt würde.

Z u r K o m b i n a t i o n d e r D e l p h i - M e t h o d e u n d d e s A H P - A n s a t z e s : V g l . : [KHOMOU 8 8 ] , [AZAKHO90],

D i e D e l p h i - M e t h o d e u n d G r u p p e n b e f r a g u n g e n im a l l g e m e i n e n w e r d e n h i e r m e t h o d i s c h n i c h t n ä h e r b e t r a c h t e t ; zu d e n e n t s p r e c h e n d e n G r u n d l a g e n u n d L i t e r a t u r q u e l l e n d e r v o r l i e g e n d e n D e l p h i - U n t e r s u c h u n g vgl. d i e V o r g ä n g e r - V e r ö f f e n t l i c h u n g [KÖHEVP 9 5 ] ,

D i e A H P - B e f r a g u n g e n w u r d e n in d e n R u n d e n z w e i bis v i e r g e m e i n s a m m i t d e r D e l p h i b e f r a g u n g d u r c h g e f ü h r t .

Entscheidungsparameter beeinflussen kann.

sind

Größen,

deren

Ausprägungen

der

Entscheider

durch

sein

Handeln

unmittelbar

Zur Entwicklung

der Forschungsmethoden

und Theoriekerne

der Wirtschaftsinformatik

39

Die Intensität, mit der eine bestimmte Größe xk(k = \,...,K) einer Menge von K Entscheidungsgrößen einer höher liegenden Ebene von den einzelnen Größen der unmittelbar darunterliegenden Ebene abhängt, wird durch eine quadratische Paarvergleichsmatrix Ak erfaßt. Die gesamte Interdependenz der beiden Ebenen wird also durch K Paarvergleichsmatrizen erfaßt. Das Element a,* der Matrix Ak drückt aus, daß die i'-te Größe der untergeordneten Ebene einen mit dem Faktor höheren Einfluß auf die Größe xk ausübt als die y'-te Größe der untergeordneten Ebene. Als Beispiel zur Veranschaulichung zeigt Abbildung 1 die aggregierten Gewichte aller im nachfolgend entwickelten AHP-Ansatz erfaßten Einflußgrößen auf die Wettbewerbsfähigkeit der Wirtschaftsinformatik:

Abb. 1:

Aggregierte Gewichte aller erfaßten Einflußgrößen auf die Wettbewerbsfähigkeit der Wirtschaftsinformatik

Diese mittels Paarvergleichsmatrizen mögliche Erfassung der Abhängigkeiten zweier Ebenen wird für sämtliche Paare unmittelbar benachbarter Ebenen vorgenommen. So sind z.B. für die in Abb. 1 dargestellte 4-Ebenen-Hierarchie mit oben einer Größe (hier: "Wettbewerbsfähigkeit der Wirtschaftsinformatik"), darunter vier Größen (hier: die Märkte, nämlich "Wissenschaft", "Studenten", "Praxis", "Stellen"), darunter vier Größen (hier: die wichtigsten inhaltlichen Ausrichtungen der Wirtschaftsinformatik, nämlich Bezug zu „Organisationslehre", "Funktionale Betriebswirtschaftslehre", "Informationswissenschaft", "Innovationswissenschaft") und darunter vier Größen (hier: vier verschiedene Klassen von Forschungsmethoden) eine vierzeilige, vier vierzeilige und weitere vier vierzeilige Paarvergleichsmatrizen zu bestimmen.

40

Wolfgang König, Armin Heinzl, Marcus-Julian

Rumpf, Ansgar von

Poblotzki

Der Entscheider spezifiziert die Komponenten von Paarvergleichsmatrizen auf einer neungeteilten metrischen Skala (1/9,1/7,1/5,1/3,1,3,5,7,9)8. Für jede Paarvergleichsmatrix Ak wird ein Gewichtungsvektor bk errechnet, dessen Komponenten b. den relativen Einfluß der i-ten untergeordneten Größe auf die übergeordnete Größe xk angeben9. Die Vier-Ebenen-Hierarchie des obigen Beispiels wird durch einen vierkomponentigen Gewichtungsvektor, vier vierkomponentige und weitere vier vierkomponentige Gewichtungsvektoren beschrieben. Die Gewichtungsvektoren werden ebenenweise zu Matrizen zusammengefaßt, die dann von unten nach oben miteinander multipliziert werden10. Das Ergebnis dieser linearen Berechnung ist eine Gewichtung der frei wählbaren Entscheidungsparameter (unterste Ebene) hinsichtlich ihres Einflusses auf das Generalziel des Entscheidungsproblems (oberste Ebene). Die Anzahl der AHP-Ebenen (Dimensionen des Entscheidungsproblems) sowie die Auswahl der einzelnen Größen auf jeder Ebene werden vom Moderatorenteam vorgegeben. Dabei sollen zum einen die wesentlichen Einflußgrößen auf die Gesamtentscheidung (hier: die Messung der Wettbewerbsfähigkeit) erfaßt werden. Zum anderen ist die Anzahl der paarweisen Vergleiche, die bei diesem Untersuchungsaufbau schnell über alle Schranken steigt", so weit wie möglich zu begrenzen. In dem vorliegenden Fall bestimmen die Mitglieder des Panels zum großen Teil selbst die Einflußgrößen auf den einzelnen Ebenen. Sie ergeben sich aus der parallel durchgeführten Delphi-Befragung,12 nämlich die inhaltliche Ausrichtung der Wirtschaftsinformatik sowie die in der Untersuchung angesprochenen Forschungsmethoden. Die für die verschiedenen Mitglieder des Panels errechneten Gewichte werden arithmetisch gemittelt.

°

^

F ü r B e f r a g u n g e n wird diese Skala mit ("absolut kleiner", "deutlich kleiner", "kleiner", "leicht kleiner", "gleich", "leicht g r ö ß e r " , " g r ö ß e r " , "deutlich größer", "absolut größer") übersetzt. Der G e w i c h t u n g s v e k t o r einer Paarvergleichsmatrix ist ihr Eigenvektor z u m höchsten Eigenwert. Vgl. [SAATY 9 0 , S. 51].

1 0

Vgl. [SAATY 9 0 , S. 27],

''

N u r z u r Spezifikation der paarweisen Vergleiche zwischen den vier unterschiedlichen A u s p r ä g u n g e n d e r inhaltlichen A u s r i c h t u n g d e r Wirtschaftsinforniatik f ü r die vier logisch übergeordneten Marktaltemativen sind von j e d e m M i t g l i e d d e s P a n e l schon insgesamt 27 Fragen zu beantworten.

'2

Von dieser R e g e l wird einzig bei der E b e n e der W i s s e n s c h a f t s m ä r k t e abgewichen. Vgl. Abschnitt 3.1.

Zur Entwicklung

3

der Forschungsmethoden

und Theoriekerne

der Wirtschaftsinformatik

41

Befunde

3.1

Zukünftige Forschungsgegenstände der Wirtschaftsinformatik und deren Verbindung zu Wissenschaftsprodukten und -märkten

Im Rahmen der Delphi-Methode wird gefragt: Welche Forschungsgegenstände muß die Wirtschaftsinformatik in den nächsten zehn Jahren untersuchen, wenn sie ihre Wettbewerbsposition gegenüber der Betriebswirtschaftslehre und der Informatik halten oder ausbauen will? Im Anschluß wird für die AHP-Untersuchung zunächst das allgemeine Ziel "Wettbewerbsfähigkeit der Wirtschaftsinformatik" präzisiert. Der Erfolg der Wirtschaftsinformatik-Fachvertreter im Wettbewerb mit anderen Disziplinen wird als deren Fähigkeit definiert, ihre Wissenschaftsprodukte (Veröffentlichungen, Lehrveranstaltungen, Projekte, Vorträge, Prototypen, etc.) auf relevanten Märkten abzusetzen. Als relevante Märkte werden definiert: • Wissenschaft, d.h. die Präsenz in namhaften wissenschaftlichen Zeitschriften, auf Tagungen und in der Deutschen Forschungsgemeinschaft (DFG), • Studenten und Mitarbeiter, d.h. die Attraktivität des Fachs für Studenten und den wissenschaftlichen Nachwuchs, • Praxis, d.h. das Interesse in der Industrie- und Dienstleistungspraxis, die Ergebnisse der Wirtschaftsinformatik zu nutzen und ihre Bemühungen zu fördern, • Stellen, d.h. die Bereitschaft der Universitäten und Forschungseinrichtungen, attraktive Professuren für das Fach Wirtschaftsinformatik anzubieten. Die Richtigkeit und Vollständigkeit dieser Systematik wurde von keinem der Teilnehmer kritisiert. Die relative Bedeutung dieser Märkte für den Erfolg der Wirtschaftsinformatik insgesamt wird mittels AHP-Befragung bestimmt:

relative Bedeutung

Wettbewerbsfähigkeit der Wirtschaftsinformatik

-

Wissenschaft

26,34%

-

Studenten und Mitarbeiter

15,95%

-

Praxis

42,02%

-

Stellen

15,69%

Tabelle 1:

Relative Bedeutung von Wissenschaftsmärkten für die Wettbewerbsfähigkeit der Wirtschaftsinformatik

42

Wolfgang König, Armin Heinzl, Marcus-Julian

Rumpf, Ansgar von

Poblotzki

Es fällt auf, daß nach Meinung des Panels das "Verwertungsinteresse" der Praxis (d.h. der Industrie- und Dienstleistungsunternehmen) an den Ergebnissen der Wirtschaftsinformatik mit 42% den stärksten Einfluß auf die Wettbewerbsfähigkeit der Wirtschaftsinformatik ausübt, mit Abstand gefolgt von der Präsenz in der Wissenschaft mit 26%. Zur Sicherung der Wettbewerbsfähigkeit der Wirtschaftsinformatik stehen bei der Delphi-Befragung die folgenden vier zentralen Forschungsgegenstände (inhaltliche Ausrichtungen der Wirtschaftsinformatik) auf den höchsten Rängen 13 : • Wissenschaft mit starkem Bezug zur Organisationslehre, die versucht, den Aufbau und die Abläufe sozio-technischer Systeme zu beschreiben und zu optimieren, • Funktionale Betriebswirtschaftslehre, die vornehmlich die Funktion der betrieblichen Datenverarbeitung/Informationsverarbeitung im Unternehmen erforscht (z.B. Informationsverarbeitung als Querschnittsfunktion), • Informationswissenschaft, die versucht, die Ökonomie des Leistungsfaktors Information und seine gezielte Bereitstellung zu erforschen, • Innovationswissenschaft, die sich mit der Definition von Anforderungen an neue Informations- und Kommunikationstechniken beschäftigt und die daraus resultierenden Produkte und Verfahren in die Unternehmen einführt. Differenziert man nach den einzelnen Wissenschaftsmärkten, so führt die AHPBefragung zu folgenden relativen Erfolgsaussichten für diese vier möglichen Forschungsgegenstände:

relative E r f o l g s a u s s i c h t e n

-

Wissenschaft

Studenten und Mitarbeiter

Praxis

Stellen

Organisationslehre

36,42%

35,11%

41,88%

33,23%

Funktionale Betriebswirtschaftslehre

23,82%

23,31%

23,04%

23,58%

Informationswissenschaft

18,94%

18,82%

18,15%

24,37%

Innovationswissenschaft

20,83%

22,75%

16,93%

18,81%

Tabelle 2:

Relative Bedeutung der Forschungsgegenstände / inhaltlichen Ausrichtungen für die Wissenschaftsmärkte der Wirtschaftsinformatik

Befragungsgegenstand sind Rangplätze inhaltlicher Ausrichtungen der Wirtschaftsinformatik, die sich aus einer offenen ersten Befragungsrunde ergeben.

Zur Entwicklung der Forschungsmethoden

und Theoriekerne der Wirtschaftsinformatik

43

Daraus resultieren folgende relative Bedeutungen der Forschungsgegenstände für die Wettbewerbsfähigkeit der Wirtschaftsinformatik insgesamt:

relative B e d e u t u n g

Wettbewerbsfähigkeit der W i r t s c h a f t s i n f o r m a t i k

-

Organisationslehre

38,00%

-

Funktionale Betriebswirtschaftslehre

23,38%

Informationswissenschaft

19,48%

Innovationswissenschaft

19,14%

Tabelle 3:

Relative Bedeutung der Forschungsgegenstände / inhaltlichen Ausrichtungen für die Wettbewerbsfähigkeit der Wirtschaftsinformatik

Dieses (metrisch skalierte) Ergebnis bestätigt die mittels Delphi-Befragung bestimmte Rangfolge der Forschungsgegenstände.

3.2

Zukünftige Forschungsmethoden der Wirtschaftsinformatik

3.2.1

Befragung nach der

Delphi-Methode

Methodenklassen Die Abschlußauswertung ergibt folgendes Bild der Einschätzung der Teilnehmer, mit welchem relativen Gewicht jede Methodenklasse von der Wirtschaftsinformatik angewendet werden soll (siehe Tabelle 4). Die beiden zur Auswahl stehenden Methodenklassen wurden von den Moderatoren vorgegeben.

Methodenklassen

%-AnteilR„14

k o n s t r u k t i v e M e t h o d e n , d i e Uberwiegend V e r ä n d e r u n g v o n S a c h v e r h a l t e n dienen -

zur

60%

e m p i r i s c h e M e t h o d e n , d i e ü b e r w i e g e n d induktionsgetrieben sind und primär dem Z w e c k d e r Ü b e r p r ü f u n g v o n T h e o r i e n zur Erklärung g e g e b e n e r S a c h v e r h a l t e dienen

40%

Tabelle 4:

deduktionsgetrieben

sind

und

primär

Methodenklassen

Sechs der 30 Mitglieder des Panels sind der Auffassung, daß die Vorteilhaftigkeit bestimmter Methoden nur vor dem Hintergrund konkreter Fragestellungen

Die Delphi-Umfrage umfaßt vier Fragerunden. R4 bezeichnet das Ergebnis nach Runde 4. Hinweis: In Runde vier wurde auf Anregung der Teilnehmer die Fragestellung modifiziert. In den Runden zwei und drei wurden die Teilnehmer gebeten, sich für eine der beiden Methodenklassen zu entscheiden. In Runde vier wurden die Teilnehmer gebeten, die relativen Gewichte beider Methodenklassen unter dem Blickwinkel einer optimalen Arbeitsteilung anzugeben.

44

Wolfgang König, Armin Heinzl, Marcus-Julian

Rumpf, Ansgar von

Poblotzki

behandelt werden kann. Drei andere Teilnehmer stellen fest, daß man bei Anwendung jeder Methode deduzieren und induzieren muß. Ein Teilnehmer merkt an, daß empirische Methoden zur 'Überprüfung von Theorien' präsupponieren, daß die Wirtschaftsinformatik über Theorien im strengen wissenschaftstheoretischen Verständnis des Theoriebegriffs verfügt. Da dies allenfalls in rudimentären Ansätzen zutrifft, dürfte nach Einschätzung dieses Teilnehmers ein mehr als bescheidenes Gewicht für empirische Methoden zur Theorieüberprüfung eher dem Wunschdenken der Zunft der Wirtschaftsinformatiker als der epistemischen Qualität ihres Wissensfundus entsprechen. Empirische

Methoden

Auf Basis der offenen ersten Runde werden nun empirische und konstruktive Methoden zu Klassen zusammengefaßt und in den Delphi-Runden zwei bis vier von den Mitgliedern des Panels bewertet, verbal kommentiert sowie ergänzt. Nach der dritten Runde wird die Anzahl der untersuchten Variablen auf die jeweils ersten fünf Nennungen reduziert, um den Umfang des sich sukzessive verlängernden Fragebogens zu beschneiden und eine Fokussierung auf die wichtigsten Forschungsmethoden und Theoriegrundlagen zu erreichen. Die Abschlußauswertung ergibt folgendes Bild der Einschätzung der Teilnehmer, welche empirischen Methoden von besonderer Bedeutung sind, damit die Wirtschaftsinformatik ihre Wettbewerbsposition behaupten bzw. ausbauen kann (siehe Tabelle 5). Empirische Methoden

ÖR415 0,74

-

E x p l o r a t i o n m i t t e l s Fallstudien und Feldstudien

X R4 1,36

-

B e o b a c h t u n g (z.B. des A n w e n d e r - oder Systemverhaltens)

2,24

-

R e f e r e n z m o d e l l e als q u a s i - e m p i r i s c h e r (semi-formaler) A n s a t z

3,60

1,26

-

M ü n d l i c h e o d e r schriftliche B e f r a g u n g e n

3,72

0,92

Forschung durch Entwicklung16

4,68

1,66

E x - P o s t - B e s c h r e i b u n g e n und Interpretationen realer Sachverhalte

5,04

0,82

-

Tabelle 5:

0,76

Empirische Methoden (herausgefallen nach Runde drei: "Laborexperimente", "Längsschnittstudien" und "Meßverfahren")

Ein Mitglied des Panels weist auf Überschneidungen innerhalb der empirischen Methoden hin. Beispielsweise können nach seinen Überlegungen schriftliche Befragungen zur Durchführung von Längsschnittstudien durchgeführt werden. Das Moderatorenteam weist die Teilnehmer darauf hin, daß diese beiden

15

x R4 bezeichnet den mittleren Rangplatz nach Runde vier; Or4 bezeichnet die zugehörige Standardabweichung.

16

Wurde erst in Runde vier eingeführt.

Zur Entwicklung

der Forschungsmethoden

und Theoriekerne

der Wirtschaftsinformatik

45

Variablen innerhalb der Fragestellung nur sehr schwach korreliert seien. Hierzu bemerkt ein weiterer Mitwirkender, daß mangelnde Korrelationen in Antworten kein Gegenbeweis für mögliche hierarchische Abhängigkeiten innerhalb der Antworten sind. Nach der Einschätzung von drei Teilnehmern benötigt man Referenzmodelle als Basis für alle empirischen Methoden. Ein anderer Teilnehmer ist der Ansicht, daß Referenzmodelle nicht in diese Methodenklasse gehören, führt jedoch keine Gründe aus. Ein Teilnehmer schlägt vor, Feld- und Fallstudien zu trennen. Nach Ansicht eines Teilnehmers ist die Fallstudie die erkenntnistheoretisch schwächste Form der Feldstudie. Die Methode Beobachtung ist für ein Mitglied des Panels viel zu allgemein und für alle engeren Forschungsmethoden erforderlich. Ein anderer Teilnehmer erläutert, daß Beobachtungen im Sinne von Regelkreisen zu optimalen Ergebnissen führen, aber immer Soll- und Istgrößen nötig sind. Versuche liefern immer nur Istgrößen und sind somit vergangenheitsgerichtet. Zwei Teilnehmer stellen in Frage, ob es sich bei der Methode Forschung durch Entwicklung um eine empirische Methode handelt. Für einen Vertreter der Praxis gehört dieser Punkt zur Kategorie Learning by Döing und wird ausdrücklich befürwortet. Ein weiterer Mitwirkender führt aus, daß eine anwendungsorientierte Wissenschaft im Interesse ihrer Fortschrittsfähigkeit nicht auf experimentelle Forschung durch reale Problemlösungsarbeit verzichten kann. Für einen Teilnehmer ist hier eine Rangreihenfolge empirischer Methoden sinnlos. Konstruktive

Methoden

Die Abschlußauswertung ergibt folgendes Bild der Einschätzung der Teilnehmer, welche konstruktiven Methoden von besonderer Bedeutung sind, damit die Wirtschaftsinformatik ihre Wettbewerbsposition behaupten bzw. ausbauen kann (siehe Tabelle 6). In der Diskussion wird mehrfach auf mögliche hierarchische Abhängigkeiten und Überschneidungen innerhalb der Antworten hingewiesen. Insbesondere wird Deduktion als eine grundlegende Arbeitstechnik angesehen. Zwei Diskussionsbeiträge beziehen sich explizit auf den Voraussetzungscharakter von Deduktion für die Entwicklung einer Konstruktionslehre. Ein Teilnehmer sieht in Modellierung Voraussetzung bzw. Bestandteil jeder Art von Konstruktion. Ein Teilnehmer fragt, wie Simulation anders als durch Laborforschung möglich

46

Wolf gang König, Armin Heinzl, Marcus-Julian

Rumpf, Ansgar von

Poblotzki

sein soll. Für einen Teilnehmer ist Konstruktion ohne Kreativität schwer nachvollziehbar.

Konstruktive Methoden

X R4

-

Entwicklung und Test von Prototypen

1,54

-

Simulation

2,75

1,23

-

Modellierung17

3,29

1,81 1,24

CR4 0,76

Deduktion

3,96

-

Learning by D o i n g (Wissenstransfer durch Untemehmensberatung)

4,17

1,40

-

Kreativitätstechniken

4,83

1,11

Tabelle 6:

Konstruktive Methoden (herausgefallen nach Runde drei: "Optimierungsverfahren")

Ein Mitglied des Panels fragt nach dem zentralen Unterschied zwischen Modellierung und Entwicklung und Test von Prototypen. In der folgenden Runde erläutert ein anderer Teilnehmer, daß Modellierung und Simulation bei technischen Entwicklungen in der Regel die Vorstufe zu[r Entwicklung von; die Verf.] Prototypen darstellen. Ein weiterer Teilnehmer führt aus, daß Simulation nicht allgemein als Modellbildung, sondern als Schreiben von Zustandsgeschichten verstanden wird. In vier Beiträgen von Mitgliedern des Panels wird der Methodencharakter von Learning by Döing bestritten. Ein Teilnehmer bedauert, daß " (...) der alte Quatsch Learning by Döing und dann auch noch mit der Erläuterung Wissenstransfer durch Unternehmensberatung immer noch drin steht". Für ihn ist es nicht nachvollziehbar, wie man hierin eine Forschungsmethode sehen kann. Diesem Argument schließen sich drei weitere Teilnehmer an. Dieser Kritik wird in zwei Beiträgen entgegengehalten, daß Learning by Döing auch Action Research genannt wird, und dann eine Methode der sozio-technischen Gestaltung ist, die anerkennt, daß soziale Situationen einmalig sind und Gestaltung, die über Prototypenbau hinausgeht, eine Veränderung im organisatorischen Gefüge hervorruft. Die Gleichsetzung der Begriffe Learning by Döing, Action Research und Beratung wird von diesem Teilnehmer jedoch als zumindest problematisch erkannt. Weiterhin soll Döing im Sinne von Prototypenentwicklung und Sammeln von Erfahrungen verstanden werden, da früh erkannte Fehler die billigsten sind. Ein Teilnehmer bemerkt zum Punkt Entwicklung und Test von Prototypen, daß Informatiker und kommerzielle Unternehmen Prototypen professioneller

W u r d e erst in Runde vier eingeführt.

Zur Entwicklung

der Forschungsmethoden

und Theoriekerne

der Wirtschaftsinformatik

47

entwickeln können als Wirtschaftsinformatiker. Diesem Standpunkt wird entgegnet, daß dies nur der Fall ist, wenn sie den betriebswirtschaftlichen Sachverhalt durchschaut haben, was nicht a priori gegeben ist. 3.2.2

Befragung nach der

AHP-Methode

Der von vielen Teilnehmern der Delphi-Befragung geäußerten Kritik, Forschungsmethoden seien nicht unabhängig vom jeweiligen Forschungsgegenstand bewertbar, wird mit einer AHP-Befragung Rechnung getragen, bei der nach den vier zentralen Forschungsgegenständen (vgl. Abschnitt 3.1) differenziert wird. Zwei Teilnehmer lehnten auch dieses Konzept mit dem Hinweis ab, die Eignung alternativer Forschungsmethoden sei ausschließlich mit Bezug auf die ganz konkrete Fragestellung bewertbar 18 . Um zu einer noch zumutbaren Anzahl von AHP-Fragen (Paarvergleichen) zu gelangen 19 , werden die in der Delphi-Befragung auf den vordersten Rängen ermittelten konstruktiven und empirischen Forschungsmethoden nach sachlicher Zusammengehörigkeit in vier Clustern zusammengefaßt, wobei die Unterteilung in konstruktive bzw. empirische Methoden aufgegeben wird (die vorbeschriebene Kritik der Mitglieder des Panels bezüglich der Trennschärfe der einzeln genannten Methoden respektive bezüglich bestehender Abhängigkeiten legte dies nahe): • Entwicklung und Test von Prototypen, Simulation, Laborexperimente • Learning by Döing Kreativitätstechniken,

(Wissenstransfer

durch

Unternehmensberatung),

• Deduktion, • Fall- und Feldstudien, Beobachtung (z.B. des Anwender- oder Systemverhaltens), mündliche oder schriftliche Befragungen. Die AHP-Befragung ergab folgende relative Bedeutungen dieser Methodencluster für die vier wichtigsten Ausrichtungsalternativen der Wirtschaftsinformatik (die wichtigsten Forschungsgegenstände), um die Wettbewerbsposition der Wirtschaftsinformatik zu halten oder auszubauen (siehe Tabelle 7): Aggregiert man die relative Bedeutung der Methodencluster, so erhält man die in Abbildung 1 dargestellten Gewichte der untersten Zeile, wonach "1" mit 36,01%, "2" mit 17,56%, "3" mit 19,67% und "4" mit 26,76% bewertet werden.

Sie negieren damit die mögliche Existenz von Merkmalen, die eine allgemeine G r u p p i e r u n g F o r s c h u n g s g e g e n s t ä n d e bezüglich zu deren B e f o r s c h u n g geeigneter F o r s c h u n g s m e t h o d e n zulassen.

Ein f ü n f t e s Cluster w ü r d e z.B. zu 4 0 anstatt 2 4 Fragen (Paarvergleichen) führen.

konkreter

48

Wolfgang König, Armin Heinzl, Marcus-Julian

relative B e d e u t u n g d e r M e t h o d e n c l u s t e r Organisationslehre

1. E n t w i c k l u n g und T e s t von Prototypen, Simulation, Laborexperimente

31,67%

Rumpf, Ansgar von

Poblotzki

Funktionale Betriebswirtschaftslehre

Informationswissenschaft

Innovationswissenschaft

33,28%

34,84%

49,29%

2. L e a r n i n g by D o i n g ( W i s s e n s t r a n s f e r durch Unternehmensberatung), Kreativitätstechniken 3.

Deduktion

19,61%

16,88%

13,95%

17,85%

20,96%

18,31%

23,37%

15,22%

27,76%

31,53%

27,84%

17,64%

4. Fall- u n d F e l d s t u d i e n , B e o b a c h t u n g (z.B. d e s A n w e n d e r - oder Systemverhaltens), mündliche oder schriftliche Befragungen.

Tabelle 7:

Die relative Bedeutung von Forschungsmethoden

Es fällt auf, daß der Methodencluster "Prototypen, Simulation, Laborexperimente" mit Abstand an der Spitze liegt, während der Methodencluster "Deduktion" den vorletzten Platz einnimmt, nur knapp vor dem heftig umstrittenen Methodencluster "Learning by Döing und Kreativitätstechniken". 20 Wie lassen sich nun die Gewichte in Abbildung 1 inhaltlich interpretieren? Die Akzeptanz in der "Wissenschaft", d.h. die Präsenz in namhaften wissenschaftlichen Zeitschriften, auf Tagungen und in der Deutschen Forschungsgemeinschaft, trägt zu 26% zur Wettbewerbsfähigkeit der Wirtschaftsinformatik bei. Die inhaltliche Ausrichtung der Wirtschaftsinformatik mit einem starken "Bezug zur Organisationslehre" trägt zu 38% zur Wettbewerbsfähigkeit der Wirtschaftsinformatik bei, aggregiert über die vier darüberliegenden Wissenschaftsmärkte und deren Gewichte. Der Methodencluster "Prototypen, Simulation und Laborexperimente" trägt wiederum zu 36% zur Wettbewerbsfähigkeit der Wirtschaftsinformatik bei, aggregiert über alle vier hier betrachteten inhaltlichen Ausrichtungsoptionen der Wirtschaftsinformatik sowie über die vier hier betrachteten Wissenschaftsmärkte. Die Methodencluster und deren Gewichtung im Rahmen des AHP werden von einigen Mitgliedern des Panels heftig diskutiert und kritisiert; dies reichte in Einzelfällen bis hin zur Verweigerung der weiteren Mitarbeit. Ein Teilnehmer ist der Meinung, daß Learning by Döing keine Forschungsmethode ist und bewertet deshalb nur teilweise. Für drei weitere Mitglieder des Panels sind die Fragen unzulässig, da völlig heterogene Methoden zu nur einer Alternative vermengt worden sind. Ein Teilnehmer ist der Auffassung, daß sich die

Zu den qualitativen Argumenten siehe spätere Ausführungen.

Zur Entwicklung

der Forschungsmethoden

und Theoriekerne

der Wirtschaftsinformatik

49

Forschungsmethode nach der konkreten Fragestellung richtet und nicht nach allgemeinen Forschungsgebieten. Deshalb sind nach seiner Auffassung die Fragen nicht seriös beantwortbar. Drei weitere Mitglieder des Panels beantworten die Fragen nicht oder nur teilweise, ohne dies zu begründen. 3.3

Zukünftige Theoriekerne der Wirtschaftsinformatik

Aus der Analyse der Antworten in der offenen Delphi-Runde eins ergaben sich vier Fragenkomplexe: Die Frage nach der Art des Erkenntnisziels, der Notwendigkeit eines eigenständigen Theoriegebäudes, den Impulsgebern für ein eigenständiges Theoriegebäude und der Fokussierung auf ein eigenständiges Theoriegebäude. Das Moderatorenteam fügte die Frage nach der Bedeutung alternativer Forschungs imperative hinzu. 3.3.1

Befragung nach der Delphi-Methode

Art des Erkenntnisziels Die Abschlußauswertung ergibt folgendes Bild der Einschätzung der Teilnehmer, welches Erkenntnisziel die Wirtschaftsinformatik zukünftig verfolgen soll, um ihre Wettbewerbsposition zu halten oder auszubauen (siehe Tabelle 8).

Art des E r k e n n t n i s z i e l s -

%-AnteilR4

p r a g m a t i s c h e s Erkenntnisziel ( W i e ist in e i n e m b e s t i m m t e n Sachverhalt zu verfahren?)

74%

theoretisches Erkenntnisziel ( W a r u m sind bestimmte S a c h v e r h a l t e genau so?)

26%

Tabelle 8:

Art des Erkenntnisziels

Zwei Mitglieder des Panels betonen, daß das theoretische und das pragmatische Erkenntnisziel gleich wichtig sind. Für einen Teilnehmer hängt die Präferenz vom Untersuchungsgegenstand ab. Ein Teilnehmer ist der Auffassung, daß das pragmatische Erkenntnisziel das theoretische Erkenntnisziel impliziert. Nach Auffassung eines Mitglieds des Panels begründet ein theoretisches Erkenntnisziel unter anderem die Wirtschaftsinformatik als eine Wissenschaft. Vier weitere Teilnehmer schließen sich diesem Argument an. Zwei Teilnehmern ist ein rein pragmatisches Erkenntnisziel zu simpel. Je ein Vertreter der Wissenschaft und der Praxis bemerken, daß nichts so praktisch ist wie eine gute Theorie. Ein Teilnehmer ist der Auffassung, daß die Wirtschaftsinformatik nicht an die Universität gehört, wenn das pragmatische Erkenntnisziel überwiegt.

50

Wolfgang König, Armin Heinzl, Marcus-Julian

Rumpf, Ansgar von

Poblotzki

Nach Ansicht eines Teilnehmers geht es im Grunde um die Frage 'konstruktive Wissenschaft versus Erkenntniswissenschaft'. Ein anderer Teilnehmer erläutert: "Warum klärt Zusammenhänge, wie ohne warum ist 'Im-Nebel-stochern' unter dem Deckmantel der Wissenschaft und Kochbuchschreiben. Das wie verbessern auf Basis von Erkenntnissen zum warum ist ein wissenschaftliches Erkenntnisziel." Notwendigkeit

einer eigenständigen

Theorie der

Wirtschaftsinformatik

Die Abschlußauswertung ergibt folgendes Bild der Einschätzung der Teilnehmer über die Notwendigkeit eines eigenständigen Theoriegebäudes der Wirtschaftsinformatik (siehe Tabelle 9).

Notwendigkeit einer eigenständigen Theorie der Wirtschaftsinformatik %-Anteil R4 -

J a , die Wirtschaftsinformatik benötigt zukünftig ein eigenständiges Theoriegebäude

54%

-

Nein, die Wirtschaftsinformatik soll zukünftig ihr T h e o r i e g e b ä u d e aus anderen Disziplinen beziehen

43%

-

Nein, die Wirtschaftsinformatik braucht keine Theorie

Tabelle 9:

3%

Notwendigkeit einer eigenständigen Theorie der Wirtschaftsinformatik

Ein Mitglied des Panels konstatiert, daß eine Wissenschaft ohne eigenständiges Theoriegebäude keine eigenständige Wissenschaft ist. Ein anderer Teilnehmer schlägt vor, zunächst mehrere Partialtheorien zu entwickeln. Drei Teilnehmer begründen, daß es hinreichend viele gute Theorien gibt, die nur gezielt angewandt werden müssen. Ein Teilnehmer hat keine Hoffnung, daß die Wirtschaftsinformatik in absehbarer Zukunft eine eigene Theorie entwickelt, da es ihr bisher noch nicht gelungen ist. Ein weiteres Mitglied des Panels schließt nicht aus, daß die Wirtschaftsinformatik ein eigenständiges Theoriegebäude entwickelt, hält dies aber nicht für unbedingt erstrebenswert. In einem weiteren Beitrag wird erläutert, daß, aufgrund der auch zukünftig zu fordernden Anwendungsorientierung der Wirtschaftsinformatik, eine Fokussierung auf eine eigene Theorie in die falsche Richtung geht. Ein Teilnehmer stellt fest: "Die Informatik hat nicht die eigene Theorie, die Ökonomie nicht, die Physik nicht, die Medizin nicht. Wie sollte es gelingen, für die Wirtschaftsinformatik eine zu entwickeln? Die Suche nach der blauen

Zur Entwicklung

der Forschungsmethoden

Blume (der Romantik) des Vaterlands ab."

und Theoriekerne

der Wirtschaftsinformatik

51

hält nur fähige Köpfe von einem Beitrag zur Rettung

Impulsgeber für ein eigenes

Theoriegebäude

Die Abschlußauswertung ergibt folgendes Bild der Einschätzung der Teilnehmer, aus welchen Disziplinen die Wirtschaftsinformatik die stärksten Impulse bei der Herausbildung eines eigenen Theoriegebäudes erfahren soll (siehe Tabelle 10).

I m p u l s g e b e r für ein e i g e n e s T h e o r i e g e b ä u d e

X R4

ÖR4

-

Betriebswirtschaftslehre

1.19

0,56

-

Informatik

2,50

0,80

-

Kybernetik/Systemtheorie

3,30

1,10

-

Verhaltenswissenschaften

3,73

1,16

-

Ingenieurwissenschaften

4,19

0,88

Tabelle 10: Impulsgeber für ein eigenes Theoriegebäude (herausgefallen nach Runde drei: Organisationstheorie, Volkswirtschaftslehre, Mathematik, Naturwissenschaften, Rechtswissenschaften) Im Hinblick auf die Informatik wird im Laufe der Diskussion von vier Mitgliedern des Panels zum Ausdruck gebracht, daß Theorien der Informatik der Wirtschaftsinformatik keine starken Impulse geben können, da sie sich nur auf das Verhalten von Maschinen und nicht von Menschen beziehen. Ein Teilnehmer widerspricht diesem Argument, da hier ein veraltetes Bild der Informatik zugrunde liegt. Für einen Teilnehmer sind die Verhaltenswissenschaften wichtig, da es sich bei Informationssystemen um Mensch-Maschine-Systeme handelt und die Rolle der Verhaltenswissenschaften wichtig ist für Akzeptanz und Motivation. Derzeit wird vor allem die Komponente 'Maschine' betrachtet, die Komponente 'Mensch' wird mit dem Begriff 'Nutzer' idealisiert, aber nicht hinreichend differenziert betrachtet. Für ein Mitglied des Panels muß die Betrachtung von Systemen und deren Verhalten wesentlicher Bestandteil der Wirtschaftsinformatik sein. Wirtschafts- und verhaltenswissenschaftliche

Theoriekerne

Die Abschlußauswertung ergibt folgendes Bild der möglichen Impulsgeber aus den Wirtschafts- und Verhaltenswissenschaften zur Entwicklung einer Theorie der Wirtschaftsinformatik (siehe Tabelle 11).

52

Wolfgang König, Armin Heinzl, Marcus-Julian

Wirtschafts- und verhaltenswissenschaftliche Theoriekerne -

Organisationstheorie, insbesondere Ablauforganisation Entscheidungstheorie Neuere Institutionenlehre Dezentralisierungstheorie Branchentheorien

Rumpf, Ansgar von

X R4

K M , welche die Komponentenmenge Ko des Objektsystems S 0 in die Komponentenmenge KM des Bildsystems S M abbildet. Um Struktur- und Verhaltenstreue zwischen S 0 und S M zu erreichen, sind isomorphe oder homomorphe Modellabbildungen f zu verwenden [Dink73],

126

Abb. 1:

Elmar Sinz

Modell und Meta-Modell

Die Abbildung f ist naturgemäß nur auf formalen Systemen definiert. Im vorliegenden Fall ist aber das Objektsystem S 0 , das betriebliche Informationssystem, ein Ausschnitt eines realen betrieblichen Systems. Das zugehörige Modellsystem S M ist ein formales System. Die Modellabbildung f und die Eigenschaften der Struktur- und Verhaltenstreue sind daher nur informal spezifizierbar und nachprüfbar. An die Stelle der formalen Konstruktion eines Modellsystems tritt die „Kunst des Modellierens". In welcher Weise kann diese Kunst unterstützt werden, um nicht einfach zu einem Kunstwerk im Wortsinne, sondern zu einem möglichst guten Modellsystem gemäß den obigen Eigenschaften zu gelangen? Die Beantwortung dieser Frage führt zum Begriff des Meta-Modells. 2.2

Meta-Modelle als Beschreibungsrahmen für Modellsysteme

Für Modelle betrieblicher Informationssysteme kann der Definitionsbereich der Modellabbildung f aufgrund der realen Objektsysteme S 0 nicht formal angegeben werden. Für den Wertebereich, d.h. für die formalen Modellsysteme SM ist dies hingegen möglich. Dieser Wertebereich wird in Form eines Meta-Modells spezifiziert. Ein Meta-Modell stellt eine Typdefinition für eine Klasse von Modellsystemen dar. Jedes Modellsystem ist eine Instanz eines Meta-Modells. Aus der Sicht des Modellierers gibt ein Meta-Modell somit den Beschreibungsrahmen für Modellsysteme S M vor (Abb. 1). Hierzu spezifiziert das MetaModell die verfügbaren Arten von Modellbausteinen, die Arten von Beziehungen zwischen Modellbausteinen, die Regeln für die Verwendung von Modellbausteinen und Beziehungen sowie die Bedeutung der Modellbausteine und Beziehungen [FeSi94, 86], Das Meta-Modell unterstützt die Kunst des Modellierens damit in zweifacher Hinsicht: • In bezug auf das Meta-Modell kann die Konsistenz und Vollständigkeit des Modellsystems überprüft werden.

Ansätze zur fachlichen

Modellierung

betrieblicher

Informationssysteme

127

• Anhand des Meta-Modells kann die Struktur- und Verhaltenstreue des Modellsystems in bezug auf das Objektsystem überprüft werden. Dies setzt voraus, daß das Meta-Modell ein Begriffsystem bereitstellt, dessen Semantik sich möglichst nahe am Objektsystem orientiert, d.h. dessen Begriffe ein fachkundiger Modellierer zielorientiert und sicher aus dem Objektsystem rekonstruieren kann. Neben dem Auffinden der Modellobjekte und -beziehungen muß ein MetaModell die Bewältigung der Komplexität des Modellsystems unterstützen. Für die extensionale Komplexität, d.h. die Menge der Instanzen zu den einzelnen Modellbausteinen, erfolgt dies durch Teilsystem- und Hierarchiebildung. Für die typmäßige Komplexität, d.h. die (Dimensions-) Vielfalt der Modellbausteine, erfolgt dies durch die Bildung von Sichten. Für das Meta-Modell selbst ist in Abhängigkeit von den verfolgten Modellierungszielen eine geeignete Komplexität zu wählen. Es gilt der Grundsatz: so komplex wie nötig, so einfach wie möglich. 2.3

Sichten auf Modellsysteme

Aufgrund ihrer typmäßigen Komplexität ist es im allgemeinen nicht möglich, Modellsysteme in einer einzigen, geschlossenen Darstellung gegenüber dem Betrachter zu präsentieren. Ein Modellsystem wird daher in mehreren Sichten dargestellt, die zusammen eine vollständige Beschreibung des Modellsystems ergeben. Ein klassisches Beispiel hierfür ist eine technische Zeichnung, die ein geometrisches Objekt mit räumlicher Ausdehnung in (x,y,z)-Koordinaten beschreibt (Abb. 2, links). Das zugehörige Meta-Modell umfaßt als Modellbausteine unterschiedliche Arten von Linien in diesem dreidimensionalen Raum. Die Linien werden spezialisiert zu sichtbaren (durchgezogenen), unsichtbaren (gestrichelten) und Hilfslinien (Strich-Punkt-Linien). Die einzelnen Sichten sind Projektionen auf jeweils zwei Koordinaten des Koordinatensystems unter Beachtung der Sichtbarkeit der Linien: eine (x,y)-Frontansicht (Aufriß), eine (y,z)-Seitenansicht (Seitenriß) und eine (x,z)-Draufsicht (Grundriß). Die Bildung dieser Sichten dient der Bewältigung der typmäßigen Komplexität: ein dreidimensionales Objekt wird in drei zweidimensionalen Sichten spezifiziert. Anhand dieser drei Sichten baut ein geschulter Betrachter in seiner Vorstellung ein räumliches Bild des geometrischen Objekts auf. Voraussetzung dafür ist, daß die einzelnen Sichten in sich und zueinander konsistent sind. In Abb. 2 (links) ist diese Konsistenz nicht erfüllt. Alle Sichten sind zwar in sich konsistent, auch sind Draufsicht und Frontsicht sowie Draufsicht und Seitensicht zueinander konsistent, die Konsistenz zwischen Frontsicht und Seitensicht ist hingegen nicht erfüllt.

128

Elmar

Funktionssicht

Sinz

Datensicht

X J ^ f

Abb. 2:

Sichten von Modellsystemen

Auch im Bereich betrieblicher Informationssysteme werden Modellsysteme aus Gründen typmäßiger Komplexität in mehreren Sichten dargestellt. Abb. 2 (rechts) symbolisiert einen Ausschnitt aus einem fachlichen Modellsystem in Form einer Funktionssicht und einer zugehörigen Datensicht. Analog zum Beispiel der technischen Zeichnung sollte ein geschulter Betrachter in der Lage sein, aus diesen Sichten ein ,Räumliches Bild" des Modellsystems eines betrieblichen Informationssystems aufzubauen. Ein Modellierungsansatz für betriebliche Informationssysteme ist umso geeigneter, je besser er die Erreichung der Struktur- und Verhaltenstreue zwischen Modellsystem und Objektsystem sowie die Beherrschung der Komplexität des Modellsystems in bezug auf die Erreichung der Modellierungsziele unterstützt. Notwendige Voraussetzung hierfür ist ein geeignetes, integriertes Meta-Modell für das Modellsystem, auf dem geeignete Sichten in Form von Projektionen spezifiziert sind und anhand dessen die Konsistenz und Vollständigkeit der Sichten in sich und zueinander überprüft werden kann. Leider wird diese Voraussetzung durch zahlreiche Modellierungsansätze nicht e rfüllt: • Vielfach liegen formale Meta-Modelle nur für die einzelnen Sichten vor. Die Kopplung der Sichten wird lediglich informal beschrieben. • Selbst die Meta-Modelle für die Sichten sind in vielen Fällen nur informal beschrieben. Informale Beschreibungen von Meta-Modellen sind im allgemeinen unvollständig und unpräzise. Es ist bemerkenswert, daß selbst weitverbreitete Model-

Ansätze zur fachlichen

Modellierung

betrieblicher

Informationssysteme

129

lierungsansätze, wie z.B. OMT [Rum + 91], ohne zugehörige formale MetaModelle publiziert werden. Alle in Kapitel 3 beschriebenen Modellierungsansätze werden anhand ihrer integrierten Meta-Modelle bzw. der Meta-Modelle ihrer Sichten dargestellt. Soweit nicht publiziert, werden die formalen Meta-Modelle für diese Arbeit entwickelt.

2.4

Meta-Meta-Modelle als Beschreibungsrahmen für Meta-Modelle

Als einheitlicher Beschreibungsrahmen für die einzelnen Meta-Modelle wird das in Abb. 3 dargestellte Meta-Meta-Modell verwendet. Die Bausteine dieses Meta-Meta-Modells sind Meta - Objekt typen, die durch Meta-Beziehungen verknüpft sind. Meta-Beziehungen sind Generalisierungsbeziehungen (is_a), Assoziationsbeziehungen (connects) oder Attribut-Zuordnungsbeziehungen (has). Jede Meta-Beziehung kann mit zwei referentiellen Integritätsbedingungen in Form von fmm./naxJ-Kardinalitäten versehen werden. Ebenfalls angegeben sind die graphischen Symbole für die einzelnen Bausteine.

Abb. 3:

Meta-Meta-Modell

In den einzelnen Abschnitten des folgenden Kapitels werden nun unterschiedliche Ansätze zur Modellierung betrieblicher Informationssysteme anhand ihrer Meta-Modelle beschrieben. Diese Meta-Modelle stellen Instanzen des in Bild 3 dargestellten Meta-Meta-Modells dar.

3

Modellierungsansätze für betriebliche Informationssysteme

Zur Darstellung der Entwicklungslinie von Ansätzen zur Modellierung betrieblicher Informationssysteme werden im folgenden drei Klassen von Modellierungsansätzen ausgewählt und an konkreten Ansätzen beispielhaft erläutert. Die Darstellung erfolgt anhand der zugehörigen Meta-Modelle. Die Entwicklungslinie der Modellierungsansätze wird entlang der in den einzelnen Sichten

130

Elmar Sinz

erfaßten Systemeigenschaften aufgezeigt. Relevante Systemeigenschaften sind der Zustandsraum eines betrieblichen Informationssystems und die darauf verfügbaren Operatoren sowie die zugehörigen Struktur- und Verhaltensmerkmale. Bei den Verhaltensmerkmalen wird zusätzlich nach statischen und dynamischen Merkmalen unterschieden. Um die Original-Terminologie der einzelnen Modellierungsansätze beibehalten zu können, werden die Begriffe Modell (z.B. Objektmodell, Dynamikmodell, Funktionsmodell), Schema (z.B. Datenschema, Funktionsschema) und Sicht (z.B. Datensicht, Steuerungssicht) synonym verwendet. 3.1

Daten- und Funktionsmodellierung

Die fachliche Modellierung betrieblicher Informationssysteme auf der Basis von Daten- und Funktionsmodellen spiegelt das dominierende Modellierungsverständnis der 70er und 80er Jahre wider. Zur Charakterisierung dieser Modellierungsansätze sind dabei folgende Merkmale von Bedeutung: (a) Hinsichtlich der Systemabgrenzung des zu modellierenden Objektsystems So ist die fachliche Modellierung zunächst stärker an Anwendungssystemen, d.h. an den automatisierten Teilsystemen eines Informationssystems orientiert, als am gesamten Informationssystem. Anwendungssysteme werden dabei lediglich als Hilfsmittel zur Unterstützung der Aufgabendurchführung durch den Menschen betrachtet. Erst später wird die fachliche Modellierung auf das gesamte betriebliche Informationssystem erweitert. Ein Beispiel hierfür sind die Anstrengungen im Bereich der (Unternehmensweiten) Datenmodellierung in den 80er Jahren. Im Zuge dieser Entwicklung werden Mensch und Maschine zunehmend als gleichrangige Aufgabenträger zur Durchführung betrieblicher Aufgaben betrachtet. (b) Hinsichtlich der verwendeten Meta-Modelle ist die fachliche Modellierung deutlich von den vorherrschenden Paradigmen der Programmierung beeinflußt. Die Programmierung kommerzieller Anwendungssysteme in den 70er Jahren ist durch Programmiersprachen wie COBOL geprägt. In den Programmen herrscht eine strikte Trennung von Daten (DATA DIVISION) und Funktionen (PROCEDURE DIVISION) vor. Die Funktionen operieren auf einem globalen Datenraum. Auch im Bereich der Datenbanksysteme findet sich dieses Verständnis eines globalen Datenraumes in Form der Drei-Ebenen-Architektur, wo über einem globalen konzeptuellen Datenschema externe Schemata zur Unterstützung der einzelnen Anwendungsfunktionen gebildet werden. Als vorherrschende Integrationsform für Anwendungssysteme wird die Datenintegration verwendet, bei der Anwendungssysteme über gemeinsame Speicherbereiche kommunizieren [FeSi94, 203ff|.

Ansätze zur fachlichen

Modellierung

betrieblicher

Informationssysteme

131

Die fachliche Modellierung betrieblicher Informationssysteme auf der Grundlage von Daten- und Funktionsmodellierung stellt nach wie vor einen QuasiStandard dar und wird von vielen der heute im Einsatz befindlichen CASETools unterstützt. 3.1.1

Entity-Relationship-Modell

Der wichtigste Modellierungsansatz für die Datenmodellierung, d.h. für die Modellierung der Datensicht betrieblicher Informationssysteme, ist das EntityRelationship-Modell (ERM) [Chen76], Die Darstellung der Datensicht erfolgt in Entity-Relationship-Diagrammen. Das zugehörige Meta-Modell ist in Abb. 4 dargestellt. Das ERM unterscheidet zwei Arten von Datenobjekttypen, Gegenstandsobjekttypen (Entity-Typen) und Beziehungsobjekttypen (RelationshipTypen). Jede Beziehung verknüpft einen Gegenstandsobjekttyp mit einem Beziehungsobjekttyp. Ein Beziehungsobjekttyp besitzt mindestens zwei Beziehungen zu Gegenstandsobjekttypen. Jedem Gegenstandsobjekttyp ist mindestens ein Attribut zuzuordnen, einem Beziehungsobjekttyp können Attribute zugeordnet werden. Referentielle Integritätsbedingungen werden durch Kardinalitäten an den Beziehungen spezifiziert.

|Kand.| Abb. 4:

Meta-Modell für das Entity-Relationship-Modell (ERM) (vereinfacht)

Ein Entity-Relationship-Diagramm besteht somit aus Datenobjekttypen und Beziehungen zwischen Datenobjekttypen. Datenobjekttypen spezifizieren Teilzustandsspeicher (Datenobjekte) gleichen Typs, die Beziehungen spezifizieren die Strukturbeziehungen zwischen den Teilzustandsspeichern. Das Daten-

132

Elmar Sinz

Schema spezifiziert damit den Zustandsraum eines betrieblichen Informationssystems. Zum ERM existiert eine Vielzahl von Varianten. Das Meta-Modell in Abb. 4 zeigt ein General Entity-Relationship-Modell (GERM) mit beliebigstelligen Beziehungen und Attributen sowohl an Gegenstands- als auch an Beziehungsobjekttypen. Varianten lassen sich u.a. durch Einschränkungen der Stelligkeit von Beziehungen und der Zuordnung von Attributen bilden [Chen83]. Z.B. entsteht durch Änderung der Kardinalität von Beziehungsobjekttyp zu Beziehung von (2,*) in (2,2) ein Binary Entity-Relationship-Modell (BERM) mit zweistelligen Beziehungen. Vielfach sind bei BERM Attribute an Beziehungsobjekttypen unzulässig. Zu weiteren Varianten des ERM siehe [Sinz90]. 3.1.2

Strukturierte

Analyse

Einer der am weitesten verbreiteten Ansätze für die Funktionsmodellierung ist die Strukturierte Analyse (SA) [DeMar79]. Sie dient der Modellierung der Funktionssicht betrieblicher Informationssysteme in Form von Datenflußdiagrammen. Das Meta-Modell für SA ist in Abb. 5 dargestellt.

Abb. 5:

Meta-Modell für die Strukturierte Analyse (vereinfacht)

Ein Funktionsschema gemäß SA besteht aus Aktivitäten, die durch Datenflüsse verknüpft sind. Zur Pufferung von Datenflüssen sind Speicher vorgesehen. Terminatoren stellen Schnittstellen zur Umwelt des Informationssystems dar. Ein Datenfluß verbindet entweder zwei Aktivitäten, eine Aktivität und einen Speicher oder eine Aktivität und einen Terminator. SA stellt ein Hierarchiemodell bereit, welches auf der Zerlegung von Aktivitäten und einer korrespondierenden Verfeinerung von Datenflüssen beruht.

Ansätze zur fachlichen Modellierung

betrieblicher

Informationssysteme

133

Ein Datenflußdiagramm spezifiziert die Operatoren auf dem Zustandsraum eines betrieblichen Informationssystems. Diese Operatoren werden hinsichtlich ihrer Struktur und ihres statischen Verhaltens beschrieben. Weitere Ansätze zur Funktionsmodellierung sind Weiterentwicklungen von SA durch

WARD

und

MELLOR

(SA/RT)

[WaMe86]

sowie

MCMENAMIN

und

PALMER [MePa88], In die gleiche Klasse von Modellierungsansätzen gehört auch Structured Analysis and Design Technique (SADT). 3.1.3

Verknüpfung von SA und ERM

Die Modellierungsansätze SA und ERM wurden getrennt entwickelt. Ihre Verknüpfung zu einem fachlichen Modellierungsansatz für betriebliche Informationssysteme erfolgte meist unter pragmatischen Gesichtspunkten und wurde insbesondere durch die Entwicklung von CASE-Tools vorangetrieben. Eine einheitliche, anhand eines integrierten Meta-Modells begründete Kopplungsform ist nicht erkennbar. Eine Form der Kopplung besteht darin, jedem SA-Speicher einen Ausschnitt aus einem ERM-Schema als externes Schema (View-Schema) zuzuordnen. Aktivitäten stellen dann Operatoren ohne Speicher dar und werden ausschließlich über ihr Input-Output-Verhalten beschrieben. Eine alternative Kopplungsform besteht in der Zuordnung externer Schemata zu Aktivitäten, Datenflüssen und Speichern. Diese Form unterstützt Aktivitäten mit Speicher, relativiert allerdings die Existenzberechtigung des SA-Speichers als Modellbaustein und schafft überdies Konsistenzprobleme. 3.1.4

Diskussion von SA und ERM

Aufgrund der methodisch unzureichend begründeten Kopplung zwischen dem in der Datensicht beschriebenen Zustandsraum eines betrieblichen Informationssystems und den in der Funktionssicht beschriebenen Operatoren ist es im allgemeinen schwer, die eingangs geforderte „räumliche Vorstellung" aufzubauen. Im allgemeinen fehlt ein integriertes Meta-Modell, anhand dessen die Datensicht und die Funktionssicht durch Projektionen ableitbar sind. Die Konsistenz und Vollständigkeit der Datensicht in bezug auf die Funktionssicht und umgekehrt ist daher nur schwer überprüfbar. Daraus folgt, daß auch die Struktur- und Verhaltenstreue des Modellsystems gegenüber dem Objektsystem nur unzureichend validiert werden kann. Hinzu kommt eine unzureichende Unterstützung bei der Komplexitätsbewältigung, da zwar SA ein Hierarchiemodell bereitstellt, ein entsprechendes Äquivalent auf der Seite von ERM aber fehlt.

134

3.2

Elmar Sinz

Objektorientierte Modellierung

Seit Anfang der 90er Jahre werden verstärkt objektorientierte Ansätze zur fachlichen Modellierung betrieblicher Informationssysteme diskutiert. Auch im Bereich der Objektorientierung zeichnet sich eine historische Entwicklungslinie von der objektorientierten Programmierung (siehe z.B. [Cox86]), über den objektorientierten Softwareentwurf (siehe z.B. [Meye88]) zur objektorientierten fachlichen Modellierung ab. Aus der Sicht der fachlichen Modellierung sind insbesondere folgende Konzepte des objektorientierten Paradigmas von Interesse: • Kapselung von Zustandsraum und darauf definierten Operatoren einschließlich der zugehörigen Struktur- und Verhaltensbeschreibungen entsprechend dem Konzept des Abstrakten Datentyps. • Lose Kopplung von Objekten, d.h. Interaktion von Teilsystemen durch Nachrichten. • Generalisierungsstrukturen, die eine Vererbung von Struktur und Verhalten unterstützen. • Aggregationsstrukturen zur Bildung komplexer Objekte. Ein derzeit intensiv diskutierter Modellierungsansatz zur objektorientierten Modellierung betrieblicher Informationssysteme ist OMT [Rum+91]. Bei OMT wird das Modellsystem in drei Sichten beschrieben, die in nachstehender Hauptreihenfolge entwickelt werden: Objektmodell, Dynamikmodell und Funktionsmodell. Die drei Sichten werden als zueinander orthogonal betrachtet. Beispiele für weitere Ansätze zur objektorientierten Modellierung betrieblicher Informationssysteme sind OOS A [ShMe92] und OOSE [Jaco+92], 3.2.1

Objektmodell von OMT

Ein Objektmodell gemäß OMT besteht im wesentlichen aus Klassen und Beziehungen zwischen Klassen. Klassen werden durch Attribute und Operatoren spezifiziert und als Mengen typgebundener Objekte verstanden. Beziehungen treten in Form von Assoziationsbeziehungen, Generalisierungsbeziehungen und Aggregationsbeziehungen auf. Den Assoziationsbeziehungen können ebenfalls Attribute und Operatoren sowie Rollenbezeichnungen zugeordnet werden. Das zugehörige Meta-Modell ist in Abb. 6 dargestellt. Aus systemtheoretischer Sicht beschreibt das Objektmodell den Zustandsraum eines betrieblichen Informationssystems. Dabei werden Klassen, aber auch

Ansätze zur fachlichen

Modellierung

betrieblicher

135

Informationssysteme

Assoziationsbeziehungen als Mengen typisierter Teilzustandsspeicher (Objekte) betrachtet, die durch Strukturbeziehungen verknüpft sind. Zusätzlich spezifiziert das Objektmodell die Operatoren auf den Teilzustandsspeichern und beschreibt damit deren statisches Verhalten. Klasso

•

V

V

Beziehung

•I Attribut | | Operatl

Awozlattor

Generali- 1 stotung [

Aggregaten 0-

Attribut | Operatl Roto-l| | Rote-2| Abb. 6: 3.2.2

Meta-Modell für das Objektmodell von OMT (vereinfacht) Dynamikmodell

von OMT

Ein Dynamikmodell gemäß OMT spezifiziert Zustände von Objekten sowie Ereignisse, welche Zustandsübergänge auslösen. Den Zuständen sind zeitraumbezogene Aktivitäten zuordenbar, die ein Objekt während des Verharrens in einem Zustand ausführt. Außerdem können zeitpunktbezogene Aktionen mit dem Erreichen (E-Aktionen) oder Verlassen (A-Aktionen) eines Zustands verknüpft werden. Statt dem jeweiligen Zustand können diese Aktionen auch direkt den Ereignissen zugeordnet werden. Das Meta-Modell für das Dynamikmodell ist in Abb. 7 dargestellt. Aus systemtheoretischer Sicht beschreibt das Dynamikmodell damit einen Teil des dynamischen Verhaltens von Teilzustandsspeichern. Durch die Beschreibung der Zustandsübergänge von Teilzustandsspeichern wird gleichzeitig der im Objektmodell beschriebene Zustandsraum auf zulässige und erreichbare Zustände begrenzt.

136

Elmar Sinz

l/WVkttod Abb. 7: 3.2.3

Meta-Modell für das Dynamikmodell von OMT (vereinfacht) Funktionsmodell von OMT

Ein Funktionsmodell gemäß OMT besteht aus Prozessen (Funktionen), Handlungsobjekten und Datenspeichern, die durch Datenflüsse verknüpft sind. Das zugehörige Meta-Modell ist in Abb. 8 dargestellt. Es besteht eine offensichtliche Analogie zu Datenflußdiagrammen gemäß SA (siehe Abschnitt 3.1.2). Eine Erweiterung gegenüber SA stellen die aus SA/RT übernommenen Kontrollflüsse dar, die ausschließlich Prozesse verbinden und zur Modellierung von Reihenfolgebeziehungen bei der Durchführung von Prozessen verwendet werden.

Abb. 8:

Meta-Modell für das Funktionsmodell von OMT (vereinfacht)

Ansätze zur fachlichen

Modellierung

betrieblicher

Informationssysteme

137

Aus systemtheoretischer Sicht beschreibt das Funktionsmodell die Struktur und das statische Verhalten der Operatoren auf dem im Objektmodell spezifizierten Zustandsraum des Informationssystems. Darüber hinaus wird mit Hilfe der Kontrollflüsse das dynamische, objektübergreifende Verhalten von Operatoren modelliert, welches nicht im Dynamikmodell spezifiziert werden kann. 3.2.4

Verknüpfung von Objekt-, Dynamik- und

Funktionsmodell

In [Rum + 91] sind keinerlei formale Meta-Modelle angegeben. Während die Meta-Modelle für die drei Sichten Objekt-, Dynamik- und Funktionsmodell relativ einfach aufstellbar sind, kann ein vollständiges, integriertes Meta-Modell nur begrenzt rekonstruiert werden. Es findet sich lediglich eine informale Beschreibung wichtiger Beziehungen zwischen den Teilmodellen. So korrespondiert z.B. ein Operator einer Klasse des Objektmodells mit einem Ereignis des Dynamikmodells. Jede Aktion des Dynamikmodells ist wiederum als Prozeß des Funktionsmodells zu beschreiben. Objekte bzw. Attribute von Objekten im Objektmodell korrespondieren mit Datenspeichern des Funktionsmodells. 3.2.5

Diskussion von OMT

Durch die Zusammenführung von Zustandsraum und Operatoren auf Teilzustandsspeichern im Objektmodell sowie durch Generalisierungs- und Aggregationsstrukturen weist OMT wichtige Merkmale objektorientierter Modellierungsansätze auf. Ansonsten ist OMT stark am klassischen Modellierungsparadigma der Daten- und Funktionsmodellierung orientiert. Dies wird besonders in der Analogie zwischen OMT-Funktionsmodell und SA deutlich. Eine durchgängige Objektorientierung wird nicht erreicht, da es nicht möglich ist, ein betriebliches Informationssystem auf beliebigen Detaillierungsebenen als System lose gekoppelter Objekte zu beschreiben. Die Steuerung des Systems, d.h. die Spezifikation des dynamischen Verhaltens, ist auf mehrere Teilmodelle verteilt. Die Prüfung auf Konsistenz und Vollständigkeit des Modellsystems wird durch das Fehlen eines integrierten Meta-Modells sowie dadurch erschwert, daß eine Vollständigkeit der Teilmodelle zueinander überhaupt nicht gefordert wird. Z.B. geht OMT nicht davon aus, daß das Dynamikmodell bezüglich des Objektmodells vollständig modelliert wird. Da die Teilmodelle in der Reihenfolge Objektmodell, Dynamikmodell, Funktionsmodell entwickelt werden, wird dadurch auch die Spezifikation des Funktionsmodells erschwert. Eine „räumliche Vorstellung" des Informationssystems wird nur bedingt unterstützt.

138

3.3

Elmar Sinz

Geschäftsprozeßorientierte Modellierung

Die jüngste Entwicklung im Bereich der fachlichen Modellierung betrieblicher Informationssysteme sind geschäftsprozeßorientierte Modellierungsansätze. Sie markieren den Übergang von einer primär statischen und strukturorientierten zu einer dynamischen und verhaltensorientierten Betrachtung der Unternehmung [FeSi93]. Gleichzeitig wird versucht, ein möglichst umfassendes Modellsystem aufzubauen. Dabei wird der Modellumfang über das Informationssystem hinaus auch auf weitere Merkmale eines betrieblichen Systems erweitert. Im folgenden werden zwei geschäftsprozeßorientierte Modellierungsansätze vorgestellt. 3.3.1

ARIS

In ARIS [Sche95] werden Geschäftsprozesse in Form einer Datensicht, einer Funktionssicht und einer Organisationssicht modelliert. Die Beziehungen zwischen diesen drei Sichten werden durch eine vierte Sicht, die Steuerungssicht, geschäftsprozeßorientiert hergestellt. Die Steuerungssicht fokussiert dabei auf den Ablauf der Geschäftsprozesse. Die Meta-Objekte des Meta-Modells von ARIS (Abb. 9) sind zunächst relativ allgemein gehalten, da für die Spezifikation der einzelnen Sichten unterschiedliche konkrete Modellierungsansätze einsetzbar sein sollen. In [Sche95] wird z.B. die Datensicht mit einem erweiterten ERM, die Steuerungssicht mit Hilfe Ereignisgesteuerter Prozeßketten (EPK) modelliert.

Abb. 9:

Meta-Modell für ARIS (fachliche Ebene) (nach [Sche95])

Die Datensicht von ARIS beschreibt wiederum den Zustandsraum eines betrieblichen Informationssystems einschließlich der Strukturbeziehungen

Ansätze zur fachlichen

Modellierung

betrieblicher

Informationssysteme

139

zwischen den Teilzustandsspeichern. Die Funktionssicht enthält die Operatoren auf dem Zustandsraum und spezifiziert deren Struktur und statisches Verhalten. Gleichzeitig wird die Bearbeitungsform der Funktionen (manuell, DV-gestützt) und die Zugehörigkeit von Funktionen zu Geschäftsprozessen erfaßt. Die Organisationssicht spezifiziert in Form von Organisationseinheiten Aufgabenträger für die Verwaltung von Informationsobjekten und für die Durchführung von Funktionen. Die Steuerungssicht spezifiziert das Zusammenwirken der drei genannten Sichten in bezug auf den Ablauf von Geschäftsprozessen. Sie beschreibt somit das dynamische Verhalten von Geschäftsprozessen. 3.3.2

Diskussion von ARIS

ARIS stellt ein integriertes Meta-Modell bereit, aus dem die einzelnen Sichten durch Projektion ableitbar sind. Die Verknüpfung der Sichten ist somit klar beschrieben. Bezüglich der Daten- und der Funktionssicht baut ARIS zunächst auf dem klassischen Modellierungsansatz (siehe Abschnitt 3.1) auf. In neuerer Zeit wird aber auch der objektorientierte Modellierungsansatz OMT innerhalb von ARIS eingesetzt. Im Vergleich zu den bisher behandelten Modellierungsansätzen bezieht ARIS neben der Aufgabenebene auch die Aufgabenträgerebene eines betrieblichen Systems in Form der Organisationssicht in die Modellierung ein. 3.3.3

SOM

Der Modellierungsansatz des Semantischen Objektmodells (SOM) [FeSi90, FeSi94, FeSi95] unterscheidet drei Modellebenen: (1) einen Unternehmensplan als Modell der Außensicht eines betrieblichen Systems, (2) Geschäftsprozeßmodelle als Modell der Innensicht eines betrieblichen Systems, wobei Geschäftsprozeßmodelle als Lösungsverfahren für die Realisierung des Unternehmensplans verstanden werden und (3) die Spezifikation von Anwendungssystemen als Ressourcen zur Unterstützung von Geschäftsprozessen. Im folgenden wird lediglich die Ebene der Geschäftsprozeßmodelle näher betrachtet. Im SOM-Ansatz ist ein Geschäftsprozeß durch folgende Merkmale charakterisiert [FeSi95, 214]: (1) er erstellt eine oder mehrere betriebliche Leistungen und übergibt sie an die beauftragenden Geschäftsprozesse, (2) er koordiniert die am Geschäftsprozeß beteiligten betrieblichen Objekte unter Verwendung betrieblicher Transaktionen und (3) er beschreibt den ereignisgesteuerten Ablauf der den betrieblichen Objekten zugeordneten Aufgaben, welche die Transaktionen durchführen. Geschäftsprozeßmodelle sind hierarchisch zerlegbar; bei der

140

Elmar Sinz

Zerlegung werden gleichzeitig Geschäftsprozessen aufgedeckt.

Koordinationsstrukturen

im

Inneren

von

Zur Koordination betrieblicher Objekte mit Hilfe von Transaktionen werden zwei Koordinationsformen verwendet: (1) die nicht-hierarchische Koordination zweier Objekte nach dem Verhandlungsprinzip erfolgt durch Anbahnungs-, Vereinbarungs- und Durchführungstransaktionen; (2) die hierarchische Koordination zweier Objekte nach dem Regelungsprinzip erfolgt durch Steuerund Kontrolltransaktionen. Das Meta-Modell für Geschäftsprozeßmodelle gemäß SOM-Ansatz ist in Abb. 10 dargestellt. Auf diesem Meta-Modell sind die beiden Sichten Interaktionsmodell und Aufgabensystem in Form von Projektionen definiert. Das Interaktionsmodell wird in Form von Interaktionsdiagrammen, das Aufgabensystem in Form von Vorgangs-Ereignis-Netzen spezifiziert. U-Ereigrfs 0 V V Aufgabe

betriebt. _ Objekt g

A

1 1

UmwaKDtskivswett

Interaktlonsmodell

Abb. 10:

O-Eretgnls O Aufgabensystem i 1/ betriebl. Transaktion V V

t

Leistung

VerhandunQsprinztp: AnbatamgrVerdrbarungsDurcMührury»Rageltrtgsprinzlp: SteuerKontro»-

Meta-Modell für Geschäftsprozeßmodelle gemäß SOM-Ansatz

Aus systemtheoretischer Sicht spezifiziert das Interaktionsmodell den Zustandsraum eines betrieblichen Systems sowie die Koordinationsstruktur der daran beteiligten betrieblichen Objekte. Das zugehörige Aufgabensystem spezifiziert das zielorientierte, statische und dynamische Verhalten des betrieblichen Systems.

Ansätze zur fachlichen

Modellierung

betrieblicher

Informationssysteme

141

Die hier nicht weiter ausgeführte objektorientierte Anwendungssystemspezifikation beschreibt in Form eines Konzeptuellen Objektschemas den Zustandsraum eines Anwendungssystems, die Struktur der Teilzustandsspeicher sowie das statische Verhalten der den Teilzustandsspeichern zugeordneten Operatoren. Das Vorgangsobjektschema beschreibt das statische und dynamische Verhalten des Anwendungssystems bei der Durchführung betrieblicher Aufgaben. 3.3.4

Diskussion von SOM

SOM stellt integrierte Meta-Modelle für jede einzelne Modellebene bereit, aus denen die einzelnen Sichten durch Projektion ableitbar sind. Die Beziehungen zwischen den Modellebenen sind anhand von Beziehungs-Meta-Modellen beschrieben. Im Gegensatz zu ARIS verwendet SOM drei Modellebenen für die fachliche Modellierung eines betrieblichen Systems. Durch die explizite Trennung dieser Modellebenen wird es u.a. möglich, alternative Geschäftsprozeßmodelle als Lösungsverfahren für einen gegebenen Unternehmensplan sowie alternative Anwendungssystemspezifikationen als Ressourcen zur Unterstützung eines Geschäftsprozesses zu untersuchen. Der Rahmen dieser Anwendungssystemspezifikationen ist dabei unmittelbar aus dem Geschäftsprozeßmodell ableitbar. Der SOM-Ansatz beruht durchgängig auf dem Paradigma der Objektorientierung und kombiniert diese mit transaktionsorientierten Koordinationsformen für Geschäftsprozesse.

4

Entwicklungstendenzen und zukünftige Anforderungen

Anhand der Entwicklungslinie der in Kapitel 3 beschriebenen Ansätze zur fachlichen Modellierung betrieblicher Informationssysteme lassen sich insbesondere folgende Trends erkennen: • Modellierungsreichweite-. Während bei den frühen Modellierungsansätzen lediglich Anwendungssysteme betrachtet wurden, bezieht sich die Modellierungsreichweite heute im allgemeinen auf das gesamte betriebliche Informationssystem und wird zunehmend auf das gesamte betriebliche System erweitert. Dadurch wird eine ganzheitliche Analyse und Gestaltung betrieblicher Systeme unterstützt. • Modellumfang und Modellintegration: Die verschiedenen Modellebenen sowie die verschiedenen Sichten der einzelnen Modellebenen werden zunehmend integriert und in einem einheitlichen Modellierungskonzept erfaßt. Die Basis hierfür bilden integrierte Meta-Modelle. Dies ermöglicht z.B. eine integrierte Gestaltung von Geschäftsprozessen und Anwendungssystemen.

142

Elmar

Sinz

• Formale Modelleigenschaften: Es ist eine Tendenz zu einer (Semi-) Formalisierung der Modellsysteme zu beobachten. Basis hierfür sind wiederum formale Meta-Modelle. Diese Formalisierung trägt entscheidend zur Präzisierung der Modellsysteme und damit zur Erhöhung ihrer Aussagekraft bei. • Begriffsdomäne: Es ist eine Verlagerung von DV-nahen Begriffsystemen (Entity-Typ, Datenfluß usw.) hin zu problemnahen und betriebswirtschaftlichen Begriffsystemen (Aufgabe, Transaktion) zu beobachten. Dies unterstützt die Validierung von Modellen und ihre Nutzung zur Analyse und Gestaltung betrieblicher Systeme. Aus der beschriebenen Entwicklungslinie folgt die Anforderung nach einer ständigen Weiterentwicklung von Methoden und zugehörigen Werkzeugen. Aus methodischer Sicht sind insbesondere Fragen der Wiederverwendung, der Erweiterung, der Flexibilisierung und der Standardisierung fachlicher Modelle zu untersuchen. Außerdem ist die Frage nach der Komplexitätsbewältigung immer wieder neu zu stellen. So mühsam dieser Weg in Forschung und Praxis auch sein mag, dies sollten die Betriebswirtschaftslehre und die Wirtschaftsinformatik von den Ingenieurdisziplinen lernen: ohne fundierte Modelle ist eine Beherrschung komplexer Systeme nicht möglich.

Literatur [Chen76] Chen P.P.-S.: The Entity-Relationship Model - Toward a Unified View of Data. In ACM Transactions on Database Systems, Vol. 1, No. 1, 1976, S. 9-36 [Chen83] Chen P.P.-S.: A Preliminary Framework for Entity-Relationship Models. In: Chen P.P.-S. (ed.): Entity-Relationship Approach to Information Modeling and Analysis. Proc. 2nd Int. Conf. on Entity-Relationship Approach 1981, North-Holland, Amsterdam 1983, S. 19-28 [Cox86] Cox B.J.: Object-oriented Programming. An Evolutionary Approach. Addison-Wesley, Reading Massachusetts 1986 [DeMar79] DeMarco T.: Structured Analysis and Systems Specification. Prentice Hall, Englewood Cliffs, New Jersey 1979 [Dink73] Dinkelbach W.: Modell - ein isomorphes Abbild der Wirklichkeit? In: Grochla E., Szyperski N. (Hrsg.): Modell- und computergestützte Unternehmensplanung. Wiesbaden 1973, 152 - 162

Ansätze zur fachlichen

Modellierung

betrieblicher

Informationssysteme

143

[FeSi90] Ferstl O.K., Sinz E.J.: Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM). In: WIRTSCHAFTSINFORMATIK 32 (1990) 6, S. 566-581 [FeSi93] Ferstl O.K., Sinz E.J.: Geschäftsprozeßmodellierung. WIRTSCHAFTSINFORMATIK 35 (1993) 6, S. 589-592

In:

[FeSi94] Ferstl O.K., Sinz E.J.: Grundlagen der Wirtschaftsinformatik. Band 1. 2. Auflage, Oldenbourg, München 1994 [FeSi95] Ferstl O.K., Sinz E.J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen. In: WIRTSCHAFTSINFORMATIK 37 (1995) 3, S. 209-220 [Hein93] Heinrich L.J.: Wirtschaftsinformatik. Einführung und legung. Oldenbourg, München 1993

Grund-

[Jaco + 92] Jacobson I., Christerson M., Jonsson P., Övergaard G.: ObjectOriented Software Engineering. A Use Case Driven Approach. AddisonWesley, Workingham, England 1992 [MePa88] McMenamin S.M., Hanser, München 1988

Palmer

J.J.:

Strukturierte

Systemanalyse.

[Meye88] Meyer B.: Object-oriented Software Construction. Prentice Hall, New York 1988 [Rum + 91] Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W.: Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, New Jersey 1991 [Sche95] Scheer A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. 6. Auflage, Springer, Berlin 1995 [ShMe92] Shlaer S., Mellor S.J.: Object Lifecycles: Modeling the World in States. Prentice Hall, Englewood Cliffs, New Jersey 1992 [Sinz90] Sinz E.J.: Das Entity-Relationship-Modell (ERM) und Erweiterungen. In: HMD, Heft 152, März 1990, S. 17 - 29 [WaMe86] Ward P., Mellor S.: Structured Development of Systems. Yourdon Press, Englewood Cliffs, New Jersey 1986

seine

Real-Time

Integration in der Wirtschaftsinformatik

Die Integration der Aufbauorganisation in Workflow-Management-Systeme Heidi Heilmann Betriebswirtschaftliches Institut, Abteilung VII: ABWL und Wirtschaftsinformatik, Universität Stuttgart

Zusammenfassung 1

Eine ganzheitliche Sicht auf Workflow Management

2

Integrationsdimensionen von Workflow Management 2.1 Dimension Workflow-Management-Zyklus 2.2 Dimension Workflow-Management-Reichweite 2.3 Dimension Ressourcenintegration

3

Das Projekt „Elektronisches Prozeßhandbuch" im Software-Labor der Universität Stuttgart 3.1 Das Software-Labor der Universität Stuttgart 3.2 Der Projektbereich Workflow Management

4

Die Integration der Aufbauorganisation 4.1 Zielsetzung 4.2 Objekt-Metamodell 4.3 Unternehmensspezifische Modellsysteminstanzen

Literatur

148

Heidi

Heilmann

Zusammenfassung Eine ganzheitliche, weitgehende Integration anstrebende Sicht auf Workflow Management muß die flexible Einbindung aufbauorganisatorischer Festlegungen und Regeln beinhalten. Ausgehend von einer weitgefaßten Definition werden Integrationsdimensionen von Workflow Management erläutert. Die Aufbauorganisation, die im Mittelpunkt dieses Beitrags steht, bildet dabei eine Komponente der Integrationsdimension „Ressourcenintegration". Es wird gezeigt, welche aufbauorganisatorischen Entitäten und Beziehungen im Rahmen eines Projekts am Software-Labor der Universität Stuttgart für ein Workflow-Management-Tool modelliert werden, und welche alternativen Übernahme- und Anpassungsmöglichkeiten sich für Anwender dieses Tools eröffnen.

1

Eine ganzheitliche Sicht auf Workflow Management

Im üblichen Sprachgebrauch der Wirtschaftsinformatik wird Workflow Management zusammen mit Workgroup Computing als Einsatzkonzept von Computer Supported Cooperative Work (CSCW) verstanden [Hasen94, S.15]. CSCW bezieht sich vorrangig auf kooperatives Arbeiten in kleinen Gruppen, wie die damit verbundenen Begriffe CATeam, Group Support und Groupware deutlich machen. Der im folgenden verwendete Inhalt von Workflow Management ist weiter gefaßt, als Synonym dafür bietet sich Prozeßmanagement an [Hein92, S.428]. Abb. 1 verdeutlicht dies. Auf der strategischen bzw. taktischen Ebene können zunächst Ist-Prozesse mit einem geeigneten Tool modelliert, im Anschluß daran computergestützt analysiert (ggfs. unter Einbezug von Animation und Simulation) und durch eine erneute (Soll-)Modellierung verbessert werden. Der Teilzyklus "Modellierung eines Prozeßtyps - Analyse - neu modellierter Prozeßtyp" kann mehrfach durchlaufen werden. Vorgegebene Ziele und Unternehmensgrundsätze sind dabei zu beachten. Spätere Neumodellierungen können auch durch Umfeldänderungen bedingt sein oder eine kontinuierliche Prozeßverbesserung zum Ziel haben.

Die Integration der Aufbauorganisation

in Workflow-Management-Systeme

149

Vorgangssupertyp

Ziele; Prinzipien der Organisationsentwicklung

Vorgangstyp (1)

Strategische und taktische Ebene Analyse, Soll-IstVergleich, Controlling UmfeldÄnderungen

Protokollierung

Einbindung von Anwendungssystemkomponenten, Dokumentenmanagement, E-Mail, Arbeitsplatzprogrammen

Revision (2) Vorgangsexemplare

Abb. 1: Workflow-Management-Zyklus Wenn ein hinreichend detailliert modellierter Prozeßtyp vorliegt, können Prozeßexemplare auf der operativen Ebene durch Workflow-ManagementSoftware gesteuert werden. Die Software löst die nötigen Arbeitsschritte bei den Aktionsträgern (Mensch oder Computer) aus, reicht die erforderlichen Daten bzw. Dokumente von Prozeßschritt zu Prozeßschritt weiter und stellt die angeforderten IuK-Systeme bereit. Berechtigte Personen können den Status eines Prozesses abfragen und in den Prozeßablauf eingreifen, z.B. Prioritäten verändern, Aufgaben umverteilen, fallweise auch den Prozeßablauf einem Prozeßexemplar anpassen. Parallel zur Steuerung wird der Ablauf jedes Prozeßexemplars protokolliert; ursprünglich diente dies Revisionszwecken, inzwischen werden die protokollierten Exemplardaten aber auch für das Prozeßcontrolling verwendet, z.B. zur Kennzahlenbildung, und können über Soll-Ist-Vergleiche Neumodellierungen von Prozeßtypen auslösen. Von der strategischen über die taktische zur operativen Ebene nimmt der Detaillierungsgrad der modellierten Prozesse ceteris parius zu. Die strategische Ebene konzentriert sich insbesondere auf die im Unternehmen vorhandene begrenzte

150

Heidi

Heilmann

Zahl primärer Kernprozesse, die Leistungen für Kunden erbringen. Auf der taktischen Ebene können Subprozesse dieser Kernprozesse, aber auch Unterstützungsprozesse, ausgewählt werden, die besonders dringend einer Optimierung bedürfen. Diesen beiden Ebenen - zunächst noch ohne operative Steuerung - entsprechen die Begriffe Business (Process) (Re-)Engineering, Process Redesign oder Geschäftsprozeßoptimierung. Die beschriebene Definition von Workflow Management wird durch die Weiterentwicklung dieser Computeranwendung gestützt. Einerseits werden zunehmend Schnittstellen zwischen reinen Modellierungstools und (vorrangig) steuernder Workflow-Management-Software geschaffen, z.B. zwischen ARIS oder Bonapart und IBM-FlowMark bzw. SNI-WorkParty. [Bach95, S.14] fordern aus ähnlichen Überlegungen eine Schnittstelle zwischen Modellierungstools und Workflow-Management-Systemen. Andererseits wird Software aus dem CSCW-Umfeld mit Workflow-Management-Paketen verknüpft [CW30-95], Nach allgemeinem Verständnis ist die Steuerung von Prozeßexemplaren (Vorgangssteuerung) insbesondere für gut strukturierte, arbeitsteilig abgewickelte Prozesse geeignet. Dies mag für die Mehrzahl erster Pilotprojekte in der Praxis gelten, ist aber nur begrenzt begründbar: Prozesse liegen auf einem Kontinuum zwischen vollständiger Strukturiertheit am einen und reiner Ad-hoc-Gestaltung am anderen Ende. Ad-hoc-Gestaltung kann dabei sowohl neue oder selten ausgeführte Prozeßtypen als auch Modifikationen von Prozeßtypen während der Ausführung einzelner Prozeßexemplare betreffen. Vollständig strukturierte Prozeßtypen sind detailliert ausgearbeitet, weitgehend automatisierbar, schnell und mit niedrigen Kosten ausführbar. Die entsprechenden Attribute für Ad-hoc-Prozesse sind niedriger Detaillierungsgrad, Offenheit für Änderungen, sie fördern die Flexibilität der Organisation und versprechen dadurch hohen Nutzen. Prozesse in der Praxis bewegen sich prinzipiell von vollständiger Strukturiertheit weg zu offenen, ad hoc an situative Veränderungen und Sonderfälle anpaßbaren Prozessen. Die Wettbewerbssituation verlangt dies zunehmend, und die heutzutage höhere Mitarbeiterqualifikation [Frese94, S.22] unterstützt diesen Trend.

2

Integrationsdimensionen von Workflow Management

Workflow Management im hier vertretenen Sinn trägt unter verschiedenen Aspekten zur Integration der Informationsverarbeitung bei. Abb. 2 zeigt drei wesentliche Integrationsdimensionen und ihre Kombinationsmöglichkeiten.

Die Integration

der Aufbauorganisation

in Workßow-Management-Systeme

151

1

5

'

1 1

£3 Ca ICjj 5 tl

19 6035 6032 573t 5210 5208

»»

Schreibtisch Briefkasten Ausgangskorb Uiederuorlage-Liste To-Do-Liste fluftr.-Nr. 285785 R e k l . - N r . 310956 ftnf.-Nr. 35272; flnf.-Nr. 360130 finf.-Nr. 360121

Extras

Milte

. . . .

. =|

J

Angebot sarrfrage

Vorgang

ßokument

| -

-

ÜRfe

lOElOll ¡«1 4lianan >»rf nrT>«sc*«f

1 RmUnq

1 2

3

4 V

1.4!

1

2

3

I > > f « 1 Ritkitq l«v>r«t»r: X7)

4

S

»

factltyqadr

W k i r « (ivH: tm m>n»i» J x l - i n r «

I R Textverarbeitung -> Fax usw.) auf diesem Weg erforderlich sind. Anschließend wäre zu fragen, wie hoch der Prozentsatz der Belegschaft ist, der in Folge der Vernetzung bereits in der Lage ist, mit elektronischen Kommunikationsformen wie Electronic Mail, Bulletin Board Systemen, Hypertextsystemen, Informationsdatenbanken etc. umzugehen (und dies auch regelmäßig tut). Aus mehreren dieser Faktoren ließe sich dann der Begriff der „Sichtbarkeit von Information" aggregieren, der einen Anhaltspunkt dafür liefern könnte, wie schnell und mit welchem Aufwand die Mitarbeiter eines Unternehmens an die für ihre Arbeit notwendigen Informationen herankommen können. 7.4

Benutzungskompetenz

Der gesamte westeuropäische IT-Markt hatte nach Beobachtungen des EITO einen Umfang von 130 Milliarden ECU. Darin waren eingeschlossen Umsätze mit Computer Hardware, Software, Dienstleistung und Hardware-Wartung, ausgeschlossen aber noch die Umsätze, die mit Ausrüstung für Telekommunikation und mit Telekommunikationsdiensten erzielt wurden [EIT095, 21]. Angesichts dieser respektablen Zahl ist zu fragen, wie gut die Benutzer in der Lage sind, die Funktionalität der angeschafften Systeme anzuwenden. Es darf vermutet werden, daß in den vorhandenen Hard- und Softwaresystemen noch Reserven hinsichtlich nicht ausgeschöpfter Kapazitäten und nicht verwendeter Funktionalitäten stecken, die durch eine gezielte Erhöhung der Nutzungskompetenz zum Einsatz gebracht werden könnten. Ebenso ließe sich für bestimmte IT-Funktionskomplexe ermitteln, wie oft sie von welchen Anwendern aufgerufen werden. Werden dabei Funktionen erkennbar, die gar nicht oder nur selten verwendet werden, so kann man unter anderem weiterfragen: • Kennen die Benutzer die Funktion überhaupt? • Ist die Funktion zu schwerfällig oder zu fehleranfällig in der Bedienung?

Auf der Suche nach Metriken für das Information

Engineering

365

• Ist die angebotene Informationsmenge zu klein, zu groß oder schlecht strukturiert? • Ist die über diese Funktion erreichbare Information für die entsprechende Anwendergruppe relevant? • Ist die angebotene Information redundant an anderer Stelle erreichbar? • Ist die angebotene Information nicht aktuell genug? 7.5

Zugriffshäufigkeit auf Informationen

Dies führt dann weiter zu der Frage, zu welchem Zeitpunkt (ggf. in welchen Zeitabständen) Informationen erneuert oder gelöscht werden müssen. Aus einer systematischen Beobachtung der Zugriffe auf die Elemente wichtiger Informationsbestände ließen sich Indikatoren über den „Zugriffswert" der gespeicherten Information gewinnen und neben, ggf. in Ergänzung zum Herstellungs- oder Wiederbeschaffungswert, verwenden. Der zeitliche Verlauf dieses Zugriffswertes könnte wiederum Rückschlüsse auf die Alterung und damit auf eine Art „Halbwertszeit" für Information ermöglichen. 7.6

Bindung von Kapital in IT, Aufwand für IT

In den obigen Abschnitten haben wir uns überwiegend mit dem Wert, den Informationen für eine Organisation darstellen können, befaßt. Diese Betrachtungen sind jedoch insbesondere unter wirtschaftlichen Gesichtspunkten nicht vollständig, wenn nicht auch nach den Kosten für die Bereitstellung gefragt wird. Mögliche Meßgrößen für den Aufwand, den ein Unternehmen für seine Informationsinfrastruktur treibt, könnten sein: • Anteil der Informationstechnik am Anlagevermögen • Jährliche Aufwendungen in Informationstechnik gemessen als - Anteil vom Umsatz, - pro Mitarbeiter insgesamt, - pro Mitarbeiter in Produktion/Dienstleistung und - pro Mitarbeiter in der Verwaltung Diese Beispiele sind freilich nur erste globale Ansatzpunkte. 7.7

Spezifische Kosten, spezifischer Ressourcenverbrauch

In Weiterführung der Kosten-/Nutzengedanken glauben wir darüber hinaus, daß es an der Zeit ist, auch im Information Engineering wieder intensiver Überlegungen über den „spezifischen Ressourcenverbrauch" anzustellen (oder über

366

Heinz G. Schwärtzel,

Rupert

Fischer

die „spezifischen Kosten", da Kosten aus dem Ressourcenverbrauch meist direkt ableitbar sind). Maßzahlen wie „Kraftstoffbedarf pro Person und 100 km Wegstrecke", „Leistung pro kg Masse" oder „Energiebedarf zur Herstellung einer Tonne Aluminium" usw. gehören zum unverzichtbaren Handwerkszeug des betreffenden Konstrukteurs bzw. Produktionsleiters. Dagegen dürfte es schwerer fallen, heute aus einem DV-Verantwortlichen ohne nennenswerten Aufwand herauszubekommen, wieviel Übertragungskapazität für den Abgleich einer verteilten Datenbank pro MByte benötigt wird, und ob dieser Wert in einem angemessenen Verhältnis zur geänderten Information steht. Der rapide Preisverfall bei Prozessorleistung, Speicherkapazität und Kommunikationsgeräten hat in den letzten Jahren den Gedanken der sparsamen Ressourcenverwendung im Information Engineering sehr in den Hintergrund gedrängt. Vielerorts hat er schon ganz vergessen lassen, daß Ressourcen eben aufgrund der mit ihnen verbundenen Kosten immer als knappe Güter zu behandeln sind. C. Shannon hat bereits vor mehr als 50 Jahren recht gut dargelegt, was Information eigentlich ausmacht. Nach seinen Definitionen und entsprechenden statistischen Auswertungen beträgt der mittlere Informationsgehalt der deutschen Sprache 4,097 bit/Zeichen. Der vorliegende Text umfaßt ungefähr 23.000 Zeichen und müßte sich damit in ca. 94.000 Bit (entsprechend etwa 12 kByte) speichern lassen. Bis auf Abb. 1 handelt es sich bei den Abbildungen um einfache, grafische Aufbereitungen von Zahlenzusammenhängen, so daß es reichlich erscheint, den Informationsgehalt aller dieser Abbildungen mit weiteren 12 kByte abzuschätzen. Die Textverarbeitungsdatei dieses Manuskripts belegt jedoch 520 kByte und weist damit gemäß Shannon etwas mehr als eine 20fache Redundanz auf. Wir wollen nun nicht prinzipiell den Komfort des zugrundeliegenden Programms wieder gegen die berühmte Kugelkopfschreibmaschine und die ansprechenden Gestaltungsmöglichkeiten gegen das Schere-Klebstoff-Erscheinungsbild früherer Arbeiten tauschen. Wir erlauben uns aber doch in aller Deutlichkeit den Hinweis, daß der Gehalt der transportierten Information sich dadurch nicht ändern würde, und daß demnach zu fragen ist, ob die 20fache Redundanz mit ihren Kosten das Ergebnis rechtfertigt. Noch schlechter wird das Verhältnis, wenn ein gescanntes Bild des Manuskripts aufbewahrt wird. Dafür wären bei 300 dpi und Schwarz-Weiß-Darstellung ungefähr 10 MByte erforderlich und damit eine 400fache Redundanz. Da dabei außerdem noch alle Strukturinformationen (Kopfzeilen, Fußzeilen, Überschriften, Absätze usw.) verlorengingen, muß schon ernsthaft darüber nachgedacht werden, ob die vollständige Digitalisierung und Archivierung kompletter Geschäftsfälle ohne strukturelle Nachbearbeitung und ohne drastische

Auf der Suche nach Metriken für das Information

367

Engineering

Redundanzreduktion vom wirtschaftlichen Standpunkt her - aber auch unter ingenieurmäßiger Betrachtung - sinnvoll ist. Unter Anwendung der elementaren Festlegungen von Shannon kann man in diesem Sinn sicher auch den „Informationsgehalt" für Informationselemente höherer Ordnung (zusammengesetzte und strukturierte Informationen, Datenbankinhalte) definitorisch in den Griff bekommen. Zumindest müßte dies mit einer Genauigkeit gelingen, die für überschlägige Abschätzungen der oben angegebenen Art ausreichend ist. Darauf aufbauend könnte man dann mit spezifischen Werten operieren: • CPU-Verbrauch/Informationselement • Hauptspeicherbedarf/Informationselement • Hintergrundspeicherbedarf/Informationselement • Übertragungskapazität/Informationselement • B earbeitungszeitbedarf/Informationselement Solche spezifischen Werte würden es erlauben, IT-Systeme und ihren aktuellen Einsatz objektiver zu analysieren, zu vergleichen und zu planen.

8

Schlußbemerkung

Wir hoffen, daß wir mit unseren Darlegungen einige Hinweise auf die Bedeutung geeigneter Metriken für das Information Engineering geben und damit den einen oder anderen unserer Leser zu einer Beschäftigung mit diesem Thema anregen konnten.

Literatur [Blaz94] Blazek, Alfred: Die Zeit des Controlling. In: Zeit des Controlling. Controller Institut GmbH, Gauting (1994), S. 3 ff. [Bryn93] Brynjolfsson, Erik: The Productivity Paradox of Information Technology. In: Communications of the ACM, 12 (Vol. 36, 1993), S. 67-77 [EIT095] European ISSN 0947-4862

Information

Technology

Observatory

1995.

[FiSc95] Fischer, Rupert; Schelle, Heinz; Wahl, Rudi: Der Wirtschaftsfaktor Software in Bayern. Tectum, Marburg (1995). ISBN 3-89608-924-2 [Hetz93] Hetzel, Bill: Making Software Measurement Work. John Wiley & Sons, New York (1993).

368

Heinz G. Schwärtzel, Rupert Fischer

[Neug86] Neugebauer, U.: Das Software-Unternehmen. GMD-Bericht 157. Oldenbourg, München, 1986. ISBN 3-486-20136-0 [Schr94] Schröder, E. F.: Strategische Unternehmensführung - Erfolgreiche Umsetzung durch Controlling. In: Zeit des Controlling. Controller Institut GmbH, Gauting (1994), S. 27 ff.

Entity-Relationship-Modell und NR/T-Netze Ein integrierter Ansatz zur Daten- und Ablaufmodellierung Wolffried Stucky Institut für Angewandte Informatik und Formale Beschreibungsverfahren, Universität Karlsruhe(TH)

Peter Jaeschke PROMATIS Informatik, Karlsbad

Andreas Oberweis Institut für Wirtschaftsinformatik, Johann Wolfgang Goethe-Universität Frankfurt/Main

1

Einleitung

2

Ablaufmodellierung mit NF^-Relationen/Transitionen-Netzen 2.1 NF 2 -Relationen 2.2 NF^-Relationen/Transitionen-Netze

3 4

5

2.3 Modellierung komplexer Objekttypen Datenmodellierung mit dem Entity-Relationship-Modell Komplexe Objekte und Entity-Relationship-Views 4.1 Vorgehensweise zur Ableitung komplexer Objekttypen 4.2 Schrittweise Ableitung komplex strukturierter Objekttypen Zusammenfassung und Ausblick

Literatur

370

1

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

Einleitung

Petri-Netze [BrRR87, Reis86, RoWi91] lassen sich als allgemeine Beschreibungssprache für Abläufe einsetzen. Sie ermöglichen die Darstellung sequentieller, paralleler, unabhängiger und alternativer Abläufe. Höhere Petri-Netze wie beispielsweise Prädikate/Transitionen-Netze [Genr87, Reis87] ermöglichen die Spezifikation objektabhängiger Regeln im Ablauf. Die Manipulation komplexer Objekte kann jedoch nur eingeschränkt modelliert werden. Die Nachteile der Prädikate/Transitionen-Netze in diesem Zusammenhang werden ausführlich in [Ober95] diskutiert. Die Manipulation komplexer Objekte und insbesondere die Manipulation einzelner Komponenten komplexer Objekte im Ablauf ist nicht unmittelbar modellierbar. Um diese Problemstellungen zu lösen, wird in [ObSa92] ein neuer Typ von Petri-Netzen vorgestellt, die als NF2-Relationen/Transitionen-Netze (NR/T-Netze) bezeichnet werden. Die Markierung einer Stelle in einem NF^-Relationen/Transitionen-Netz ist eine NF^-Relation [ScSc86], d . h . in einer Stelle können komplex strukturierte Objekte abgelegt werden. Die Beschriftung der Netze läßt sowohl den Zugriff auf Objekte als ganzes als auch den Zugriff auf einzelne Teilobjekte zu. Das Entity-Relationship-Modell [BaLN92, Chen76, Teor90] hat sich in der Praxis in unterschiedlichen Varianten und mit verschiedenen Erweiterungen zur Informations- bzw. Datenmodellierung durchgesetzt und wird von zahlreichen CASE-Tools unterstützt. Ziel der nachfolgenden Ausführungen ist es, die Möglichkeiten der NF2-Relationen/Transitionen-Netze im Rahmen der integrierten Unternehmensmodellierung zu nutzen. Der Begriff des integrierten Unternehmensschemas wird dabei in dem Sinn interpretiert, daß zwar trotz Integration unterschiedliche Teilschemata - Ablaufschema, Datenschema - zu erstellen, jedoch die Abhängigkeiten und Zusammenhänge zwischen den Teilschemata ebenfalls zu spezifizieren und zu dokumentieren sind. Zu diesem Zweck ist das mit NF^-Relationen/Transitionen-Netzen erstellte Ablaufschema mit dem Datenschema zu verknüpfen. Es existieren verschiedene Ansätze, um Informations- und Ablaufschema zu integrieren, in denen Entity-Relationship-Modelle mit einer Variante der PetriNetze kombiniert werden [EKTW86, HePR93, Saka83, SoKu88]. Im vorliegenden Beitrag wird vorgeschlagen, die komplexen Objekttypen als hierarchisch strukturierte Sichten auf das globale Datenschema zu interpretieren. Grundlagen hierzu sind in [JaOS94] zu finden. Die komplexen Objekttypen können sowohl in Form von SHM-Schemata [SmSm77, Brod81, BrRi84] als auch in Form von Schemata eines erweiterten

Entity-Relationship-Modell

und

NR/T-Netze.

371

Entity-Relationship-Modells dargestellt werden. Es werden beide Modelle berücksichtigt, da beide Vor- und Nachteile hinsichtlich ihrer Modellierungsmöglichkeiten bieten. SHM-Schemata eignen sich besser zur graphischen Darstellung der hierarchischen Struktur der komplexen Objekttypen. Hingegen ermöglicht die Verwendung der Konzepte des erweiterten Entity-RelationshipModells, daß sowohl das globale Datenschema als auch die Sichten mit dem gleichen Modellierungsansatz dargestellt werden. Dies ist wichtig, weil sich große Schemata besser mit dem Entity-Relationship-Modell als mit SHM darstellen lassen. Große SHM-Schemata sind verglichen mit großen Entity-Relationship-Schemata im allgemeinen unübersichtlicher, da ein globales Schema normalerweise nicht hierarchisch strukturiert ist und sich die Strukturen unterschiedlicher Objekte des globalen Schemas häufig überschneiden. das Konzept der Zunächst wird ein Überblick über NF^-Relationen/Transitionen-Netze gegeben. Dieser Überblick umfaßt eine kurze Einführung in NF^-Relationen und in SHM. Im Anschluß werden die Möglichkeiten der Integration zu einem Unternehmensschema exemplarisch dargestellt. Danach werden Regeln zur Ableitung der komplexen Objekttypen vorgestellt.

2

Ablaufmodellierung mit NF2-ReIationen/Transitionen-Netzen

Informale Ausführungen zur Ausdrucksmächtigkeit der NF^-Relationen/Transitionen-Netze sind in [ObSS93], formale Ausführungen in [ObSa92] zu finden. Eine vollständige sowohl formale als auch exemplarische Einführung in NF2-Relationen/Transitionen-Netze erfolgt in [Ober95]. 2.1

NF2-Relationen

Die Stellen eines solchen Netzes sind NF^-Relationenschemata [ScSc86], Das Schema einer solchen Relation ist hierarchisch strukturiert und setzt sich aus atomaren und relationenwertigen Attributen zusammen. Atomar heißt dabei nicht zusammengesetzt und nicht mengenwertig. In Abb. 1 ist ein Formular für die Anforderung einer Crew für einen bestimmten Flug abgebildet. Abb. 2 zeigt die Darstellung dieses Formulars als NF 2 Relation. Das Schema der NF^-Relation Crewanforderung setzt sich aus den atomaren Attributen F#, Start, Ziel, Datum, Flugzeug, Flug zeug typ und dem relationenwertigen Attribut Crew zusammen, das wiederum durch ein Relationenschema definiert wird. Ein solches Schema wird auch als Subschema, die zugehörige Relation als Subrelation bezeichnet. Relationenwertige Attribute setzen sich wiederum aus atomaren und relatio-

372

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

nenwertigen Attributen zusammen. Ein zu einem Objekt der Realwelt gehörender Eintrag wird Tupel genannt, die Tupel innerhalb von Subrelationen werden als Subtupel bezeichnet. C r e w - A n f o r d e r u n g für

455

Flug:

Start: Ziel:

London Madrid

Flugdurchführung Datum:

17.Feb.94

Flugzeugzuordnung F l u g z e u g : 12

Crew Aufgaben Copilot Navigator Pilot

Abb. 1:

T y p : Airbus

343

Flugpersonal 24 Miller 48 Schmidt

Komplexes Büroobjekt

Den atomaren Attributen entsprechen die Eintragsfelder im Formular, in denen jeweils nur ein Wert eingetragen werden darf. Die relationenwertigen Attribute entsprechen zumeist tabellarisch angeordneten Feldern, in denen mehrere Einträge möglich sind.

Crewanforderung F#

455

Start

Ziel

London Madrid

Datum

17.Feb.94

Flugzeug

12

Flugzeugtyp

Airbus 343

Crew Aufgabe

Nr

Name

Copilot

24

Miller

Navigator

48

Schmidt

Pilot 417

Paris

New York

27.Feb.94

17

Boing 747

Pilot Navigator Copilot

Abb. 2:

NF^-Relation Crewanforderung

Entity-Relationship-Modell

2.2

und

NR/T-Netze.

373

NF^-Relationen/Transitionen-Netze

Im Rahmen der Ablaufmodellierung mit Petri-Netzen wird ein zu modellierender Realweltausschnitt zunächst in aktive Komponenten - graphisch als Rechtecke dargestellt - und in passive Komponenten - graphisch als Kreise dargestellt - unterteilt. Die aktiven Elemente werden als Transitionen bezeichnet und modellieren Aktivitäten, Vorgänge und Ereignisse. Diese verbrauchen, erzeugen, verändern und transportieren Objekte, die in den passiven Elementen, den sogenannten Stellen abgelegt werden. Letztere lassen sich zur Modellierung beispielsweise von Zuständen, Bedingungen, Materiallagern und Datenspeichern einsetzen. Am Beispiel eines Ausschnitts (Abb. 3) des Geschäftsvorfalls Flugvorbereitung wird das Konzept der NF2-Relationen/Transitionen-Netze sowie die Beschriftung mit sogenannten Filtertabellen vorgestellt. In diesem Beispiel ist lediglich ein Ausschnitt aus einem Geschäftsprozeß modelliert. Es wird insbesondere nicht dargestellt, daß Flugzeuge und Mitarbeiter weiteren Flügen zu anderen Zeitpunkten zugeordnet werden können. Flugpersonal

Crewzusammenstellung

Verfügbare Flugzeuge

Abb. 3:

Ausschnitt aus dem Geschäftsvorfall Flugvorbereitung

Der Geschäftsvorfall des Beispiels aus Abb. 3 läßt sich einschließlich der zugrundeliegenden Business Rules [KnHe93] verbal folgendermaßen beschreiben: • Die Transition Flugzeugzuweisung entnimmt eine geplante Flugdurchführung aus der Stelle Flugdurchführung und ein Flugzeug mit mehr als 50 Plätzen einschließlich der Aufgaben, die den einzelnen Besatzungsmitgliedern zuzuweisen sind, aus der Stelle Verfügbare Flugzeuge und fügt ein Objekt mit den entsprechend zusammengestellten Informationen in die Stelle Crewanforderung ein. • Die Transition Crewzusammenstellung wählt Mitarbeiter des Flugpersonals mit der entsprechenden Qualifikation aus und aktualisiert die

374

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

Crewanforderung, indem sie den Mitarbeiter in die Crew aufnimmt, ihm eine Aufgabe zuweist und die zugewiesene Aufgabe aus der Menge der noch zuzuweisenden Aufgaben entfernt. • Sobald alle Aufgaben zugewiesen sind, kann die Vollständigkeitsprüfung erfolgreich abgeschlossen und die vollständige Crew in der Stelle Einsatzplan abgelegt werden. Die Stellen und ihre Markierungen im Beispielnetz lassen sich durch die nachfolgenden NF^-Relationen (Abb. 4-7) beschreiben.

Verfügbare Flugzeuge Flugzgnr

Flugzeugtyp

Plätze

Aufgaben Aufgabe

1

Boing 747

40

Pilot Copilot

2

Boing 747

Navigator

179

Copilot Pilot 3

Airbus 343

148

Pilot Copilot

Abb. 4:

F^-Relation Verfügbare Flugzeuge

Flugpersonal Angnr

1

4

6

Name

Smith

Brown

Henry

Abb. 5:

Qualifikation Aufgabe

Flugzeugtyp

Pilot

Boing 747

Navigator

Airbus 343

Copilot

Airbus 343

Pilot

Airbus 343

Pilot

Boing 747

Navigator

Boing 747

NF^-Relation Flugpersonal

Entity-Relationship-Modell

und

375

NR/T-Netze.

Flugdurchführung F#

Start

Ziel

Datum

417

Paris

New York

25.Mär.94

455

London

Madrid

17.Feb.94

234

Frankfurt

Dallas

20.Mär.94

417

Paris

New York

27.Feb.94

234

Frankfurt

Dallas

17.Mär.94

65

Madrid

London

17.Mär.94

Abb. 6:

NF2-Relation Flugdurchführung

Crewanforderung F#

455

417

Starl

London

Paris

Ziel

Madrid

New York

Datum

17.Feb.94

27.Feb.94

Flugzgnr

12

17

Flugzeugtyp

Airbus 343

Boing 747

Aufgaben

Crew

Aufgabe

Angnr

Aufgabe

Pilot

24

Copilot

48

Navigator

Pilot Navigator Copilot

Abb. 7:

NF^-Relation Crewanforderung

Um den Ablauf beschreiben zu können, ist es notwendig zu spezifizieren, wie Tupel und Subtupel in eine NF^-Relation eingefügt bzw. aus ihr entfernt werden. Das Besondere an dem hier verwendeten Ansatz ist, daß nicht nur vollständige Tupel einer solchen Relation manipuliert werden können, sondern auch Subtupel eines bestehenden Eintrags. Die theoretischen Grundlagen sind in [ObSa92] beschrieben. Es ist nicht nur möglich, ein Tupel entweder als Subtupel oder als eigenständiges Tupel zu interpretieren, sondern auch beide Gesichtspunkte geeignet zu kombinieren. Für jedes relationenwertige Attribut kann lokal festgelegt werden, ob auf die zugehörigen Werte als Ganzes zugegriffen wird, oder ob nur Teilmengen dieser Werte angesprochen werden sollen.

376

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

Die Kanten eines NF^-Relationen/Transitionen-Netzes werden mit sogenannten Filtertabellen beschriftet, um die auf den Stellen durchzuführenden Operationen zu beschreiben: • Filtertabellen besitzen eine hierarchische Struktur entsprechend der dem NF^-Relationenschema zugehörigen Stelle. Daher kann der Zugriff auf Werte innerhalb von Subtupeln formuliert werden. • Filtertabellen beschreiben im allgemeinen nicht einzelne Tupel, sondern Mengen von Tupeln. Dies ermöglicht die Verarbeitung von relationenwertigen Attributen. • In Filtertabellen wird zwischen zwei Typen von Termen unterschieden: offene Terme und geschlossene Terme. Syntaktisch werden geschlossene Terme durch einen Überstrich gekennzeichnet. Ein geschlossener Term x beschreibt den Zugriff auf den ganzen, unteilbaren Mengenwert. Im Gegensatz dazu beschreiben offene Terme den Zugriff auf eine Teilmenge eines relationenwertigen Attributs. Abb. 8 zeigt Filtertabellen, die als Definition von Einfüge- bzw. Löschoperationen auf die NF^-Relation Crewanforderung aus Abb. 7 interpretiert werden können. Die Variablen werden mit Großbuchstaben geschrieben, alle anderen Angaben beschreiben konkrete Werte. Die Variable D steht für Datum, A für Aufgabe und C für Crew. Die Variablen werden entweder bei der Auswahl eines Tupels oder vor dem Einfügen eines Tupels mit Werten instantiiert.

pilot 455, london, madrid, 17.Feb.94, 12, airbus 343, copilot

FLUG, START, ZIEL, D, FLUGZEUG, TYP,

(d)

Abb. 8:

455, START, ZIEL, D, FLUGZEUG, TYP,

455, START, ZIEL, D, FLUGZEUG, TYP.

pilot copilot

I

I

,

c

A ,

C

Ä.|

|

Filtertabellen NF^-Relation Crewanforderung

(a) Einfügen: Füge ein neues Objekt mit F# 455, Start London, ... in Crewanforderung ein. Die Menge der zuzuweisenden Aufgaben besteht aus Pilot und Copilot. Der Umstand, daß noch keine Crew zusammengestellt ist, wird durch eine leere Menge dargestellt.

Entity-Relationship-Modell

und

NR/T-Netze.

377

Wenn bereits ein Tupel mit F# 455, Start London, ... existiert, so werden lediglich Pilot und Copilot in die bereits existierende Menge der zuzuweisenden Aufgaben eingefügt. Der Inhalt des relationenwertigen Attributs C r e w bleibt unverändert. Löschen: Lösche die Einträge Pilot und Copilot aus der Menge der zuzuweisenden Aufgaben des Tupels mit F# 455, Start London,... . (b) Einfügen: Füge ein neues Tupel als eigenständiges Tupel ein, da für alle relationenwertigen Attribute geschlossene Terme verwendet werden. Die Menge der zuzuweisenden Aufgaben besteht genau aus den Einträgen Pilot und Copilot. Die Variablen FLUG, START, ZIEL, D, F L U G Z E U G und T Y P müssen entsprechend instantiiert werden. Löschen: Lösche ein Tupel, bei dem die Menge der zuzuweisenden Aufgaben aus Pilot und Copilot besteht, als Ganzes, da für alle relationenwertigen Attribute geschlossene Terme verwendet werden. (c) Einfügen: Füge ein neues Tupel mit F# 455 als eigenständiges Tupel ein, da für alle relationenwertigen Attribute geschlossene Terme verwendet werden. Die Variablen müssen entsprechend instantiiert werden. Löschen: Lösche das Tupel mit F# 455 als Ganzes, da für alle relationenwertigen Attribute geschlossene Terme verwendet werden. (d) Einfügen: Füge ein neues Tupel mit F# 455 als eigenständiges Tupel ein, für das noch keine Crew zusammengestellt ist. Die Variablen müssen entsprechend instantiiert werden. Löschen: Lösche das Tupel mit F# 455, dem noch keine Crew zugeordnet ist, als Ganzes. Abb. 9 zeigt das Netz aus Abb. 3 mit den entsprechend beschrifteten Kanten. Bei mehrfachem Schalten der Transition C r e w z u s a m m e n s t e l l u n g zum gleichen Zeitpunkt läßt sich ein und dieselbe C r e w a n f o r d e r u n g mehrfach parallel bearbeiten, wenn unterschiedliche Aufgaben zugewiesen werden, da nicht ein Tupel als Ganzes, sondern nur einzelne Subtupel manipuliert werden.

378

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

F, START, ZIEL, D, FLG2G, T, C

Einsatzplan

Abb. 9:

Mit Filtertabellen beschrifteter Netzausschnitt

Filtertabellen können in beliebiger Tiefe entsprechend dem zugehörigen NF^-Relationenschema geschachtelt werden. Werte, mit denen geschlossene Terme instantiiert werden, werden als atomare Werte behandelt. Ein Tupel kann nur dann als Ganzes gelöscht werden, wenn alle relationenwertigen Attribute durch geschlossene Terme spezifiziert werden. Wenn ein relationenwertiges Attribut durch einen offenen Term spezifiziert wird, können nur Werte des offenen Terms entfernt werden. Wenn eine Filtertabelle hinsichtlich eines relationenwertigen Attributs einen offenen Term enthält, können unterschiedliche Subtupel parallel bearbeitet werden. Wenn alle Terme geschlossen sind, kann das Tupel nur als Ganzes von einer Transition bearbeitet werden. Die atomaren Attribute eines (Sub-)Tupels können nur dann manipuliert werden, wenn man für alle Subrelationen des (Sub-)Tupels geschlossene Terme

Entity-Relationship-Modell

und

379

NR/T-Netze.

verwendet. Beispielsweise dürfen in der Transition C r e w z u s a m m e n s t e l l u n g weder die Flugnummer noch der Startflughafen oder andere atomare Attribute verändert werden, da sonst beim parallelen Schalten dieser Transition Inkonsistenzen entstehen können. 2.3

Modellierung komplexer Objekttypen

Für die Ablaufmodellierung existieren Möglichkeiten zur graphischen Darstellung von Prozeßschemata in Form von Petri-Netzen. Für die graphische Darstellung komplexer, hierarchisch strukturierter Objekte bietet sich das Semantic Hierarchy Model (kurz SHM, semantisch hierarchisches Objektmodell) [SmSm77, Brod81, BrRi84] an. Dieses Modell verwendet die Typkonstruktoren Aggregation, Generalisierung und Gruppierung. Die Grundelemente des SHM sind Objekttypen, auf welche die Typkonstruktoren angewendet werden können. Im Gegensatz zum Entity-Relationship-Modell unterscheidet das semantisch hierarchische Objektmodell nicht zwischen Attributen und Objekttypen, vielmehr sind Objekttypen entweder elementar (z.B. STRING, REAL,...) oder sie werden auf Basis anderer Objekte mittels der Typkonstruktoren definiert.

Abb. 10:

(a) Aggregation

(b) Generalisierung

(c) Gruppierung

SHM stellt die folgenden Typkonstruktoren zur Verfügung (Abb. 10): • A ist eine Aggregation der Komponenten K i , i = 1, ..., n. A setzt sich aus den Ki zusammen. • G ist die Generalisierung von S i , i = 1, ..., n. Die S i erben die Struktur von G. Die S i werden auch als Spezialisierung von G bezeichnet. • S ist eine Menge (Gruppierung, Grouping, Assoziation) von Ausprägungen des Elementtyps E. Die Darstellung der Objekte im Ablauf durch SHM-Schemata wird exemplarisch für das vorhergehende Beispiel durchgeführt. Die Strukturen der NF^-RelationenSchemata lassen sich direkt in SHM-Schemata umsetzen.

380

Wolffried

Stucky,

Peter

Jaeschke,

Andreas

Oberweis

Crewanforderung

Start

F#

Ziel

Datum

Flugzgnr

Flugzeugtyp

Au,

Aufgabe

Abb. 11:

Crew

9aben

Angnr

Aufgabe

SHM-Schema Crewanforderung

Jedes Relationenschema bzw. Subschema wird in einem SHM-Schema als Aggregation der einwertigen Attribute und als Gruppierung der relationenwertigen Attribute dargestellt. In Abb. 11 wird zunächst jedes Relationenschema bzw. Subschema aus Abb. 7 - Crew-Anforderung, Aufgaben, Crew - als Aggregation der einwertigen Attribute - F#, Start, Ziel, Flugzeugnr,

Flugzeugtyp für Crew-Anforderung; Aufgabe für Aufgaben; Angnr und Aufgabe für Crew- modelliert. Die relationenwertigen Attribute Aufgaben und Crew werden als Elementtypen einer Gruppierung dargestellt. Analog zur oben gegebenen Darstellung als SHM-Schemata Konstrukte des erweiterten Entity-Relationship-Modells verwendet die komplexen Objekttypen als EER-Schemata zu modellieren. In wird die Modellierung als SHM-Schemata und als EER-Schemata tigt.

3

können die werden, um Abschnitt 4 berücksich-

Datenmodellierung mit dem Entity-Relationship-Modell

Wir setzen im folgenden voraus, daß der Leser mit den Grundlagen der EntityRelationship-Modellierung [Chen76, BaLN92, Teor90] vertraut ist. Es wird ein um Aggregation, Generalisierung und Gruppierung erweitertes Entity-Relationship-Modell verwendet.

Abb. 12:

Entity-und Beziehungstypen

Entity-Relationship-Modell

und

NR/T-Netze.

381

Entity-Typen werden durch ihre Attribute beschrieben, Relationship-Typen (im folgenden auch Beziehungstypen) durch die teilnehmenden Entity-Typen und Beziehungsattribute. Abb. 12 zeigt die Entity-Typen E i und E2 (Rechteck) und den Beziehungstyp R (Raute) mit Attributen (Kreis). Außerdem werden (min, max)-Kardinalitäten verwendet. Die minimale Anzahl von Beziehungen des Typs R, an denen ein Entity des Typs E i teilnehmen muß, wird durch m i n i angegeben. Die maximale Anzahl von Beziehungen des Typs R, an denen ein Entity des Typs E i teilnehmen darf, wird durch m a x i angegeben.

Abb. 13:

Entity-Typ E mit Weak-Entity-Typ E '

Zusätzlich wird das Konzept der Weak-Entity-Typen unterstützt. Der Entity-Typ E ' in Abb. 13 ist ein Weak-Entity-Typ (doppeltes Rechteck). Ein Entity vom Typ E ' kann ohne das zugehörige Entity vom Typ E weder existieren noch identifiziert werden. Dieser Sachverhalt wird durch den Pfeil an der Kante zwischen Beziehungstyp und Weak-Entity-Typ zum Ausdruck gebracht. Die hier verwendeten Erweiterungen Aggregation und Generalisierung wurden in [ScSW79] eingeführt. Eine Beziehung zwischen mehreren Entities kann als Objekt einer höheren Abstraktionsebene betrachtet werden. Sie wird dann als Aggregation bezeichnet und kann selbst an weiteren Beziehungen teilnehmen. Der Aggregationstyp in Abb. 14 basiert auf dem Beziehungstyp R]_. Die Beschreibung des Aggregationstyps entspricht der des zugrundeliegenden Beziehungstyps.

Abb. 14:

Aggregation Ri

382

Wolffried Stucky, Peter Jaeschke, Andreas

E El Abb. 15:

...

Ei

Oberweis

En

Generalisierung

| «1 J / SET \ (a2. (a, b) (c, d) I E1 I

0

Abb. 16:

Gruppierung

Die Generalisierung (Abb. 15) wird verwendet, um einen generischen EntityTyp zu modellieren. Alle Attribute, die für den Supertyp definiert sind, werden an die Subtypen weitervererbt. Entities der Subtypen können an Beziehungen teilnehmen, deren Typ für den Supertyp definiert sind. Für die Subtypen können zusätzliche Attribute und Beziehungstypen spezifiziert werden. Eine Menge (SET) von Entities wird als Gruppierung (Abb. 16) bezeichnet, wenn diese Menge als eigenständiges Objekt betrachtet wird. Die hier verwendete Darstellung geht auf [LiNe86] zurück. Ein Gruppierungstyp wird durch seinen Namen, den Elementtyp und seine Attribute beschrieben. Abb. 17 zeigt das Datenschema des hier verwendeten Beispiels. Ein Flug wird durch einen Start- und einen Zielflughafen beschrieben. Jeder Flug kann mehrfach zu unterschiedlichen Zeitpunkten durchgeführt werden. Jeder Flug wird mit einem bestimmten Flugzeug durchgeführt. In Abhängigkeit des Flugzeugtyps sind innerhalb der Besatzung bestimmte Aufgaben zu erfüllen, dabei müssen die Crew-Mitglieder die entsprechende Qualifikation für den eingesetzten Flugzeugtyp vorweisen.

Entity-Relationship-Modell

Abb. 17:

4

und

NR/T-Netze.

383

Vereinfachtes Datenschema für das Beispiel einer Fluggesellschaft

Komplexe Objekte und Entity-Relationship-Views

In Abschnitt 2.2 wurde der Ausschnitt eines Geschäftsprozesses unter Verwendung komplexer Objekttypen modelliert. Diese komplexen Objekttypen können als NF^-Relationenschemata beschrieben werden. Graphisch lassen sich diese als SHM-Schemata oder als Schemata im erweiterten Entity-RelationshipModell darstellen. Soweit es darum geht, Objekte aus einem lokalen Gesichtspunkt heraus - d. h. für eine Stelle des Petri-Netzes - zu modellieren, sind diese Möglichkeiten ausreichend. Probleme entstehen, wenn nicht nur die lokalen Objektschemata für einzelne Stellen relevant sind, sondern der Bezug zu einem globalen Datenschema hergestellt werden soll und muß, um das Datenschema und das Geschäftsprozeßschema zu einem integrierten Unternehmensschema zusammenzuführen. Im folgenden wird eine Trennung der lokalen und der globalen Aspekte vorgeschlagen. Die globalen Aspekte werden hierzu in einem globalen, konzeptuellen Datenschema modelliert. Im Gegensatz dazu werden die lokalen Aspekte in Form von komplexen Objekttypen modelliert, die vom konzeptuellen Schema abzuleiten bzw. auf der Basis des globalen Datenschemas zu definieren sind. In diesem Abschnitt wird beschrieben, wie komplexe Objekt-

384

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

typen auf Basis eines globalen Entity-Relationship-Schemas definiert werden können. Die Struktur der komplexen Objekte wird jeweils als SHM-Schema und als erweitertes Entity-Relationship-Schema dargestellt.

Abb. 18:

Darstellung des Formulars aus Abb. 1 als Sicht auf das globale Schema

In Abb. 1 wird ein typisches Formular aus der Bürowelt der Fluggesellschaft dargestellt, das als komplexer Objekttyp zu interpretieren ist. Der komplexe Objekttyp läßt sich als Entity-Relationship-View [Ling87] darstellen. Das Teilschema des Datenschemas, das die zur Beschreibung des Objekttyps notwendigen Informationen enthält, wird in Abb. 18 gezeigt. Die grundlegende Idee des hier vorgestellten Ansatzes ist, die komplexen Objekttypen als Sicht bzw. View auf das konzeptuelle Schema zu interpretieren. Zunächst werden die Überlegungen exemplarisch vorgestellt, danach werden die dem Ableitungsvorgang zugrundeliegenden Regeln beschrieben. 4.1

Vorgehensweise zur Ableitung komplexer Objekttypen

Die einzelnen Phasen der Ableitung komplexer Objekttypen aus dem globalen Datenschema können folgendermaßen gegliedert werden: (1)

Bestimme den Kern-Entity-Typ des komplexen Objekttyps.

Entity-Relationship-Modell

und NR/T-Netie

385

Der Kern-Entity-Typ des komplexen Objekttyps ist der Entity- oder Aggregationstyp, dessen Identifikator auch Identifikator des komplexen Objekttyps ist. (2) Bestimme das Teilschema des konzeptuellen Datenschemas, welches die Informationen enthält, die dem komplexen Objekttyp zugrunde liegen. (3) Definiere eine Entity-Relationship-View, die der Struktur des komplexen Objekttyps entspricht, gemäß den Regeln aus [Ling87; JaOS94], (4) Leite das SHM- bzw. EER-Schema des komplexen Objekttyps aus der Struktur der View ab. Weder das Teilschema noch die View werden automatisch erzeugt bzw. abgeleitet, sondern beide sind explizit vom Designer bzw. Anwender zu spezifizieren. Der komplexe Objekttyp Flugroute, der die Route eines bestimmten Flugs beschreibt, läßt sich folgendermaßen aus dem konzeptuellen Schema ableiten: (1) Zunächst wird der Entity-Typ Flug als Kern-Entity-Typ des komplexen Objekttyps Flugroute festgelegt, da der Identifikator von Flug auch der Identifikator des komplexen Objekttyps ist. (2) Dann werden die Entity- und Beziehungstypen in das Teilschema (Abb. 19a) aufgenommen, welche die für den Objekttypen erforderlichen Informationen beschreiben.

zugrundeliegendes Teilschema

ausgeblendete Kardinalitäten

(a)

0»)

Abb. 19:

Ableitung des komplexen Objekttyps mit Kern-Entity-Typ Flug

In einem Zwischenschritt (Abb. 19b) werden alle Kardinalitäten ausgeblendet, die aus Sicht des Kern-Entity-Typs nicht erforderlich sind. Nur die Kardinalitäten, die hinsichtlich des Kern-Entity-Typs relevant sind, werden angegeben. Aus der Sicht von Flug ist relevant, daß sich ein Flug auf genau einen Start-

386

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

und genau einen Zielflughafen bezieht. Hingegen ist unter diesem Gesichtspunkt nicht relevant, daß ein bestimmter F l u g h a f e n Start- bzw. Zielflughafen vieler Flüge sein kann. (3) In diesem Beispiel stimmt das Teilschema mit der dem Objekttyp zugrundeliegenden View überein. (4) Die Struktur des komplexen Objekttyps ist in Abb. 20a als SHM-Schema und in Abb. 20b als EER-Schema dargestellt, um beide Modellierungsmöglichkeiten zu veranschaulichen. Auf Basis der Kardinalitäten in Abb. 19b wird die Struktur des komplexen Objekttyps bestimmt. Elementtypen der Gruppierungstypen werden auf Basis von Maximumkardinalitäten > 1 und die Komponenten von Aggregationstypen aufgrund von Maximumkardinalitäten = 1 bestimmt. Durch eine Maximumkardinalität = 1 wird ausgedrückt, daß genau eine Komponente zugeordnet ist, diesem Sachverhalt entspricht die Aggregation. Die Gruppierung besagt, daß eine Menge von Objekten zugeordnet ist, dieser Sachverhalt wird durch eine Maximumkardinalität > 1 ausgedrückt.

abgeleitetes EER-Schema

abgeleitetes SHM-Schema Flug

Flug

Startflug haten

Zielflughafen

Flugnummer

Zielflughafen

Startflughafen Flughafen

Flughafen

(a) Abb. 20:

(b)

Komplexer Objekttyp mit Kern-Entity-Typ Flug als SHM-Schema und als EER-Schema

Da hier nur Maximumkardinalitäten = 1 auftreten, werden die Attribute von Flug und Flughafen sowohl im Sinne von Startflughafen als auch im Sinne von Zielflughafen als Komponenten des Aggregationstyps Flug - entspricht dem komplexen Objekttyp Flugroute - modelliert.

Entity-Relationship-Modell

und

NR/T-Netze.

387

Im Anschluß wird ein komplexer Objekttyp Flugabwicklung abgeleitet, der einen bestimmten Flug zu einer bestimmten Zeit mit einem bestimmten Flugzeug und mit einer bestimmtem Besatzung modelliert: (1) Zunächst wird der Entity-Typ Flugdurchführung als Kern-EntityTyp des komplexen Objekttyps festgelegt, da der Identifikator von Flugdurchführung auch der Identifikator des komplexen Objekttyps

Flugabwicklung ist. (2) In Abb. 21 ist das Teilschema dargestellt, das alle relevanten Entity- und Beziehungstypen beinhaltet.

Abb. 21:

Teilschema mit Kern-Entity-Typ Flugdurchführung

Der Beziehungstyp erfordert ist mit unterbrochenen Linien gezeichnet, da es sich hier um einen integritätssichernden Beziehungstyp handelt: Es soll ausgedrückt werden, daß einem Besatzungsmitglied nur dann eine Aufgabe zugewiesen werden darf, wenn der Flugzeugtyp diese Aufgabe erfordert. (3)

In Abb. 22 ist die Entity-Relationship-View dargestellt.

388

Wolffried Stucky, Peter Jaeschke, Andreas

Abb. 22:

Oberweis

View mit Kern-Entity-Typ Flugdurchführung

Auch hier sind die zur Bildung des komplexen Objekttyps nicht relevanten Kardinalitäten bereits ausgeblendet. Im Gegensatz zum vorhergehenden Beispiel werden in der View verschiedene Entity- und Beziehungstypen des konzeptuellen Schemas zu einem neuen Entity-Typ zusammengefaßt. In Abb. 22 sind aus Gründen der anschaulichen Darstellung anstelle eines eigenen Entity-Namens die Namen der zusammengefaßten Entity- und Beziehungstypen eingetragen. Diese werden mit '*' verknüpft. Das Symbol '*' wird verwendet, um eine Art Joinoperation zu spezifizieren und verschiedene miteinander verbundene Objekte zu einem einzigen Objekt zusammenzufassen. (4) Abb. 23 zeigt das SHM-Schema, in Abb. 24 ist das EER-Schema des komplexen Objekttyps dargestellt. Auch hier wird, anstelle eines eigenen Namens, der Verweis auf die zugrundeliegenden Entity-Typen eingetragen.

Flugdurchführung

I

Flug» silnahme

Angnr

Flugzeug

I

Flugzeugtyp

Name Aufgabe

I

Name

Abb. 23:

Datum

Flugzeugnr

Flug

StartZielFlugflughafen flughafen nummer

Anzahl Plätze

SHM-Schema des komplexen Objekttyps

Entity-Relationship-Modell

und

NR/T-Netze.

389

In diesem Beispiel werden die unterschiedlichen Modellierungsmöglichkeiten im semantisch hierarchischen Objektmodell und im Entity-Relationship-Modell deutlich. Während das SHM-Schema die Struktur der zugrundeliegenden View wiedergibt, ist die Struktur im EER-Schema nicht mehr zu erkennen. Diese Unterschiede sind dadurch begründet, daß das Konstrukt der Aggregation in SHM eine andere Semantik besitzt als im hier verwendeten Extended-EntityRelationship-Modell. Weil SHM nicht zwischen Entity-Typen und Attributen unterscheidet, entspricht der Aggregationstyp des SHM sowohl dem Entity-Typ - Aggregation seiner Attribute - als auch dem Aggregationstyp des EERModells.

Flugdurchführung 'durchgeführt * Flug * Startflughafen * Zielflughafen * benutzt für * Flugzeug * ist vom Typ * Flugzeugtyp 5ET

Flugteilnahme 'begleitet * Flugpersonal * als * Aufgabe

Abb. 24:

EER-Schema des komplexen Objekttyps

Darüber hinaus unterscheidet das EER-Modell zwischen zwei verschiedenen Arten von Komponenten (Abb. 25) eines Aggregationstyps: Entity-Typen und Beziehungsattribute. An einem Aggregationstyp müssen mindestens zwei Entity-Typen teilnehmen, d. h. es kann kein Aggregationstyp abgeleitet werden, der sich aus nur einem Entity-Typ und einem oder mehreren Attributen zusammensetzt. Dies hat zur Folge, daß im erweiterten Entity-Relationship-Modell Aggregationstypen nicht beliebig geschachtelt werden können. 4.2

Schrittweise Ableitung komplex strukturierter Objekttypen

In diesem Abschnitt wird eine Vorgehensweise zur schrittweisen Ableitung komplexer Objekttypen eingeführt. Für die Regeln zur Definition von EntityRelationship-Views wird auf [Ling87, JaOS94] verwiesen. Für die Vorgehensweise werden verschiedene Begriffe benötigt. Der Kern-Entity-Typ des komplexen Objekttyps ist der Entity-, Aggregationsoder Beziehungstyp des konzeptuellen Schemas, dessen Identifikator auch der Identifikator des komplexen Objekttyps ist. Ein Entity-Typ bzw. ein Beziehungstyp in einer Entity-Relationship-View wird als externer Entity-Typ bzw. als externer Beziehungstyp bezeichnet.

390

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

Ein Beziehungstyp wird als struktureller Beziehungstyp bezeichnet, wenn er zur Bildung der hierarchischen Struktur des komplexen Objekttyps verwendet wird. Ein Beziehungstyp wird als integritätssichernder Beziehungstyp bezeichnet, wenn eine Entitykombination der an dem integritätssichernden Beziehungstyp teilnehmenden Entity-Typen nur dann Bestandteil des komplexen Objekttyps sein darf, wenn sie in der entsprechenden Kombination an einer Beziehung des integritätssichernden Beziehungstyps teilnimmt.

Abb. 25:

Indirekte und direkte Unterordnung

In einer als Baum strukturierten Entity-Relationship-View wird ein Beziehungstyp R einem anderen Beziehungstyp R' als direkt untergeordnet bezeichnet, wenn R an R ' teilnimmt und R im Baum R' untergeordnet ist. In einer als Baum strukturierten Entity-Relationship-View wird ein Beziehungstyp R einem anderen Beziehungstyp R' als indirekt untergeordnet bezeichnet, wenn ein Entity-Typ E dem Beziehungstyp R' unter- und dem Beziehungstyp R übergeordnet ist, d. h. E nimmt sowohl an R als auch an R ' teil. Dementsprechend sind in der als Baum strukturierten Sicht in Abb. 25 der Beziehungstyp R2 dem Beziehungstyp R i indirekt und der Beziehungstyp R3 dem Beziehungstyp R i direkt untergeordnet. Ableitung des SHM-Schemas eines komplexen Objekttyps von einem globalen Entity-Relationship-Schema: (1)

Bestimme den Kern-Entity-Typ des komplexen Objekttyps.

(2) Bestimme das Teilschema des globalen konzeptuellen Schemas, das die für den komplexen Objekttyp erforderlichen Informationen enthält. Das Teilschema muß als Baum mit dem Kern-Entity-Typ als Wurzel strukturiert werden. Die ausgewählten Entity-Typen und die strukturellen Beziehungstypen bilden die Knoten des Baumes.

Entity-Relationship-Modell

(3)

und

NR/T-Netze.

391

Bestimme die integritätssichernden Beziehungstypen.

(4) Definiere eine Entity-Relationship-View, so daß aus dem Aufbau der View die hierarchische Struktur des komplexen Objekttyps abgeleitet werden kann. Die View muß als Baum mit einer Wurzel, welcher der Kern-Entity-Typ zugrunde liegt, und den externen Entity-Typen und den externen strukturellen Beziehungstypen als Knoten strukturiert werden. (5) Definiere das zugehörige SHM-Schema entsprechend den folgenden Regeln:

auf Grundlage der

View

- Lege für die Wurzel jeden Aggregationstyp bzw. jeden Beziehungstyp des Baumes einen SHM-Aggregationstyp an. - Die Komponenten des angelegten SHM-Aggregationstyps X' im Falle eines zugrundeliegenden Entity-Typs - nur für die Wurzel möglich - oder Beziehungs- bzw. Aggregationstyp X sind (a) die Attribute des zugrundeliegenden Entity- oder Beziehungs- bzw. Aggregationstyps, (b) die Attribute von Entity-Typen, die an dem zugrundeliegenden Beziehungs- bzw. Aggregationstyp X teilnehmen und die ihm in der Baumstruktur untergeordnet sind, (c) die SHM-Aggregationstypen C i , ..., C m , welche Beziehungs- bzw. Aggregationstypen entsprechen, die X direkt oder indirekt - d. h. über einen Entity-Typ Y - untergeordnet sind, wenn die Maximumkardinalität von X bzw. Y hinsichtlich der den C i , ..., C m zugrundeliegenden Beziehungstypen = 1 ist. - Zwischen zwei SHM-Aggregationstypen, die auf X und Y basieren, wird eine Gruppierungsverbindung ( — • • ) angelegt, wenn Y im Baum X direkt oder indirekt über einen Entity-Typ Z untergeordnet ist und wenn die Maximumkardinalität von X bzw. Z hinsichtlich des Beziehungstyps, der Y zugrunde liegt, größer 1 ist. - Generalisierungshierarchien werden unmittelbar aus der zugrundeliegenden View übernommen. Zusätzlich kann die Verwendung von Rollennamen in eine SHM-Generalisierung umgesetzt werden. In Abb. 26 wird für A, R]_ und R2 jeweils ein SHM-Aggregationstyp angelegt. Gemäß Regel (a) werden a i , a 2 , a 3

als Komponenten von A, x

als

Komponente von R^ und y als Komponente von R2 modelliert. Die Regel (b)

392

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

wird verwendet, umfc>i,b2, b3, c\, C2, C3 als Komponenten von Ri und um d i , ä-2, d3, e i , e2, e3 als Komponenten von R2 darzustellen. Aufgrund von Regel (c) wird Ri Komponente von A und Ri wird als Gruppierung von R2 modelliert.

^

Ableitung

A

a

a

1

a

2

3

R

1 «W

b

1

b

2

b

3

x c

1

c

2

c

R2

3

d1

Abb. 26:

d2

d3 y

e1

82

©3

Ableitung des SHM-Schemas

Analog zu den SHM-Schemata können auch EER-Schemata abgeleitet werden. Aus den bereits zuvor diskutierten Gründen ist es nicht möglich, Aggregationstypen beliebig zu schachteln. Anstelle geschachtelter Aggregationstypen wird ein einziger Entity-Typ definiert, der alle Attribute der ineinander geschachtelten Aggregationstypen umfaßt. Gruppierungstypen werden wie oben gebildet. In Abb. 27 wird die entsprechende Umsetzung aus Abb. 26 für EER-Schemata angegeben.

Entity-Relationship-Modell

Abb. 27:

5

und

NR/T-Netze.

393

Ableitung des EER-Schemas

Zusammenfassung und Ausblick

In diesem Beitrag werden NF^-Relationen/Transitionen-Netze verwendet, um Abläufe unter Berücksichtigung komplexer Objekte zu modellieren. Es wurde vorgestellt, wie ein mit NF^-Relationen/Transitionen-Netzen erstelltes Ablaufschema mit einem Datenschema integriert werden kann, das mit einem EntityRelationship-Ansatz erstellt wurde. Die komplex strukturierten Objekte der Ablaufschemata werden als hierarchisch strukturierte Sichten auf das globale Datenschema definiert. Petri-Netze unterstützen die Darstellung unterschiedlicher Abstraktionsebenen durch die Möglichkeit zur Verfeinerung von Transitionen durch ganze Netze. Diese Technik kann mit dem Entity-Relationship-Modell-CIustering [JaOS93] kombiniert werden. Mit Hilfe des Entity-Relationship-Modell-Clustering lassen sich ganze Teildiagramme zu Entity-Clusters oder Relationship-Clusters zusammenfassen, die dann in einem abstrahierten ER-Diagramm verwendet werden. In diesem Fall werden die komplexen Objekttypen nicht auf der Ebene des Detaildiagramms, sondern auf einer höheren Abstraktionsebene festgelegt. Sollen auf einem höheren Abstraktionsniveau bereits Ablaufregeln definiert werden, so ist die Interpretation der Clusters als Sichten unabdingbar, da jetzt Cluster nicht nur als Entwurfs- und Präsentationshilfsmittel eingesetzt werden, sondern auch instantiiert werden müssen. Entity-Clusters lassen sich direkt als hierarchisch strukturierte, komplexe Objekttypen interpretieren. Schwieriger ist hingegen die Interpretation von Relationship-Cluster - insbesondere von Complex-Relationship-Cluster - als Views. Hier besteht die Möglichkeit, Join und Projektion anzuwenden.

Literaturverzeichnis [BaLN92] Batini, C.; Ceri, S.; Navathe, S.: Conceptual Database Design - An Entity Relationship Approach. Benjamin Cummings, Reedwood City 1992.

394

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

[Brod81] Brodie, M. L.: Association: A database abstraction for semantic modeling. In: Chen, P.P. (Hrsg.): Proc. of the 2nd Intern. Conf. on EntityRelationship Approach. Washington, D.C., USA 1981, North-Holland 1983, S. 577-602. [BrRi84] Brodie, M. L.; Ridjanovic, D.: On the design and specification of database transactions. In: Brodie, M. L.; Ridjanovic, D.; Schmidt, J. W. (Hrsg.): On Conceptual Modelling, Springer Verlag, Berlin, Heidelberg 1984, S. 278-306. [BrRR87] Brauer, W.; Reisig, W.; Rozenberg, G. (Hrsg.): Petri Nets: Central models and their properties. Advances in Petri Nets 1986. LNCS 254, Springer Verlag, Berlin, Heidelberg 1987 [Chen76] Chen, P.P.: The entity-relationship model: Toward a unified view of data. In: ACM Transaction on Database Systems, 1 (1976) 1, S. 166 - 192. [EKTW86] Eder, J.; Kappel, G, Tjoa, A M.; Wagner, A. A.: BIER - The behaviour integrated entity relationship approach. In: Spaccapietra, S. (Hrsg.): Proc. of the 5th Intern. Conf. on Entity-Relationship Approach, Dijon, France 1986, North-Holland 1987, S. 147-168. [Genr87] Genrich, H. J.: Predicate/transition nets. In: W. Brauer, Reisig, W.; Rozenberg G. (Hrsg.): Petri Nets: Central models and their properties. LNCS 254, Springer Verlag, Berlin, Heidelberg 1987, S. 207-247. [HePR93] Heuser, C.A.; Peres, E.M.; Richter, G.: Towards a complete conceptual model: Petri nets and Entity-Relationship diagrams. In: Information Systems 18 (1993) 5. S. 275-298. [JaOS93] Jaeschke, P.; Oberweis, A.; Stucky, W.: Extending ER model clustering by relationship clustering. In: Elmasri, R.; Kouramajian, V.; Thalheim, B. (Hrsg.): Proc. 12th International Conference on the Entity Relationship Approach. Arlington, TX, 1993, LNCS 823, Springer Verlag, Berlin, Heidelberg 1994, S. 451-462. [JaOS94] Jaeschke, P.; Oberweis, A.; Stucky, W.: Deriving Complex Structured Object Types for Business Process Modelling. In: Loucopoulos, P. (Hrsg.): Proc. 13th International Conference on the Entity Relationship Approach. Manchester, UK, 1994, LNCS 881, Springer Verlag, Berlin, Heidelberg 1994, S. 28-45. [KnHe93] Knolmayer, G.; Herbst, H.: Business WIRTSCHAFTSINFORMATIK 35 (1993) 4, S. 386-390.

Rules.

[LiNe86] Lipeck, U.; Neumann, K.: Modelling and manipulating objects in geoscientific databases. In: Spaccapietra, S. (Hrsg.): Proc. of the 5th Intern. Conf. on Entity-Relationship Approach. Dijon, France 1986, North-Holland 1987, S. 67-88.

Entity-Relationship-Modell

und

NR/T-Netze.

395

[Ling87] Ling:, T.W.: A three level schema architecture ER-based data base management system. In: March, S.T. (Ed.): Proc. of the 6th Intern. Conf. on Entity-Relationship Approach. New York, USA 1987, North-Holland 1988, S. 205-222. [Ober95] Oberweis, A.: Verteilte betriebliche Abläufe und komplexe Objektstrukturen: Integriertes Modellierungskonzept für Workflow-Managementsystem, Habilitationsschrift, Institut für Angewandte Informatik und Formale Beschreibungsverfahren, Universität Karlsruhe, Februarl995. [ObSa92] Oberweis, A.; Sander, P.: The specification of complex object behaviour by high level Petri nets. Forschungsbericht 254, Institut für Angewandte Informatik und Formale Beschreibungsverfahren, Universität Karlsruhe, September 1992. [ObSS93] Oberweis, A.; Sander, P.; Stucky, W.: Petri net based modelling of procedures in complex object database applications. In: Cooke, D. (Ed.): Proceedings 17th Annual International Computer Software and Applications Conference COMPSAC 93, Phoenix/Arizona 1993, S. 138-144. [Reis86] Reisig, W.: Petrinetze: Eine Einführung. Springer-Verlag, Berlin, Heidelberg 1986. [Reis87] Reisig, W.: Place/transition systems. In: Brauer, W.; Reisig, W.; Rozenberg, G (Hrsg.): Petri Nets: Central models and their properties. LNCS 254, Springer Verlage, Berlin, Heidelberg 1987. [RoWi91] Rosenstengel, B.; Winand, U.: Petri-Netze, Eine anwendungsorientierte Einführung. 4. Auflage. Vieweg, Braunschweig, Wiesbaden 1991. [Saka83] Sakai, H.: A method for entity-relationship behaviour modeling, in Davis. C. G.; Jajodia, S.; Ng, P. A.-B.; Yeh, R. T. (Hrsg.): Proc. of the 3rd Intern. Conf. on Entity-Relationship Approach, Anahaim, California, USA 1983, North-Holland 1983. S. 111-129 [ScSc86] Schek, H.-J.; Scholl, M.H.: The relational model with relationvalued attributes. In: Information Systems 11 (1986), 2, S. 137-147. [ScSW79] Scheuermann, P.; Schiffner, G.; Weber, H.: Abstraction capabilities and invariant properties modelling within the entity-relationship approach. In: Chen, P.P. (Hrsg.): Proc. of the Intern. Conf. on Entity-Relationship Approach, Los Angeles, California, USA 1979, North-Holland 1980, S. 121140. [SmSm77] Smith, J.M.; Smith, D.C.P.: Database abstractions: Aggregation and generalization. In: ACM Transactions on Database Systems 2 (1977) 2, S. 105-133.

396

Wolffried Stucky, Peter Jaeschke, Andreas

Oberweis

[S0K1188] Solvberg, A.;. Kung, C.H: On structural and behavioral modelling of reality. In: Steel, T.B.; Meersman, R. (Hrsg.): Database Semantics. NorthHolland 1988, S. 205-221 [Teor90] Teorey, T. J.: Database Modelling and Design: The Entity-Relationship Approach. Morgan Kaufmann Publishers, San Mateo, California 1990.

Umfassendes Qualitätsmanagement für das Information Engineering Ernest Wallmüller UNISYS (Schweiz) AG

1

Einführung 1.1 Bedeutung der Qualität im Unternehmen 1.2 Beispiele von Qualitätsproblemen in der Informationsverarbeitung 1.3

Ursachen von Qualitätsproblemen

2

Grundlagen des Qualitätsmanagements

3

Lösungsansatz

4

Schlußbemerkungen

Literatur

398

1 1.1

Ernest

Wallmüller

Einführung Bedeutung der Qualität im Unternehmen

"Die weltweite Qualitätsrevolution hat permanent die Art und Weise verändert, wie wir unsere Geschäfte betreiben. War Qualität einst nur auf technische Belange beschränkt, so ist Qualität heute ein dynamischer Verbesserungsprozeß, der alle Bereiche unserer Geschäftswelt durchdringt." Dieses Zitat von R.C. Stempel [Munr92], dem Vorsitzenden der General Motors Corporation, kennzeichnet treffend unsere heutige Situation. Qualität und deren Verbesserung ist zu einer fundamentalen Geschäftsstrategie der 90er Jahre geworden. Keine Unternehmensfunktion, auch nicht die Informationsverarbeitung, kann sich dieser Strategie entziehen. Qualitätsmanagement zielt darauf ab, den Wert des Produkts oder der Dienstleistung für den Kunden und Benutzer zu steigern. Im Wettbewerb ist die Produktqualität oft der zentrale Erfolgsfaktor. Sie ist ein ausschlaggebendes Kriterium für den Käufer, erlaubt in der Regel höhere Preise und ist vielfach mit strategischen Wettbewerbsvorteilen verbunden, die durch Konkurrenten nicht kurzfristig aufzuholen sind (z.B. amerikanische Autoindustrie). 1.2

Beispiele von Qualitätsproblemen in der Informationsverarbeitung

Einige Beispiele aus der internationalen Softwareszene und aus der Beratungspraxis des Autors zeigen die Vielfalt der Qualitätsprobleme und ihre Folgen für die Unternehmen. Ein internationaler Softwarehersteller Der Direktor von Ashton Täte forcierte die Freigabe einer neuen Version eines Datenbanksystems, ohne zu erkennen, daß es stark fehlerbehaftet war. Das Produkt mußte vom Markt zurückgenommen werden. Die daraus resultierenden finanziellen Schwierigkeiten führten zur Entlassung des Direktors und zur Übernahme des Unternehmens durch Borland. Eine Schweizer Großbank Die Einführung von Wertpapieren an den Börsen von New York und Tokio kann nicht direkt über die Konzernfirma mit Hauptsitz Zürich informationstechnisch geplant und kontrolliert werden, da die dazu nötigen Informationssysteme fehlen. Das Großprojekt zur Entwicklung der Basisapplikationen für das Auslandsgeschäft der Bank ist innerhalb von 10 Jahren dreimal gescheitert. Der Verlust beträgt mehrere hundert Millionen Franken.

Umfassendes

Qualitätsmanagement

für das Information

Engineering

399

Beim kleinen Börsencrash im Oktober 1987 kam es zu einer Häufung von Mängeln und Fehlern im Börseninformationssystem, die bei der Wochenverarbeitung begannen und bis zu einer vierstündigen Abschaltung des Informationssystems vier Tage später führten. Das Börsengeschäft mußte rein manuell durchgeführt werden. Die informationstechnische Aufarbeitung der Geschäftsfälle dauerte mehrere Wochen. 1.3

Ursachen von Qualitätsproblemen

Die Ursachen von schlechter Softwarequalität lassen sich nach Rathbone [Rath88; Rath90] auf drei Einflußgrößen zurückführen: • Management, • Technologie und • Mitarbeiter. Management • Kurzfristiges Reagieren verhindert eine geplante mittelfristige Umsetzung von Zielen. • Es ist keine strategische Planung vorhanden, oder bei vorhandener strategischer Planung fehlt die konsequente Umsetzung (Management der Umsetzung), oder die Ergebnisse der Planung werden nicht mit den Mitarbeitern besprochen (fehlende Kommunikation). • Die Informationstechnik unterstützt nur geringfügig die Unternehmensziele. Die kritischen Erfolgsfaktoren werden entweder gar nicht oder mit veralteten Informationssystemen unterstützt. • Managementprozesse werden nicht als solche gesehen und exekutiert. • Die Führung ist entweder autoritär oder chaotisch, oder sie fehlt ganz. • Die Qualifikation der Mitarbeiter wird weder systematisch gepflegt noch weiterentwickelt. • Die Aufgaben der Organisationsentwicklung, die für Unternehmen in extrem dynamischen Märkten entscheidend sind, werden entweder gar nicht oder nur unzureichend wahrgenommen. Eine dieser Aufgaben, das Management von technologiebedingten Veränderungen, gehört gegenwärtig zu den größten Problemen. • Die Nichtbeherrschung von Projekten und Prozessen, insbesondere bei der Erstellung von Informations-/Softwaresystemen, ist eine wesentliche Ursache für die schlechte Qualität der Ergebnisse.

400

Ernest

Wallmüller

Technologie • Durch den raschen Wandel in der Informationstechnologie müssen sich die Unternehmen verstärkt mit dem parallelen Umgang unterschiedlicher Generationen von Technologie beschäftigen. Applikationsportfolios, die in Assembler, Cobol, PL/1, C und C++ geschrieben sind, sind keine Seltenheit mehr. Das heute in den Unternehmen praktizierte Technologiemanagement berücksichtigt dies nicht oder nur schlecht. • Die Zeitspanne vom Vorliegen von Forschungsergebnissen bis zu deren Einführung und Umsetzung wird immer kürzer. Technologiebeobachtung und Technologieerprobung werden zu einem kritischen Wettbewerbsfaktor. Unternehmen besitzen gegenwärtig kaum oder nur schlecht die Fähigkeit, neue Technologien zu beobachten, zu erproben, einzuführen oder zu beherrschen. • Die qualitative Voraussetzung, um Geschäftsziele durch Informationssysteme flexibel unterstützen zu können, ist eine Informationssystemarchitektur, die auf den Pfeilern Applikationen, Daten, Technologie und Management/Organisation beruht. Bei vielen Unternehmen ist diese Architektur einseitig auf Applikationen ausgerichtet. Die Ergebnisse der strategischen Informationssystemplanung, die diese Architekturen etablieren soll, werden - wenn überhaupt vorhanden - nicht umgesetzt. • Derzeit wird die Bedeutung guter rechnergestützter Werkzeuge unterschätzt, und mit veralteten Hilfsmitteln werden Ergebnisse mit niedriger Qualität produziert. Der Anteil an Überarbeitung und Ausschuß ist demzufolge hoch (ca. 40 % [Boeh81]). Qualität im Informatikbereich wird wesentlich von den eingesetzten Werkzeugen, Fehlerbehebungsmechanismen, dem Grad der Wiederverwendung von Bauteilen, den Programmiersystemen und dem Entwicklungsprozeß mit seiner Methodik beeinflußt.

Mitarbeiter • Mangelnde Qualifikation ist ein Problem mit zunehmender Bedeutung. Insbesondere wird der Vorbereitung auf neue Aufgaben zu wenig Aufmerksamkeit geschenkt. • Persönliche Qualifikation hat mit persönlichem Einsatz/Aufwand, Neigungen/Fähigkeiten, Erziehung/Ausbildung, Weiterbildung und Einstellung zu tun. Ein Großteil dieser Einflußgrößen wird in einem Berufsleben nicht bewußt gestaltet, und somit werden Potentiale nicht genutzt. • Die Mitarbeiter haben Angst, in einer Informationsgesellschaft zu leben und zu arbeiten, in der die Verfallszeit des Wissens auf fünf Jahre geschrumpft ist.

Umfassendes

Qualitätsmanagement

für das Information

Engineering

401

• Die Mitarbeiter haben immer größere Schwierigkeiten, sich mit der Arbeit zu identifizieren und somit den Erfolg des Unternehmens zu sichern. • Die Stabilität eines qualifizierten Mitarbeiterstabes wird für Unternehmen zu einer Überlebensfrage. Durch die hohe Fluktuationsrate im Informatikbereich verlieren Unternehmen jährlich einen wesentlichen Anteil ihres Know-hows. Die sind sen, sich

Ursachen und die mit diesen Problemen resultierenden Kostenkategorien im Detail in [Rath88] und [Rath90] beschrieben. Weitere Ursachenanalydie von IBM Deutschland über mehrere Jahre durchgeführt wurden, finden in [Kell92],

Zusammenfassend kann festgestellt werden, daß die gegenwärtigen Anstrengungen, die zu einer qualitativ besseren Leistung führen sollten, meist nur lokal und stark an neuen, noch nicht ausgereiften Technologien orientiert sind. Die Einflußgröße "Mitarbeiter" wird nur geringfügig strategisch geplant, schlecht operativ geführt und erbringt meistens mangelhafte Leistungen. Die Realität von heutigen Informatikorganisationen sind in der Folge schlecht qualifizierte Mitarbeiter, die den Unternehmen viel Geld und Zeit kosten.

2

Grundlagen des Qualitätsmanagements

Der Qualitätsbegriff ist seit dem Altertum bekannt. In der lateinischen Sprache wird "qualitas" mit der Beschaffenheit (eines Gegenstands) übersetzt. So alt wie der Begriff selbst ist auch die Diskussion um seine Inhalte, die bis heute andauert. Es ist unmöglich, alle Standpunkte dieser fachlichen Diskussion wiederzugeben. Nach ISO 8402 ist Qualität die Gesamtheit von Merkmalen eines Produktes oder einer Dienstleistung bezüglich der Eignung, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. ISO 8402 definiert Qualitätsmanagement als Summe aller Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen, sowie diese durch Mittel der Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen. Qualitätsmanagement gehört in den Verantwortungsbereich aller Führungskräfte. Bei der Umsetzung des Qualitätsmanagements, die unter dem Gesichtspunkt der Wirtschaftlichkeit erfolgt, sind alle Mitarbeiter der Organisation involviert. Seghezzi [Segh92] rundet die obige Definition praxisnahe ab, indem er dem Qualitätsmanagement vier Fachfunktionen und eine Führungsfunktion zuordnet (siehe Abbildung 1).

402

Ernest

Wallmüller

Von den vier Fachfunktionen hat die Qualitätsplanung die Aufgabe, Bedürfnisse zu ermitteln und diese in Form von Produkt- und Prozeßmerkmalen umzusetzen. Im Rahmen der Qualitätslenkung (Prozeßmanagement) sind sämtliche Prozesse einer Unternehmung so durchzuführen und zu beherrschen, daß die Spezifikationen eingehalten werden und fehlerfreie Produkte entstehen. Die Qualitätssicherung nimmt ausschließlich die Aufgabe wahr, Qualitätsrisiken zu ermitteln und Maßnahmen zu treffen, um sie zu vermindern oder zu eliminieren. Schließlich werden durch die Qualitätsförderung (Qualitätsverbesserung) Anstrengungen unternommen, die Qualität der Produkte, der Prozesse und somit des Unternehmens zu steigern, um damit die Wettbewerbsfähigkeit zu erhöhen.

Qualitätsplanung

;;

j Führung Qualitätssicherung

; Sachen j Qualität !

Qualitätslenkung (Prozeßmanagement)

Qualitätsförderung (Qualitätsverbesserung)

Abb. 1:

Funktionen des Qualitätsmanagements

Diese vier Fachfunktionen lassen sich nicht einzelnen Organisationseinheiten zuordnen, sondern sind als Querschnittsaufgaben auf eine Vielzahl von Unternehmenseinheiten verteilt. Damit tritt auch eine beachtliche Schnittstellenproblematik auf. Aus diesem Grund definiert Seghezzi eine fünfte Funktion, die Führung in Sachen Qualität, die weit bedeutsamer geworden ist, als dies in der Vergangenheit der Fall war. Im folgenden werden einige der bekanntesten Qualitätskonzepte untersucht und weiterführende Konzepte diskutiert.

3

Lösungsansatz

Der hier vorgestellte Lösungsansatz [vollständig beschrieben in Wall95] ist offen und erweiterbar. Dadurch kann auf die jeweilige Situation einer Organi-

Umfassendes

Qualitätsmanagement

fur das Information

Engineering

403

sation in bezug auf Management, Mitarbeiter und Technologie eingegangen werden. Gleichzeitig ist dieser Ansatz auf eine umfassende Qualitätskonzeption für das gesamte Unternehmen ausgerichtet (Bezugnahme auf die Normenreihe ISO 9000, Prozeßmanagement, Total Quality Management), die wir heute bereits bei vielen europäischen Unternehmen vorfinden [Zink94, 13 und 23], Das Lösungskonzept beruht auf drei Ebenen (siehe Abbildung 2): • Normative Lösungsebene Die erste Ebene umfaßt die Entwicklung einer (Qualitäts-)Vision und einer (Qualitäts-)Politik im Rahmen der strategischen Informationsplanung. Vision und Politik sind im strategischen Planungsprozeß mit den Zielen für die Informationsinfrastruktur [Hein92] abzustimmen. • Strategische Lösungsebene Die zweite Ebene legt die Rahmenbedingungen für die kritischen Einflußgrößen Management, Technologie und Mitarbeiter fest. • Operative Lösungsebene Die dritte Ebene (Prozeßmanagement) zielt auf die Beherrschung der Prozesse ab, um eine Informationsinfrastruktur zu entwickeln und zu pflegen.

Normative Ebene

(Qualitäts-) Vision, Politik und Ziele

Strategische Ebene

'Operative Ebene

Rahmenbedingungen • Management • Technologie • Mitarbeiter Prozeßmanagement

>H>]

Abb. 2:

Qualitätsmanagementkonzept

Dieses 3-Ebenen-Modell orientiert sich am allgemein anerkannten Managementmodell von Bleicher [Blei91].

404

Ernest

Wallmüller

Normative Lösungsebene Ausgangspunkt für den Lösungsansatz sind die heute in der Praxis sich stark ausbreitenden Ansätze des Qualitätsmanagements im Unternehmen, beginnend mit den Programmen von Deming und Juran bis hin zum Total Quality Management (TQM). In [Wall95, 27] findet sich eine kritische Bewertung dieser Ansätze. Diese Bewertung führt zur Erkenntnis, daß bereits im Rahmen einer zu entwickelnden Vision der Begriff Qualität zu verankern ist, und diese Vision über die Politik- sowie Zielbildung in einer Organisation, die Information Engineering betreibt, umzusetzen ist. Der Begriff Information Engineering wurde von Finkelstein und Martin 1981 eingeführt [Fink81]. Martin versteht darunter die Anwendung einer Menge von formalen Methoden für die Planung, die Analyse, den Entwurf und die Realisierung von Informationssystemen auf unternehmensweiter Basis oder in wesentlichen Bereichen eines Unternehmens. Die Methoden bauen dabei aufeinander auf und sind in gewisser Weise voneinander abhängig. Heinrich [Hein91] hat eine Definition erarbeitet, die Information Engineering als wissenschaftliche Disziplin akzeptiert: "Information Engineering ist eine Teildisziplin der Wirtschaftsinformatik, deren Erkenntnisobjekt die Methoden zur Gestaltung der Informationsinfrastruktur in Organisationen, insbesondere in Betriebswirtschaften, sind. Sie erarbeitet die Grundlagen zur Erklärung der Aufgaben des Informationsmanagements und der Methoden zu ihrer Unterstützung ('Erklärungsaufgabe'), paßt vorhandene Methoden an und entwickelt neue Methoden, sowohl als Einzelmethoden als auch als Methodenverbund, und die zur Methodenanwendung erforderlichen Werkzeuge ('Gestaltungsaufgabe'). Sie untersucht auch die Anwendung der Methoden und Werkzeuge in der Praxis, die durch einen ganzheitlichen, primär von 'oben nach unten' verlaufenden Ansatz gekennzeichnet ist, und setzt die Untersuchungsergebnisse zur Verbesserung der Methoden und Werkzeuge um." Ziel ist ein Qualitätsmanagementkonzept, das im Rahmen der strategischen Planung der Informationsinfrastruktur entsteht und speziell auf die Belange des Information Engineering ausgerichtet ist. Es müssen dabei Vorstellungen entwickelt werden, wie die Zukunft der Informationsverarbeitung in Form von Vision, Mission, Zweck und Grundsätzen aussehen soll. Die Visions- und die Missionsaussagen enthalten in der Regel Informationen darüber, wie sich die Organisation in Zusammenhang mit Produkten, Dienstleistungen, Technologie, Mitarbeitern und sonstigen Stakeholdern darstellen will. Das methodische Vorgehen orientiert sich am Deming-Zyklus ("Plan-DoCheck-Act", [Demi86]). Über eine Reihe von Workshops werden die Vision

Umfassendes

Qualitätsmanagement

für das Information

Engineering

405

und Politik mit der Geschäftsleitung und dem Informatikmanagement erarbeitet und in einem Aktionsprogramm über einen Zeitraum von mindestens zwei Jahren über Zielvorgaben, Grundsätze und Prozeßanweisungen umgesetzt. Durch regelmäßige Prüfungen, z.B. durch interne und externe ISC)-9000-Audits, werden Schwachstellen gefunden und durch korrektive Maßnahmen behoben. Dieses Qualitätsmanagementkonzept stellt einen Beitrag im Rahmen des normativen Managements dar [Blei91]. Es legt damit den Grundstein für eine Qualitätsvorstellung, die sich primär am Markt und an den Bedürfnissen, Wünschen und Erwartungen der Kunden ausrichtet. Strategische Lösungsebene Das Qualitätsmanagementkonzept wird durch drei Kategorien von Rahmenbedingungen und Maßnahmen auf strategischer sowie taktischer Ebene umgesetzt. Es sind dies Rahmenbedingungen für • Management - Verbesserungen der Führungsarbeit - Einsatz eines Qualitätsmanagementsystems - Durchführen von Qualitätskostenanalysen - Anwendung von organisationsbezogenem Änderungsmanagement • Technologie Technologiemanagement mit - Beobachtung der Technologieentwicklung, - Bestimmung des Technologiebedarfs, - Technologieentscheid, - eigentlichem Technologietransfer und - Technologiepflege • Mitarbeiter - Qualifikation und anforderungsgerechtes Personalmanagement - Einbezug in die Prozeßentwicklung - Forcieren von Teamansätzen bei der Arbeitsgestaltung Zuerst diskutieren wir Maßnahmen zur Verbesserung der eigentlichen Führungsarbeit. Die Begründung für die Verbesserung der Führungsarbeit besteht in folgenden Fakten:

406

• Qualität bedeutet Managementverantwortung werden.

Ernest

Wallmüller

und kann nicht

delegiert

• Vorbildfunktion (leadership) wird durch sichtbares, persönliches Engagement für Qualität wahrgenommen. • Um aktive Führungsarbeit in Sachen Qualität zu leisten, sind das Verständnis und die Kenntnisse von Qualitätskonzepten, -methoden und -Werkzeugen bei Führungskräften zu fördern (daher ist die Information, die Aus- und Fortbildung für Führungskräfte in Sachen Qualität unerläßlich). Anschließend fordern wir, daß informationsverarbeitende Organisationen ein Qualitätsmanagementsystem nach ISO 9001 als Managementwerkzeug betreiben (ISO 9001 enthält die stärkste Anforderungsstufe an ein Qualitätsmanagementsystem und wird für Dienstleister und Informatikorganisationen von den Zertifizierungsstellen vorgeschrieben). Derzeit sind in Europa ca. 80 000 Unternehmen zertifiziert und die Anzahl der Unternehmen, die auf dem Weg des Systemaufbaus sind, wird auf dreimal soviel geschätzt [Zahn95], Es handelt sich daher um keine willkürliche Forderung, sondern um eine durch den Markt bedingte Entwicklung, die auch global feststellbar ist. Die Begründung für den Einsatz eines Qualitätsmanagementsystems beruht auf folgenden Fakten: • Die Kundenzufriedenheit wird verbessert, da Produkte und Dienstleistungen entsprechend ihrer Anforderungen entwickelt und produziert werden. • Die Zertifizierung nach ISO 9001 ist ein Marketinginstrument. • Immer mehr Unternehmen fordern von ihren Auftragnehmern den Nachweis der Qualitätsfähigkeit in Form eines ISO-9001-Zertifikats. • Die Internationalisierung der Märkte schreitet unaufhaltsam fort. Immer mehr Unternehmen in den USA und in Fernost sind durch den globalisierten Wettbewerb gezwungen, ein Qualitätsmanagementsystem auf der Basis von ISO 9001 zu betreiben. • Die Mitarbeitermotivation wird gesteigert, da die Mitarbeiter effizienter arbeiten können. • Im Bereich der Produkthaftung entstehen Vorteile. • Die Qualitätskosten werden reduziert durch Reduktion der Nonkonformitätskosten (insbesondere durch Reduktion der Ursachen von Reklamationen und des Anteils an Überarbeitung). • Die Häufigkeit von Audits durch den Auftraggeber wird reduziert. Die Begründungen basieren auf einer Studie, die von Price Waterhouse durchgeführt wurde [Engl93; Frie94], Darüber hinaus bietet ein effizient betriebenes

Umfassendes

Qualitätsmanagement

für das Information

Engineering

407

Qualitätsmanagementsystem eine ideale Basis, um kontinuierliche Verbesserung zu betreiben. Die Norm ISO 9001 verlangt, daß jedes Jahr ein internes Systemaudit auf Veranlassung der Geschäftsleitung durchgeführt und alle drei Jahre das ISO-9001-Zertifikat durch ein externes Systemaudit erneuert wird. Diese Bedingungen stellen sicher, daß Qualitätsmanagement keine einmalige Aktion bleibt. Als weiteres Gestaltungsmittel werden Qualitätskostenanalysen als essentielles Managementwerkzeug eingeführt, um die Umsetzung der Qualitätspolitik und der daraus abgeleiteten Qualitätsziele in der Informationsverarbeitung zu fördern. Die Begründung für die Messung und Analyse der Qualitätskosten beruht auf folgenden Fakten: • Die Größe der Qualitätskosten kann benutzt werden, um die Aufmerksamkeit der Geschäftsleitung zu gewinnen und ihre Verpflichtung zur aktiven Umsetzung des Qualitätsmanagementansatzes zu bekommen. • Die Berichterstattung über qualitätsrelevante Aktivitäten in Form von finanziellen Größen steigert die Bedeutung von Qualität in der Geschäftsleitung und stellt sicher, daß die gleiche Aufmerksamkeit erreicht wird wie durch andere Aktivitäten mit großer Auswirkung auf die Unternehmensleistung. • Das Aufzeigen von Bereichen mit hohen Qualitätskosten liefert eine gute Ausgangsbasis für Verbesserungsprojekte und -maßnahmen. • Das Wissen um Qualitätskosten und deren Entstehungsgründe ermöglicht Entscheidungen, die faktenbasiert sind. Der Nutzen von jeglichen Entscheidungen oder Maßnahmen kann entsprechend ihrer Wirkung auf die Qualitätskosten bewertet werden. Die Begründung für das Änderungsmanagement besteht darin, daß Qualitätsmanagement mit folgenden Unternehmensbedingungen konfrontiert ist: • großflächiger Einsatz neuer Technologien, • Deregulierung und Globalisierung der Märkte, • Intensivierung des Wettbewerbs, • stark erhöhte Innovationsdynamik und drastisch verkürzte Produktlebenszyklen, • Diskontinuitäten und Turbulenzen in Politik und Wirtschaftsleben, • gestiegene Ansprüche der verschiedensten Interessensgruppen der Unternehmung, • verschärfter Kampf um begrenzte Ressourcen, • Zerfließen bisheriger Unternehmensgrenzen (Fusionen, Allianzen, Ventures).

408

Ernest

Wallmüller

Für einen qualitätsorientierten Umgang mit Technologien und Innovationen werden Maßnahmen des Technologiemanagements und -transfers empfohlen [Hein92; Hump89], Begründet wird dies unter anderem durch Untersuchungen von Ulich, der feststellte, daß ca. 80 % der CAD-/CAM-Projekte in der Schweiz nicht den gewünschten Erwartungen entsprachen und nicht den erwarteten Return of Investment brachten [Ulic92], Die Qualifikation aller Beteiligten ist eine der kritischen Einflußgrößen bei den personellen Rahmenbedingungen. Als Voraussetzung für jegliche qualitätsverbessernde Maßnahme ist die Qualifikation aller Beteiligten zu prüfen. Bühner [Bühn93, 47—48] hat nachgewiesen, daß zum Erreichen eines qualitätsorientierten Qualifikationsniveaus sechs qualitätsorientierte Lernziele relevant sind: • Wissen erwerben • Erkennen von Qualitätsproblemen • Anwenden von Wissen in Problemsituationen • Systematische Analyse komplexer Situationen • Synthese, um eigene, neue Lösungsansätze zu entwickeln • Kritisches Beurteilen der eigenen Leistung hinsichtlich der vorgegebenen Ziele Qualitätsmanagement ist mit Ausbildung und Fortbildung der Mitarbeiter unabdingbar verbunden. Die Normenreihe ISO 9000 berücksichtigt dieses Faktum mit dem Normelement 18. Dort wird unter anderem der Nachweis der Anforderungen für Schulungsbedarf und der durchgeführten Schulungsmaßnahmen verlangt. Im Modell des Europäischen Qualitätspreises (EQA), das auch als europäisches TQM-Modell bezeichnet wird, finden sich die Bewertungselemente Mitarbeiterzufriedenheit und Personalmanagement. Weltklasse-Unternehmen wissen, daß es nicht länger genügt, die Kunden nur zufriedenzustellen, sondern daß die Kunden über ihre Produkte und Dienstleistungen begeistert sein sollten. Dies kann nur dann erreicht werden, wenn auch die Mitarbeiter davon begeistert sind. Mitarbeiterbeteiligung am (Qualitäts-) Prozeß ist eine notwendige Voraussetzung, um zu überzeugten und von der Qualität begeisterten Mitarbeitern zu gelangen. Die Mitarbeiterbeteiligung ist einer der wichtigsten Beiträge, den japanische Unternehmen im Rahmen ihrer Qualitätsprogramme/-konzepte geleistet haben. Die Begründung der Mitarbeiterbeteiligung beruht auf folgenden Argu menten: • Der Graben zwischen Mitarbeitern und Führungskräften wird durch Vertrauen, Kooperation und gemeinsame Ziele überwunden.

Umfassendes

Qualitätsmanagement

für das Information

Engineering

409

• Die individuellen Fähigkeiten werden entwickelt und durch Selbstführung und Führungsfähigkeit gestärkt. Dadurch wird auch das Verständnis für die "mission" geschaffen und das Vertrauen gefördert. • Die Mitarbeitermoral und das Engagement werden erhöht. • Die Kreativität und die Innovation werden gefördert, beides Voraussetzungen für einen Wettbewerbsvorsprung. • Sie hilft den Mitarbeitern, die Qualitätsprinzipien zu verstehen und verankert diese Prinzipien in der Unternehmenskultur. • Sie ermöglicht den Mitarbeitern, Probleme gleich am Ursprung zu lösen. • Die Qualität und die Produktivität werden verbessert. • Sie ist ein dominierendes Organisationsmodell unter Weltklasse-Unternehmen. Untersuchungen von Ernst & Young [Huge90] haben gezeigt, daß ein Wechsel von einem traditionellen Managementsystem zu einem, das auf Qualitätsprinzipien beruht, zwei- bis zehnmal effektiver ist, wenn er in Form von Mitarbeiterbeteiligung und Mitarbeiterbefähigung erfolgt. Operative Lösungsebene Auf dieser Ebene stehen die Prozesse im Zentrum. Durch Managementverantwortung und mit ingenieurmäßigen Methoden werden die Prozesse zur Entwicklung und Pflege der Informationsinfrastruktur gestaltet. Dafür hat sich der Begriff Prozeßmanagement [Imai86; Hump89; Harr91; Chro92] durchgesetzt. Die wesentlichen Aufgaben sind: • Prozeß-Definition • Prozeß-Verantwortung festlegen • Prozeß-Messungen • Prozeß-Kontrolle • Prozeß-Benchmarking • Prozeß-Verbesserung • Prozeß-Innovation Durch die Anwendung des Prozeßmanagements wird eine qualitativ hochwertige Erstellung und Pflege von Produkten und Dienstleistungen der Informationsverarbeitung sichergestellt. Haist und Fromm [Hais89] verstehen unter einem Prozeß das Zusammenwirken von Menschen, Maschinen (z.B. Rechnern), Informationen und/oder Materia-

410

Ernest

Wallmüller

lien und Verfahren, das darauf ausgerichtet ist, eine bestimmte Dienstleistung zu erbringen oder ein bestimmtes Endprodukt zu erzeugen. Rombach [Romb90] definiert einen Prozeß im Kontext des Software Engineering als jede Aktivität, die ein Eingabeprodukt konsumiert und ein Ausgabeprodukt erzeugt. Als Beispiele nennt er den gesamten Lebenszyklus, jede Aktivität des Lebenszyklus oder die Ausführung eines Übersetzungsprogramms. Unter Produkt versteht er jedes Dokument, das in einem Projekt erzeugt wird, unbeschadet der Frage, ob es zur direkten Auslieferung an den Kunden bestimmt ist. Wir erweitern diese Aussagen zu einer Arbeitsdefinition mit dem Fokus Planung, Kosten und Qualität: Ein Prozeß umfaßt jede Aufgabe, die innerhalb eines geplanten und budgetierten Arbeitspakets auszuführen ist. Jedes Arbeitspaket (und somit jeder Prozeß) konsumiert ein Eingabeprodukt mit bestimmten Anforderungen und führt zu einem (Ergebnis-)Produkt oder einer Dienstleistung, welches/welche definierten Anforderungen genügt. Ein Prozeß schafft einen Mehrwert für den Prozeßkunden und ist wiederholbar. Er ist gekennzeichnet durch einen Kunden-Lieferanten-Anforderungsfluß und einen Lieferanten-Kunden-Leistungsfluß. Das erweiterte Prozeßmodell ist in Abbildung 3 dargestellt.

Kunden-Lieferanten-Anforderungsfluß

Lieferanten-Kunden-Leistungsfluß * ... n-mal

Abb. 3:

Erweitertes Prozeßmodell

Beispiele für Prozesse und Subprozesse bei der Erstellung und Pflege von Informationssystemen sind beispielsweise der strategische Planungsprozeß für Software-/Informatikprodukte, der Projektmanagementprozeß, der Entwicklungs-

Umfassendes

Qualitätsmanagement

für das Information

Engineering

411

prozeß, der Evolutionsprozeß, der Qualitätsmanagement-/Risikomanagementprozeß, der Konfigurationsmanagementprozeß, die Pflege der Kunden-/Benutzerbeziehung, das Lieferantenmanagement und das Finanzmanagement. Die Kundenorientierung eines Prozesses führt dazu, daß der Kunde/Benutzer als Empfänger der Prozeßergebnisse gesehen und die Zufriedenheit des Benutzers/Kunden als primärer Faktor zur Bewertung des Prozesses herangezogen wird. Der Mensch als Benutzer, Mitarbeiter oder als Manager ist integraler Bestandteil von Prozessen. Es stellt sich die Frage, wie die Zuordnung der Prozesse zu den "ausführenden" Menschen geschieht. Man faßt kleine Mengen von Aktivitäten zusammen zu Aufgaben. Die zusammengehörigen Aufgaben einer oder mehrerer Personen in einem Projekt werden als Rollen bezeichnet. Eine Rolle besitzt eine funktionale Verantwortung zur Erreichung eines gegebenen Ziels. Es wird deutlich, daß die Zuordnung Mensch - Prozeß durch die beiden Zuordnungen Mensch - Rolle und Rolle - Prozeßbeschreibung vorgenommen wird. Eine Rolle ist also, entsprechend dieser Sichtweise, eine Abstraktion von Aktivitäten. Beispiele für Rollen bei der Erstellung und Pflege von Informationssystemen sind: • Projektteamrollen, wie z.B. Applikationsdesigner, Applikationsentwickler, Analytiker, Benutzer, Informationsarchitekt, Informationsplaner, Projektleiter, Technischer Spezialist, Tester, Wissensbasiskoordinator • Projektunterstützungsrollen, z.B. Abnahmetester, Auditor, InformationEngineering-Manager, Moderator, (Prozeß-)Qualitätsberater, Reviewer, Sponsor, Trainer Unter Prozeßengineering verstehen Haist und Fromm [Hais89] die Anwendung von Ingenieur- und Informationstechniken auf Prozesse (Geschäftsprozesse, informationsverarbeitende Prozesse). Insbesondere durch zunehmende Rechnerunterstützung und Automatisierung gewinnt das Prozeßengineering als Methode zur Formalisierung und Systematisierung von Prozessen an Bedeutung. Ein besonderes Interesse erlangt die explizite Modellierung einer Teilklasse von Information-Engineering-Prozessen, die sich mit der Entwicklung, Lieferung und der Evolution von Software beschäftigen. Die Relevanz einer expliziten Repräsentation und Standardisierung der in einer Projektumgebung existierenden Tätigkeiten wird besonders durch die vermehrte Bewertung von Softwareorganisationen mittels Capability-Maturity-Modellen (CMM) deutlich. Beispiele solcher Modelle sind:

412

•

Ernest Wallmüller

SEI-CMM,

• B O O T S T R A P [Maio92], • Software Assessment Method ( S A M ) von British Telecom, • Software Development Capability Assessment Method ( S D C A M ) von Bell Canada, • Software Quality and Productivity Analysis ( S Q P A ) von Hewlett Packard und • ISO-9001. Das ISO-Projekt SPICE [Dorl93] entwickelt einen internationalen Standard für Software-Prozeßbewertungen und -Verbesserungen, der die Erkenntnisse der obigen Modelle und Methoden berücksichtigt. Erste Werkzeuge und Hilfsmittel zur Modellierung von Softwareprozessen sind Arcadia, HFSP, M V P und Process Weaver [Romb93], Ein Beispiel einer rechnergestützten Werkzeugumgebung für Prozeßmodellierung, aber auch für die Projektabwicklung ist das Automated Methods Environment ( A M E ) von Ernst & Young [E&Y93], Humphrey [Hump89] vom Software-Engineering-Institut (SEI) der Carnegie Mellon University und seine Mitarbeiter haben die Charakteristiken eines wirklich effizienten Softwareprozesses untersucht und analysiert. Ein wirklich effizienter Softwareprozeß muß die Beziehungen zwischen allen notwendigen Aufgaben, Werkzeugen und Techniken, die benutzt werden, und die Fähigkeiten der Entwickler, das Training und die Motivation der Mitarbeiter berücksichtigen. Humphrey definiert einen Softwareprozeß wie folgt (siehe Abbildung 4):

Management

Abb. 4:

Softwareprozeß

Umfassendes

Qualitätsmanagement

für das Information

Engineering

413

Ein Softwareprozeß ist eine Menge von Aktivitäten, Methoden, Arbeitstechniken und Transformationen, die Managern und Softwareingenieuren hilft, Informationstechnologie (insbesondere Werkzeuge) einzusetzen, um Software zu entwickeln und zu pflegen, die definierte Qualitätsziele erfüllt. Das Prozeß-Fähigkeits-/Reifegradmodell, das am amerikanischen SoftwareEngineering-Institut entwickelt worden ist, unterstützt kontinuierliche Verbesserungen. Es beruht auf den Prinzipien und Erfahrungen anerkannter Qualitätsexperten, wie W. Shewart, E. Deming, J. Juran und P. Crosby. Die fünf Reifegrade von Prozessen sind: • der Initial- oder chaotische Prozeß, • der wiederholbare Prozeß, • der definierte Prozeß, • der geführte Prozeß und • der optimierende Prozeß. Die fünf Grade definieren eine Ordinalskala, die zur Messung der Prozeßreife und zur Bewertung der Prozeßfähigkeit verwendet wird. Sie helfen einer Softwareorganisation, für ihre Verbesserungsaufwände/-anstrengungen Prioritäten festzulegen. Jeder Reifegrad umfaßt eine Menge von Prozeßzielen, die bei Erfüllung wesentliche Elemente eines Softwareprozesses stabilisieren. Das Erreichen jedes Reifegrades etabliert unterschiedliche, aufeinander aufbauende Elemente eines Softwareprozesses. Dies führt zu einer Zunahme an Prozeßfähigkeit einer Softwareorganisation.

4

Schlußbemerkungen

Unsere Wirtschaft und unser gesellschaftliches Leben wird in einem solchen Maße von rechnergestützten Informationssystemen beherrscht, daß jeder von uns von diesem fundamentalen Veränderungsprozeß direkt oder indirekt betroffen ist. Nicht nur, daß Information und ihre Verarbeitung neben Kapital und Arbeit zum bestimmenden Faktor geworden ist, sondern auch der innovative und zugleich verändernde Einfluß auf alle uns umgebenden Arbeits-, Geschäfts, ja sogar Lebensprozesse zeigt quantitative, aber auch qualitative Wirkung. Mit dem vorliegenden Qualitätsmanagementansatz soll auch eine kritische Einstellung aller Informationsnutzer und -erzeuger zu Information-Engineering-Produkten und -Dienstleistungen geschaffen werden. Der vorliegende Ansatz trägt mit einem offenen und umfassenden Qualitätskonzept für die Informationsverarbeitung dem Bedarf und der Notwendigkeit Rech-

414

Ernest

Wallmüller

nung, das Erstellen und die Evolution von Informationssystemen auf einem qualitativ hohem Niveau durchführen zu können.

Literatur [Blei91] Bleicher, K.: Das Konzept Integriertes Management. Das St. Galler Management Konzept, Band 1, Campus, 1991. [Boeh81]

Boehm, B.: Software Engineering Economics. Prentice-Hall, 1981

[Biihn93] Bühner, R.: Der Mitarbeiter im Total Quality Schäffer-Poeschel, 1993. [Chro92] 1992.

Management.

Chroust, G.: Modelle der Software-Entwicklung. Oldenbourg,

[Demi86] Deming, W.E.: Out of the Crisis. MIT Center for Advanced Engineering Study, Cambridge, 1986. [Dorl93] Dorling, A.: SPICE: Software Process Improvement and Capability Determination. In: Software Quality Journal, 2 (1993), S. 209-224. [Engl93] Englert, N.; Pfriem, S.: Studie über den Nutzen von ISO 9000. Price Waterhouse, Report, Frankfurt 1993. [E&Y93] Ernst&Young: Automated Methods Environment (AME). Einführungsbeschreibung, 1993. [Fink81] Finkelstein, C.; Martin, J.: Information Engineering. Technical Report, Savant Institute, 1981. [Frie94] Friedrich. J.: Zertifizierung von Software-Qualitätsmanagementsystemen. In: Software Process Maturity, erste deutsche Konferenz zum Thema Softwareprozeßreife, Tagungsunterlagen, Institute for International Research, München, 26. - 27. Januar 1994. [Hais89]

Haist, F.; Fromm, HJ.: Qualität im Unternehmen. Hanser, 1989.

[Harr91] 1991.

Harrington, HJ.: Business Process Improvement. McGraw-Hill,

[Hein91] Heinrich, L.J.: Information WIRTSCHAFTSINFORMATIK (1991) 3.

Engineering.

In:

[Hein92] 1992.

Heinrich, L.J.: Informationsmanagement. 4. Aufl., Oldenbourg,

[Huge90]

Huge, E.C.: Total Quality. R.R. Irwin, 1990.

[Hump89] Humphrey, W.S.: Managing the Software Process. Wesley, 1989. [Imai86]

Imai, M.: Kaizen. Random House, 1986.

Addison-

Umfassendes Qualitätsmanagement für das Information

Engineering

415

[Kell92] Kellermann, T.: Fehlervermeidung in der Software-Entwicklung. In: Schweiggert, F. (Hrsg.): Wirtschaftlichkeit von Software-Entwicklung und -Einsatz. Teubner, 1992. [Maio92] Maiocchi, M.: Esprit Project BOOTSTRAP: The European Kickoff of Higher Process Maturity in Software Development. In: Woda, H.; Schynoll, W. (Hrsg.): Lean Software Development. Proceedings, Stuttgart, 22.-23. 10. 1992. [Munr92] Munro-Faure, Pitman, 1992.

L.:

Implementing

Total

Quality

Management.

[Rath88] Rathbone, M.P.; Vale, J.M.: Software Quality Management. In: Quality Assurance, 14 (1988) 3. [Rath90] Rathbone, M.P.: The Cost and Benefits Associated With the Introduction of a Quality System. In: Proc. of Sec. Int. Conf. on Software Quality Assurance, 1990. [Romb90] Rombach, H.D.: Software Specifications: A Framework. Curriculum Module SEI-CM-11-2.1, January 1990.

SEI

[Romb93] Rombach, H.D et al.: Entwicklungsumgebungen zur Unterstützung von qualitätsorientierten Projektplänen. In: Softwaretechnik-Trends, 13 (1993) 3. [Segh92] Seghezzi, H.D.: Bewirtschaftung der Qualität - eine betriebswirtschaftliche Aufgabe. In: Dokumentation Betriebswirtschaft, (1992) 1. [Ulic92]

Ulich, E.: Arbeitspsychologie. 2. Aufl., vdf, 1992.

[Wall95] Wallmüller, E.: Ganzheitliches Qualitätsmanagement in der Informationsverarbeitung. Hanser, 1995. [Zahn95] Zahner, E.: Eröffnungsreferat des Auditorentags 95 der SQS, Tagungsunterlagen, März 1995.

Gestaltungsmöglichkeiten von kybernetischen Planungs- und Kontrollverfahren Eckart Zwicker Fachgebiet Betriebswirtschaftliche System- und Planungstheorie Institut für Betriebswirtschaftslehre, Fachbereich 14 - Wirtschaft und Management Technische Universität Berlin

1

Zum Begriff der kybernetischen Planung und Kontrolle

2

Zur Formalisierung der kybernetischen Planung und Kontrolle

3

Das Dilemma der kybernetischen Planung und Kontrolle

Literatur

418

1

Eckart Zwicker

Zum Begriff der kybernetischen Planung und Kontrolle

Viele Autoren sind der Auffassung, daß die Planung und Kontrolle von Unternehmen nur in Form kybernetischer Planungs- und Kontrollsysteme realisiert werden soll. Diese Forderung wird im folgenden kritisch analysiert. Als erstes wird der Begriff eines kybernetischen Planungs- und Kontrollsystemes erläutert. Dem schließen sich einige Zitate von Autoren an, in denen die Anwendungsrelevanz solcher Systeme betont wird. Auf dieser Grundlage wird der Aufbau kybernetischer Planungs- und Kontrollsysteme beschrieben, in welchen eine optimale Kontrolle realisiert wird. Es wird sich herausstellen, daß solche optimierenden Systeme nicht mit dem Unternehmensziel einer Gewinnmaximierung zu vereinbaren sind. Daher stellt sich die Frage, ob kybernetische Planungs- und Kontrollsysteme überhaupt in einem Unternehmen realisiert werden sollten. Hierzu wird eine Logik für die Planung und Kontrolle von Unternehmen beschrieben, welche auf der Grundlage von Zielverpflichtungen beruht. Diese Planungs- und Kontrollogik wird mit dem Konzept der kybernetischen Planung und Kontrolle verglichen. Im Lichte dieses Vergleiches erfolgt eine Würdigung der Forderung nach der Realisierung kybernetischer Planungs- und Kontrollsysteme. Ein kybernetisches Planungs- und Kontrollsystem ist ein System, welches in Form eines Regelkreises gestaltet ist. Unter einem Regelkreis ist die „Gesamtheit aller Glieder" zu verstehen, „die an dem geschlossenen Wirkungsablauf der Regelung teilnehmen". 1 Die Regelung wiederum „ist ein Vorgang, bei dem eine Größe, die zu regelnde Größe (Regelgröße), fortlaufend erfaßt, mit einer anderen Größe, der Führungsgröße, verglichen und abhängig vom Ergebnis dieses Vergleiches im Sinne einer Angleichung an die Führungsgröße beeinflußt wird. Der sich dabei ergebende Wirkungsablauf findet in einem geschlossenen Kreis, dem Regelkreis, statt." 2 Viele Autoren sind der Auffassung, daß die Planung und Kontrolle von Unternehmen tatsächlich in Form eines Regelkreises abläuft und auch ablaufen soll. Im folgenden seien einige solcher Forderungen angeführt. Nürck weist darauf hin [Nürc65, 581], daß die Organisation, die einen glatten und reibungslosen Betriebsablauf gewährleistet, nichts anderes als ein kybernetisches System ist. Während hier nur implizit eine Forderung erhoben wird, äußert sich Flik eindeutiger [Flik69, 34]: „Da jeder Organisator, der eine optimale Organisation anstrebt, versuchen wird, derartige Bestimmungsmerkmale zu realisieren, kommt dem Regelkreisprinzip im Prozeß des

Gestaltungsmöglichkeiten

von kybernetischen

Planungs-

und Kontrollverfahren

419

kybernetischen Organisierens normativer Charakter zu." Von einigen Autoren wird folgerichtig darauf hingewiesen, daß wegen des Absolutheitsanspruches der kybernetischen Planung jede Planung eine Regelung darstellen muß. So bemerkt Stachowiak [Stac70, 4]: „Planung erweist sich somit als ein Regelungsprozeß. Das Planungssystem ist ein Regelungssystem. Vergleicht man es mit einem Regelkreis, so wird man den Motiven des Aktionssubjektes die Rolle der Führungsgröße zuerkennen. Das Planungssubjekt wirkt als das eigentlich regelnde System, d.h. als Regler, es vergleicht die Sollwerte der Planungsziele mit den Istwerten des beplanten Bereiches und übt aufgrund dieses Vergleiches seine regelnde Funktion aus, indem es nötigenfalls verbesserte, abgewandelte, neue Pläne erstellt, die das Aktionssubjekt in die Lage versetzen, entsprechende informationell-energetische Inputs (beim Regelkreis Stellgrößen genannt) an das Aktionsobjekt abzugeben. Auch die Störgrößen finden bei diesem Vergleich ihre Entsprechung. Von außerhalb des Planungssystemes ... auf das Aktionsobjekt wirkend, beeinflussen sie störend die gewünschte Annäherung des jeweiligen Istzustandes dieses Objekts an seinen Sollzustand." Die Beschreibung von Unternehmen anhand von Regelkreisbildern wird von vielen Autoren praktiziert. Abb. 1 zeigt die Darstellung eines Unternehmens als einen Regelkreis, welche auf Heinen zurückgeht [Hein70, 233], Außer dem Hinweis, daß das 'Zielsystem der Unternehmung' die oberste Führungsgröße des Regelkreises bildet, enthält das Schema allerdings keine betriebswirtschaftliche Interpretation der Zusammenhänge.

Störfaktoren

Abb. 1:

Das Unternehmen als ein Regelkreissystem nach Heinen

420

Eckart

Zwicker

Eine stärkere betriebswirtschaftliche Interpretation liefert das Regelkreisschema von Meffert in Abb. 2 [Meff71, 192],

Abb. 2:

Regelkreisebenen im Unternehmen nach Meffert

Es sei darauf hingewiesen, daß diese Regelkreisbilder nicht erste Ansätze einer weiteren Verfeinerung bilden, sondern auf dieser Stufe abbrechen. Solche Regelkreisbilder werden bis in die jüngste Zeit von Autoren verwendet, um den Aufbau von betrieblichen Planungs- und Kontrollsystemen zu demonstrieren. So bemerkt beispielsweise Küpper [Küpp95, 179; siehe auch Huch93, 26, Lies90, 311]: „Die Verknüpfung zwischen Planung und Kontrolle läßt sich mit dem Konzept eines kybernetischen Regelkreises entsprechend Abb. ... veranschaulichen und gestalten." Dabei wird die auf Pfohl zurückgehende Abb. 3 angeführt [Pfoh81, 20 f.].

Gestaltungsmöglichkeiten

von kybernetischen

Planungs-

und Kontrollverfahren

421

Informationen

(Vorkoppelung)

Abb. 3:

2

Darstellung des Konzeptes eines kybernetischen Regelkreises nach Pfohl

Zur Formalisierung der kybernetischen Planung und Kontrolle

Die Äußerungen der erwähnten Autoren können als Forderungen zur generellen Realisierung einer kybernetischen Planungs- und Kontrollogik verstanden werden. Diese Logik, welche die Übernahme der Forderungen zur Gestaltung technischer Regelkreise auf Unternehmen postuliert, soll etwas präziser durch vier Forderungen gekennzeichnet werden: (1) Lege als Führungsgröße einen Sollwert der Regelgröße R s für den Planungszeitraum fest. 3 (2) Stelle den Istwert der Regelgröße (R,1) nach Ablauf der Planperiode fest. (3) Wenn R s - R,1 * 0, dann wähle die Stellgröße für die nachfolgende Periode t+1 (St+i) so, daß eine Angleichung an den Sollwert erreicht wird.

422

Eckart

Zwicker

(4) Die Stellgröße S t+ i wird in Abhängigkeit von der Soll-Ist-Differenz gewählt, d.h. S t+ , = F(R S - R t '). (1) Es wird bei diesem Vorgehen unterstellt, daß die Abweichungen R s - R t ' von bestimmten Störgrößen (et) verursacht sind. Verschwinden diese Störgrößen von einem bestimmten Zeitpunkt an, konvergiert R s - R,1 mit zunehmender Periodenzahl gegen Null. Um das beschriebene Verfahren auf Unternehmen anzuwenden, ist es notwendig, eine unternehmensspezifische Interpretation der Größen Führungsgröße, Regelgröße, Stellgröße und Störgröße vorzunehmen. Betrachtet man die angeführten Texte, so unterbleibt eine solche Interpretation entweder völlig; oder es werden wie in Abb. 1 und Abb. 2 Zuordnungen vorgenommen, die (noch) nicht erkennen lassen, welche quantitativen betrieblichen Größen als Führungsgröße etc. interpretiert werden sollen. Wenn bei Heinen das 'Zielsystem der Unternehmung' als Führungsgröße bezeichnet wird, so wird nicht deutlich, wie 'das Zielsystem' durch eine Größe repräsentiert werden kann, die die Führungsgröße eines Regelkreises bildet. Ähnliches gilt für Mefferts Darstellung. Wie soll beispielsweise das 'Produktionsprogramm' als Stellgröße eines Regelkreises formuliert werden? Regelkreise werden im technischen Bereich durch Regelkreismodelle beschrieben. Dies sind empirisch interpretierte, dynamische Kalküle in der Form von (zumeist) Differential- oder Differenzengleichungen. Um eine Regelkreisplanung auch auf ein Unternehmen zu übertragen, ist es unausweichlich zu fordern, daß letztlich auch in einem Unternehmen solche Regelkreismodelle zur Planung und Kontrolle verwendet werden. Die beschriebenen Regelkreisbilder und die mit ihnen verbundenen 'unpräzisen' Interpretationen können daher nur als erste Ansätze einer noch ausstehenden präziseren kybernetischen Planungs- und Kontrollogik von Unternehmen gedeutet werden. Im Rahmen einer solchen präziseren Logik müssen aber auch Aussagen darüber erfolgen, welche quantitativen betrieblichen Größen als Variablen eines Regelkreismodelles Anwendung finden können. In der Literatur sind aber nur wenige quantitative Modelle von Betrieben oder betrieblichen Teilsystemen beschrieben, die sich als kybernetische Planungsund Kontrollmodelle interpretieren lassen. Neben einem Ansatz von Simon zur Lagerhaltungsmodellierung [Simo52] handelt es sich vor allem um Modelle des System-Dynamics-Typs, die auf Forrester zurückgehen [Forröl], Ein bestimmter Typ von Modellen, die im Rahmen dieser Konzeption entwickelt werden, lassen sich als Regelkreismodelle interpretieren. 4 Wie auch

Gestaltungsmöglichkeiten

von kybernetischen

Planungs- und

423

Kontrollverfahren

Coyle erwähnt, gibt es aber nur relativ wenige praktische Anwendungen [Coyl77, 445], Es fragt sich daher, ob die Forderung, daß Unternehmen immer eine kybernetische Planung und Kontrolle realisieren sollen, überhaupt akzeptabel ist. Diese Forderung soll unter der Annahme analysiert werden, daß es möglich sei, Unternehmen durch ein Regelkreismodell in Form von Differenzengleichungen zu beschreiben. In einer sehr einfachen Form kann ein solches Regelkreismodell durch folgendes Gleichungssystem beschrieben werden. Rtp =

R t V + e, + S t p

FormelR(2)

Stp

=

F(R S - R t ')

FormelSt(3)

R

-

Regelgröße

Rs

- Sollwert der Regelgröße

St

-

Stellgröße

8

- Störgröße

P

-

Index für Planwert

I

- Index für Istwert

In einem Regelkreissystem ist die Regelgröße (R) immer eine Bestandsgröße, die bestimmten Störgrößen (e) ausgesetzt ist. Es wird angenommen, daß die Störgröße durch eine Wahrscheinlichkeitsverteilung beschreibbar ist. Mit der Stellgröße, die anhand der Soll-Ist-Abweichung der Bestandsgröße gewählt wird, soll eine 'Angleichung an die Führungsgröße' erfolgen. Das vorliegende Regelkreismodell ist ein mehrperiodiges stochastisches Modell. Im Lichte der stochastischen Kontrolltheorie läßt sich der in den DIN-Normen gewählte Begriff einer 'Angleichung an die Führungsgröße' weiter präzisieren. Die Angleichung kann unter einem Optimierungskriterium beurteilt werden. Eine Optimierung, d.h. eine optimale Regelung kann offenbar nur darin bestehen, ein Fluktuationsmaß der Soll-Ist-Abweichung zu minimieren. Dieses Fluktuationsmaß kann beispielsweise wie in (4) die quadratische Abweichung zwischen dem Soll- und dem Istwert, d.h. (R s - R,1)2 sein. (4) Da es sich um ein stochastisches Modell handelt, wird der Erwartungswert dieser Abweichung minimiert.

Eckart Zwicker

424

Damit ist die Forderung nach einer generellen Realisierung kybernetischer Planungs- und Kontrollsysteme in Betrieben zu der Forderung verschärft, (wie bei technischen Regelkreisen) das vorliegende System durch ein solches Regelkreismodell zu beschreiben und seine fluktuationsminimierende (optimale) Stellgröße zu bestimmen. Das Ziel eines kybernetischen Planungsmodelles in einem Unternehmen besteht daher in der Fluktuationsminimierung einer Bestandsgröße wie der Lagerhaltung oder dem Arbeitskräftebestand. Alle Bestrebungen, mit einem stochastischen mehrperiodigen Unternehmensplanungsmodell andere Zielgrößen als Soll-Ist-Fluktuationsmaße zu optimieren, müßten daher 'verboten' werden, wenn die kybernetische Planung als ein zwingendes Gebot betrachtet wird. Die Akzeptanz eines solchen Gebotes auf der Ebene mehrperiodiger stochastischer Modelle führt aber zu inakzeptablen Konsequenzen. Wenn ein solches Modell eines Unternehmens entwickelt wird, liegt es nahe, die Maximierung des Erwartungswertes des Gewinnes im Rahmen des Planungszeitraumes zu fordern. Handelt es sich um ein bestimmtes Teilsystem des Unternehmens, kann die Minimierung der Kosten gefordert werden, wenn es sich um ein gewinnkompatibles Subziel handelt. Keiner dieser Fälle beinhaltet aber eine Soll-Ist-Fluktuationsminimierung, wie es die kybernetische Planung fordert. Als Beispiel sei ein mehrperiodiges stochastisches Planungsmodell des Fertigungsbereiches einer Farbenfabrik angeführt, welches von Holt, Modigliani, Muth und Simon entwickelt wurde [HoltöO, 51 f.]. Das Zielkriterium für die Optimierung dieses Systemes besteht in der Minimierung des Erwartungswertes der Gesamtkosten über einen bestimmten Planungshorizont t = 1, ..., T, d.h. / T (5) Vt=i

/

Die Periodenkomponente K t bestimmt sich nach: K t = c, * A,

Arbeitskosten

+ c 2 (At - A t _i) 2

Einstellungs- und Entlassungskosten

+ c 3 P t - c 4 A t 2 + c 5 Pt + c 6 A t

Überstundenkosten

+ c 7 (L, - c 8 - c 9 Zt) 2

Lagerkosten

Gestaltungsmöglichkeiten

425

von kybernetischen Planungs- und Kontrollverfahren

Die Aktionsvariablen sind der Arbeitskräftebestand At und die Produktionsmenge Pt. L, repräsentiert den Lagerbestand des Systemes und stellt eine Zustandsvariable dar, die durch L, = U . + P . - U ,

(6)

definiert ist. U, ist der mengenmäßige Umsatz der Farbenfabrik, der durch eine stationäre Wahrscheinlichkeitsverteilung gekennzeichnet w ird. In dem von den Autoren beschriebenen Fall einer Farbenfabrik wurden folgende Koeffizienten verwendet: c 2 = 64,3

c 3 = 0,2

c5=

c 6 = 281,0

c 7 = 0,0825 c 8 = 320,0

51,2

c4 =

5,67

c, = 340,0

c9 = 0

Die Autoren ermittelten unter Annahme eines unendlichen Planungshorizontes die folgenden optimalen Entscheidungsvorschriften: At = 0,0455 E(U t ) + 0,742 A,., - 0,00996 Lt_, + 2,003536 Pt = 0,8224 E(U t ) + 1,005 At., -

0,464 L M + 153,12

Dieses Modell läßt sich als ein Feedbacksystem interpretieren. Denn in Abhängigkeit von den in der Vorperiode realisierten Werten At.] und L,_i werden die Aktionsvariablen A t und P, gewählt. Dieses System ist aber kein Regelkreissystem, denn die Aktionsvariablen werden nicht gemäß (1) durch einen Soll-Ist-Vergleich ermittelt.

3

Das Dilemma der kybernetischen Planung und Kontrolle

Die Fixierung auf eine kybernetische Planung verschleiert offenbar den Blick für den Umstand, daß eine stochastische mehrperiodige Planung, welche zu einer Gewinnmaximierung oder Kostenminimierung führt, nie eine (fluktuationsminimierende) Regelkreisplanung ist. 5 Das hier zu Tage tretende Dilemma der kybernetischen Planung besteht darin, daß die Forderung nach Realisierung einer kybernetischen Planung bei Vorliegen eines stochastischen mehrperiodigen Modelles für eine Unternehmensplanung gegenstandslos wird. Liegt eine solche Modellbeschreibung vor, dann ist es nicht mehr sinnvoll, mit Soli-Ist-Abweichungen zu arbeiten. Das einzige Ziel besteht darin, Aktionsvariablen (wie A, und P,) zu finden, die eine Zielfunktion [wie (5)] extremieren. Einer der wenigen, die sich kritisch gegen das 'Soll-Ist-Denken' äußern, ist Laßmann. Er bemängelt [Laßm95], „daß man ein Auto offenbar erst in den

426

Eckart Zwicker

Graben fahren (muß), um aus dieser 'Abweichung' zu lernen, anstatt den Wagen anhand echter Informationen und ohne Kursabweichungen an den gewünschten Ort zu steuern". Laßmanns Ausführungen implizieren aber, daß es offenbar noch einen 'Sollpfad' für das zu steuernde Auto gibt. Im Rahmen einer mehrperiodigen stochastischen Gewinnmaximierung fehlt aber jegliche Sollvorgabe. Woran liegt es aber, daß das Konzept einer kybernetischen Planung und Kontrolle auf der beschriebenen Verbal- und Regelkreisbildebene eine solche Anziehungskraft besitzt, während es auf der Modellebene in eine Sackgasse führt? Im folgenden soll eine Planungs- und Kontrollogik beschrieben werden, die eine Art von 'Zielverpflichtungsplanung' darstellt. 6 Auf der Grundlage dieser Logik soll die Fruchtbarkeit der kybernetischen Verbal- und Regelkreisbilddarstellung erörtert werden. Es wurde davon ausgegangen, daß ein Gleichungsmodell zur Verfügung steht, dessen 'Spitze' die Topziele des Unternehmens beschreiben. Vereinfachend sei angenommen, daß das Betriebsergebnis das einzige Topziel sei. Dieses Modell besitzt bestimmte Basisgrößen, welche sich durch drei verschiedene Stati auszeichnen. Erstens: unkontrollierbare Basisgrößen. Das sind Größen wie z.B. der Wechselkurs, die unbeeinflußbar sind und für eine anstehende Planung zu schätzen sind. Zweitens: Entscheidungsparameter. Das sind Größen, die voll kontrollierbar sind, aber zu Beginn der Planung endgültig festgelegt werden. Ein Beispiel ist der Absatzpreis. Drittens: Basisziele. Das sind Größen, für deren Realisierung ein bestimmter Bereich verantwortlich gemacht wird. Basisziele können beispielsweise Absatz- oder Verbrauchsmengen sein. Die Planung erfolgt in drei Schritten. Im ersten Schritt, dem Bottom-Up-Schritt, wird eine Hochrechnung des Modelles mit Basiszielwerten vorgenommen, welche 'freiwillige Zielverpflichtungen' der Bereiche darstellen. Die Werte der unkontrollierbaren Basisgrößen sind dabei geschätzt, die Werte der Entscheidungsparameter von der zentralen Planung festgelegt. Wenn das gewünschte Bottom-Up-Betriebsergebnis nicht den Vorstellungen der Unternehmensleitung entspricht, dann legt sie ein gewünschtes Top-Down-Betriebsergebnis fest. Im Rahmen des Top-Down-Schrittes ermittelt die zentrale Planung eine Kombination von Basiszielen, welche das Top-Down-Betriebsergebnis realisiert. Während des nachfolgenden Konfrontationsschrittes werden die ermittelten Top-Down-Basisziele den Bereichen zur Realisierung angetragen. Es erfolgt eine Verhandlung über die endgültig zu realisierenden Basisziele. Diese werden (wahrscheinlich) für jeden Bereich zwischen den Bottom-Up- und den Top-Down-Basiszielwerten liegen. Nach Ablauf des Planjahres wird für

Gestaltungsmöglichkeiten

427

von kybernetischen Planungs- und Kontrollverfahren

jeden Bereich ein Soll-Ist-Vergleich seiner Basisziele vorgenommen. Die beschriebene Prozedur wird jährlich wiederholt. Die (knappe) Beschreibung des Verfahrens erfordert keine kybernetischen Beschreibungskategorien. Es stellt sich daher die Frage, wie man dieses Verfahren im Sinne einer kybernetischen Planung interpretieren kann und ob dadurch eine klarere Darstellung des Planungs- und Kontrollverfahrens zustande kommt. Als Soll-Ist-Abweichungsgrößen einer kybernetischen Planung kommen nur die Abweichungen zwischen den Basiszielen in Frage. Die Plan-Ist-Abweichung zwischen den Werten des Betriebsergebnisses ist durch eine Abweichungsanalyse auf die Plan-Ist-Abweichungen der Basisgrößen rückführbar. Sie sind daher nicht direkt mit einer Stellgröße beeinflußbar. Die unkontrollierbaren Basisgrößen führen nicht zu einer Soll-Ist-, sondern zu einer 'Wird-IstAbweichung', d.h. einer Prognoseabweichung. Sie sind ex definitione nicht durch eine Stellgröße beeinflussbar. Die Entscheidungsparameter sind ex definitione voll kontrollierbar. Sie sind daher als 'eingefrorene' Stellgrößen interpretierbar. Eine kybernetische Planung setzt aber 'bewegliche' Stellgrößen voraus. Soll eine kybernetische Planung stattfinden, dann müssen in dem Modell Stellgrößen, d.h. kontrollierbare Basisgrößen, auftreten, deren Werte in Abhängigkeit von der Soll-Ist-Differenz der Vorperiode festgelegt werden. Das ist aber in dem beschriebenen Planungs- und Kontrollsystem nicht der Fall. Das Planungsmodell besitzt keine 'beweglichen' Stellgrößen, d.h. Maßnahmegrößen, die periodenweise durch eine Entscheidungsvorschrift der Form (3) festgelegt werden. Es besitzt aber Basisziele, deren Sollwerte (BZ S ) die Bereiche durch die Realisierung bestimmter Maßnahmen M t , M 2 , ... zu realisieren versuchen. Diese Maßnahmen und ihre Verknüpfung mit den Basiszielen werden aber nicht in dem Modell beschrieben. Die Bereiche gehen bei der Festlegung ihrer Bottom-Up-Basiszielverpflichtungen aber von bestimmten Verknüpfungsannahmen, d.h. Maßnahmen-Basiszielhypothesen aus. Diese können durch BZ = f(M],..., M n )

(7)

gekennzeichnet werden. Abb. 4 zeigt, in welcher Art diese Maßnahmen-Basiszielhypothesen in dem beschriebenen Planungs- und Kontrollsystem auftreten.

Eckart Zwicker

428 Periode t

Periode t+1

BottomTop- KonfronUpDown- tationsPlanung Planung planung

BottomTop- KonfronUpDown- tationsPlanung Planung Planung

BZ,

>

M,

Abb. 4:

BZ;

BZ,

?

A

MaßnahmenBasiszielHypothesen

M!

Beziehung zwischen den Maßnahmen-Basiszielhypothesen und den Basiszielverpflichtungen

Zur Vereinfachung wird angenommen, es gäbe in dem Planungs- und Kontrollsystem nur ein Basisziel (BZ). Dessen Bottom-Up-Wert in der Periode t wird von dem Verantwortungsbereich aufgrund der Maßnahmen-Basiszielhypothese MtB —» BZ,8 bestimmt. Am Ende der Konfrontation besitzt der Verantwortungsbereich eine revidierte Maßnahmen-Basiszielhypothese M t p —> BZtp, die zu der Planendwert-Basiszielverpflichtung BZtP führt. Sobald der Basiszielistwert BZt' bekannt ist, wird der Verantwortungsbereich überprüfen, wie die MaßnahmenBasiszielhypothese im Lichte der Istgrößen BZ,1 und M,1 zu revidieren ist. Wenn nunmehr für die nächste Planperiode t+1 eine erneute Bottom-Up-Basiszielverpflichtung BZt+]B vorzunehmen ist, dann wird die zugrundeliegende Maßnahmen-Basiszielhypothese Ml+iB BZt+iB auch von der Hypothese B b 1 Mt —» BZ, und den Istergebnissen BZ, und M,1 abhängen. Diese Abhängigkeit ist aber äußerst kompliziert. Der Bereich kann zu der Auffassung gelangen, daß die neue Basiszielverpflichtung verändert werden kann, weil in der Vorperiode das Basisziel 'ohne große Belastung' realisiert wurde. Er kann auch neue Maßnahmen, die vorher noch nicht bewußt waren, wählen etc . Im Sinne einer Regelkreisinterpretation wäre eine Maßnahme Mt+iB zu wählen, die eine Funktion der Differenz von BZ,P - BZT1 ist. Das ist eine unzulässige Vereinfachung des Planungs- und Kontrollprozesses, die zwar zu einer Regelkreisinterpretation führt, aber den Prozeß nicht mehr in einer adäquaten Weise beschreibt. Wenn man von der Annahme ausgeht, daß die Maßnahmen-Basiszielhypothese (7) mit in das Planungsmodell aufgenommen wird, dann wird das beschriebene Dilemma der kybernetischen Planung auch in diesem Kontext deutlich. Die

Gestaltungsmöglichkeiten

von kybernetischen Planungs- und Kontrollverfahren

429

Wahl der 'Stellgröße' M ,+1B hängt nicht von der Soll-Ist-Differenz des Basiszieles ab. Sie ist vielmehr so zu wählen, daß das Betriebsergebnis maximiert wird. Es liegt damit eine reine optimierende Planung vor, die keine kybernetische Deutung zuläßt. In fast allen anstehenden Fällen einer Unternehmensplanung ist es nur nicht möglich, in Planungsmodellen die Basisziele auf bestimmte zu optimierende Aktionsvariablen eindeutig zurückzuführen und damit die Hypothese (7) in das Planungsmodell einzubauen. Daher ist die beschriebene Zielverpflichtungsplanung eine geeignete Planungslogik für eine tatsächlich auch anwendbare Planung. In diesem Sinne läßt sich die in der Praxis verwendete flexible Plankostenrechnung als eine Realisierung dieser Zielverpflichtungsplanung rekonstruieren. Wie dargelegt, führt der Versuch, die beschriebene Planungs- und Kontrollprozedur als ein Verfahren der kybernetischen Planung zu interpretieren, zu Unklarheiten und Mißverständnissen. Daher fragt es sich, ob der kybernetischen Planung oder Regelkreisplanung tatsächlich eine solche Bedeutung zukommt.

Literatur [Coyl77]

Coyle, Robert G.: Management System Dynamics. London 1977.

[Flik69] Flik, Heinrich: Kybernetische Ansätze zur Organisation Führungsprozesses der Unternehmung. Berlin 1969. [Forröl] 1961.

des

Forrester, Jay Wright: Industrial Dynamics. Cambridge, Mass.

[Hein70] Heinen, Edmund: Betriebliche Kennzahlen - eine organisationstheoretische und kybernetische Analyse. In: Linhardt, Hanns et al. (Hrsg.): Dienstleistungen in Theorie und Praxis. Stuttgart 1970, S. 227-236. [HoltöO] Holt, Charles C., Modigliani, Franco, Muth, John F., Simon, Herbert A.: Planning Production, Inventories, and Work-Force. Englewood Cliffs, N.J. 1960. [Huch93] Huch, Burkhard: Integrierte Informationssysteme im Controlling. In: Bloech, Jürgen et al. (Hrsg.): Managementorientiertes Rechnungswesen. Wiesbaden 1993, S. 21-37. [Küpp95] Küpper, Hans-Ulrich: Controlling - Konzepte, Aufgaben, Instrumente. Stuttgart 1995. [Laßm95] Laßmann, Gert: Buchbesprechung zu: Müller, H.: Prozeßkonforme Grenzplankostenrechnung. In: ZfbF 5 (1995) S. 523. [Lies90] Liessmann, Konrad: Strategisches Controlling als Aufgabe des Managements. In: Mayer, Elmar, Weber, Jürgen: Handbuch Controlling. Stuttgart 1990, S. 303-323.

430

Eckart Zwicker

[Meff71] Meffert, Heribert: Systemtheorie aus betriebswirtschaftlicher Sicht. In: Schenk, Karl-Ernst (Hrsg.): Systemanalysen in den Wirtschafts- und Sozialwissenschaften. Berlin 1971, S. 174-206. [Nürc65] Nürck, Robert: Wirtschaftskybernetik - Ein Schlüssel zur Ganzheitsbetrachtung. In: ZfB 35 (1965), S. 573-592. [Pfoh81 ]

Pfohl, Hans-Christian: Planung und Kontrolle. Stuttgart 1981.

[Simo52] Simon, Herbert A.: On the Application of Servomechanism Theory on the Study of Production Control. In: Econometrica 20 (1952), S. 247-268. [Stac70] Stachowiak, Herbert: Grundriß einer Planungstheorie. In: Kommunikation VI (1970), S. 1-18. [Zwic80] Zwicker, Eckart: System Dynamics in Inventory and Production Planning. In: OR Spektrum 1 (1980), S. 143-168.

Anmerkungen 1

DIN 19226 Definitionen der Regelung.

2

Ebenda.

3

Es handelt sich hierbei um den Fall einer Festwertregelung. Die nachfolgenden Betrachtungen können in analoger Weise auch für andere Formen einer Regelung, z.B. eine Folgeregelung vorgenommen werden, in welcher der Sollwert nicht über alle Perioden unverändert bleibt.

4

Es handelt sich um singulär offene Modelle, welche mit Soll-Ist-Entscheidungsvorschriften arbeiten und in Form von Testantworten analysiert werden. Siehe hierzu [Zwic80].

5

Sie ist nur dann mit einer fluktuationsminimierenden Regelkreisplanung identisch, wenn die Minimierung der Fluktuation einer Bestandsgröße (der Regelgröße) gleichzeitig auch zu einer Gewinnmaximierung bzw. Kostenminimierung führt. Eine solche Zielkompatibilität ist selbst für Einzelfälle sehr unwahrscheinlich.

6

Sie wird vom Verfasser als 'inkrementale Zielplanung' bezeichnet.

Schlagwortverzeichnis

—A— Ablauforganisation 52; 154; 156; 240; 289; 299 Agenten 103; 105; 106; 116; 198 Architektur 71; 95; 97; 124; 130; 168; 171; 195; 196; 222; 229; 236; 237; 238; 241;242; 245; 248; 249;250; 254; 255; 256; 286; 306; 346; 400 Aufbauorganisation 154; 156; 157; 196;197;249; 299 Ausbildung 59; 90; 91; 92; 94; 96; 99; 155; 265; 400; 408 —B— Benutzerbeteiligung 334; 335; 340; 343; 350 Benutzerschnittstelle 52; 96; 171; 180;248; 325 Benutzungsschnittstelle 153 Beobachtung 44; 45; 47; 48; 76; 77; 81 Betriebswirtschaftslehre 32; 36; 37; 39; 42; 51; 54; 69; 72; 76; 80; 114; 142 Business Engineering 216; 217; 231 Business Process Reengineering 152;154;216;236; 244; 245 —C— Case-Based Reasoning 211 Controlling 103; 149; 196; 211; 240; 241; 247; 255; 308; 359 Controllinginstrument 281 —I)— Datenbankschema 173; 185; 186; 313; 315; 3 1 7 ; 3 1 8 ; 3 1 9

Datenmodell 21; 79; 82; 130; 131; 183;184; 187; 249; 312; 313; 315;318 Dezentralisierung 52; 62; 157; 216; 240; 241; 242 Dokument 69; 149; 194; 195; 196; 197;198; 209; 266 Dokumentenmanagement 153; 194 —E— Electronic Mall 303; 304; 305; 306 empirisch 32; 43; 44; 45; 47; 60; 62; 69; 74; 81; 82; 114; 115; 152; 356;422 Empirismus 77 Entity-Relationship 131; 132; 312; 370;371; 380; 383; 385; 390; 393 Entscheidungsunterstützungssystem 332 Erfolgsfaktor 102; 220; 222; 226; 308 Evaluierung 270; 278; 280; 281; 282;351 —F— Fallstudie 44; 45; 94; 95 Flexibilität 150; 208; 223; 247; 256 Forschung 32; 45; 61; 69; 74; 75; 98; 161; 184; 266; 267; 268; 269; 270; 274; 275; 277;333 Forschungsmethode 32; 36; 37; 38; 44; 45; 47; 48; 58; 62; 63 Funktionsmodell 131; 132; 133; 134; 136; 137 —G— generisch 181; 182; 188

432

Schlagwortverzeichnis

Geschäftsprozeß 19; 106; 109; 138; 139; 150; 168;194; 195;245; 246; 247; 251; 255; 373 Geschäftsprozeßmanagement 161; 237; 244; 245; 246; 250;252 Group Support System 332 Grundlagenforschung 73 Grundsätze ordnungsgemäßer Modellierung 184 —II— Hochschulklinik 264; 265; 267; 281 —I— Informatik 26; 32; 36; 37; 50; 51; 54; 61; 62; 63; 71; 72; 76; 83; 92; 93; 94; 103; 104; 108; 118; 124; 155; 168; 183; 400 Information 18 Informationsinfrastruktur 33; 236; 238; 347; 348 Informationsmanagement 28; 29; 68; 106; 217;237;238;239; 246; 300; 332; 334; 335; 404 Informationsmodell 24; 53; 238; 246 Informationssystemarchitektur 244 Innovation 39; 42; 113; 297; 355; 356; 407; 409 Integration 26; 130; 148; 151; 153; 155; 168; 171;181;183;195; 196; 216; 243; 248; 256; 270; 292; 302; 313; 360; 370 Integration Engineering 170; 188 Integrationsfenster 187 —K— Know-how 108; 109; 110; 114; 194; 197; 203; 205; 211; 236; 287; 290; 361; 401 Know-how-Datenbank 104; 204 Know-how-Unternehmen 114 kognitiv 81; 102; 103; 118

Kölner Integrationsmodell 168 Konstruktivismus 78 Kontrollsystem 418; 428 Kooperation 91; 93; 104; 216; 227; 241; 286; 288; 290; 293; 295; 297; 298; 299; 301; 408 kritischer Rationalismus 77 Kybernetik 51 kybernetisch 418; 421; 423; 424; 425; 427 —L— Lebenszyklus 109; 236; 410 Lehre 83; 154; 264; 265;272 Lernprozeß 110; 113; 115 Lerntheorie 52; 114 —M— Medizin 264; 267 Methode 25; 26; 32; 38; 44; 46; 57; 70; 83; 88; 103; 106; 118; 168; 170; 237; 240; 244; 250; 282; 286; 316; 317; 318; 327; 404; 409; 411 Methodik 26; 30; 101; 270; 274 Metrik 360; 361; 367 —O— Objektorientierung 134; 137; 141; 237; 312; 313; 315; 317; 318; 322; 324; 327 Organisationslehre 37; 39; 42; 43; 48; 53; 54; 61; 63; 77; 80; 82; 156; 158 Outsourcing 240; 297 —P— Paradigma 76; 78; 96; 104; 130; 134; 137; 141; 169; 181; 188; 245; 246; 313 Petri-Netz 370; 373 Phasenmodell 24; 25; 195 Planungssystem 418; 424; 428

Schlagwortverzeichnis

Positivismus 77 Prototyp 27; 46; 48; 76; 96; 174; 300 Prozeßhandbuch 156; 161;162 Prozeßmanagement 148; 152; 161; 402;403; 409 Prozeßmodell 21; 25; 139; 141; 152; 195; 196; 198; 246; 248; 251;254 Prozeßorientierung 240; 255 - Q -

Qualität 25; 44; 79; 88; 89; 97; 182; 187; 222; 231; 298;306;341; 398; 400; 401; 404 Qualitätsmanagement 398; 401; 404; 407; 408; 411 Qualitätssicherung 88; 89; 98; 236; 401;402 —R— Reengineering 170; 187; 225; 327 Reverse Engineering 26; 188; 313 Revision 149 rural areas 286; 289; 291 —S— Softwarequalität 399 Softwaretechnik 89; 90; 93 Softwaretechniker 90; 91; 92; 93; 95 Stakeholder 334; 335; 341; 349; 350 Strategie 30; 61; 82; 185; 218; 222; 227; 231;232;240;243; 307;398 Synopse 18 Systemarchitektur 170; 244 Systemplanung 28; 29; 103; 106; 287;334; 343

433

—T— Team 40; 44; 90; 95; 148; 154;157; 160; 163; 240; 243; 273; 304; 334;336;350; 405;411 Telematik 291; 292; 294; 295; 296; 303 —U— Unternehmensarchitektur 243 Unternehmensdatenmodell 168 Unternehmenskultur 102; 105; 114 —V— Verhaltenswissenschaft 51; 52; 62; 105 virtuell 173; 256; 298; 300; 305 virtuelle Organisation 104 virtuelles Unternehmen 104; 152; 236; 244 Vision 25; 59; 63; 227 Vorgangsbearbeitung 211; 241 Vorgangskette 239 Vorgangsmappe 196; 201; 203; 205; 206; 209; 211 —W— Weiterbildung 89 Wertschöpfung 198 Wirtschaftsinformatik 21; 22; 31; 32; 36; 37; 39; 42; 43; 49; 50; 51; 59; 61; 63; 68; 69; 72; 76; 80; 83; 102; 124; 125; 142;158;168; 183; 188; 229; 404 Wissenschaft 17; 18; 31; 36; 37; 41; 42; 45; 50; 54; 56; 59; 61; 68; 69; 70; 71; 75; 76; 77; 78; 104; 109; 114; 274; 281 Workflow 228; 230; 299 Workflow Management 148; 149; 150; 151; 153; 154; 155; 162; 194; 195; 200; 201; 230; 245; 252;254;255

434

Workflow-Modell 196; 198; 253; 254 Workflow-Script 197; 201; 203; 208 Workgroup Computing 148

Schlagwortverzeichnis

—Z— Zentralisierung 216

Autorenverzeichnis Dr. Baugut Gunar Deutsches Krankenhausmanagement Beratungs- u. Forschungsgesellschaft mbH Am Bonneshof 6 D-40474 Düsseldorf Telefon-Büro: 0211/4548827 Faxanschluß: 0211/4548850 Dipl.-Inf. Fischer Rupert Forschungsinstitut für Angewandte Software-Technologie Arabellastr. 17 D-81925 München Telefon-Büro: 089/920047-53 E-Mail: [email protected] Prof. Dr. Heilmann Heidi Universität Stuttgart, BWI, Abt. für Wirtschaftsinformatik Silberburgstr. 90 D-70176 Stuttgart Telefon-Büro: 0711/121-3194 Faxanschluß: 0711/121-3197 E-Mail: [email protected] Prof. Dr. Heinrich Lutz J. Universität Linz, Inst, für Wirtschaftsinformatik Altenberger Str. 69 A-4040 Linz-Auhof Telefon-Büro: 0732/2468/9456 Faxanschluß: 0732/2468/10 E-Mail: heinrich @ winie.uni-linz.ac.at

436

Autorenverzeichnis

Prof. Dr. Heinzl Armin Universität Bayreuth, Lehrstuhl für BWL III Universitätsstraße 30 D-95440 Bayreuth Telefon-Büro: 0921/552807 Faxgerät: 0921/55842807 E-Mail: [email protected] Dipl.-Wirtschaftsing. Jaeschke Peter Promatis Informatik Decostraße 10 D-76307 Karlsbad Telefon-Büro: 07248/91450 Prof. Dr. König Wolfgang Universität Frankfurt/Main, Inst, für Wirtschaftsinformatik Postfach 11 19 32 D-60054 Frankfurt/Main Telefon-Büro: 069/798-23318 Faxanschluß: 069/798-8585 E-Mail: [email protected] Prof. Dr. Kurbel Karl Europa-Universität Viadrina, Lehrst, für Wirtschaftsinformatik II Große Scharmstr. 59 D-15230 Frankfurt/Oder Telefon-Büro: 0335/5534-320 Faxanschluß: 0335/5534-321 E-Mail: [email protected] Prof. Dr. Lehner Franz Universität Regensburg, Inst, für Wirtschaftsinformatik D-93040 Regensburg Telefon-Büro: 0941/943/2734

Autorenverzeichnis

Prof. Dr. h. c. mult. Mertens Peter Universität Erlangen-Nürnberg, Bereich Wirtschaftsinformatik I Lange Gasse 20 D-90403 Nürnberg Telefon-Büro: 0911/5302-284 Faxanschluß: 0911/536634 E-Mail: wsw [email protected] Dipl.-Inf. Morschheuser Stefan Universität Erlangen-Nürnberg, Bereich Wirtschaftsinformatik I Postfach 3931 D-90020 Nürnberg Telefon-Büro: 09131/85-7881 Faxanschluß: 09131/85-7880 E-Mail: Morschheuser@wiso. uni-erlangen.de Prof. Dr. Oberweis Andreas Universität Frankfurt/Main, Inst, für Wirtschaftsinformatik Postfach 11 19 32 D-60054 Frankfurt/Main Telefon-Büro: 069/79828722 Faxanschluß: 069/79825073 E-Mail: [email protected] Prof. Dr. Österle Hubert Hochschule St. Gallen, Inst, für Wirtschaftsinformatik Dufourstr. 50 CH-9000 St. Gallen Telefon-Büro: 071/30 24 20 Faxanschluß: 071/22 87 56 Internet: [email protected]

437

438 Prof. Dr. Pils Manfred Universität Linz, Inst, für Datenverarbeitung Altenbergerstr. 69 A-4040 Linz Telefon-Büro: 0732/2468-9152 E-Mail: [email protected] cand. rer. pol. von Poblotzki Ansgar Universität Frankfurt/Main, Inst, für Wirtschaftsinformatik Mertonstraße 17 D-60054 Frankfurt/Main Telefon-Büro: 069/798-23318 Faxanschluß: 069/798-8585 E-Mail: {wkoenig, mrumpf, poblotzki} @wiwi.uni.frankfurt.de Prof. Dr. Pomberger Gustav Universität Linz, Inst, für Wirtschaftsinformatik Altenbergerstr. 69 A-4040 Linz Telefon-Büro: 0732/2468-9432 Telex: 022323 uni Ii a Faxanschluß: 0732/2468-9430 E-Mail: [email protected] Mag. Prückler Thomas Universität Linz, Inst, für Wirtschaftsinformatik Data & Knowledge Engineering Altenbergerstraße 69 A-4040 Linz Telefon-Büro: 0732/2468-9473 Faxanschluß: 0732/2468-9471 E-Mail: prü[email protected]

Autorenverzeichnis

Autorenverzeichnis

Dipl.-Kfm. Raufer Heinz Universität Erlangen-Nürnberg, Bereich Wirtschaftsinformatik I Lange Gasse 20 D-90403 Nürnberg Telefon-Büro: 0911/5302-284 Faxanschluß: 0911/536634 E-Mail: {Mertens, Morschheuser,Raufer}@wiso.uni-erlangen.de Priv.-Doz. Dr. Rautenstrauch Claus DIRON Wirtschaftsinformatik GmbH Geringhoffstraße 48 D-48163 Münster Telefon-Büro: 0251/979200 Prof. Dr. Roithmayr Friedrich Universität Innsbruck, Inst, für Wirtschaftsinformatik Herzog-Otto-Straße 8/II A-6020 Innsbruck Telefon-Büro: 0512/507/7650 Faxanschluß: 0512/507/2844 E-Mail: [email protected] Dr. Rumpf Marcus-Julian Neue Niedenau 2 D-60325 Frankfurt/Main Telefon-privat: 069/7432639 Prof. Dr. Scheer August-Wilhelm Universität des Saarlandes, Inst, für Wirtschaftsinformatik Postfach 15 11 50 D-66041 Saarbrücken Telefon-Büro: 0681/302-3106 Faxanschluß: 0681/302-3696 E-Mail: [email protected]

439

440

Prof. Dr. Schrefl Michael Universität Linz, Inst, für Wirtschaftsinformatik Altenberger Str. 69 A-4040 Linz-Auhof Telefon-Büro: 0732/2468/9479 E-Mail : schrefl @ dke.uni-linz. ac .at Prof. Dr. Schwärtzel Heinz G. Forschungsinstitut für Angewandte Software-Technologie Arabellastr. 17 D-81925 München Telefon-Büro: 089/92004740 Faxanschluß: 089/92004718 E-Mail: schwärtzel @fast.de Prof. Dr. Sinz Elmar J. Universität Bamberg, Lehrstuhl für Wirtschaftsinformatik Feldkirchenstr. 21 D-96047 Bamberg Telefon-Büro: 0951/863-2511/2 Faxanschluß: 0951/39636 E-Mail: [email protected] Dr. Splettstößer Dietrich M & I Beratungsgesellschaft mbH Elfbuchenstr.23 D-34119 Kassel Telefon-Büro: 0561/71508 Faxanschluß: 0561/772368 derzeit: E-Mail: [email protected]

Autorenverzeichnis

Autorenverzeichnis

441

Prof. Dr. Stucky Wolffried Universität Karlsruhe (TH), Inst, für Angewandte Informatik und Formale Beschreibungsverfahren Kaiserstr. 12 D-76128 Karlsruhe Telefon-Büro: 0721/6083812 Faxanschluß: 0721/693717 E-Mail: stucky @ aifb.uni-karlsruhe.de Univ.-Doz. Dr. Wallmüller Ernest ATAG Informatik AG, Kanalstraße 31 CH-8152 Glattbrugg Telefon-Büro: 01/810/1233 Faxanschluß: 01/810/9909 [email protected] Prof. Dr. Zwicker Eckart TU Berlin, Institut für Betriebswirtschaftslehre Straße des 17. Juni 135 D-10623 Berlin Telefon-Büro: 030/31423601