5. U nternehmensmodellierung

"Charakteristisch fiir jede Theorie- oder Modellbildung ist, daf dieRealitat nur symbolisch und zugleich unter Beschrankung auf dasWesentliche abgebildet wird (Abstraktion vom Unwesentlichen). Da­mit tragen Theorien zur Komplexitatsreduktion bei. Eine vollstan­dige Abbildung der Realitat ware - abgesehen von der Frage derMachbarkeit - ebenso nutzlos wie eine Nachbildung im MaBstab 1:1.Grundsatzlich gilt: Je einfacher eine Theorie sein solI, desto h6herrnuf der Abstraktionsgrad sein. Was bei dieser Abstraktion als we­sentlich bzw. unwesentlich angesehen wird , hangt von der Zweckset­zung der Theorie (des Modells) ab." (Heinen (1991), S. 6)

"All models are wrong, but some are useful." (George Box)

Die Unternehmensmodellierung solI die notwendige Transparenz iiber Da­ten und Prozesse im Unternehmen schaffen, d.h. auch iiber Informationen undInforrnationsfliisse.! Die Bedeutung dieser Transparenz liegt sowohl in derAnalyse von Prozessen mit Blick auf Rationalisierung und Automatisierungals auch dem Erkennen von Mustern (fiir eine rezeptive Problemwahrneh­mung und Entscheidungsfindung), d .h. in der Schaffung einer strukturiertenBasis fiir die Strategieentwicklung. Die Unternehmensmodellierung ist somitaus zwei unterschiedlichen Sichtweisen von groBer Bedeutung fiir das Infor­mationsmanagement und die Wirtschaftsinforrnatik; zum einen fiir die Kon­zeption und Erstellung von Anwendungssystemen, zum anderen (und zwariibergeordnet) fiir die Gestaltung des Informationssystems an sich, d.h. fiirdie Organisationsgestaltung durch Darstellung der ProzeB- und Datenstruk­turen sowie deren Zusammenhange.

Die Transparenz iiber die repetitiven Ablaufe kann vor allem bei der Soft­waresystementwicklung genutzt werden. Softwareprodukte dienen zum einender Unterstiitzung der Kommunikation und der Informationsversorgung, zumanderen der Automatisierung von Prozessen und z.B. der Ubertragung vonInformationsfliissen auf Workflow Management-Anwendungen. Die Software­entwicklung unterliegt dabei neben sich standig verandernden Anforderungenauch standig neuen technischen M6glichkeiten (u.a. evoziert durch die Ent-

1 Aus produktionswirtschaftlicher Sicht spiegelt der Inforrnationsfluf insbesondereden LeistungserstellungsprozeB wider und ist mit diesem untrennbar verbunden .

S. Voß et al., Informations-management© Springe-Verlag Berlin Heidelberg New York 2001

150 5. Unterne hmensmodellierung

wicklung im Hardwarebereich). Die gegenseit ige Beeinflussung der beidenBereiche wur de im EWIM-Ansatz bereits verdeutlicht (s. Kap . 3.1.5, S. 65).Die Modellierung erfolgt hier allgemein von natiirli chsprachlichen Aussageniiber die Rekonstruktion der Begriffe, auf denen die Aussagen basieren, biszu einem Schema-Entwurf. Auf Basis dieses Entwurfs kann dann eine Imple­mentierung erfolgen.

Modelle werden in der Literatur oftmals in Beschreibungs- (deklarativ)und Entscheidungsmodelle (normativ) klassifiziert; vgl. z.B. Domschke undDrexl (1998) . Ein Unte rnehmensmodell kann als deklar atives Modell bezeich­net werden, wenn es der reinen Beschreibung dient , ohne als Entscheidungs­modell genutzt zu werden. In diesem Kapitel stellen wir zunachst einigeModellierungsmethoden bzw. (graphische) Beschreibungsspr achen zur Erstel­lung prim ar deklarativer Modelle VOL Diese Modelle konnen aber auch fiirweitere Analysen eingesetzt werden. So kann z.B. die Buchhaltung (als dekla­ratives Modell) als Basis fiir weitergehende Analysen des Controlling dienen.

Eine detailliertere Klassifikation unterscheidet Beschreibungsmodelle, Er­klarungsmodelle und Entscheidungsmodelle; vgl. Schweitzer (1994). Es wer­den Beschreibungs- und Erkl arungsmodelle danach unterschieden, ob demModell neben rein deklar ativen Dingen und Beziehungen (Beschreibungsmo­delle) auch Ursache-Wirkungsbeziehungen entnommen werden k6nnen. Dasich eine eindeutige Unte rscheidung fur viele Modelltypen als schwierig er­weist, klassifizieren wir die Modelltypen, die wir im folgenden beschreiben,lediglich nach dem Grad der Erklarungsorient ierung (von rein beschreibendzu erklarenden Modellen) und dem Grad der Entscheidungsorientierun g (vgl.Abb . 5.1).

Erklarungs­oricnticrung

Funktionshierarchie­diagramrn , Datcnmodcll,Organigrarnm , Softw are ­archit ekturbes chrei ­

bend

Referenzmodell

maihematischcsOptirn ierun gsmodell ,Simulationsmod ell

Prognosemodell

Entscheidungs ­orien tierung

Abbildung 5.1. Einordnung der vorgest ellten Modelltypen

5. Unternehmensmodellierung 151

Mathematische Optimierungsmodelle sind klassische Entscheidungsmo­delle, besitzen aber gleichfalls ein relativ hohes Erkliirungspotential. Proble­matisch an diesen Modellen ist die Kompliziertheit der Modellentwicklungmittels der zur Modellierung verwendeten Sprache.f Das Potential von Simu­lationsmodellen zur Entscheidungsunterstiitzung ist tendenziell geringer, dadiese Modelle keine Optimierung aus sich heraus beinhalten, sondern lediglichzur Systembewertung und -analyse herangezogen werden konnen.i' Gleich­wohl bietet sich die Simulation insbesondere zur Entscheidungsunterstiitzungin Problemfeldern an, in denen die mathematische Optimierung aufgrund derSystemkomplexitiit und stochastischer Einfliisse an eine Grenze der Anwend­barkeit stoBt (vgl. Kap. 5.4.5). Beide Ansiitze werden daher beziiglich beiderDimensionen in Abb. 5.1 als gleichrangig bewertet. Prognosemodelle sindsowohl beziiglich der Erklarungs- als auch der Entscheidungsorientierung un­terhalb der Simulations- und Optimierungsmodelle angeordnet.

Dariiber hinaus sind weitere, weitaus weniger stark entscheidungsorien­tiert ausgelegte Modellierungsansiitze von Relevanz. Innerhalb dieser zweitenGruppe besitzen wiederum Referenzmodelle ein hoheres Erkliirungspotentialals die iibrigen Ansiitze. Referenzmodelle sind Modelle, die ideale Struktu­ren oder Abliiufe der jeweiligen Branche repriisentieren sollen. Sie ergebensich durch Abstraktion mehrerer unternehmensspezifischer Modelle und un­ter Beriicksichtigung theoretischer Erkenntnisse (vgl. Kap. 5.6 sowie Beckeret al. (1995), S. 436). Diese Modelle besitzen einen hohen Erklarungscharak­ter, da sie ein (imaginiires oder idealtypisches) Unternehmen mit allen re­levanten technischen und betriebswirtschaftlichen Wirkungsbeziehungen be­schreiben (Keller (1993), S. 55). Dariiber hinaus konnen Entscheidungen iiberorganisatorische Veriinderungen durch den Vergleich von tatsiichlich realisier­ten Strukturen im Unternehmen und Referenzmodellen unterstiitzt werden.Eine starker entscheidungsorientierte Moglichkeit, Analysen durchzufiihren,besteht in der Anbindung eines solchen Modells an eine Simulationsumge­bung. Hier konnen unter Einbeziehung geeigneter Datenbasen betrieblicheAbliiufe simuliert und unterschiedliche Szenarien, z.B. auch organisatorischeVeriinderungen vor Einfiihrung im realen System, getestet werden.

In diesem Kapitel diskutieren wir unterschiedliche Modellierungsmetho­den, die fiir Unternehmensmodelle relevant sind. Diese sollen auch anhanddes Ansatzes von Taylor (1995) betrachtet werden. Er sieht die einzigeMoglichkeit, Softwareanwendungen schritthaltend mit organisatorischen Ver­iinderungen und technischen Innovationen erstellen zu konnen, in der Imple­mentierung integrativer Unternehmensmodelle. Taylor (1995), S. 21, unter-

2 Auf die mathematische Modellierung im Kontext der mathematischen Program­mierung werden wir im folgenden nicht eingehen. Der Leser wird hier auf Wil­liams (2000) verwiesen.

3 Die Simulation gehort zu den Methoden des Operations Research und stelltneben der Graphentheorie und der linearen sowie der kombinatorischen Opti­mierung die fur die Praxis wichtigste Teildisziplin des Operations Research dar;vgl. Domschke und Drexl (1998) .

152 5. Unternehmensmodellierung

scheidet zunachst die aus betriebswirtschaftlicher Sicht relevanten Modellein:

• Datenmodelle,• ProzeBmodelle,• Simulationsmodelle,• Workflow-Modelle und• Finanzmodelle.

In der Literatur findet sich haufig eine Unterscheidung der Modellierungin eine funktionsorientierte und eine datenorientierte Modellierung sowie inintegrierende Ansatze. Bei der funktionsorientierten Modellierung stehen Pro­zesse im Vordergrund der Betrachtung. Diese werden zunachst ablauforien­tiert modelliert, bevor in einem zweiten Schritt die Definition der erforderli­chen Datenstrukturen erfolgt. Bei der datenorientierten Modellierung werdenreine Datenmodelle erstellt. Ein Datenmodell stellt ein strukturiertes Ab­bild der Daten eines fest abgegrenzten Teils der wahrgenommenen Realitatdar , die fiir eine bestimmte Anwendung bzw. fiir bestimmte Anwender re­levant sind, einschlieBlich der zwischen ihnen bestehenden Beziehungen. DieErstellung von Datenmodellen stellt eine Voraussetzung zur effizienten Ver­waltung groBer Datenbestande dar. Eine gangige Modellierungsmethode isthier die Entity Relationship (ER)-Modellierung bzw. Erweiterte Entity Rela­tionship (EER)-Modellierung. Eine erweitere Modellierungssprache, die aucheine funktionsorientierte Modellierung erm6glicht, ist die Unified ModelingLanguage (UML).

Der Ansatz von Taylor (1995) besteht nun darin, iibergreifende bzw. inte­grierende Modelle zu konzipieren. Ziel dieses Ansatzes ist die Konsistenz allerbetriebswirtschaftlich relevanten Modelle sowie die Vermeidung von Mehr­fachmodellierung. Auch in der Softwareentwicklung soli sich das jeweils ak­tuelle Modell automatisch widerspiegeln. Zur Erfiillung dieser Anforderungist es erforderlich, die im Rahmen der Softwareentwicklung unterschiedenen(Entwicklungs-) Ebenen der semantischen, logischen und physischen Modellein einem einheitlichen Modell abzubilden oder die Teilmodelle zumindest mit­tels einer einheitlichen Beschreibungssprache zu erstellen, die eine Automa­tisierung aIle notwendigen (Modell-) Transformationen von einer Ebene zurnachsten erm6glicht.

Das ARIS-Konzept (Architektur Integrierter Informationssysteme) hateinen ahnlichen Anspruch wie der Ansatz von Taylor (vgl. Kap . 5.5) undsoli dazu dienen, die Komponenten der unterschiedlichen betriebswirtschaft­lichen Anwendungssysteme (Administrations-, Dispositions-, Planungs- undKontrollsysteme) mit ihren Beziehungen in einer gemeinsamen Architektur zuintegrieren; vgl. Scheer (1997) . ARIS soli dabei die Entwicklung betrieblicherInformationssysteme in folgender Weise unterstiitzen (vgl. Scheer (1998b) ,S.9):

5.1 Motivation - einige Prinzipien der Moclellierung 153

1. Angebot eines Rahmenkonzeptes (Architektur) zur vollstandigen Be­schreibung von Anwendungssoftware

2. Einordnung geeigneter Modellierungsmethoden in diese Architektur3. Werkzeuge zur Verwaltung von Referenzmodellen, zur Analyse von Sy­

stemanforderungen und zur Navigation durch Modelle4. Konzept zum Management von Oeschaftsprozessen mit Hilfe von Stan­

dardsoftwaresystemen im Sinne einer Montagebeschreibung fiir Softwa­rekomponenten

Fur dieses Kapitel wahlen wir folgenden Aufbau: Zunachst stellen wireinige Prinzipien der Modellierung voran. Die Prinzipien gelten sowohl fiirdie Konzeption von Unternehmensmodellen als auch von entscheidungsun­terstiitzenden Systemen. Wir werden sehen, daB der Detaillierungsgrad unddie Datenbasis durch die Anwendung, d.h . den Zweck des jeweiligen Modells,definiert werden. Ein unternehmensweites Modell muf sich demnach verdich­ten bzw. verfeinern lassen. Nach diesem Einstieg gehen wir dann auf die Zieleund Betrachtungsebenen der Unternehmensmodellierung ein. Es schlieBt sichein Abschnitt iiber Modellierungsmethoden an, in dem auch die Objektori­entierung und die Simulation thematisiert werden. Nach der Vorstellung vonARIS als einem moglichen Rahmenkonzept zur Bildung integrativer Modellewerden einige Referenzmodelle angesprochen. In einem abschlieBenden Ab­schnitt modellieren wir beispielhaft einen Help Desk und veranschaulichenhieran die Simulation als Analysewerkzeug.

5.1 Motivation - einige Prinzipien der Modellierung

In diesem Abschnitt werden einige Prinzipien der Modellierung vorgestellt,wie Pidd (1996) sie in seinem Buch Tools for Thinking erlautert. Wir er­heben nicht den Anspruch auf Vollstandigkeit, halten es aber dennoch fiirwichtig, diese Prinzipien an den Anfang dieses Kapitels zu stellen. Zum einensoIl deutlich gemacht werden, daB riesige Modelle, wie sie z.B. bei Referenz­modellen iiblich sind, nur dann Sinn machen, wenn mit ihnen "gearbeitetwird" oder nichts mehr "hinzugedacht" werden muB, d.h. daB die Modelledie vollstandige Komplexitat erfassen - z.B. in Blickrichtung auf die Auto­matisierung (Stichwort Informationssystemgestaltung). Diese Einleitung istsomit gleichsam als Warnung vor der Vorstellung zu verstehen, alles in einemModell abbilden zu wollen (oder zu k6nnen).

Zum anderen dient diese Einleitung bereits als Anleitung fur die Model­lierung bzw. Anwendung von Entscheidungsmodellen im Rahmen der Deci­sion Support-Systeme. Die Warnung geht in die Richtung, den auf Basis derUnternehmensmodellierung geschaffenen Informationssystemen in bezug aufDatenqualitat (jeweils im Entscheidungskontext) nicht blind zu vertrauen.Das Prinzip "the model should drive the data and not vice versa" ist hier alsgrundlegend zu erachten.

154 5. Unternehmensmodellierung

5.1.1 Modelliere einfach - denke kompliziert

Komplexe Systeme benotigen nicht unbedingt komplizierte Modelle, sonderneher einfache Modelle, denen mit einer komplizierten Denkweise begegnetwird. So banal es auch klingen mag, mit (explizit formulierten) ModellenmuB gearbeitet werden . Nach unseren Uberlegungen zum Konzept der ein­geschriinkten Rationalitiit nach Simon (1982) ist nicht das Modell an sichfur die Giite zustiindig, sondern immer die Kombination von Modell undBenutzer. Dies ist besonders wichtig, wenn das Modell nicht vom Benutzererstellt wurde . Eine Analogie stellt das Programmieren dar. Einen fremdenProgrammtext zu verstehen, ist meist viel komplizierter, als einen eigenenwieder zu verstehen (Programming is Understanding).

Komplizierte Modelle , wie z.B. Modelle zur Steuerung im operativen Be­trieb, benotigen meist keine menschliche Intervention mehr, da alle Bereichedes Aufgabenumfeldes abgedeckt sind. Die meisten Modelle im Bereich derUnternehmensmodellierung dienen dem Verstandnis von Ablaufen , d.h. dieModelle (oder Teilmodelle) miissen einfach zu verstehen sein. Eine einfa­che Modellierungssprache ist somit zumindest Voraussetzung. Diese Modellemiissen dariiber hinaus aber hinreichend detailliert ausgestaltet werden kon­nen , urn als Vorlage zur Automatisierung von betrieblichen Ablaufen (Aufga­ben) zu dienen. Diese Anforderung an die Modellierung (von Unternehmen)findet sich im zweiten Prinzip (Beginne klein und erweitere) wieder.

5.1.2 Beginne klein und erweitere

Im allgemeinen gibt es keinen Indikator dafiir, wie detailliert ein Modell zugestalten ist, urn alle relevanten Aspekte des betrachteten Systemausschnittsabzudecken. Dies liegt primar daran, daB vorab nicht alle relevanten Aspektebekannt sind . Das heiBt, die Modellierung ist Teil eines Lernprozesses, in demdas Modell stiindig erweitert wird (vgl. Kapitel 2). Details sollten auch nurin das Modell aufgenommen werden, wenn sie im Rahmen von Analysen not­wendig werden ("diesen Systemausschnitt jetzt aber bitte etwas genauer") .

Im Rahmen von Simulationsmodellen konnen z.B. bestimmte Systemkom­ponenten zunachst als Black Box4 abgebildet werden : Statt eine Fertigungs­station detailliert abzubilden, wird einfach auf der Basis von Wahrschein­lichkeitsverteilungen angenommen, wie lange die Verweildauer in der Stationfiir die zu bearbeitenden Elemente dauert; die tatsiichlichen Abliiufe in derStation sind somit nicht "sichtbar" . Sollten Experimente aufzeigen, daB dieStation einen EngpaB darstellt, so kann die Black Box aufgelost werden undder BearbeitungssprozeB innerhalb der Station detaillierter abgebildet wer­den .

4 Der Begriff der Black Box entstammt dem Gebiet der Fernmeldetechnik.Er wurde im Krieg auf erbeutetes Feindmaterial bezogen, das aufgrund desmoglicherweise enthaltenen Sprengstoffs nicht geoffnet werden konnte ; vgl. Watz­lawick et aI. (1996), S. 45.

5.1 Motivation - einige Prinzipien der Modellierung 155

Die Modellierung sollte zudem immer mit bekannten (und verst andenen )Elementen beginnen und weitere Aspekte spater sukzessive einbeziehen. Ne­ben der Verfeinerung von Modellen ist die Er weiterung von Modellen einesinnvolle Vorgehensweise, urn Modelle verst ehen zu konnen,

5.1.3 Teile und herrsche, vermeide Mega-Modelle

Ein kritischer Punkt der Modellierung besteh t in der Validierung und Inter­pretation. In diesem Zusammenhang solIte die prinzipielle Vorgehensweiseder Dekomposition verfolgt werden. Referenzmodelle, auf die wir in die­sem Kapitel noch eingehen werden, dienen in diesem Zusammenhang einerim Vergleich zur Neumodellierung einfacheren Validierung. Eine Orientie­run g an bestehenden, bereits validierten Modellen solI hier die Fehlerhaftig­keit des ents tehenden Modells verringern. Trotzdem bleibt das Problem derUniiberschaubarkeit der Gesamt-Unternehmensmodelle bestehen. Nur wennes moglich ist , Teilmodelle getrennt zu betrachten , sind diese Modelle sinn­voll. Bei der Modellierung sollte man dabei im Auge behalten, daB mehrerekleine Modelle oftm als fiir das Cesamtverstandnis besser geeignet sind alsein groBes. In diesem Zusammenhang mag es auch als sinnvoll erscheinen,auf die Beschrankung der menschlichen Informationsverarbeitungskapazitathinzuweisen; vgl. Miller (1956).

Die Entwicklung von Komponenten unter expliziter Angabe von Verbin­dungen zu anderen Komponenten kann hier einen sinnvollen Ansatzpunktzur Unternehmensmodellierung darstellen, da die Modellierung gerade iiberdie Verdeut lichung der Zusamrnenhange einzelner Bereiche (die als solche jaunter Umstanden weiterhin Bestand haben werden) der Schaffung von Trans­parenz dienen kann. Hier kann zum Beispiel ein Modell ein ProzeBablaufplan(als Obj ekt ) sein, der alle an ihm beteiligten Organisationsinstanzen mit an­gibt, die ebenfalls als Modell (als Obj ekt ) abgebildet sind .

Der Benutzer der Modelle besitzt dann die Moglichkeit , bei einem Modellzu beginnen und die Verbindungen (d.h. letztendlich andere Modelle) erstdann in die Betrachtung aufzunehmen, wenn er eine gewisse Sicherheit imUmgang mit dem ersten Modell erlangt hat .

Diese Vorgehensweise entspricht auch unserer Definition des Erlangensvon Wissen - Wissen als das Erkennen von Mustern (Komponenten und Ver­bindungen) . Durch diese Lernprozesse kann unter Umstand en ein groferesSystemverstandnis erla ngt werden als bei der Betrachtung riesiger Modell­darstellungen . Der Navigator in ARIS bietet z.B. die Moglichkeit , nur Aus­schnit te sowie verschiedene Hierarchiestufen der Modelle zu betrachten.

5.1.4 Nutze Metaphern, Analogien und Ahnlichkeiten

Bei der Analogiebildung und dem Einsatz von Metaphern handelt es sichurn Vorgehensweisen, urn Probleme zu erkennen und Losungsansatze, also

156 5. Unternehmensmodellierung

Modelle, im Rahmen eines kreativen Prozesses zu entwickeln. Hier sindMoglichkeit en zu untersu chen , Systemausschnitte aus verschied enen Sicht­weisen zu betrachten. In Analogie-Modellen werden Teildarst ellungen desSystems durch andere ersetzt , die einfacher zu reprasent ieren und zu ma­nipulieren sind; vgl. Ackoff und Sasieni (1968) , S. 60. Diese Vorgehensweisewird in ahnlicher Weise, allerdings imm er in die gleiche " Richt ung" (TopDown-Entwurf) bei der Unt ern ehm ensm odellierung eingese tzt, d.h. von einernatiirlichsprachlich formuli erten Beschreibung zu einer Darstellung in einersemi-formalen Sprache,

Wichtiger sind allerdings Analogien, die zu neuen Modellen fiihren. Pidd(1996) gibt vier Moglichkeit en zur Analogiebildung an:

• Personli cher Bezug: selbst in das Problem versetzen ("st ellt euch vor , ihrseid ein gelangweilter Computer, den die Algorithmen wirklich nicht reizen ,und ihr iiberlegt euch, das geht doch besser . . .")

• Direkt: "Die Nachfrage nach Giitern entspricht doch irgendwie einer War­teschlange . .."

• Phantasie: Idealismus, urn zu neuen Ideen zu komm en ("Denkt doch einfachmal , alles wird immer zum Zeitpunkt des Bedarfs geliefert . . ." )

• Symbolik: Komprimierte Beschreibung von Problemen und Losungsan sat­zen

Gerade im Bereich der entscheidungsunterstiit zenden Systeme ist es wich­tig zu erkennen, welche bereitgestellt en Modelle und Methoden fiir konkreteProblemstellungen genutzt werden konnen (z.B. durch Problemreformulie­rung). Analogiemodelle ste llen hier einen moglichen Bestandteil derartigerSysteme dar.

5.1.5 Verliebe Dich nicht in Daten

Eingangs von Kap. 5.1 haben wir auf ein wesentliches Prinzip bereits hinge­wiesen: Die Modellierung sollte die Datensuche hervorrufen und nicht umge­kehrt. Das Problem des Dateniiberflusses ist ein zentrales Thema beziiglichder Informationsbereitstellung. Eine haufig geauferte Kritik von Entschei­dungstragern besagt, daB zwar immer jede Menge Daten bereitli egen , ab ernie die richtigen. Dies liegt primar daran, daB erst mit der (Problem-) Model­lierung bekannt wird, welche Daten sich als geeignet einstufen lassen . Diesesind ex-ante (in ihrer Form) meist gar nicht bestimmbar (und somit in derrichtigen Form Ld.R. auch nicht ex-ante bereitst ellbar).

Ein schnell gemachter Fehler ist, Daten, auf die unmittelbar zugegriffenwerd en kann, unreflektiert zu nutzen und somit au s den bereitliegenden DatenParameter des Modells zu machen. Oftmals wird bei der durch Daten gelei­te ten Modellierung sogar Uberfliissiges in das Modell aufgenommen ("weil eshal t da ist"). Aus dieser Sichtweise ist es Aufgabe des Modellierers, die richti­gen Daten zu spezifizieren, und Aufgab e der Datenbereitstellung (als Aufgab e

5.2 Ziele der Unternehmensmodellierung 157

des Informationsmanagements) , diese fiir ihn durch einfach auszufiihrendeSelektions- und Aggregationsfunktionen erreichbar zu machen. Der Slogan"die richtige Information zur richtigen Zeit am richtigen art" kann aus die­ser Betrachtung heraus eigentlich nicht erfiillt werden. Eine realistische An­forderung an das Informationsmanagement ist allein die Unterstiitzung derindividuell zu tatigenden Selektion und Aggregation von Daten durch Be­reitstellung geeigneter Informationssysteme. Die Aggregation von Daten ba­siert oftmals auf statistischen Verfahren. Dieser Bezug kann aufgrund deserforderlichen Expertenwissens sogar eine personelle Unterstiitzung bei derDatenbeschaffung notwendig erscheinen lassen .

Daten sind weiterhin immer nur Beispieldatensatze, sie konnen mit Auf­nahme- oder Aggregationsfehlern versehen sein. Zudem sollten Daten, dieder Modellierung dienen, und Testdaten unterschiedlich sein. Entwirft manz.B. ein Modell zur Prognoserechnung auf der Basis vergangenheitsbezoge­ner Daten, so sollte man diese Daten vorab in zwei Gruppen trennen, inModellierungs- und Testdaten.

5.2 Ziele der U nternehmensmodellierung

Wie wir bereits in den vorangegangenen Kapiteln aufgezeigt haben, ist eineSystematisierung von Informationsbeziehungen und betrieblichen Ablaufen,d.h. Prozessen mit entsprechenden Informationsfliissen, aus einer Reihe vonGriinden notwendig. Die Ziele der Unternehmensmodellierung lassen sich wiefolgt zusammenfassen:

• Systematisierung von Informationsfliissen• Systematisierung von Integrationspotentialen (Synergieeffekte)• Datenintegration• Funktionsintegration (EntscheidungsprozeBintegration)• Ableitung von (objektiven) Informationsbedarfen• Grundlage fiir die Planung einer IT-Infrastruktur• Grundlage fiir Datenhaltungskonzepte (z.B. Data Warehouse)• Reorganisation von Unternehmen (z.B. objektorientierte Organisationsfor­

men)5

5 Insbesondere das (radikale) Business Reengineering ist hier als eine aktuelle Ten­denz zu nennen, die im wesentlichen auf eine stiirkere Proze6orientierung derOrganisation abzielt; vgl. Gaitanides (1998) und die dort angegebenen Quel­len fiir eine Einfiihrung und kritische Bewertung. So sieht Gaitanides das Busi­ness Reengineering als Organisationsmode, das sich allerdings als Katalysatorfiir Veriinderungsprozesse durchgesetzt hat und dessen Kernelement, das Den­ken in Prozessen (Business Process Reengineering) , modeiiberdauernd (im Pro­ze6management) Bestand haben wird . Wahrend das Business Reengineering eingrundsiitzliches Uberdenken des Geschiiftszwecks sowie einen radikalen Neuent­wurf umfaflt , kann das Business Process Reengineering auf das grundsiitzliche

158 5. Unternehmensmodellierung

• Grundlage fiir die Entwicklung von (integrierten) Anwendungssystemen(vgl. das Konzept des Computer Integrated Manufacturing (Cllvl), S. 159,sowie Moglichkeiten zur Steuerung und Kontrolle der Geschaftsprozessemittels Workflow Management-Systemen")

• Simultane Entwicklung der Unternehmensstruktur und Informationssy­stemgestaltung; vgl. Keller (1993)

Die unterschiedlichen Anwendungen, die mit einem zentralen Modellermoglicht werden sollen, haben wir eingangs des Kapitels bereits genannt;vgl. Taylor (1995). Die Auswahl der Modellierungsmethode(n) sollte dieseForderungen beriicksichtigen.

Die Ziele der Unternehmensmodellierung beziehen sich zu einem GroBteilauf die Neuorganisation von Aufgaben, d.h. die Entscheidungsunterstiitzung(fiir Probleme, wie wir sie definiert haben) tritt in den Hintergrund der Be­trachtung, und die Verteilung der Aufgaben und die partielle Automatisie­rung von Aufgaben stellen eine wesentliche StoBrichtung dar. Unter diesemGesichtspunkt sind die Ziele der Daten- und Funktionsintegration zu sehen.Aus den dargestellten Zusammenhangen der Daten ergibt sich auch der Zu­sammenhang von (bereits existenten) Einzelanwendungen.

Die Datenmodellierung bewirkt somit bereits einen Integrationseffekt derDaten (iiber verschiedene Abteilungen) und kann zur Definition von Schnitt­stellen der Einzelanwendungen herangezogen werden. Unter Integration ver­steht man die (Wieder-) Herstellung eines Ganzen, einer Einheit durch Einbe­ziehung auBenstehender Elemente. Unter Datenintegration wird nun der Zu­griff unterschiedlicher betrieblicher Bereiche auf dieselbe Datenbasis verstan­den . Fragestellung ist dabei nicht allein, wer welche Daten erzeugt, sondernauch, wer welche Daten benotigt. Dieser Bereich der Unternehmensmodellie­rung ist somit auch eine Vorgehensweise der Informationsbedarfsanalyse.

Ziele der Datenintegration sind die Verbesserung der Vollstandigkeit undder Konsistenz der Daten (durch Redundanzarmut), der Aktualitat der be­trieblichen Bereiche, der Wegfall von Mehrfacheingaben von Daten, die gleich­zeitige Vermeidung von Eingabefehlern sowie die Verbesserung der Informa­tionsiibertragung (vgl. z.B. Keller (1993), S. 25). Die Verbesserung der Infor­mationsiibertragung erfolgt auch mit dem Ziel der Reduktion der Unbequem­lichkeit der Informationsbeschaffung und der Koordination der Aufgabe derDatenpflege.

Nach einer empirischen Untersuchung von Maier (1996), bei der die Be­deutung der Anwendungsbereiche (64 Faktoren in 12 Kategorien) fiir Daten­modelle von Unternehmen (als So11-Werte) erfragt wurden, ergaben sich diewichtigsten Gebiete (als durchschnittliche Werte angegeben) wie in Tab . 5.1

Uberdenken und den Neuentwurf der Geschaftsprozesse beschrankt werden ; vgl.Pietsch und Steinbauer (1994).

6 Vgl. hierzu z.B. die Beitrage in Vossen und Becker (1996), insbesondere Ferstlund Sinz (1996) fiir einen objektorientierten Modellierungsansatz, sowie Kap .9.1.3.

5.2 Ziele der Unternehmensmodellierung 159

dargestellt. Hierbei stellt der Wert 5 eine hohe Bedeutung, der Wert 1 eineniedrige Bedeutung dar.

Anwendungsbereich (Kategorie) WertBasis fur den Datenbankentwurf bzw. physische Datenorganisation 4,17Instrument zur Standardisierung 4,17Basis fur Management Information-Systeme; vgl. S. 323 f. 4,05Basis fur die Integration im DV-Bereich 3,98Basis fur die Anwendungssystementwicklung 3,96Organisationsinstrument auBerhalb des DV-Bereichs 3,83Verringerung des Wartungsaufwands 3,79Basis fiir den Einsatz von Standardsoftware 3,69Verbesserung der Kommunikation 3,68Grundlage der Nutzung von Anwendungssystemen in den 3,62FachabteilungenErhohung der Motivation / Akzeptanz 3,39Organisationsinstrument im DV-Bereich 3,18

Tabelle 5.1. Anwendungsbereiche von Datenmodellen; vgl. Maier (1996), S. 204

Die Untersuchung kommt weiterhin zu dem Ergebnis, daf der (vonder Auskunftsperson eingeschatzte) mogliche Nutzen (SolI) im DurchschnittgroBer ist als der tatsachlich in deren Organisationen realisierte (aber wie­derum eingeschatzte) Nutzen (1st). Die Datenmodellierung besitzt folglich injedem der Anwendungsgebiete noch unausgeschopfte Potentiale; vgl. Maier(1996), S. 208.

Die Funktionsintegration kann in eine technische und eine organisatori­sche Integration unterschieden werden. Unter technischer Funktionsintegra­tion verstehen wir die Neukonzeptionierung der Anwendungen (in Hinblickauf die Prozesse) als Integration von Einzelanwendungen, die an der Bear­beitung von Prozessen beteiligt sind . Mit der Einbeziehung der Organisationals zu gestaltendes Element, z.B. als Reorganisation auf der Grundlage derProzesse, gelangen wir zu einer organisatorischen Funktionsintegration.

Eine wesentliche Motivation fiir die Unternehmensmodellierung liegt inder Schaffung einer Grundlage fiir die Entwicklung von integrierten An­wendungssystemen, wie sie von Taylor und in der CIM-Forschung, derenBetrachtungsgegenstand auch die Informationsgestaltung im Unternehmenbeinhaltet, behandelt werden bzw. wurden. Die Unternehmensmodellierung,die im Rahmen des CIM-OSA Projekts (Open Systems Architecture) in ihrerendgiiltigen Form der Steuerung und Kontrolle der taglichen Oeschaftsvorfalledient, ist bzw. war neben der Ermittlung und Gestaltung einer integrieren-

160 5. Unternehmensmodellierung

den Infrastruktur Schwerpunkt der CIM-OSA Forschung." Die Anwendungs­systeme solien dabei folgenden Anforderungen geniigen:

• kurze Entwicklungszeiten• hohe Flexibilitat und Anpassungsfahigkeit• Kombinationsmoglichkeit von Standard- und Individuallosungen

Es sei noch einmal darauf hingewiesen, daB die Modellierung hier zum Teilmit dem Ziel einer ProzeBautomatisierung erfolgt , d.h. die Modelle miissendann hinreichend detailliert sein, urn die Komplexitat der (relevanten) Sy­stemausschnitte vollstandig zu erfassen. Hier unterscheidet sich die Funktiondes Modells vom beschriebenen Werkzeugcharakter, urn ein System zu ana­lysieren (Tool for Thinking) , und stellt vielmehr ein Tool to Replace (insuffi­cient) Working dar.

Ein wesentliches Problem der Analyse von Unternehmensmodellen, diewir im folgenden ansprechen, liegt in der Kompliziertheit der Modelle, ins­besondere bei einer starken Detaillierung der Aufgaben und Funktionen. DieKompliziertheit kann sich hier in uniiberschaubar groBen Ubersichtsdarstel­lungen widerspiegeln. Dabei ist die Dekomposition des Modells zum Modell­verstandnis von eminenter Wichtigkeit . Moglichkeiten sind zum einen einhierarchischer Aufbau der Modelle und zum anderen eine separate Darstel­lung der einzelnen Betrachtungsebenen verbunden mit der Moglichkeit, auchZusammenhange betrachten zu konnen. Fiir beide Alternativen ist eine Com­puterunterstiitzung von groBer Bedeutung, da eine Navigation durch Akten­ordner und Schauplane Ld.R. sehr viel komplizierter ist.

5.3 Betrachtungsebenen

In diesem Abschnitt geben wir die Ebenen an , die bei der Unternehmens­modellierung zu beriicksichtigen sind, urn alle relevanten Aspekte wiederge­ben zu konnen. Neben den originaren Daten und Betriebsmitteln ("womit")und Funktionen ("was") sind auch die Organisationseinheiten ("wer") zu be­trachten. Diese drei Bestandteile reichen allerdings nicht zur Beschreibungvon Prozessen (als Folge von Funktionen) aus . Hierzu sind Ereignismodelle("wann") notwendig. Zur Analyse mittels Simulation benotigt man neben deneigentlichen Funktionen auch zugehorige Bearbeitungszeiten ("wie lange")und Wahrscheinlichkeiten ("wie haufig"}, wenn es innerhalb eines Prozessesmehrere rnogliche Nachfolge-Funktionen einer Funktion gibt. Diese konnenin den Funktionen und Ereignismodellen angegeben werd en, verdienen abereine gesonderte Beriicksichtigung.

7 Man beachte, daf die elM-OSA Forschung in der aktuellen Diskussion zwaranderen Schlagworten gewichen ist , in weiterfiihrenden Programmen aber nachwie vor Bestand hat bzw. deren Grundlage bildet; vgl. z.B. Segarra (1999).

5.3 Betrachtungsebenen 161

Im eIM-OSA Rahmenwerk werden drei komplementare Ebenen unter­schieden, die das Unternehmen aus verschiedenen Sichtweisen reprasentieren.Die Architekturebene unterteilt sich in eine generische Ebene, die fiir aile Un­ternehmenstypen gilt, eine partielle Ebene (branchenspezifisch) und eine in­dividuelle, unternehmensspezifische Ebene. Die Modellierungsebene gliedertsich nach dem Top Down-Ansatz, d.h . auf der obersten Ebene wird das Unter­nehmen aus funktionaler Sicht in allgemein verstandlicher Sprache beschrie­ben . In der Zwischenschicht wird das Modell in eine serni-formale Spracheiibersetzt und erst dann auf der untersten Ebene in ein Implementierungsmo­dell iiberfiihrt . Die Sichtebene setzt sich aus den Sichten Funktion, Informa­tion, Ressource und Organisation zusammen. In der Funktionssicht werdenAufgaben strukturiert beschrieben (einschlieBlich der Hierarchiebildung).

Fiir die einzelnen Ebenen bieten sich unterschiedliche Modellierungsme­thoden an , die in der Vergangenheit auch getrennt eingesetzt wurden. DieIntegration der Ebenen (Modelle) muB in diesem Zusammenhang eine in­tegrierte Anwendbarkeit der unterschiedlichen Modellierungsmethoden - ineinem iibergeordneten Rahmenkonzept - als Voraussetzung haben. Eine ein­heitliche graphische Beschreibungssprache findet sich z.B. in der UML; vgl.Kap. 5.4.7.

5.3.1 Daten

Der Begriff Daten wurde weiter oben bereits eingefUhrt. Daten konnenim Rahmen der Unternehmensmodellierung (repetitiver Prozesse) in Infor­mationsdienstleistungen und Umfelddaten unterschieden werden; vgl. z.B.Scheer (1998b) . Informationsdienstleistungen dienen als Input zur Funkti­onsausiibung, entsprechen also genau unserer Definition von Information (alsDaten, die in Entscheidungsmodellen verarbeitet werden) und entstehen alsOutput einer Funktionsausiibung, die wiederum als Input fiir andere Funk­tionen dienen. Umfelddaten sind nicht direkt in einen betrieblichen Informa­tionsfluB per Definition eingebunden, konnen innerhalb des Entscheidungs­prozesses aber durchaus als Informationen bezogen werden. Umfelddaten un­terliegen dabei einem standigen TransformationsprozeB.

Speziell fiir die Informationsdienstleistungen ist es notwendig, die zugrun­deliegenden Daten zu strukturieren, urn eine automatisierte Verarbeitungzu errnoglichen. Mit der Schaffung einer einheitlichen Datenbasis und mitHilfe von Datenbanksystemen konnen verschiedene Sichtweisen (aufgaben­spezifisch) auf die Datenobjekte angelegt und Informationssysteme konzipiertwerden . Diese Betrachtungsebene kann also isoliert genutzt werden.

Hierbei ist zu beachten, daf aus Sicht der Datenbankentwicklung eineAnforderung an die Analyse- sowie Designphase darin besteht, diese in Zu­sammenarbeit mit den Benutzern durchzufiihren. Aus Sicht des Inforrnati­onsmanagements bedeutet dies, daB eine Zusammenarbeit mit Datenbank­Experten erfolgen muB, die schlieBlich eine Implementierung eines konzeptio-

162 5. UnternehmensmodeIlierung

nellen Schemas (KS) zur Aufgabe haben werden. Der Bezug zur Informatikerstreckt sich dann sogar auf die personelle Ebene.

Obwohl wir erst im Abschnitt 5.4 auf Modellierungsmethoden eingehenwerden, soll bereits an dieser Stelle auf das konzeptionelle Datenschema einge­gangen werden, da vermoge dieses Schemas Integrationspotentiale abgeleitetwerden konnen, Insbesondere aus der Sicht der Entwicklung von formatiertenDatenbanken sind zehn Prinzipien des Designs eines KS zu nennen:

1. Das KS stellt die Daten eines Unternehmens konsolidiert (aus der Sichtaller Anwendungen) dar.

2. Das KS kommt durch unternehmensweite Klarung von Fachbegriffen undderen Eigenschaften zustande.

3. Das KS ist unabhangig von den Strukturierungsbeschriinkungen der ein­setzbaren Datenbanksoftware definiert .

4. Das KS ist neutral gegeniiber Einzelanwendungen und deren lokaler Sichtauf die Daten.

5. Das KS wird als Informationsdrehscheibe zwischen den Informations­nachfragern und den Informationsanbietern eingesetzt.

6. Das KS dient in Verbindung mit den Begriffen "externe Schemata", "10­gische Schemata" und "interne Schemata" als Architekturmodell undOrdnungsrahmen fur die Daten.

7. Das KS bildet die Grundlage fur die Ableitung der in konkreten Daten­banken implementierten Datenstrukturen im Unternehmen.

8. Das KS bildet die Grundlage fiir die Planung und Realisierung integrier­ter Anwendungssysteme im Unternehmen.

9. Die Entwicklung des KS fordert die Feststellung alternativer Losungender Informationsverarbeitung (Zusammenhang mit Anwendungssyste­men) .

10. Das KS bildet die gemeinsame sprachliche Basis fiir die Kommunikationaller an der Informationsverarbeitung beteiligten Personen.

5.3.2 Organisationseinheiten

Neben den Daten sind Organisationseinheiten der zweite Teil der statischenBetrachtungsebenen. Die systematische Darstellung der Organisationseinhei­ten erfolgt i.d.R. anhand von Organigrammen und Stellenbeschreibungen,d.h. Beschreibungen, welche Aktivitiiten durchgefiihrt werden. Hier findetsich bereits eine Integration der Ebenen Organisationseinheiten und Funk­tionen.

Neben den Menschen konnen dieser Betrachtungsebene auch die Betriebs­mittel zugeordnet werden. Diese umfassen neb en der menschlichen Arbeitslei­stung u.a. Maschinenressourcen sowie die Hardware. So stellt das betriebliche

5.3 Betrachtungsebenen 163

Netzwerk mit allen angeschlossenen Rechnern z.B. ein eigenes Modell dieserBetrachtungsebene dar."

5.3.3 F'unktionen und Prozesse

Funktionen stellen Teilaufgaben zur Erreichung der Unternehmensziele dar.Funktionen implizieren i.d .R. eine Zusammenfassung von Tatigkeiten, dieauf der jeweiligen Betrachtungsebene bzw. hinsichtlich des zweckorientier­ten Abstraktionsgrades nicht weiter aufgeteilt werden (sogenannte Elemen­tartatigkeiten) . In unserer Begriffswelt sollen Funktionen immer an genaueine verantwortliche und / oder ausfiihrende Organisationseinheit gebundenwerden , d.h. nur dann weiter aufgeteilt werden konnen, wenn auch die Or­ganisationseinheit eine entsprechende (weitere) Detaillierung zulaBt. Sie sindaber als organisationsiibergreifend zu betrachten. Mehrere Funktionen kon­nen zu iibergeordneten Funktionen (Aujgaben) oder Prozessen zusammenge­setzt werden. Aufgaben entsprechen einer hierarchischen Zusammenfassungmehrerer Funktionen. Wird bei dieser Zusammenfassung gleichzeitig eine Rei­henfolge der Funktionen definiert , so handelt es sich urn ein Ereignismodell(ProzeBmodell) .

Prozesse sind , etwas allgemeiner gefaBt, Ablaufe, wie sie sich aus der Ab­lauforganisation ergeben. Formal ausgedriickt stellt ein ProzeB eine zeitlich(und raumlich) spezifizierte Menge von Funktionen (Aktivitaten) mit einemAnfang und einem Ende sowie eindeutig definierten Eingangsgr6Ben (Input)und Ausgabegrofen (Output) dar; vgl. Davenport (1993). Spezielle Graphendieser Art lassen sich in Petri-Netze und ausfiihrbare Programme iibersetzen;vgl. Kap. 5.5.

Beziiglich integrierender Gesamtmodelle stellen Prozesse und Aufgaben ­als Abbildungen von Ablaufen - die dynamische Komponente dar. Die Ab­bildung der Aufbauorganisation beziiglich der Organisationseinheiten, Funk­tionen und Daten erfolgt hingegen statisch. Beispiele fiir Prozesse sind z.B.Produktionsprozesse oder die Bearbeitung von Urlaubsantragen im Rahmendes Workflow Management (vgl. Kap . 9.1.3). Neben der Reihenfolgebeziehungkann es erforderlich sein, bei mehreren m6glichen Nachfolgern Eintrittswahr­scheinlichkeiten fiir die einzelnen Nachfolger anzugeben. Dies ist vor allem fiirdie Simulation von besonderer Bedeutung. Fiir die einzelne Funktion laBt sicheine Einbindung in ein Ereignismodell durch Angabe eines Startereignissesrealisieren, welches durch eine Nachricht die Funktion ausl6st und die selbstwiederum ein Ereignis als Ergebnis produziert (vgl. Abb. 5.2). Einer Funktionk6nnen neben der Bearbeitungsdauer auch Finanzmittel und Sachleistungen(Input) zugeordnet werden, die verarbeitet werden.

8 1m CIM-OSA Rahmenwerk stellen die Betriebsmittel eine eigenstandige Betrach­tungsebene dar.

164 5. Unternehrnensrnodellierung

Abbildung 5.2. Urn Nachrichten erganzte ereignisorientierte ProzeJ3kette

5.3.4 Integration der Ebenen

Prinzipiell lassen sich Elemente aller Ebenen jeweils miteinander kombinie­reno So konnen Zustandigkeiten fiir Betriebsmittel und Funktionen etc. abge­bildet werden. Um die statische Darstellung der Daten zu erweitern, konnenDatenbestanden auch Organisationseinheiten zugeordnet werden, und zwarbeziiglich der Erzeugung der Daten und der potentiellen Nutzung von (an­dernorts erzeugten) Daten. Eine solche Zuordnung definiert einen eigenenInformations- bzw. DatenfluB zur (auf die Organisationseinheiten bezogenen)Aufgabenerfiillung. Wichtig bei dieser Zuordnung ist aber vor allem die Ver­teilung der Aufgaben der Datenpflege zu Organisationseinheiten.

Um allerdings eine ProzeBorientierung zu realisieren, erscheint es sinnvoll,die Funktion als zentrales Element im Rahmen der Ebenenintegration zu be­trachten, da sich aIle iibrigen Objekte sinnvoll um den FunktionsfluB (Pro­zeB) gruppieren lassen. Fiir jede Funktion lassen sich die benotigten Datensowie die Ergebnisdaten spezifizieren. Fiir die Durchfiihrung einer Funktionbenotigt man immer eine verantwortliche Organisationseinheit, so daf auchhier eine eindeutige Zuordnung moglich ist . Betriebsmittel, wie notwendigemenschliche Arbeitsleistung, Maschinenressourcen, Hard- und Software, diezur Ausfiihrung genutzt werden , konnen zugeordnet werden. Leistungskenn­zahlen und Finanzmittel als Input bzw. Output einer Funktion lassen sichebenfalls zu einer Funktion angeben.

Dieser prozeBorientierte Ansatz wird auch bei der Geschaftsprozebmodel­lierung unter ARIS realisiert . Ein Geschaftsprozef stellt eine zusammen­gehorige Abfolge von Unternehmensverrichtungen zum Zweck der Leistungs­erstellung dar. Dieser kann in materielle und immaterielle Fliisse zerlegt wer­den , die den unterschiedlichen Betrachtungsebenen bzw. den sich ergebendenObjekten entsprechen (vgl. Abb. 5.3 in Erweiterung von Abb . 5.2).

Der Organisationsfluf kennzeichnet Zustandigkeiten und Leitungsbefug­nisse. Der Kontroll- bzw. SteuerungsfluB steuert den logischen Ablauf durchEreignisse und Nachrichten, wobei die Funktionen des Prozesses die Fliisserealisieren. Der Betriebsmittel- und ArbeitsleistungsfluB bezeichnet die Lei­stungsabgabe von Potentialfaktoren, wahrend der Informationsfluf schliefl­lich den Zugriff auf die notwendigen Daten zur Funktionsausiibung beschreibt(vgl. Scheer (1998b), S. 11 ff.). Zudem existieren unter ARIS noch ein Ziel-,Finanz- und LeistungsfluB. Jede Funktion besitzt ein Ziel, das diese steu­ert . Der LeistungsfluB, der in den Sachleistungs- und DienstleistungsfluB un­terschieden wird, und der FinanzmittelfluB beschreiben zum einen die not-

5.3 Betrachtungsebenen 165

Informations ­dienstleistung

I

Software II

--------------------~

fiihrt steuert Betriebsmittel-undArbeitsleistungs­fluB

Ou_~~~g~h ~

Kontroll- bzw .SteuerungsfluB

- ----------------------------~

Organisationsfluf

Nutzun

• •Computer-

• Hardware.

oNutzun

Maschinen­ressource

menschlicheArbeitsleistung

-------------------------------------------------------------~

Zielflu13

-------------------------------------------------------------~LeistungsfluB

-------------------------------------------------------------~

FinanzmittelfluB

Abbildung 5.3. Das allgemeine ARIS-GeschaftsprozeBmodeli

wendigen Eingangsgr6Ben (Input) und Ergebnisse der jeweiligen Funktionenbzw. Prozesse (analog zum InformationsfluB durch die Informationsdienstlei­stungen) . In ARIS wird fiir den LeistungsfluB eine eigene Betrachtungsebeneeingesetzt.

Ein einziges Modell kann bei der vollstiindigen Darstellung aller Prozessemit allen Fliissen leicht uniibersichtlich werden. Es ist daher sinnvoll, die Be­trachtungsebenen getrennt zu modellieren (vgl. das CIM-OSA Rahmenwerk)und (mittels definierter Sichten auf das Gesamtmodell) Komponenten ein­zeIner Teilmodelle fiir spezielle Betrachtungen zu verkniipfen, Hierzu zahltdann z.B. die Erstellung von (ereignisgesteuerten) Prozessen auf der Basisvon Funktionsrnodellen."

Im folgenden Abschnitt werden giingige Methoden der Modellierung vor­gestellt. Hier wird wiederum deutlich, welche Methoden primar auf welcherBetrachtungsebene eingesetzt wurden bzw. werden. Wir fokussieren dabei aufMethoden, die fiir das Informationsmanagement im engeren Sinne relevantsind, d.h. im wesentlichen auf die semantische Ebene. Die Ubergange von die-

9 Diese Methode der Verkniipfung entspricht den Forderungen "Beginne klein underweitere" sowie " Teile und herrsche" .

166 5. Unternehmensmodellierung

ser Ebene der Modellierung zur tatsachlichen Anwendungsentwicklung, dieGegenstand der Wirtschaftsinformatik ist, werden dabei aufgezeigt, sollenaber nicht vertieft dargestellt werden.

5.4 Modellierungsmethoden

Nachdem wir im letzten Abschnitt unterschiedliche Betrachtungsebenen vor­gestellt haben, gehen wir in diesem Kapitel auf unterschiedliche Modellie­rungsmethoden bzw. Beschreibungssprachen ein. Diese konnen zum Entwurfeiner Datenbank oder eines Anwendungssystems, aber auch eines Simulati­onsmodells als Planungsinstrument konzipiert sein.

Ist das Ziel der Modellierung die Konzeptionierung von Anwendungssy­stemen, so rniissen alle die Diskurswelt betreffenden Regeln im konzeptio­nellen Modell definiert werden , d.h. keine der relevanten Regeln oder Ge­setzrnailigkeiten darf erst als Teil des implementierten Programms hinzu­kommen. Das konzeptionelle Modell darf zudem ausschlieBlich Regeln undGesetzmafligkeiten der Diskurswelt enthalten, d.h. Regeln, die Implementie­rungsaspekte betreffen, sind im konzeptionellen Modell unzulassig,

Konzeptionelle Modelle sollten im Idealfall folgenden Anforderungen ge­niigen bzw. die folgenden Eigenschaften besitzen, wie sie zum Teil auch inden Uberlegungen zu den Prinzipien der Modellierung und im Kontext desKS-Designs angesprochen wurden:

• implementierungsunabhangig• abstrakt• formal• modularisierbar• analysierbar• nachvollziehbar• ausfiihrbar

Die Forderung nach Ausfiihrbarkeit betrifft zwei unterschiedliche Aspekte,zum einen die Forderung nach (teil-) automatisierter Informationssystemer­stellung; zum anderen kann hierunter auch verstanden werden, Prozesse aufder Grundlage der Modelle im zeitlichen Verlauf zu betrachten, d.h. diesezu simulieren. Ziel der Simulation kann z.B. die Analyse der Prozesse inbezug auf tatsachliche Bearbeitungsdauern sein, die aufgrund von kapa­zitatsbedingten Engpassen in den Organisationseinheiten entstehen.

In der Literatur finden sich eine breite Anzahl von Methoden, die dortoftmals nebeneinander dargestellt werden, ohne Beziige zwischen den Metho­den herzustellen; vgl. z.B. Keller (1993). Mit Modellierungsmethoden konnendrei Ansatze verfolgt werden:

1. Abbildung von statischen Zusammenhangen, wie z.B. von Organisations­strukturen, Funktionshierarchien und Datenbestanden

5.4 Modellierungsmethoden 167

2. Statische Abbildung von Prozessen, z.B. Arbeitsablaufplanen3. Dynamische Abbildung von Prozessen

In Abb . 5.4 sind den drei Ansatzen unterschiedliche Methoden der Model­lierung zugeordnet. Der Abbildung kann weiterhin entnommen werden, daBmit der Objektorientierung aIle Ansiitze gleichzeitig verfolgt werden konnen,

statische Abbildung von dynamischcnZusammcnhiin en

Darstellung von statischenZusammenhiingenr- -,

Datcnmodclle,Organigramme,

Funktionshierarchie­diagrammc

dynamische Abbildung vondynamischcnZusammcnhiingen

Prozcl3modellc

Struktograrnm,Prograrnmablaufplan,Datenflu llplan,Strukturierte Analyse,SADT.HIPO

Sirnulatorenmit Skriptsprachen

Simulations­modelie

Prozell­modcllc

Petri-Netze,cndliche Automaten

basieren teilweise auf

Abbildung 5.4. Modellierungsmethoden

1m weiteren Verlauf dieses Kapitels werden wir unterschiedliche Methodenkurz vorstellen, wobei wir uns an der in Abb. 5.4 vorgenommenen Klassifi­kation orientieren. In den folgenden Abschnitten werden wir teilweise einenHelp Desk als Beispiel zur Anwendung der einzelnen Modellierungsmethodenverwenden. Der Begriff Help Desk umfaBt Geschiiftsfunktionen, die Anfragenund Probleme von Kunden behandeln.!" Die Aufbauorganisation des HelpDesks sei folgendermaBen gestaltet:

1. Ebene (first level): Telefonzentrale

• Management der eingehenden Anrufe, Faxe und E-Mails• Aufnahme der Kundendaten• Beantwortung einfachster Fragen

10 Zu einer Einfiihrung und einer Ubersicht verschiedener Help Desk-Software­systeme wird auf Jagodic und Ungerer (1998) verwiesen. Vgl. dariiber hinausauch den Begriff des Information Center zur Unterstiitzung von Endbenutzernbei der Nutzung der IT.

168 5. Unternehmensmodellierung

• Eingliederung in Warteschlangen fiir den zustandigen Kundenbetreuer(kundenbezogen)

2. Ebene (second level) : Kundenbetreuer• Beantwortung der Fragen• Pflege der Datenbank mit den bekannten Problemfallen und zugeho­

rigen Losungen• gegebenenfalls Kontaktierung von Experten aus den Fachabteilungen

zur Klarung der Fragen3. Ebene (third level): Experten aus Fachabteilungen

• Losung von Problemen - Losung dem Kundenbetreuer erlautern

5.4.1 ER-Modellierung

Das Entity Relationship-Modell nach Chen (1976) hat sich als die wesentli­che Beschreibungssprache fiir den Entwurf von Datenbanksystemen heraus­gestellt . Die Methode basiert auf Objekten (Entitaten), die durch Attributegekennzeichnet werden, sowie Beziehungen (Relationen) zwischen den Ob­jekten. Es handelt sich um ein semantisches Modell, z.B. zur Darstellung deskonzeptionellen Schemas.

Attribute sind die kleinsten, sinnvollen Einheiten zur Strukturierung vonDaten iiber ein Informationsobjekt, ein von einem real en Objekt abstrahier­ten und innerhalb eines Modells verwendeten Reprasentanten des Objekts.So kann z.B. kann das Informationsobjekt Mitarbeiter iiber die AttributeName, Personalnummer, Stellennummer, Gehalt etc. beschrieben werden . EinObjekttypenmodell stellt dann eine Zusammenfassung bzw. Einteilung von(Informations-) Objekten unter spezifischen Begriffen dar (Aquivalenzrelati­on) .

Ein weiteres Element sind Beziehungstypen, die Beziehungen zwischenObjekten abbilden, wie z.B. die Zuordnung von Kunden zu einem Kunden­berater. Beziehungen konnen durch Angabe von K ardinalitiiten dahingehendspezifiziert werden, wie oft ein Objekt an einer Beziehung, die fiir zwei odermehr Objekttypen definiert ist, teilnehmen darf. So ist es bei einer entspre­chenden Organisation eines Help Desks gegebenenfalls sinnvoll, daB jederKunde genau einem Kundenbetreuer, ein Kundenbetreuer aber beliebig vie­len Kunden zugeordnet werden darf.

Neben diesen einfachen Konzepten existieren verschiedene Erweiterungender ER-Modellierung. Die wesentlichen Erweiterungen der Modellierungs­sprache sind :ll

• Generalisierung / Spezialisierung (von Objekten)• Integritatsbedingungen: Einschrankungen der erlaubten Zustande oder Zu­

standsiibergange eines Datenbestands (Aussagen beziiglich der Konsistenz("Giiltigkeit") von Daten, die stets erfiillt sein miissen).

11 Fur eine Beschreibung der Sprache wird der Leser auf Elmasri und Navathe(1994) sowie Vossen (2000) verwiesen .

5.4 Modellierungsmethoden 169

5.4.2 Struktogramm, Programmablaufplan und DatenfluBplan

Struktogramme dienen der statischen Beschreibung von Prozessen.P IhrenUrsprung findet dieses graphische Beschreibungsmittel in der Programmie­rung. Dem Modellierer stehen die drei Grundelemente Reihung, Verzweigungund Wiederholung zur Verfiigung, urn Bearbeitungsschritte abzubilden (vgl.Abb . 5.5 (a)) . Damit eignet sich diese Methode insbesondere zur Darstellungvon Funktionen und ihren logischen Zusammenhangen.

Start

nein

AufnahmeKundendaten(I. Ebene)

Problemedirekt losbar

Probleme inWarteschlangeVer­

zweigung

Operation,allgemein

Eingabe/

Ausgabe '-----_-'-------.-----'-------'

Losungerklaren(I. Ebene) ja

Wieder­holung

Bedingung

Reihung

Wiederholen bis aile IProbleme bearbeitet sind

Aufnahme Problem (I. Ebene)-c..-

~m~ja losbar nein-f-

Losung Aufnahmeerkliiren Kundendaten(I. Ebene) (I. Ebene)

Anfrage anKundenberaterweiterleiten

Anfrage anKundenberaterweiterleiten

(a) Struktogramm (b) Programmablaufplan

Abbildung 5.5. Beispiel: Struktogramm und Programmablaufplan fiir die ersteEbene des Help Desks

Der Programmablaufplan ist ebenfalls eine Methode zur Beschreibung vonProgrammen, die aufgrund einer starker differenzierenden und (in einem ge­wissen Rahmen) iibersichtlicheren Darstellungsweise den Struktogrammeniiberlegen erscheint (vgl. Abb. 5.5 (b)) . Die moglichen Bestandteile von Pro-

12 Die in diesem und im folgenden Abschnitt dargestellten Methoden werden z.B.von Keller (1993) sowie Ferstl und Sinz (1998) ausfiihrlicher diskutiert und inden Kontext der Unternehmensmodellierung gestellt .

170 5. Unternehmensmodellierung

grammablaufplanen sind in der Abbildung kursiv angegeben, wobei weitereElemente der DIN 66001 entnommen werden konnen.P

Der DatenfiujJplan stellt eine normierte Methode zur graphischen Darstel­lung von Datenfliissen in Systemen in Form eines gerichteten Graphen dar.Ziel dieser Darstellungsweise ist es, fiir Funktionen aufzuzeigen , welche Datenben6tigt werden und welche neuen Daten durch die Bearbeitung entstehen.Auch die Art der Ubertragung wird visualisiert, wobei zwischen dem Trans­port der Datentriiger und der Dateniibertragung unterschieden wird. Ergeb­nis ist somit ein Ablaufdiagramm der auszufiihrenden Bearbeitungsschritteunter Beriicksichtigung der ben6tigten und erzeugten Daten. Der zeitlogischeAblauf der Bearbeitungsschritte ist allerdings nicht eindeutig, was den sta­tischen Charakter dieser Darstellungsform weiter unterstreicht. Ein Beispielmit den hierfiir verwendeten Symbolen findet sich in Abb. 5.6.

Eingreifen vonHand

Problem­Datenbank

Eingeben vonHand

Platten­speicher

Abbildung 5.6. Beispiel : DatenfluBplan fur die zweite Ebene des Help Desks

13 Eine weitere Methode zur statischen Darstellung von Prozessen im Kontextder Programmentwicklung stellt die Hierarchy of Input Process Output-Methode(HIPO-Methode) dar. Dieses graphische Verfahren zur Formalisierung und Vi­sualisierung von Programmarbeitsschritten dient der Entwurfsphase von Soft­wareentwicklungsprozessen. Die Darstellung erfolgt in Form von Baumdiagram­men, in denen Prozesse hierarchisch aufgeteilt werden. Jeder Prozef (hier alsFunktion bezeichnet) wird durch eine ProzeBbeschreibung und die Ein- und Aus­gabedaten definiert . Je nach Detaillierungsgrad werden die so entstehenden Ebe­nendiagramme als Ubersichts- oder Detaildiagramme bezeichnet.

5.4 Modellierungsmethoden 171

5.4.3 Strukturierte Analyse und Vorgangskettendiagramme

Bei der Methode Strukturierie Analyse (SA) stehen wiederum Datenfliisse imVordergrund der Betrachtung; vgl. DeMarco (1978) sowie Yourdon (1989).Funktionen sollen hier nicht isoliert betrachtet werden, sondern es werdeninsbesondere Beziehungen zwischen Funktionen herausgestellt. Funktionenund Daten bilden dabei duale Sichtweisen eines Systems.

DatenfluBdiagramme stell en eine von drei Komponenten der SA dar. Dieeinzelnen Elemente konnen Tab . 5.2 entnommen werden. Jede Funktion be­schreibt eine Transformation von Eingangs- in Ausgangsdaten. Einer Funk­tion werden zudem ein Steuerungs- und KontrollfluB sowie ein Mechanismuszugeordnet, d.h. ein ProzeBtriiger oder Prozessor, der die Aktivitiit ausfiihrtoder unterstiitzt.

ElementDatenfliisseProzesseDateien und andere SpeichermedienQuellen und Senkenund- Verkniipfungenoder-Verkniipfungen

DarstellungsformpfeileKreisezwei parallel verlaufende gerade LinienRechteckeSterneKreuze

Tabelle 5.2. Komponenten der DatenfluBdiagramme; vgl. Keller (1993) , S. 76

Die zweite Komponente stellen Data Dictionaries dar. Hier werden Defi­nitionen iiber die Datenfliisse, die Komponenten der Datenfliisse, die Dateienund die Prozesse verwaltet .

Die dritte Komponente sind Minispezifikationen, die der eigentlichen Be­schreibung der Funktionen (auf der untersten Ebene, der sogenannten Ba­sisebene) dienen. Diese bestehen aus einer Beschreibung des zu erzielendenErgebnisses und Transformationsregeln zur Umwandlung von Ein- in Ausga­bedaten.

Ein wesentlicher Vorteil dieser Methode liegt in den Moglichkeiten derStrukturierung der Datenfliisse. Komplexe Sachverhalte lassen sich hierar­chisch gliedern, indem Prozesse auf der darunterliegenden Hierarchiestufeweiter aufgegliedert werden . So konnen funktionale Zusammenhiinge beziig­lich der Prozesse dargestellt werden , ohne daf der Benutzer einem Mega­Modell gegeniibersteht, sondern iiber die Hierarchieebenen hinweg navigie­ren kann . Ziel dieser Modellierungsmethode ist die Unterstiitzung sowohlder Anforderungsanalysephase als auch der Definitionsphase des Software­entwicklungsprozesses. Aus diesen Strukturierungsmoglichkeiten lassen sichdie Entwurfsprinzipien von SA-Diagrammen ableiten. So wird mit der SALd.R. ein Top Down-Ansatz verfolgt, wobei eine schrittweise Verfeinerungausgehend von einem iibergeordneten Prozess propagiert wird . Im Rahmen

172 5. Unternehmensmodellierung

der Hierarchiebildung kann eine beliebig tiefe ProzeBdekomposition realisiertwerden.

Mit dieser Methode k6nnen allerdings keine Zeitablaufe beziiglich der Er­ledigung von Funktionen abgebildet werden, d.h. es k6nnen wiederum keinedynamischen Aspekte analysiert werden .J"

Die Methode der Vorgangskettendiagramme wurde von Scheer (1990a)entwickelt und dient der Darstellung von Prozessen iiber Abteilungsgrenzenhinweg. Objekte, z.B. Produkte, werden hier iiber die ihnen zugeordnete Folgevon auszufiihrenden Funktionen definiert . Die Darstellung des Informations­flusses erfolgt als Informationsinput, der anschlieBenden Tatigkeit und einemInformationsoutput.l" Diese Diagramme dienen damit der Visualisierung derReihenfolge von Tatigkeiten (Prazedenzstruktur} , der jeweils verwendetenBetriebsmittel sowie der Erkennung von Medienbriichen zwischen der EDVund manueller Bearbeitung. Im Kontext der Medienbriiche sind insbeson­dere das Aufzeigen von Datenredundanz, von Mehrfacherfassung sowie vonzeitlichen Verz6gerungen der Vorgangsbearbeitung von besonderer Bedeu­tung, wobei ein Ziel dieses Modellierungsansatzes in der Vorgangsautoma­tisierung gesehen werden kann (z.B. einfache Formularhandhabungssystemeoder komplexe Workflow Management-Systerne) . Vorgangskettendiagrammesind im Kontext der Weiterentwicklung der Modellierungsansatze in ARISiibergegangen.

5.4.4 Petri-Netze

Petri-Netze dienen der Modellierung verteilter Systeme und Ablaufe, Sie er­lauben die Simulation der Modelle mittels einfacher Verhaltensregeln undkonnen daher eingesetzt werden, urn dynamische Aspekte dynamisch abzu­bilden, d.h. sie fungieren als lauffahige Programme und unterscheiden sich

14 Die Methode Strukturierte Analyse und Design Technik (SADT) ist der SA sehrahnlich und unterscheidet sich im wesentlichen in der Betrachtungsweise. Siesoli die Kommunikation zwischen Personen mit verschiedenen Funktionen er­leichtern und der Dokumentation der (Zwischen-) Ergebnisse der Analyse undEntwurfsprozesse dienen. Nachteil dieser Darstellungsweise ist wiederum die sta­tische Darstellung von Prozessen, d.h. daB die Prozesse nicht im Gesamtkontextanalysiert werden konnen. Die Klarung der Begriffe und Zusammenhange unddie Unterstiitzung des Softwareentwurfs ist das wesentliche Ziel, nicht aber dieAnalyse der Geschaftsprozesse an sich.

15 Man beachte hierbei den Bezug zum klassischen ProzeB der Produktionsplanung;vgl. Domschke et al. (1997). Bezieht man sich auf Scheer (1990a) sowie altereAuflagen von Scheer (1997) - z.B, die erste bis dritte Auflage - so wird die Her­kunft aus diesem Bereich nicht nur fiir das Informationsmanagement, sondernauch fiir die Wirtschaftsinformatik mehr als deutlich. Die dariiber hinausgehendeVerselbstandigung und auch zwischenzeitliche Abkehr der Wirtschaftsinformatikund des Informationsmanagements vom Operations Research - nicht nur in die­sem Bereich - konnte sich in Zukunft als Fehler erweisen , insbesondere wenn esurn die Integration von Planungsfunktionalitat in die Unternehmensmodellierunggeht.

5.4 Modellierungsmethoden 173

damit von den bisher dargestellten Modellierungsmethoden. Ziel dieser Me­thode ist, moglichst viele Erscheinungen bei der Informationsiibertragungund Informationswandlung in einheitlicher und exakter Weise zu beschrei­ben. Fiir eine Einfiihrung und Vertiefung der Materie wird der Leser aufAbel (1990), Baumgarten (1996), Desel und Oberweis (1996) sowie Schnie­der (1993) verwiesen .

In Abb. 5.4 sind Petri-Netze als mogliche Basis der Simulationsmodelledargestellt . Natiirlich konnen sie auch direkt zur Unternehmensmodellierungeingesetzt werden . Es ist dabei allerdings anzumerken, daB die Modellierungmittels Petri-Netzen im Vergleich zur objektorientierten Modellierung, wie siez.B. von einigen Simulationssystemen angeboten wird, der Programmierungvon Assembler gegeniiber Sprachen der vierten Generation entspricht.!" Trotzdieser Kritik behandeln wir Petri-Netze in diesem Kapitel, urn die Grundla­gen fiir die Modellierung lauffiihiger Unternehmensmodelle zu schaffen, wiesie z.B. fiir die Gestaltung und Optimierung von Workflow Management­Systemen benotigt werden.

Petri-Netze sind gerichtete Graphen. Ein gerichteter Graph besteht auseiner Menge von Knoten und einer Menge von gerichteten Kanten, wobei eineKante jeweils zwei Knoten in einer Vorgiinger-Nachfolger-Beziehung mitein­ander verbindet. In Petri-Netzen ist zwischen zwei Knoten jeweils maximaleine Kante zuliissig, und alle Knoten miissen im Graphen iiber eine Kanteerreichbar sein.

Die Knotenmenge wird in zwei disjunkte Mengen aufgeteilt, die akti­ven und die passiven Systemkomponenten. Passive Komponenten werdenals Kreise dargestellt und beschreiben den aktuellen Zustand des Knotens.Aktive Komponenten werden als Quadrate symbolisiert und reprasentierenEreignisse, die den Ubergang von einem alten zu einem neuen Zustand desGraphen realisieren. Es lassen sich drei verschiedene Klassen von Netztypenangeben:

1. Kanal-Instanzen-Netz: Diese Klasse zeigt eine statische Sicht auf ein zu­grundeliegendes Problem. Die passive Komponente (Kreis) wird als Ka­nal bezeichnet und reprasentiert Informationszustande, Das Beispiel desHelp Desks ist in Abb. 5.7 als Kanal-Instanzen-Netz modelliert.

2. Bedingung-Ereignis-Netz: In diesem Netztyp wird festgelegt, welche Be­dingungen erfiillt werden miissen, damit ein bestimmtes Ereignis eintre­ten kann. Erfiillte Bedingungen werden mit einem Punkt (Markierung)gekennzeichnet (vgl. Abb. 5.8). Sind alle Bedingungen, die auf ein Ereig­nis zeigen, erfiillt, so tritt das Ereignis ein und liefert - iiber das soge­nannte Schalten der folgenden aktiven Komponente - als Ergebnis eineMarkierung der nachfolgenden passiven Komponente. Im Beispiel kanndie Problemaufnahme durch den Mitarbeiter auf Ebene 1 erfolgen , dasowohl der Mitarbeiter verfiigbar ist als auch ein Anruf eingegangen ist.

16 Dennoch linden sich viele Anwendungen fur Petri-Netze, insbesondere in techni­schen Systemen bzw. der Systemautomatisierung.

174 5. Unternehrnensrnodellierung

Losung Losunggemeldet in Datenbank

aufhehmen

Losungin Datenbankaufgenommen

Kunden­kontaktaufhehmen

Anruf

Kunden­kontaktaufgenommen

Losungmelden

Losungmelden

Losunggefunden

Abbildung 5.7. Kanal-Instanzen-Netz

Die genaue Problemaufnahme des weitergeleiteten Auftrags durch einenMitarbeiter der zweiten Ebene kann aber erst erfolgen, wenn der Mit­arbeiter der zweiten Ebene frei ist, d.h. die entsprechende Markierunggesetzt istP

3. Stellen-Transitions-Netz: Dieser Netztyp stellt eine Erweiterung des Be­dingung-Ereignis-Netzes dar. Stellen bilden die passiven Elemente des Sy­stems. Durch eine Kapazitiitsangabe an jeder Stelle wird die maximaleAnzahl moglicher Markierungen festgelegt. Die Kanten sind in diesemGraphen bewertet, wobei das Gewicht die Anzahl an Markierungsele­menten definiert, die beim Schalten transformiert werden. Die Transfor­mation erfolgt tiber die Transition (aktive Komponente), die schaltet,sobald fiir aile eingehenden Kanten die Zahl der Markierungen der vor-

17 An einigen Stellen irn Modell treten Konflikte derart auf, daf eine Stelle zweiNachfolger hat, wobei jeweils nur ein Nachfolger schalten solI. Urn festzulegen,welcher Nachfolger zu wahlen ist, sind Regeln irn Modell zu hinterlegen. Dieskann durch explizite Angabe in den Knoten erfolgen oder durch Nutzung so­genannter gefiirbter Petri-Netze, bei denen aus der Farbe der Markierung derNachfolger abgeleitet werden kann.

5.4 Modellierungsmethoden 175

MitarbeiterEbene Iverfiigbar

AufuahmeProblem

Losungdirekterklaren

Anruf

genaueAufnahmeProblem

Abbildung 5.8. Bedingung-Ereignis-Netz

MitarbeiterEbene 2verfiigbar

gelagerten Stellen die Kantenbewertung zur betrachteten Transition er­reicht oder iiberschreitet. 1m Beispiel des Help Desks kann dieser Netztypgenutzt werden, urn mehrere Mitarbeiter pro Ebene abzubilden. Da im­mer eine ProzeBinstanz behandelt wird, sind alle Kantenbewertungen aufden Wert eins zu setzen. Fur jeden Mitarbeiter ist in der Initialisierungdes Netzes eine Markierung der Stellen Miiarbeiter Ebene X verfiigbarzu setzen . Die Anzahl maximaler Markierungen k pro Stelle kann fiir dieStellen , die die verfiigbaren Mitarbeiter reprasentieren, ebenfalls auf dieAnzahl eingesetzter Mitarbeiter der jeweiligen Ebene eingestellt werden .Alle anderen Schranken konnen auf k = 00 gesetzt werden. In Abb. 5.9 istdas Schalten fiir die erste Ebene nach Eingang eines Anrufs dargestellt .

Ebene Iverfiigbar

AufuahmeProblem

k='"• Anruf

eingegangen

AufuahmeProblem

k=OOAnrufeingegangen

(a) vor dem Schalten (b) nach dem Schalten

Abbildung 5.9. Stellen-Transitions-Netz

176 5. Unternehmensmodellierung

Ein Nachteil der Darstellungsform liegt im notwendigen Detaillierungs­und Abstraktionsgrad - im Sinne einer exakten mathematischen Formulie­rung. In der urspriinglichen Form der Petri-Netze sind Moglichkeiten derVerdichtung (Hierarchisierung) von Modellkomponenten nicht gegeben, d.h.Daten, Funktionen und Organisationseinheiten sind auf der gleichen Ebeneund dariiber hinaus in der gleichen Notation abzubilden, was entsprechendeAbbildungen durchaus kompliziert erscheinen lassen kann ; vgl. Abb. 5.7. Soist der logische Ablauf in einem Petri-Netz ohne Werkzeug-Unterstiitzung,mit der der Ablauf simuliert werden kann, Ld.R. nicht ersichtlich; vgl. z.B.Keller (1993). Fiir derartige Zwecke eignen sich insbesondere spezialisierteSimulationsumgebungen, die im folgenden Abschnitt thematisiert werden.

5.4.5 Simulation

Urn Prozesse zu simulieren, muf es das zugrundeliegende Modell ermoglichen,sie dynamisch abzubilden. Unter Simulation wird im allgemeinen die Nach­bildung eines dynamischen Prozesses in einem Modell verstanden, urn zuErkenntnissen zu gelangen, die auf die Realitat iibertragbar sind (RichtlinieVDI 3633). Der Einsatz von Simulation wird dann erforderlich, wenn sichein analytisches mathematisches Optimierungsmodell aufgrund der Komple­xitat nicht mehr oder nur noch mit unvertretbarem Aufwand definieren liiBt,analytische Methoden zu stark vereinfachende Annahmen erfordern, diese zukompliziert oder mit nur zu groBem Aufwand anwendbar sind , und die Un­tersuchungen am real en System zu komplex, zu kostspielig, zu gefahrlich oderiiberhaupt nicht moglich sind; vgl. Domschke und Drexl (1998).

Petri-Netze stellen eine rnogliche Basis (Konzept) fiir die diskrete, ereig­nisorientierte Simulation dar, die wir in diesem Unterabschnitt kurz vorstel­len. Diese Form der Simulation findet derzeit vor allem in den BereichenProduktion und Logistik, speziell im Zusammenhang mit MaterialfluBsyste­men, Anwendung.l" Da aber auch GeschiiftsprozeBmodelle (als Teil der Un­ternehmensmodelle) meist sehr komplex sind und eine Bewertung der Pro­zesse mittels mathematischer Formulierungen oder Modelle aufgrund ihrerKomplexitiit Ld.R. nicht moglich ist , bieten sich Simulationsmodelle auch fiirdiesen Anwendungsbereich an; vgl. z.B. Liem et al. (1997) . Dariiber hinaussollten Workflow Management-Systeme in der Testphase (Validierung undVerifikation) simuliert werden, bevor sie im operativen Betrieb eingesetztwerden . Aus diesen Griinden ist die Behandlung der Simulation im Rahmen

18 Vgl. hierzu z.B. Noche und Wenzel (1991» . Einige Beispiele in der Automobil­industrie finden sich bei Spieckermann und Gutenschwager (1997) , die aile dreiAnwendungsbereiche, wie sie die VDI Richtlinie 3633 vorschlagt , namentlich diePlanung, die Realisierung sowie den operativen Betrieb von Systemen, abdecken.Neben dem zeit lichen Veriauf von Projekten findet die Simulation Anwendungauf allen Ebenen der Planung, der strategischen, der taktischen und der opera­tiven Ebene.

5.4 Modellierungsmethoden 177

des Informationsmanagements eine sinnvolle Erganzung zu anderen Model­lierungsrnethoden.

Die diskrete, ereignisorientierte Simulation basiert (irn Gegensatz zurkontinuierlichen Simulation) darauf, daB die Modellvariablen ihre Wertenur zu bestimrnten (diskreten) Zeitpunkten verandern k6nnen. Diese Zu­standsiibergange der Modellvariablen (die als Ereignisse bezeichnet werden)definieren dann den Ablauf eines Simulationsexperiments. Ereignisorientiertbedeutet, daf das Modell nur zu den Zeitpunkten betrachtet wird, in deneneine Zustandsveranderung eintritt. Zustandsiibergange k6nnen beispielsweisedarin bestehen, daB ein Auftrag eine Abteilung erreicht oder eine belegte Res­source frei wird. Ein Ereignis kann jeweils weitere, sogenannte Folgeereignisseausl6sen (z.B . Auftrag verlafit die Abteilung nach der Bearbeitung) . Die Zeit­punkte, zu denen die (Folge-) Ereignisse auszufiihren sind, werden jeweils neuberechnet (z.B . auf der Basis von Wahrscheinlichkeitsverteilungen).

Simulatoren stell en Entwicklungsplattformen zur Erstellung von Simula­tionsmodellen dar und dienen im wesentlichen der Abbildung der Zeit unddes stochastischen Verhaltens von Systemen. Dariiber hinaus beinhalten vieleSimulatoren wiederverwendbare Softwarekomponenten, die z.B . fur die Abbil­dung von Lager- oder Produktionssystemen gemaf der abzubildenden Anlagekombiniert und erweitert werden k6nnen. Das zentrale Element eines ereignis­orientierten Simulators ist die Ereignisliste bzw. der Ereigniskalender. Dortwerden alle Zustandsanderungen mit ihrem Eintrittszeitpunkt, der Bezeich­nung der betroffenen Objekte und unter Urnstanden weiteren Angaben ein­sortiert. Die Grobstruktur der Ablaufebene ereignisorientierter Simulatorengestaltet sich wie in Algorithmus 5.1 dargestellt .

Initialisierung: Auffiillen der Ereignisliste mit Startereignissenwhile Simulationsende nicht erreicht do

Ermittle den Zeitpunkt T E des nachsten Ereignisses eSetze die Simulationszeit auf T EArbeite das Ereignis e abErzeuge Folgeereignisse (und sortiere diese in die Ereignisliste ein)Entferne das Ereignis e aus der Ereignisliste

endwhile

Algorithmus 5.1. Funktionsweise des Ereigniskalenders

Fur die Modellierung kommen daher zwei neue Aspekte hinzu. Die Mo­dellierung von Zeitablaufen, speziell die vollstandige Beschreibung aller Fol­geereignisse einschlieBlich der Zeitabstande, und die Angabe von Wahrschein­lichkeiten, wenn einem Ereignis rnehrere Folgeereignisse zugeordnet sind. EinVerstandnis der Grundlagen der Statistik ist also erforderlich, urn den Ein­fluf des" Zufalls" auf Realitat und Modell richtig einschatzen und abbildenzu konnen,

178 5. Unterne hmensmodellierung

Filr das Verst andnis eines Simulationsablaufs sind Warteschlangensy­stem e wichtig . Ihre allgemeine Struktur kann folgendermaBen beschriebenwerden (vgl. Kosturiak und Gregor (1995)): Sogenannte bewegliche Objekt ewerden in Quellen generiert und reihen sich in Warteschlangen, die Statio­nen (Bedienstellen oder Bearbeitungsplatze) reprasentieren, ein. In diesenStationen erfolgt die Abfertigung (Bearb eitung) der beweglichen Objekte.Die Bearbeitung ste llt Ld.R. eine Black Box dar, d.h . es werden im Modellnur der Anfangszeitpunkt und der Endz eitpunkt der Bearbeitung betrach­tet. Nach Erreichen des Endzeitpunkts der Bearb eitung verlaflt das jeweiligebewegliche Objekt die Station und reiht sich in die nachste Warteschlangeein oder wird in einer sogenannten S enke vernichtet . Die Entscheidung tiberdie als nachstes anzusteuernde Warteschlange kann per vordefiniertem Ar­beitsplan , per Zufallszahlengenerat or oder per (programmierter) Strat egieerfolgen. Die Auswahl des nachsten Obj ekt s zur Bearbeitung aus einer War­teschlange kann ebenfalls zufallig oder per programmierter Strat egie erfolgen.Eine Stand ardstrategie stellt FIFO (Fir st In - First Out) dar. Die Struktureines Warteschlangensystems ist in Abb. 5.10 dargestellt .

Au'gangs- Elnl;anl;'- Au'gang... Elnl;anl;S- Au,gangs- Elnga ng.-steuerung steuerung steuerung steuerung steuerung vte uer ung

Bestimmung Bcrcchnung dcr Beenden Bcrcchnung dcr Becndcn Vcrn ichtcndcr Hearbcitun gs- der Bcarbcitungs- de r desNach folge- dauc r (z.B. auf Bcarbe itung, dauc r Bearbcitung, bcwcg lic hcnStation Basis eincr Weitcrleitcn weitcrleiten Ohjckt s

Wahrschcinlich-kcitsvcrtcilun g)

I Stat ion 0 ~.... Wartc-- t>4 t---schlange I 1 Station I

iQuelle

Wartc ---.~ . l IStation 4 1schlange 3 Station 3 r

{Erzcugcn Wan e-- ..: Station 2 ~

Senkedes .• schlangc 2

bcwcglichcnObj eklS)

Abbildung 5.10. St ruktur eines Warteschlangensyst ems

Wir haben bereits angesprochen, daBdie Simulation auf Petri-Netzen auf­setzen kann . In der einfiihrenden Literat ur finden sich weitere, hohersprachigeKonzepte, wie z.B. das Bausteinkonzept; vgl. z.B. Noche und Wenzel (1991)oder Kosturiak und Gregor (1995). Beim Bausteinkonzept, auf dem auch

5.4 Modellierungsmethoden 179

SiMPLE++19 basiert, verfiigt der Anwender iiber eine Bibliothek vorde­finierter Bausteine, die sich in statische und dynamische Objekte unter­teilen lassen. Die statischen Objekte beschreiben das Systemlayout, z.B.Bearbeitungsstationen. Die dynamischen Elemente lassen sich in Bearbei­tungsobjekte (Produkte), Bearbeitungselemente (Fertigungshilfsmittel, Ar­beiter, mobile Montagehilfsmittel), Transportelemente (passive und aktiveForderhilfsmittel) und Informationselemente (Nachrichten oder Datensatze)unterteilen; vgl. z.B. Kosturiak und Gregor (1995). Diese Bausteine lassensich nun beliebig zu neuen , komplexeren Bausteinen kombinieren. Eine Pro­grammierung moglicherweise notwendiger Steuerungsstrategien erfolgt meistiiber eine Skriptsprache des Simulationssystems. Der Ereigniskalender stehthier ebenfalls als Baustein zur Verfiigung. In Abb. 5.11 ist der Bausteinkastenvon SiMPLE++2o dargestellt .

(lee res) Netzwerkzur DefinitionneuerObjckle

Puffer

•

Einzclstation Tabelle Ercigni,kalcOOc:r

I I

~~;;~:;;i==t=~f::==tI- Paleu e(bewegllcbes Objektj

Fahrzeug (bewegficbesObjekt)

- - Zufallv:JhlcngcnCr.llor

globale Variable

Abbildung 5.11. Bausteinkasten des Simulators SiMPLE++

Mit Simulatoren, die nach dem Bausteinprinzip arbeiten, lassen sich teil­weise bereits durch Kombination und Parametrisierung des bereitgestelltenBausteinvorrats einfache Modelle erstellen. Es ist allerdings eine Illusion zuglauben, man konnte groBere und komplexe reale Systeme nur auf diese Artund ohne Programmierung - zumindest in der Skriptsprache des Simulators ­abbilden.

19 Der Simulator SiMPLE++ wird seit Anfang 2000 unter dem Namen eM-Plantvon der Firma Tecnomatix vertrieben. Mit diesem Simulator wird auch das Bei­spiel Help Desk in Abschnitt 5.7 modelliert.

20 Weltweit gibt es fur Simulation iiber 100 Werkzeuge von nahezu ebenso vielenAnbietern; vgl. Spieckerrnann et al. (1997) sowie Swain (1997) .

180 5. Unternehmensmodellierung

Uberwiegend sollen mit Simulationsexperimenten What-if-Analysen undHow-to-achieve-Analysen durchgefiihrt werden. Grundsatzlich ist bei Simu­lationsstudien zu bedenken, daf fiir die Ergebnisauswertung aufgrund derstochastischen Einfliisse statistisches Know-How benotigt wird. Der Bewer­tung der Eingangsdaten kommt dabei ebenfalls eine zentrale Bedeutung zu.Simulation funktioniert nach dem GIGO-Prinzip: "Garbage In - GarbageOut". Wenn z.B. die Zeiten fur einzelne Bearbeitungsschritte nicht der Rea­litat entsprechen, so kann die Simulation nur schwerlich zu guten Prognosenfiihren,

Zur Unterstiitzung der Auswertung bieten die meisten Simulatoren Stan­dardstatistiken an, z.B. wieviele bewegliche Objekte in den einzelnen Statio­nen bearbeitet wurden oder wie hoch die minimalen, durchschnittlichen undmaximalen Durchlaufzeiten waren. Spezielle Statistiken und Auswertungenmiissen aber i.d.R. programmiert werden .

Simulationsmodelle konnen auf anderen Modellen beruhen (die z.B. mitARIS erstellt wurden). Zu ihrer Inbetriebnahme ist allerdings oftmals einerheblicher zusatzlicher Programmieraufwand (zur Abbildung von Steue­rungsstrategien) notwendig, da in anderen Modellierungsumgebungen eineausfiihrbare Abbildung von solchen Algorithmen zum Teil nicht moglich ist. 21

Im folgenden Abschnitt befassen wir uns mit der Objektorientierung, durchdie auch SiMPLE++ gekennzeichnet ist .

5.4.6 Objektorientierung als Modellierungsansatz

Urn Software zu entwickeln, benotigt man Modelle, die alle notwendigenDaten, Funktionen und Informationsfliisse abbilden.F Auch im Falle einerAnderung eines bestehenden Systems sollte zunachst das zugrundeliegendeModell angepaBt werden. Dariiber hinaus lassen sich wesentliche Anforderun­gen an Software wie folgt formulieren; vgl. z.B. Pagel und Six (1994) sowieSommerville (1996):

• Kurze Entwicklungszeiten• Hohe Flexibilitat und Anpassungsfahigkeit• Kombinationsmoglichkeit von Standard- und Individuallosungen• Abbildung komplexer Strukturen und Vorgange• Baukastenprinzip im Software Engineering (modularer Aufbau)• Wiederverwendbarkeit

21 Eine auf SiMPLE++ basierende Simulationskomponente ist z.B. in derARIS-Modellierungsumgebung integriert, und fiir SiMPLE++ existieren ARIS­Objekte zur Modellierung als Bausteinkasten. Diese Tendenzen deuten auf dieRealisierung integrierender UnternehmensmodelJe hin, wie Taylor (1995) sie kon­zeptionelJ beschreibt.

22 Aus betriebswirtschaftlicher Sicht impliziert dies auch eine einheitliche Sichtweisefiir die Aufbau- und Ablauforganisation; vgl. Becker (1991b) .

5.4 Modellierungsmeth oden 181

Demgegeniib er lassen sich die Unzulanglichkeiten der vorgestellten Mo­dellierungsmethoden und Nachte ile der Modellierungsprax is in diesem Zu­sammenhang folgendermaBen zusam menfassen:

• Der Ubergang zur Implementierung ist meist schwierig (Briiche zwischenModellartefakten und Softwarebausteinen) .

• P rozeBanalysen sind bei statischer Darstellung nur bedingt moglich (feh-lende Ausfiihrbarkeit ).

• Petr i-Netze sind sehr schwer zu "lesen" .• Modelle werden oftmals quasi unabhangig voneinander entwickelt .• Es exist ieren eigenstandige Entwicklungsumgebun gen fur Simulations-,

Finanz- und Workflow-Modelle.• Die Modellzusammenfiihrung erfolgt oft manuell (z.B. Dateniibertragung).

Wie in der Einleitung zu diesem Kapitel bereits angesprochen, exist iert inder Literatur die Forderung nach Modellintegration. Die Anwendungsbereicheund Ziele integrativer Unt ernehmensmodelle lassen sich (nach Taylor (1995»folgendermaBen zusamm enfassen:

• Repriisentation: AIle Daten und Prozesse werden abgebildet, urn ein Ver­standnis der Aufbau- und Ablauforganisation zu errnoglichen und Verbes­serungspotentiale zu erkennen.

• Simulation: Abbildung von Zukunftsszenari en (z.B. Vera nderung der Ab­lauforganisation unter Beriicksichtigun g der Ressourcenplanung).

• Ausfiihrung: Automatische Erstellung von Anwendungsprogrammen (z.B.Workflow-Anwendungen).

Dabei ist kri tisch zu hinterfragen, ob ein einziges Unte rnehmensmodelliiberhaupt realisiert werden kann und sollte . So besagt ein Prinzip der Mo­dellierung, wie sie von Booch et al. (1999) definiert werden, daB kein einzelnes,iibergreifendes Modell fur komplexe Systeme ausreichend ist. Vielmehr kannjedes nicht-triviale System am besten durch eine Reihe kleiner , aber nahezuunabhangiger Modelle angegangen werden. Die Komplexit at von Unterneh­men laBt es da her realisti scher erscheinen, die prinzipiell als sinnvoll zu er­achtende Forderung nach integrativen Modellen auf jeweils relevante Aspekteinnerhalb eines Unt ernehmens einzuschranken, zumal es in der Praxis an Bei­spielen der Anwendung von Modellen , die gleichzeitig Reprasent ation, Simu­lation und Ausfiihrung ermoglichen, mangelt.

Die einzige Moglichkeit , anwendungsiibergreifende Modelle zu konzipie­ren, sieht Taylor (1995) in der Obj ektorientierung. Fur ihn ste llen die Ob­jekte mit den Moglichkeiten des Nachrichtenaustauschs und der Bildung vonOberobjekten , die mit der menschlichen Denkweise des Chunking korrespon­dieren , den wesent lichen Vort eil der Obj ektorient ieru ng dar.23

23 Mittels Chunking lassen sich komplexe Systeme, z.B. Unterne hmen, st rukt urie­reno In der menschlichen Denk weise beschr eibt Chunking die Art , wie wir unsDinge merken . Zum Beispiel merken wir uns nicht die Ziffernfolge 0015052688840,

182 5. Unternehmensmodellierung

Die Vorteile der Objektorientierung liegen in der Nahe zur und gleich­zeitigen Unabhiingigkeit von der Implementierungsebene. Dem Nachteil desaufwendigen Ubergangs zur Implementierung kann damit deutlich entgegen­gewirkt werden. Auch ist mit der Objektorientierung die Strukturierung vonSystemen moglich (Klassen, Hierarchien) . So konnen aIle Modelltypen, dieTaylor nennt, realisiert werden .

Auch fur die Implementierung an sich lassen sich weitere Vorteile ange­ben . Diese betreffen im wesentlichen die Anforderungen an die Softwareent­wicklung, wie sie oben definiert wurden. Objekte bzw. Objektklassen bildeneigenstiindige Module, die separat getestet werden konnen, Der Forderungnach Korrektheit liil3t sich in der Verifikationsphase relativ strukturiert nach­kommen. Objekte als Module konnen einzeln ausgetauscht oder modifiziertwerden, wobei nur das Modul an sich verandert werden mul3 (intern) oderneue Schnittstellen zum Objekt definiert werden miissen . So sind Objekteauch einfach zu erweitern (z.B . urn zusiitzliche Funktionen) - bzw. das Ge­samtsystem urn neue Objekte. Objekte als Module konnen auch fiir andereSysteme wiederverwendet werden. Dies ist insbesondere fur die Adaption vonReferenzmodellen von grol3er Bedeutung.

Mit objektorientierten Modellierungsmethoden (Analyse- und Designme­thoden) haben sich eine Vielzahl von Autoren auseinandergesetzt .P" Andersals in der ER-Modellierung, wo Objekte (Entities) durch ihre Attribute de­finiert werden, besitzen Objekte in der objektorientierten Modellierung eineeindeutige Identitiit, und zwar unabhiingig davon, wie die Attributwerte ge­setzt sind. Attribute beschreiben das Objekt (struktureller Aspekt) . Danebenzeichnen sich Objekte zusatzlich durch verhaltensmiiBige Aspekte aus, die inForm von bereitgestellten Methoden (Operationen) definiert werden .

Ein wichtiger Aspekt der objektorientierten Modellierung ist der Aus­tausch von Nachrichten, d.h . es findet eine Kommunikation zwischen denObjekten statt. Dieser Austausch erfolgt durch gegenseitigen Aufruf von Me­thoden, auf die das empfangende Objekt reagiert. Die Methoden bilden dieSchnittstellen nach aul3en (sichtbare Operationen auf den Objekten) . Die Im­plementierung und dazu notwendige weitere Operationen bleiben verborgen(Prinzip der Kapselung).

Zudem besteht die Moglichkeit der Klassenbildung, der Zusammenfassungvon Objekten mit gleichen Eigenschaften (Attribute und definierte Opera­tionen) zu Klassen. Weitere Kennzeichen der Objektorientierung sind dieVererbung und das Overriding, d.h. Objekte konnen Eigenschaften und Me­thoden vererben, wobei die erbenden Objekte wiederum partiell veriindert

sondern nutzen Chunking, urn mehr als 7 +/- 2 Elemente, auf die unserVerstandnis im allgemeinen beschrankt ist (Miller (1956)) , zu behalten, hier 001fur USA, 505 fur New Mexico usw. Chunking ist auch ein wesentliches Konzeptder klassischen Organisation, z.B. die Aufteilung in Bereiche oder Abteilungen.

24 Vgl. hierzu Booch (1994), Coad und Yourdon (1994), Harel (1988), Rumbaughet al. (1991) und Wirfs-Brock et al. (1990). Zu einer kurzen Ubersicht zur ob­jektorientierten Programmierung vgl. auch Fink et al. (2000a).

5.4 Modellierungsmethoden 183

werden konnen . Die Unterklasse (Spezialisierung) erbt aIle Attribute undOperationen / Methoden ihrer Oberklasse (Generalisierung), kann dann je­doch gegebenenfalls urn weitere Attribute und Operationen erweitert werden .In einer Objekthierarchie werden also globale Eigenschaften oben, spezielleEigenschaften unten definiert . Es konnen zudem Methoden in der Unterklasseverandert werden (Overriding). Dariiber hinaus HiBt sich zwischen einfacherund multipler Vererbung unterscheiden, je nachdem wieviele Eltern Attributeoder Methoden an eine Subklasse vererben.

In einem objektorientierten Modell konnen gleiche Nachrichten unter­schiedliche Methoden (Implementierung) auslosen. Die letztendlich ausge­fiihrte Methode wird hier durch den Typ der empfangenden Klasse bestimmt.

Bei Betrachtung der Anforderungen an Software wird deutlich, daB einekonsequente Objektorientierung besonders die Einhaltung von Flexibilitatund Kombinationsmoglichkeiten auf elegante Weise ermoglicht. Wichtig isthier die Kommunikation, die auf Basis des Nachrichtenaustauschs realisiertwird und den InformationsfluB beschreibt. Werden z.B. die Organisationsein­heiten als Objekte unter Angabe der bereitgestellten Methoden abgelegt, sokann die Kommunikation dazu genutzt werden, Instanzen der Aufgaben (alsObjekte definiert) den am BearbeitungsprozeB beteiligten Organisationsein­heiten sequentiell zuzuschicken (unter Beachtung der Auftragsreihenfolge).

Obwohl die Objektorientierung im Rahmen der Softwareentwicklung zudeutlichen Verbesserungen gefiihrt hat, ist sie nicht als die Methode anzu­sehen, die aIle oben angesprochenen Probleme beziiglich der Modellierungund Softwareentwicklung, speziell der Wiederverwendung, abschlieBend losenkonnte; zu kritischen Auseinandersetzungen vgl. z.B. Czarnecki und Eisen­ecker (2000), Szyperski (1998) sowie Webster (1995).

5.4.7 Unified Modeling Language

Eine Moglichkeit, aIle Modellierungsmethoden, die bisher genannt wurden, ineiner einheitlichen Notation abfassen zu konnen, bietet die Unified ModelingLanguage, die auf der Objektorientierung basiert. Mit UML solI es dariiberhinaus moglich sein, die verschiedenen Entwicklungsphasen eines Softwaresy­stems mit den entsprechenden Modellen zu begleiten. Eine mogliche Einord­nung verschiedener Diagrammtypen beziiglich des Softwareentwicklungspro­zesses findet sich in Tab. 5.3, wobei anzumerken ist, daB die Anwendungs­bereiche der dargestellten Methoden nicht scharf voneinander abzugrenzensind. Zu einer weitergehenden Einfiihrung in UML wird der Leser auf Boochet al. (1999) verwiesen.

1m folgenden werden wir die verschiedenen Diagrammtypen vorstellen,wobei wir das Beispiel des Help Desks erneut aufgreifen.

184 5. Unternehmensmodellierung

Entwicklungsphase Statisches Modell Dynamisches Modelldes Softwaresystems (Objekt-Struktur) (Objekt-Verhalten)Anforderungen Anwendungsfalldiagramme AktivitatsdiagrammeAnalyse Klassendiagramme ZustandsdiagrammeEntwurf verfeinerte Klassen- Sequenzdiagramme,

diagramme (mit Kollaborations-Vererbung, Assoziationen) diagramme

Implementierung Komponentendiagramme Verteilungsdiagramme

Tabelle 5.3. Klassifikation der UML-Diagrammtypen

5.4.7.1 Anwendungsfalldiagramme

Ein Anwendungsfalldiagramm (Use Case) beschreibt allgemeine Beziehun­gen zwischen handelnden Personen und typischen Anwendungsfallen in ei­nem System. Es konnen verschiedene Teilnahme-Beziehungen zwischen Per­sonen und Anwendungsfallen sowie Generalisierungen innerhalb der Anwen­dungsfalle dargestellt werden (vgl. Abb. 5.12). In der Abbildung sind Perso­nen als Strichmannchen, Anwendungsfalle als Ellipse mit einer informellenBeschreibung und Beziehungen durch Pfeile dargestellt. Beziehungen wer­den dahingehend unterschieden, ob sie Erweiterungs- (durch << extends> >gekennzeichnet) oder Benutzungsbeziehungen (durch « uses» gekenn­zeichnet) darstellen.

~xperte aus einerA ~aChabteilUng

}------+- ~MitarbeiterderA ~elefonzentrale~--«-e""xtends »

t,-,FindeLosungUDdbeantworte

Kundenproblem

Help Desk

Kunde

~ BeantworteA:--If---------'- Kundenproblem

Abbildung 5.12. Beispiel fur ein Anwendungsfalldiagramm

5.4 Modellierungsmethoden 185

5.4.7.2 Akt.ivitatadiagramme

Mit Hilfe von Aktivitiitsdiagrammen (Activity Diagrams) UiBt sich ein Vor­gang (Workflow) vcranschaulichen. Die verschiedenen Phasen oder Zustandeeines Prozesses werden dabei durch Transitionen miteinander verbunden. Da­bei wird der KontrollfluB in Form von Bedingungen und Verzweigungen undder DatenfluB mit der Weitergabe von Objekten veranschaulicht (vgl. Abb.5.13).

t----~ Aufnahme Problem 1-----------,'--__-,--__-1 [Problem direkt losbar]

[Problem in der Datenbank)

Losung erstellen

Losung an Kunden­berater melden

Kundenkontaktaufnehmen

Abbildung 5.13. Beispiel fur ein Aktivitatsdlagramm

Aktivitaten werden durch abgerundete Rechtecke reprasentiert , Transi­tionen zwischen ihnen stellen den Ablauf des Vorgangs dar. Der Ubergangzwischen zwei Aktivitaten kann mit einer Bedingung verbunden sein . Paral­lele Aktivitaten gehen von Synchronisationslinien aus und munden wieder

186 5. Unternehmensmodellierung

in solchen Linien. 1m Beispiel wird der Vorgang der Problemlosung und dieAufnahme in die Datenbank parallel ausgefiihrt.

5.4.7.3 Klassendiagramme

Klassendiagramme (Class Diagrams) beschreiben (im Gegensatz zu den Akti­vitatsdiagrammen) die allgemeine , statische Struktur von Anwendungssyste­men und stellen eine Weiterentwicklung der ER- und erweiterten ER-Modelledar. Ein Klassendiagramm ist ein Graph, in dem die Klassen des Anwen­dungs systems und ihre unterschiedlichen Beziehungen dargestellt sind. Klas­sen werden als Rechtecke dargestellt , Attribute und Methoden der Klasseebenfalls in das jeweilige Rechteck geschrieben, wobei die Notation PASCAL­ahnlich ist. Fur Methoden lassen sich durch ein vorangestelltes SonderzeichenGiiltigkeitsbereiche analog zur Programmiersprache C++ spezifizieren. Soentspricht ein Plus einem offentlichen Giiltigkeitsbereich (public), ein Minuseinem auf die Klasse der Methode beschrankten Zugriff (private) und das Zei­chen # einem auf die Klasse sowie abgeleitete Klassen beschrankten Zugriff(protected) . Attribute, die sich aus anderen Attributen einer Klasse berechnenlassen, werden als abgeleitete Attribute bezeichnet und durch einen vorange­stell ten Schragstrich gekennzeichnet. Gleiches gilt auch fiir Beziehungstypen.

1m Verlauf des Entwicklungsprozesses kann der Detaillierungsgrad derDarstellung zunehmen, indem die Modelle schrittweise verfeinert werden .Zu Beginn des Entwicklungsprozesses dienen sie noch der Anforderungs­analyse, wahrend sie am Ende der Entwicklung quasi eine Systemdokumen­tation darstellen. Abb. 5.14 illustriert diese Verfeinerung. In der Anforde­rungsanalyse geniigt es zu wissen, daf es eine Klasse Problem/all gibt, diein der Analysephase durch Attribute und Methoden spezifiziert und in derImplementierungsphase schlieBlich erweitert wird . Aus Sicht des Informati­onsmanagements ist die Anforderungsanalyse der wesentliche (wenn nichtsogar einzige) Betrachtungsgegenstand, wahrend die implementierungsnahenStufen im EntwicklungsprozeB Gegenstand der Wirtschaftsinformatik sind.Beziiglich der Modellierung findet sich hier somit eine Schnittstelle zwischendiesen beiden Gebieten.

Beziehungen zwischen Klassen werden, wie in den Anwendungsfalldia­grammen, durch Verbindungslinien gekennzeichnet. Die verschiedenen Ar­ten von Beziehungstypen werden dabei durch unterschiedliche Linientypenund Pfeilarten dargestellt (vgl. Abb. 5.15). Der aus der ER-Modellierungbekannte Beziehungstyp zwischen Objekttypen wird durch eine Kante zwi­schen den Klassensymbolen abgebildet. Kardinalitaten lassen sich analog zurER-Modellierung angeben. Die Beziehung kann ebenso wie die Rollen der be­teiligten Klassen benannt werden. So wird die Rolle qetuirt.eu.Fallsammlunqin Abb. 5.15 z.B. durch die Klasse Symptom eingenommen. Eine hierarchischeBeziehung zwischen Klassen wird durch eine entsprechende Vererbungsbezie­hung beschrieben.

5.4 Modellierungsmethoden 187

ProblemfaIl Problemfall

Nummer: IntegerKurzbeschreibung: Stringbekannt_seit: Date

anlegen( )erweitem( )loschem )

ProblemfaIl

+ Numrner : Integer+ Kurzbeschreibung: String# ist_Spezialfall_von : Problemfall+ bekannt_seit: Date

+ anlegen()+ erweitem( )+ loscheru )+ in_DB_speichem()

Abbildung 5.14. Klassennotation in der Anforderungs-, Analyse- undImplementierungsphase

In Abb. 5.15 findet sich neben den Beziehungstypen auch ein Ausschnittdes Help Desks . Jeder Problemfall ist durch eine Nummer und eine Kurz­beschreibung gekennzeichnet. Zu jedem Problemfall gehoren verschiedeneSymptome, wobei das identische Symptom in mehreren Problemfallen vor­kommen kann, was durch die Kardinalitaten dargestellt ist. Innerhalb dieserBeziehungen nimmt die Klasse Problemfall die Rolle ist.Problemfall ein . EineFallsammlung ist eine Aggregation von Problemfallen, wobei ein Problem­fall genau einer Fallsammlung zugeordnet ist. Die Beziehung gehorLzu_Fall­sammlung ergibt sich aus den beiden anderen Beziehungen und stellt dahereine abgeleitete Beziehung dar, was durch den vorangestellten Schragstrichillustriert wird.

----t> Vererbung

....-------{:> Realisierung- - - - Bidirektionale Beziehung

• gehiM_zu_Problem/ all > Unidirektionale Beziehung

--<> Aggregation

---<lII.~ Komposition

Abbildung 5.15. Beispiel fur Beziehungen zwischen Klassen

Zu den Klassen k6nnen dariiber hinaus Bedingungen (sogenannte Con­straints) angegeben werden, die die Menge der zulassigen Objekte ein­schrankt. Diese Bedingungen konnen grundsatzlich in jeder beliebigen Spra­che formuliert werden. Es bietet sich zu diesem Zweck allerdings speziell dieobjektorientierte Modellierungssprache OCL (Object Constraint Language)an.

188 5. Unternehmensmodellierung

5.4.7.4 Zustandsdiagramme

Zustandsdiagramme (State Charts) sind eine gebrauchliche Technik zur Be­schreibung des dynamischen Verhaltens von Systemen. Sie weisen eine gewisseVerwandschaft zu Petri-Netzen auf. Zustande werden hier durch abgerundeteRechtecke , Zustandsiibergange durch Pfeile dargestellt . Zustandsiibergangewerden optional hinsichtlich drei Aspekten beschrieben (A usliisendes Ereignis[BedingungJ/ Aktion).

Mittels dieser Diagramme k6nnen somit fiir einzelne Objekte, z.B. dasObjekt Problemfall, verschiedene Zustande angegeben werden . Die Zustands­iibergange ergeben sich dabei aus der Erfiillung von im Modell spezifiziertenBedingungen; ist z.B. die Bedingung [Problem ist auf der ersten Ebene losbar]durch ein entsprechendes Ereignis erfiillt, so andert das Objekt Problemfallseinen Zustand zu "L6sung wird erklart", Die Zustandsiibergange konnendabei aueh objektiibergreifend, d.h. systemweit, spezifiziert werden .

5.4.7.5 Sequenz- und Kollaborationsdiagramme

Analog zur Verfeinerung der Klassendiagramme im EntwicklungsprozeB las­sen sich auch Aktivitatsdiagramme schrittweise in implementierungsnahe Mo­delle iiberfiihren, Hierzu dienen Sequenz- (Sequence Diagrams) und Kolla­borationsdiagramme (Collaboration Diagrams) , mit denen das dynamischeVerhalten von Objekten abgebildet werden kann .

Bei den Sequenzdiagrammen wird der KontrollfluB hervorgehoben. Diebeteiligten Objekte werden wiederum als Reehtecke dargestellt . Der Nach­richtenaustausch zwischen den Objekten wird durch Pfeile angezeigt , die mitden entsprechenden Methodennamen beschriftet sind .

In einem K ollaborationsdiagramm werden die gleichen Informationen wiein Sequenzdiagrammen modelliert, allerdings werden hier weniger der Kon­trollfluB als die strukturellen Beziehungen dargestellt . Die zeitliche Abfolgeder einzelnen Methodenaufrufe wird dureh eine Numerierung der Pfeile ab­gebildet.

5.4.7.6 Komponenten- und Verteilungsdiagramme

Die Komponenten- (Component Diagrams) und Verteilungsdiagramme (De­ployment Diagrams) dienen der Modellierung der Implementierungsebene.Komponentendiagramme dokumentieren im wesentlichen die Architektur desSoftwaresystems, indem Abhangigkeiten innerhalb des Quellcodes beschrie­ben werden. Typische Komponenten k6nnen z.B. die Komponenten Daten­bank, Solver und CUl (Graphical User Interface) darstellen. Dureh eine geeig­nete Notation konnen hier Schnittstellen und damit verbundene Abhangig­keiten abgebildet werden.

5.5 Architektur Integrierter Informationssysteme (ARIS) 189

In einem Verteilungsdiagramm wird die Implementierung in einer verteil­ten Rechnerumgebung (z.B . Client-Server-Systeme) beschrieben. Ein sinnvol­ler Einsatzbereich eines Verteilungsdiagramms ist immer dann gegeben, wennVerteilungsaspekte im modellierten objektorientierten System eine Rolle spie­len. Beispielhaft k6nnen so die Objekte Server und Windows-PC, zwischendenen eine TCP/IP-Verbindung besteht, modelliert worden. Die Objekte ent­halten dabei verschiedene Komponenten sowie deren Schnittstellen.

5.5 Architektur Integrierter Informationssysteme(ARIS)

In den beiden folgenden Abschnitten wird das ARIS-Konzept zur Modellie­rung vorgestellt und dann auf unterschiedliche Werkzeuge und Schnittstellen,die ARIS anbietet, kurz eingegangen. Ziel des Konzeptes ist die Abbildung ei­ner strukturierten und ganzheitlichen Analyse der Informationsverarbeitungeines Unternehmens.

5.5.1 Das Geschaftsprozefsmodell

1m Abschnitt zu den Betrachtungsebenen der Unternehmensmodellierungwurde bereits das ARIS-Konzept mit den unterschiedlichen Sichten bzw.Ebenen angesprochen. Das Informationssystem eines Unternehmens wird hiernach den Phasen des Systementwicklungsprozesses und nach seinen wesentli­chen Komponenten (Betrachtungsebenen oder Sichten) strukturiert. Ortho­gonal zu den Sichten erfolgt eine Unterteilung in die drei Ebenen Fachkonzept,DV-Konzept und Implementierung, die sich durch die Nahe zur IT unter­scheiden (vgl. CIM-OSA Rahmenwerk). Wahrend auf der Fachkonzeptebenedie Beschreibung betriebswirtschaftlicher Inhalte erfolgt, findet im Rahmendes Entwicklungsprozesses eine Konkretisierung in der Begriffswelt der Infor­mationsvcrarbeitung bis hin zur Spezifikation der einzusetzenden Hard- undSoftwarekomponenten start; vgl. Bungert und HeB (1995).

Die Ebenen (bzw. Sichten) von ARIS sind die Organisations-, Daten-,Funktions- und Leistungssicht. Innerhalb der Sichten k6nnen unterschiedlicheModellierungsmethoden verwendet werden, wie sie im vorherigen Abschnittbesprochen wurden. ARIS erhebt dabei den Anspruch, daB sich neue Modell­typen leicht integrieren lassen. Die Datensicht umfaBt die Beschreibung derInformationsobjekte, deren Beziehungen und ihre betriebswirtschaftlich rele­vanten Zustande, die betriebliche Vorgange anstoBen bzw. deren Ergebnissesein k6nnen. Innerhalb der Funktionssicht lassen sich Funktionen definierenund hierarchisieren. Die Organisationssicht erfaBt die Aufbauorganisation, sodaB Organisationseinheiten mit ihren Beziehungen dargestellt werden kon­nen. Diose Sicht umfaBt auch die Computer-Hardware und Maschinenres­sourcen (vgl. Abb. 5.16).

190 5. Untcrnehmensmodellicrung

Organisationssicht

Lcistungssicbt

Abbildung 5.16. Sichten des ARIS-Hauses; nach Scheer (1998b) , S. 37

Verbindungen zwischen Elementen einzelner Sichten konnen innerhalb derSteuerungssicht modelliert werden. Mittels dieser Sicht lassen sich integrie­rende Modelle konzipieren. In diesem Zusammenhang konnen sogenannteereignisgesteuerte Proze13ketten (EPK) als Vorganger-Nachfolger-Graphendefiniert werden, wobei drei Arten von Knoten existieren: Ereignisse, Funk­tionen und logische Konnektoren (AND, OR , XOR). AIle Kanten verbin­den jeweils zwei Knoten unterschiedlichen Typs. Nur die logischen Konnek­toren verzweigen, sie verbinden Ereignisse mit Funktionen und umgekehrt.Sofern aIle Eingange und aIle Ausgange eines jeden logischen Konnektorsentweder vom Typ Ereignis oder vom Typ Funktion und aIle Endknoten derEPK Ereignisse sind, lassen sich EPK (automatisiert) in Petri-Netze bzw. an­dere Modellierungssprachen und sogar in ausfiihrbare Programme iibersetzen(Workflow-Anwendungen), da sie eine mathematisch exakte Semantik besit­zen (vgl. Langner et al. (1997), S. 479 ff.).

EPK lassen sich zudem in objektorientierte Modelle iiberfiihren (vgl. Bun­gert und He13 (1995), S. 58 ff.). Informationsobjekten (aus ARIS) wird da­bei die Rolle von Klassen zugeordnet. Sie erhalten Methoden, Attribute undeine Liste von Ereignissen, die aufgrund des Eintretens bestimmter Status-

5.5 Architektur Integrierter Informationssysteme (ARIS) 191

werte eintreten. Des weiteren werden sie mit einer Liste von Funktionen derFunktionssicht und mit auslosenden bzw. von ihnen ausgelosten Ereignissenverkniipft. Die Zuordnungen werden in einem Klassendiagramm des Infor­mationsobjekts spezifiziert. Ein Triggermechanismus bildet den Nachrichten­austausch zwischen den Objekten abo

Urn einen vollstandigen Geschaftsprozef unter Einbeziehung der Objekteder Organisations- und Leistungssicht zu erstellen, stehen die erweitertenEPK (eEPK) zur Verfiigung. Zusatzlich kann mit ProzeBwegweisern auf vor­und nachgelagerte Prozesse hingewiesen werden. Zur Implementierung wer­den statt der ProzeBmodelle, die bevorzugt auf der Fachkonzeptebene ein­gesetzt werden, oftmals sogenannte Business-Objekte verwendet. Diese be­schreiben ebenfalls vollstandige Geschaftsprozesse. Sie enthalten mehrere Ob­jekte (auf Basis des objektorientierten Ansatzes) einschlieBlich der Leistungs-,Organisations- und Kontrollfliisse . Die einem Business-Objekt zugeordne­ten Daten und Methoden werden mit einem ProzeBmodell verbunden, urndie interne Ablaufsteuerung zu definieren. Eine Anwendung besteht dannaus mehreren Business-Objekten, die wiederum von einem dafiir definiertenGeschaftsprozef gesteuert werden (vgl. Scheer (1998a), S. 171 ff.).

5.5.2 Schnittstellen und Anwendung

An dieser Stelle greifen wir erneut die Forderungen an Unternehmensmodellevon Taylor auf. Das ARIS-Framework soll es dem Benutzer ermoglichen,mit den Modellen auf vier verschiedenen Ebenen zu arbeiten (vgl. Abb .5.17). Auf der ersten Ebene (ProzeBoptimierung) werden Prozesse beschrie­ben, urn dann per Simulation oder Vergleich mit Referenzmodellen verbes­sert zu werden . Die ersten beiden Forderungen (Darstellung und Simulation)werden damit errnoglicht. Die zweite Ebene beinhaltet die ProzeBplanungund stellt Werkzeuge zur Kostenanalyse, Zeit- und Kapazitatsplanung zurVerfiigung. Hier wird auch ein Monitoring der aktuell laufenden Prozesseerrnoglicht. Die dritte Ebene stellt die Workflowsteuerung dar und transpor­tiert die Inforrnationsobjekte durch die modellierten Informationsfliisse (bzw.Wertschopfungsketten) und liefert Ist-Daten an die zweite Ebene. Auf dervierten Ebene werden schlieBlich die im Modell spezifizierten Anwendungs­programme am konkreten Arbeitsplatz aufgerufen; vgl. Scheer et al. (1997).

Das ARIS-Framework enthalt eine Sammlung von Komponenten, die sichzu einem konkreten Anwendungsfall zusammensetzen lassen. Dazu werdenzunachst Business-Objekte verkniipft und urn Infrastrukturkomponenten,wie Workflow-Systeme, Modellierungs-Werkzeuge und Middleware, erganzt.Middleware bezeichnet Software, die zwischen Anwendung und Betriebssy­stem bzw. zwischen verteilten Anwendungen steht und diese miteinanderverkniipft. Die Komposition von entsprechenden Anwendungen basiert somitauf austauschbaren Komponenten; zur komponentenbasierten Softwareent­wicklung vgl. z.B. Griffel (1998) sowie Pree (1997).

192 5. Unternehmensmodellierung

I. Prozel3optimierung IModclli crung, IISimu latio n

IAna lyse,Navization

T kontinuierliche Prozellvc rbcssc rung 1 11II. Prozel3management I Cont rolli ng IIMonitoring II Kapazitats-

I(-syste me) und Zeit -

steucrunu

11III. Workflow I Real isierung der Funktionsaufrufe ,

Ides Dokumcntenflusses und derDatenaufru fe

1'1IV. Bcarbcitung (A RIS Iwei tere Bausteine( Sta ndardsoftwarc- II Datenbank

Imod ule und Schnittstellen zuBusincss-Objcktc) Standardso ftware)

A b bildung 5. 17. Prozel3management im ARIS-Framework; nach Scheer (1998b) ,S. 56 f.

Auf der Ebene II (vgL Abb . 5.17) besteht z.B. die M6glichkeit , Pro­jektpliine in Microsoft P roject zu laden . Neben dem ARIS-Workflow, dasaus einem GeschiiftsprozeBmodell ein lauffahiges Anwendungssystem erzeugt,existieren weitere (standardisierte) Schnittstellen zu alternativen Workflow­Systemen. Auf der untersten Ebene k6nnen Business-Objekte z.B. mittels Re­mote Function Calls (RFC) und Business Application Programming Interfa­ces (BAPI) , die Methoden der Business-Objekte darstellen, konfiguriert wer­den; vgL SAP AG (1996). Uber Datenmodelle werden Attribute hinzugefiigtoder unterdriickt, Maskenmodelle bestimmen die Priisentation, Funktionenlassen sich iiber Funktionsmodelle auswahlen, und aus Organigrammen wer­den Datenrechte eingestellt. ProzeBmodelle konfigurieren die Zuordnung zwi­schen Funktionen und Modulen und steuern den Ablauf innerhalb und zwi­schen den Business-Objekten. Auf dieser Ebene existieren zusiitzlich Schnitt­ste llen zu relationalen Datenbanksystemen und Client-Server-Systemen.

Hier ist wiederum krit isch anzumerken, daB auch im ARIS-Frameworkvon einer einfachen, durchgiingigen Nutzung der Modelle bis zur Anwendungderzeit nicht die Rede sein kann. Hier sind auf den einzelnen Ebenen Modi­fikationen und Erweiterungen notwendig, die eine Systementwicklung zwarerleichtern, aber nicht automatisieren. Insbesondere der Forderung nach au­tomatischer Anpassung der Applikationen nach Modifikation eines Modellskann mittels ARIS nur bedingt nachgekommen werden.

5.6 Referenzmodelle 193

5.6 Referenzmodelle

Unter einem Referenzmodell versteht man konkrete, aber vom Unternehmens­einzelfall abstrahierte Modelle zur Darstellung von technischen oder be­triebswirtschaftlichen Fachinhalten beziiglich der Strukturen und Abliiufe.25

Bekannte betriebswirtschaftliche Unternehmensmodelle, die auch Referenz­modelle darstellen, sind z.B. das externe und das interne Rechnungswe­sen, das von Gutenberg (1983) entwickelte System der Produktionsfaktorenund die im Rahmen des Operations Research entwickelten Unternehmensge­samtmodelle zur Darstellung funktionsiibergreifender Entscheidungszusam­menhange; vgl. hierzu Scheer (1990a).

Referenzmodelle werden eingesetzt, weil die Modellierung komplexer Sy­sterne mit Ausgangspunkt "Null" mit einem hohen Aufwand sowie einer ver­gleichsweise hohen Fehlerwahrscheinlichkeit verbunden ist . Referenzmodelleerlauben einerseits, durch Spezialisierung und Umgestaltung unter Wieder­verwendung der Strukturen und Elemente ein Anwendungsmodell fiir einreales Objekt (ein Unternehmen) zu konzipieren, andererseits kann die Tat­sache , daB das Referenzmodell einen Idealzustand widerspiegeln soll, dazugenutzt werden, einen Vergleich mit dem realen Objekt durchzufiihren undAbweichungen festzustellen. Abweichungen konnen dann die Grundlage fiirEntscheidungen iiber organisatorische Veranderung sein. 26

Insbesondere Branchenmodelle bilden dariiber hinaus eine Grundlage fiirdie Entwicklung betriebswirtschaftlicher Standardsoftware. Je mehr ProzeB­und Strukturvarianten in einem entsprechenden Referenzmodell beriicksich­tigt werden , desto eher konnen resultierende Softwarepakete allein durchKonfiguration zur Abbildung und Unterstiitzung quasi individueller Ge­schaftsprozesse eingesetzt werden; vgl. Keil und Lang (1998) .

Ziel des Projektes CIM-OSA ist z.B. die Erstellung eines Referenzmo­dells fiir CIM-Systeme. Referenzmodelle dienen hier als generisches Ausgangs­modell fiir eine unternehmensindividuelle Modellierung. Die Architektur be­schreibt ein generisches Ausgangsmodell, ein partielles Modell , das z.B. bran­chenspezifisch sein kann, und ein individuelles Modell , das schlieBlich ein be­stimmtes Unternehrnen beziiglich seiner betriebswirtschaftlichen Fachinhalteabbildet.

Folgende Referenzmodelle sollen kurz vorgestellt werden, urn die Entwick­lung bzw. Schwerpunkte in dieser Form der Modellierung zu verdeutlichen:

25 Fiir eine aktuelle Ubersicht zu Referenzmodellen wird auf die Beitrage in Beckeret al. (1999) verwiesen.

26 Ein einfaches Praxisbeispiel findet sich bei Aichele et al. (1994) . 1m Rahmendes Benchmarking diskutieren Homburg und Eichin (1998) Moglichkeiten, ag­gregierte ProzeBanalysen zur Bewertung ahnlicher Prozesse ohne detaillierte, ko­stenintensive ProzeBanalysen durchzufiihren. Die Idee ist hierbei, virtuelle Pro­zesse als Linearkombinationen der beobachteten ProzeBstrukturen einzufiihren,die Aufschluf iiber ihren Grad der Ineffizienz in bezug zu guten Prozetllosungengeben konnen.

194 5. Unternehmensmodellierung

• Kolner Integrationsmodell von Grochla (1974)• Unternehmensdatenmodell von Scheer• Integrationsmodell von Becker• Referenzmodelle im Rahmen von ARIS

Das Kolner Integrationsmodell (KIM) (Grochla (1974)) wurde mit demZiel entwickelt, die Integrationsprobleme beziiglich der DV durch ein Be­schreibungsmodell zu reduzieren, indem die sachlogischen Verkniipfungenzwischen unterschiedlichen Unternehmensaufgaben verdeutlicht werden. DieDarstellung der in einem Unternehmen durch die DV unterstiitzbaren Aufga­ben und der dazugehorigen Inforrnationsstrorne erfolgt weitestgehend in einerfunktionsorientierten Beschreibungssprache.

Irn Gegensatz zum CIM-OSA Konzept oder dem ARIS-Sichtenkonzepterfolgt hier eine Aufteilung des Gesamtmodells in Planungs-, Realisierungs­und Kontrollaufgaben. Ziel ist die Reduktion der Kompliziertheit entspre­chender Gesamtmodelle. Die Teilmodelle bestehen aus einer

• Aufgabenbeschreibungsliste (Nummer / Benennung / Inhalt (stichwortar­tig) ),

• Kanalbeschreibungsliste (Nummer / benotigte Daten zur Erfiillung derAufgaben) und

• Konnektorenbeschreibungsliste.

Die Nummern der Aufgabenbeschreibungsliste geben die Positionen in dergraphischen Darstellung (gerichtctcr Graph) an , wobei Aufgaben als Recht­ecke und Daten als abgerundete Rechtecke graphisch dargestellt werden. DieNummern der Kanale sind Kanten zugeordnet. Uber die Nummer konnenin der Kanalbeschreibungsliste die zur Bewiiltigung der im Graphen nachge­lagerten Aufgabe benotigten Daten abgelesen werden. Der Konnektorenbe­schreibungsliste ist zu entnehmen, zu welcher Aufgabe erzeugte Daten flieBen.

Das Ziel des Unternehmensdatenmodells von Scheer (1990b) bestehtdarin, Datenverflechtungen innerhalb eines Unternehmens iiber die Abtei­lungs- und Anwendungsebene hinweg aufzuzeigen; vgl. auch Scheer (1990a).Die Datenintegration, wie sie oben vorgestellt wurde , stellte eines der wesent­lichen Ziele dieses Modells dar. Die Darstellung erfolgte als ER-Modell (Chen(1976)), wie sie fiir Datenmodelle iiblich ist. Das Datenmodell, das hier alsgenerisches Ausgangsmodell zu betrachten ist, umfaBt ca. 300 Entity- undBeziehungstypen. Ein solches Datenmodell ist auch Bestandteil des ARIS­Konzepts. Dieses Referenzmodell bildet aus dieser Betrachtungsweise herauseinen ersten Baustein fiir das umfassendere ARIS-Informationssystem.

Das Integrationsmodell von Becker (1991a) geht einen Schritt weiter undversucht neben den Integrationseffekten der Daten auf die Informationsbezie­hungen zwischen einzelnen Funktionsbereichen abzuzielen. Dies erfolgt iibereine Analyse der Datenbeziehungen jeweils von einem Funktionsbereich zuden vor- und nachgelagerten Bereichen . Das Modell basiert auf dem Y-CIM­Modell nach Scheer; vgl. Abb. 5.18.

5.6 Referenzmodelle 195

Finanz- Kos tenrechnungbuch- Personal-

haltung I J wirtschaft

Mitarbeiter-Zeiten

\ \ J IVertrieb Realisierungskennzeichen

Produkt-entwurf

Kal kulation

Prim r-bedarfs- Planmenge

Konstruk -planung tio n

Material- Planmengewirtschaft

Kapazit ts-Arbei ts-termi-

nierung planung

Kapazit ts-abgleich NC-,

Robote r-

Auftrags- Program-

freigabe mierung

Arbeitsg nge der Auftragsnummer, NC·, Roboter-Programm- NC-,

Fertig ung s-Fertigungsauf- Nummer, Betriebsmittel, Personal, Roboter-trget Betriebs- Teilenummer, Menge Steuerung

steuerung mittelbedingung

Tran sport-

Transportrnittel, Transporthilfsmittel, steuerungAuftragsnummer, Start,Ziel, Zeiten

Betriebsdaten-Lagerort, Teilenummer, Menge, Reservierungs- Lager-

erfassung Dummer, Auftragsnummer, Transporthilfs-steuerungmittel, Lagerungszeit

IMontageplarz, Teilenumrner, Auftrags- L

Kontrolle Dummer, Menge, Mitarbeiter, Zeiten Montage-

der steuerung

Mengen, Ist-DatenZeiten, (Auftrag. Personal, Artdeclnstandhaltung, Betricbsmittel,Koste n Maschinen, Proze ,

Personal, Zeiten, Instandhaltungstei le, Instand-lnstandhaltung)

Arbeitsg nge haltungSoll-Vorgaben(ausMaterialwirtschaft,

Versand-Fcrtigungssteuerung,Instandhaltung,

steuerung Qualit tssicherung) Fehlerschl ssel, Fehlerklassifikation, Quali tts-arbeitsgang- undteiJebezogcne Qualitts- sicherungdaten, Prfauftr ge, Prfarbcitsg nge

Abbildung 5.18. Das Integrat ionsmodell nach Becker (1991a)

196 5. Unternehmensmodellierung

In diesen drei Referenzmodellen werden die Erklarung der Aufgabenab­laufe sowie deren Bezug zu Daten und Funktionen in den verschiedenen Pro­zeBschritten nicht in ausreichendem MaBe erfaBt. KIM bildet den Aufgaben­ablauf im Sinne von Kontrollfliissen nicht ab, denn zur Verdeutlichung derfunktionsiibergreifenden Zusammenhiinge miissen Informations- und Aufga­benfluf explizit dargestellt werden .

Auch werden in diesen Modellen keine externen Informationsquellen ab­gebildet. Die Anwendbarkeit beschrankt sich somit weitestgehend auf reinrepetitive Aufgaben. Im ARIS-Konzept sind diese Quellen mit den Umfeldda­ten enthalten, und durch die unterschiedlichen Schnittstellen, die modelliertwerden konnen, sind auch Ablaufe, die nicht repetitiver Natur sind, model­lierbar.

Zur Unterstiitzung der Modellierung von Geschiiftsprozessen kann unterARIS auf bestehende Modelle , die aus Best Practice-Beispielen oder theo­retischen Uberlegungen abgeleitet sind , als AusgangslOsung zuriickgegriffenwerden . Referenzmodelle konnen nach dem ARIS-Konzept beschrieben undim ARIS-Toolset gespeichert werden.F Dies errnoglicht bei der Modellierung~.B . Modellvergleiche. ARIS unterstiitzt dabei die Referenzmodelltypen Vor­gehensmodell, Branchenmodell und Softwarernodell, die auch zur Gestaltungvon Workflow-Systemen eingesetzt werden konnen; vgl. Scheer (1999).

Das bekannteste Referenzmodell im ARIS-Konzept stellt der SAP R/3Analyzer dar, der aus dem ARIS-Navigator und dem R/3 Referenzmodellbesteht. Uber die Schnittstelle ARIS Link for R/3 konnen R/3-Modelle ausdem Repository in das sogenannte ARIS-Toolset geladen, geiindert und er­neut dem R/3 Repository iibergeben werden .

5.7 Beispiel: Simulation des Help Desks

Das Informationsmanagement hat sich explizit mit Moglichkeiten der orga­nisatorischen Veriinderung durch den gezielten Einsatz der IT zu befassen.Urn Veriinderungen zu planen und transparent zu machen, sind Unterneh­mensmodelle, die mogliche Veranderungen nachzeichnen, von wesentlicherBedeutung. Zur Bewertung von entsprechenden MaBnahmen sind dariiberhinaus weitergehende Analysen notwendig. In diesem Abschnitt soil dies­beziiglich der Ablauf einer Simulationsstudie anhand des Beispiels des HelpDesks dargestellt werden. Es solI hier exemplarisch aufzeigt werden, wie mananhand des Modells Experimente durchfiihren kann , urn zu Erkenntnisseniiber mogliche organisatorische Veriinderungen zu gelangen.

Simulationsstudien weisen in vielen Phasen deutliche Ahnlichkeiten zutraditionellen Softwareprojekten auf, die hier aber nicht weiter angesprochen

27 Hierzu dient die als ARIS-Repository bezeichnete Datenbank. Die Miichtigkeitder darstellbaren Modelle wird dabei durch die im ARIS -Meta-Modell spezifi­zierten Beschreibungskonstrukte begrenzt. Diese sind in der neuesten Versionmit der UML einheitlich dargestellt.

5.7 Beispiel : Simulation des Help Desks 197

werden. Fiir den Ablauf von Simulationsstudien gibt es - ahnlich wie fiirSoftware Engineering-Projekte - sogenannte Vorgehensmodelle.r" 1m erstenSchritt ist abzuschatzen, ob das Problem "simulationswiirdig" ist , denn nurwenn sich mit analytischen Methoden keine befriedigenden Antworten fin­den lassen , die Systernkomplexitat sich als zu groB erweist und das gesamteProjektvolumen eine Simulationsstudie rechtfertigt, sollte simuliert werden.

Zur Abschatzung der Simulationswiirdigkeit eines Problems gehort aucheine Wirtschaftlichkeitsbetrachtung. Die (veroffentlichte) Erfahrung zeigt ,daf sich Simulation im wirtschaftlichen Sinne haufig lohnt. Der Verein Deut­scher Ingenieure gibt ein Kosten-Nutzen-Verhaltnis von 1:6 an. Dabei handeltes sich natiirlich nur urn eine Faustregel. Leider ist es im Vorfeld von Simu­lationsprojekten ahnlich wie im Vorfeld vieler anderer EDV-Projekte: DieKosten lassen sich relativ gut beziffern, aber iiber den Nutzen bestehen eherunprazise Vorstellungen. Bei Simulationsstudien zur Planungsunterstiitzungware es auch regelrecht kurios , wenn sich der Nutzen von vornherein spezi­fizieren lieBe. SchlieBlich dient die Simulation nicht zuletzt dazu , Planungs­fehler aufzudecken. Wenn diese schon vor der Studie bekannt sind , lassen siesich auch ohne Simulation abstellen (vgl. Informationsparadoxon).

Ahnlich wie bei Softwareprojekten wird in Simulationsstudien das Sy­stemverhalten zunachst in einer Modellierungsgrundlage, der Modellbeschrei­bung, zusammengefaBt. Diese Beschreibung kann und sollte, sofern vorh an­den, auf bestehenden Modellen aufsetzen. Sie erlautert den Modellumfang(was soli modelliert werden) , die Modellgrenzen (was soli nicht modelliertwerd en - und das ist mindestens genauso wichtig), dokumentiert aile reievan­ten Steuerungsregeln und stellt die fiir das Modell notwendigen Eingangsda­ten zusammen. In einer solchen Modellbeschreibung sind idealerweise auchaile Prozesse detailliert beschrieben.

Ein ProzeB stellt im Help Desk-Beispiel die vollstandige Bearbeitung einesKundenproblems dar , wie wir ihn bereits im Abschnitt zur UML als Akti­vitatsdiagramm vorgestellt hab en (vgl. Abb. 5.13, S. 185). Diese Darstellungist (in der Modellbeschreibung) st atisch, d .h. es konnen keine Aussagen iiberdas Systemverhalten gemacht werden. Hierfiir sind weitere Einfluflgroflen zubetrachten. Zunachst miissen die einzelnen Funktionen mit Bearbeitungszei­ten versehen werden . Wir unterstellen hier eine Dreiecksverteilung. Die rele-

28 Einfache Vorgehensmodelle sind z.B. das Wasserfallmodell, das Wasserfallmodellmit Riickschleifen od er das V-Modell nach Boehm (1979) . In diesen Modellenwerden Ld.R. die Phasen der Analyse, des Entwurfs (Des igns) , der Implemen­tieru ng sowie der Tests unterschieden ; zu einer Einfiihrung und Ubersicht wirdauf Pagel und Six (1994) sowie Sommerville (1996) verwiesen . Ausgehend vondem einfachen V-Modell wurde ein Modell zur Standard isierung der Software­Entwicklung fur die Bundeswehr und Behorden (vgl. Brohl und Dros chel (1995))und hierauf aufbauend das V-Modell 97 zur Planung und Durchfiihrung von IT­Projekten ent wickelt, das einen Rahmen zur Softwareentwicklung vorgibt ; vgl.Droschel et al. (1997) . Ein e Erweiterung des V-Modells zur durchgangigen Qu a­litatssicherung der Softwar eentwicklung von Steuerungssystemen in der Logistikrnittels Simulation wird von Gutenschwager et al. (2000) vorgestellt .

198 5. Unternehmensmodellierung

vanten Parameter der Verteilung konnen Tab. 5.4 entnommen werden. DieseZeiten enstehen primar durch Beschaffung und Auswertung der Daten (dieebenfalls als Funktionsfolgen modelliert werden konnen) .

Funktion Organisations- Dauereinheit (Ebene) min mittel max

Aufnahme Kundendaten 1. Ebene 20 22 25Aufnahme Problem 1. Ebene 20 150 500Losung erklaren Ebene 1 1. Ebene 120 240 800Anruf an Kundenberater weiterleiten 1. Ebene 20 22 25genaue Aufnahme Problem 2. Ebene 240 400 1200Problem in Datenbank aufnehmen 2. Ebene 80 120 300Problem an Experten weiterreichen 2. Ebene 240 500 1500Losung erstellen 3. Ebene 360 800 3600Losung an Kundenberater melden 3. Ebene 120 380 800Losung in Datenbank aufnehmen 2. Ebene 200 220 300Kundenkontakt aufnehmen 2. Ebene 20 80 300Losung erklaren Ebene 2 2. Ebene 200 300 490

Tabelle 5.4. Bearbeitungszeiten der Funktionen (gemessen in Sekunden)

Fur die Simulation sind zusatzlich fur alle ProzeBverzweigungen Wahr ­scheinlichkeitsverteilungen anzugeben und die Zahl und Verteilung der Kun­denanfragen fiir den zu simulierenden Zeitraum zu spezifizieren. Nachdem mitder Modellbeschreibung die Grundlage fiir die Implementierung des Modellsvorliegt, kann mit einer Simulationsumgebung (Simulator, Simulationswerk­zeug) mit der eigentlichen Modellerstellung begonnen werden. Auf Basis derEingangsdaten kann nach der Implementierung und einer 'Icstphase-? be­gonnen werden, Experimente mit dem Modell durchzufiihren. Die folgendenFragestellungen der ProzeBsimulation konnen z.B. betrachtet werden :

• Wieviele Personen sind auf den jeweiligen Ebenen einzusetzen, urn alleKundenprobleme innerhalb eines bestimmten Zeitrahmens bearbeiten zukonnen?

• Wie sind die Personen einzusetzen (Aufbauorganisation)?• Was bringt z.B. eine Umstellung von Schriftstiicken / Handbiichern auf

Hypertexte?• Lohnt es sieh, ein Expertensystem zu erstellen , urn die Experten aus den

Fachabteilungen zu entlasten?• Ubergeordnetes Ziel: Welche Umstellungen bergen das groBte Verbesse­

rungspotential?

29 Neben reinen Implementierungsfehlern sind vor allem die Systemlogik, der Auf­bau und die Ablaufe zu priifen, bevor aufwendige Experimente und Auswertun­gen durchgefiihrt werden.

5.7 Beispiel : Simulation des Help Desks 199

Ein ProzeB wird als Objekt dargestellt, das sich aus einzelnen Unterob­jekten (Funktionen) zusammensetzt (vgl. Abb . 5.19). Besitzt einc Funktionmehr als eine Nachfolgefunktion, so sind innerhalb des Prozesses Wahrschein­lichkeiten anzugeben, mit denen die jeweiligen Folgefunktionen eintreten.

Testa utbauf-Il:I--:l-H -f--H-f--H If-":fJ'4-I-l--t-I-l--t-H 2lJU.lLULlJU.lLULULL-!-l-J3

_Iol x'

Statistik

Mltttere Wal1ez9rten

Grolle Wartesc;tjange2 10 0

DODAusJaslung der Ebenen

Ill:l eYeI 2rdlhfll lrdl8'¥el

o ~ 0

li D

[Problem dueld I~sbar ]

An:S~II.nden~..e

linlJ~oSllIderNI-1 0

Ano,LNr,...,.-67

M

-Abbildung 5.19. SiMPLE++-Modell des Help Desks

Im Simulationsexperiment durchlaufen Instanzen des Prozesses (model­liert als bewegliche Objekte) den ProzeB einmal. Sie beanspruchen fiir jedeFunktion jeweils einen Mitarbeiter (Objekt) der entsprechenden Organisa­tionseinheit . So k6nnen Warteschlangen (von ProzeBinstanzen) an den Or­ganisationseinheiten entstehen. Daten werden in diesem Modell nur implizit

200 5. Unternehme nsmo dellierung

Experiment 11. Ebenc 2. Eb ene 3. Ebene

Anz ahl Mitarbeit er 3 8 7Auslastung 37% 44% 24%Durchschni ttliche Wartezeit 0 248 0

Experunent 2

Experime nt 3

1. Eb ene 2. Eb ene 3. Eb eneAnzahl Mit arbeit er 1 10 7Auslastung 99% 28% 18%Durchschni ttliche Wartezeit 652 193 0

,

1. Ebene 2. Ebene 3. Eb eneAnzahl Mitarbeit er 2 10 7Auslastung 52'10 34% 24'70Durchschnittliche Wartezeit 0 186 0

Tabelle 5.5. Ergebnisse der Simulat ionsexperimente 1 - 3

(uber Bearbeitungszeit en der Funk tioncn) abgebildet . Abb. 5.19 konnen auchalle Funktionen zur Auswertung entnommen werden.

Ziel der Simulationsexperimente ist in einern erste n Schritt die Bestirn­mung der Anzahl einzusetzender Personen, so daf diese relativ hoch ausge­lastet sind, aber keine "zu" hohen Wartezeiten fur Kunden ent stehen.

Typischerweise beginnt mit der Phase des Exp erimentierens eine "Opti­mierungsschleife". Planer und / oder Sirnulant begutachten die Ergebnisse,leiten mogliche Verb esserungen des Modells (und damit zugleich der Aufbau­oder Ablauforganisation) ab, bauen sic in das Modell ein und experimentierenerneut .i'"

Anhand der ersten Exp erimente (vgl. Tab . 5.5) kann man im Beispiel er­kennen, daB, obwohl aIle Bereiche relativ schwach ausgelaste t sind , immernoch Wartezeiten bei den Kundenbetreuern ents tehen (gemessen in Sekun­den) . Zudem ist eine relativ hohe Beanspruchung der Experten der drittenEbene zu verzeichnen . Die Ursachen liegen vor allem in der exakten Zu­ordnung von Kundenberatcr zu Kunden, d.h, ein Kunde wird immer demgleichen Berater zugewiesen. Zudcm miissen die Kundenberater ca. 40% derProbleme von Exp erten losen lassen.

30 Mit Hilfe von Met hoden des Operations Research lassen sich Teilaufgab en inder Phase des Exp erimentierens gegcbcnenfalls effizienter losen : Das Simula­tionsm odell bewer tet wie gehabt die Losung en ; anschlieBend wird regelbasiertdie Losung verandert, die dann erneut vom Simulator bewertet wird , wiedermodifiziert werd en kann und so fort. Diese "Automatisierung" der simulations­gest iitzten Losungsoptimierung ist auf qu antitative Veranderungen beschrankt .Qu alit ative Anderungen bleib en im wesentlichen dem Pl an er od er kiinftig viel­leicht ents prechenden Expertensystemen vorbehalten .

5.7 Beispiel : Simulation des Help Desks 201

Experiment 41. Eb ene 2. Ebene 3. Ebene

Anzahl Mit arbeiter 2 10 7Ausl astung 52'70 38'70 21'70Durchschnittliche Wartezeit 0 72 0

Expenment 51. Ebene 2. Eb ene 3. Ebene

Anz ahl Mitarbeit er 2 8 7Auslastung 54'70 46'70 24'70Durchschnittliche Wartezeit 0 72 0

Expenment 61. Ebene 2. Ebene 3. Eb ene

Anzahl Mitarbeit er 2 5 7Auslastung 53'70 76'70 24'70Durchschnittliche Wartezeit 0 132 0

Expenment 71. Eb ene 2. Eb ene 3. Eb ene

Anz ahl Mitarbeit er 2 3 7Auslastung 53'70 84'70 24'70Durchschnittli che Wartezeit 0 1941 0

Tabelle 5.6. Er gebni sse der Simulationsexper imente 4 - 7

Es soli nun exemplarisch vorgeste llt werden, wie man Alternativen iiber­priifen kann . Eine Moglichkeit zur Reorganisation des Help Desks ist , jedenKundenberater fur aIle Kunden einzusetzen (Prozefiveranderung - ProzeB2), urn somit eine hohere Auswahl m6glicher Bet reuer zu erhalten. DieseAltern ative ist gegen den Vorteil des direkt en Kontakts zum Kunden ab­zuwagen. Voraussetzung ist die Schulung der Kundenbetreuer (wenn sich dieErst-Zuordnung der Kunden am Produkt oder einer Produktgruppe orien­tiert) . Im Experiment 4 wird der ProzeB 2 bei gleicher Anzahl Mitarbeiterpro Bereich wie in Experiment 3 betrachtet . Das Ergebnis ist in Tab . 5.6 dar­gestellt . Durch die Prozefiveranderung konnte die durchschnittliche Wartezeitauf der zweiten Eb ene von 186 auf 72 Sekunden gesenkt werden. Als weitererBetrachtungsgegenstand bietet sich nun eine Verringerung der Anzahl dereingesetzten Kundenbetreuer an.

Das Ergebni s des Experiments 5 zeigt trotz Verringerung urn zwei Mit­arbeiter auf der zweiten Ebene keine Auswirkung auf die durchschnittli­che Wartezeit . Eine genauere Analyse ergibt, daB die War tezeiten dadurchents tehen, daB der Exp erte sein Ergebnis an denselben Kundenbetreuerzuriickgeben muB. Dem Kundenbetreuer werden aber unter Urnstanden be­reits neue Auftrage zugewiesen. Eine Verringerung auf drei Mitarbeiter ergibteinen EngpaB auf der zweiten Ebene, der durch Wartezeit en von 1940 Sekun­den gekennzeichnet ist . Beim Einsatz von fiinf Mitarbeite rn ergibt sich eine

202 5. Unternehmensmodellierung

Experiment 81. Ebene 2. Eb ene 3. Ebene

Anzahl Mitarbeiter 2 5 7Auslastung 52% 68% 13%Durchschnittliche Wartezeit 0 32 0

Tabelle 5.7. Ergebnisse des Simulationsexperiments 8

relativ hohe Auslastung von 76% auf der zweiten Ebene, wahrend die War­tezeiten bei durchschnittlich 132 Sekunden liegen.

Im Vergleich zur ersten Alternative (ProzeB 1) konnte durch die Umst el­lung der Zuordnung von Kunden zu Beratern die Anzahl der Kundenbetreuerhalbi ert , die Auslastung der Kundenbetreuer mehr als verdoppelt und diedurchschnittliche Wartezeit auf der zweiten Ebene um 33% verringert wer­den. Das Einsparungspotential ist gegen die Kosten der Schulun gsmaBnah­men abzuwagen, unter Beriicksichtigung des moglichen Nachteils im Bereichder Kundenbetreuung.

Das zweite Problem, das ebenfalls kurz betrachtet werden soll, ist diehohe Auslastung der Exp erten. Eine Alternative ware, ein Exp ertensystemeinzufiihren, so daB die Kundenberater auf mehr Wissen direkten Zugriffbekommen und die Experten weniger haufig konsultieren miissen . Im Mo­dell lieBe sich diese MaBnahme durch die Annahme, daB Bur noch 20% derProbleme vom Kundenbetreuer an den Experten weitergereicht werden, ab­bilden und auf ihre Auswirkung hin analysieren. In der Tab . 5.7 ist ein er­stes Ergebnis dargest ellt . Wie erwartet ist die Auslastung auf der drittenEbene gesunken. Gleichzeitig ist auch die Auslastung auf der zweiten Ebenezuriickgegangen, was auf dem Wegfall des Koordinationsaufwands zwischenden Eb enen beruht. Es kann nun weiter untersucht werden, ob die Anzahlder Mitarbeiter erneut reduziert werden kann.

Nach Abschluf der Experimente erfolgt die Dokum entation der Ergeb­nisse der Simulationsexperimente und die Dokumentation des Modells undder dort hinterlegten Strategien und Regeln selbst. Es bleibt anzumerken,daB die Ergebnisse der Simulation stet s durch st atistische Methoden (z.B.Konfidenzintervalle) abgesichert werden sollten. Dies bedeutet u.a. , daB dieAnzahl Exp erimente pro Par ameter-Konstellation hoch genug liegen muB, umzu nutzbaren Aussagen (iiber Durchschnittsbetrachtungen) zu gelangen. Zu­dem ist die Datenerhebung, gerade wenn menschliche Arb eit abgebildet wird ,sehr schwierig , und es sollten im vorliegenden Beispiel auf jeden Fall Sensi­tivitatsanalysen durchgefiihrt werden, um Giiltigkeitsbereiche der erzieltenErgebni sse bewerten zu konn en.