Zu dieser Arbeit
Die Aufgabenstellung dieser Vorleistung lautete ursprünglich
„Geschäftsprozessmodellierung mit UML“. Bei der Bearbeitung
des Themas ergab sich, dass die Bezeichnung
„Unternehmensmodellierung mit UML“ sinnvoller ist, da sonst
nur ein unverständlicher Ausschnitt des Themas beleuchtet
würde. (am unmissverständlichsten wäre der englische Titel
„Enterprise modeling with UML“[1])
Diese Arbeit stellt das Konzept einer objektorientierten
Modellierung von Unternehmen mit Hilfe des
Modellierungssprache UML (Unified Modeling Language) vor.
Dabei wird sowohl die informationstechnische Seite, wie auch
die rein organisatorische Sicht gewürdigt. Sinn und Zweck
dieser Modellierung ist die erfolgreiche Entwicklung von
Software und Modellen für die Unternehmensorganisation
durch objektorientierte Analyse und Design. Neu ist
insbesondere die rein organisatorische Konstruktion eines
Unternehmens und seiner Geschäftsprozesse.
Die Arbeit ist in Ihrem Ansatz theoretisch und holt teilweise
weiter aus, um auch Personen ohne Vorwissen in diesem
Thema die Möglichkeit zu geben, die angebotenen Lösungen
zu diskutieren. Dafür wird zunächst Modellierung allgemein
besprochen, die Prozessorientierung ausführlich dargestellt
sowie die Anwendbarkeit der Modellierung beispielhaft
verdeutlicht. Darauffolgend wird die Modellierungstechnik UML
beschrieben und Ihre Anwendbarkeit erläutert. Grafische
Beispiele sollen helfen, die Anforderungen an die
Praxisbezogenheit so gut wie möglich zu gewährleisten.
[...]
______
1 Enterprise Modeling with UML, Designing Succesful Software through Business Analysis, Chris Marshall, 1999, Addison Wesley
Inhaltsverzeichnis
1. Zu dieser Arbeit
2. Einführung
2.1 Case-Tools und Reengineering
3. Modellierungstechniken und Modellierungssprachen
3.1 Fachbegriffsdefinition Modell
3.2 Grundsätze ordnungsmäßiger Modellierung
3.3 Notwendigkeit einer Modellsprache
3.3.1 Anforderungen an die Modellierung
3.3.2 Modellierungsmethoden & Diagramme (Auswahl)
4. Prozessorientierung und Perspektiven für die Modellierung von Geschäftsprozessen
4.1 Nutzungsmöglichkeiten von Modellierungen
5. Aus Methodenstreit wird UML – Entwicklung einer Modellierungssprache
5.1 Notation und Metamodell
5.1.1. Klassendiagramm
5.1.2 Klassendiagramme (Schnittstellen, parametrisierte Klasse, Assoziationsklasse)
5.1.3 Use Case Diagram (Anwendungsfalldiagramm)
5.1.4 Activity Diagram (Aktivitätsdiagramm)
5.1.5 Statechart Diagram (Zustandsdiagramm)
5.1.6 Collaboration Diagram (Kollaborationsdiagramm)
5.1.7 Komponentendiagramm (Component Diagramm)
5.2 Alternativen zum Standard ?
5.3 Notationen ändern sich, aber die Konzepte bleiben
6. Business Engineering
6.1 Kennzeichen neugestalteter Unternehmen
6.2 Methodenüberblick Business Reengineering
Glossar
Ich verbürge, daß ich diese Arbeit ohne Inanspruchnahme von fremder Hilfe selber erstellt habe und nicht Inhalte anderer Arbeiten verwendet habe, ohne diese deutlich kenntlich gemacht zu haben.
Markus Bussmann 2001
1. Zu dieser Arbeit
Die Aufgabenstellung dieser Vorleistung lautete ursprünglich
„Geschäftsprozessmodellierung mit UML“. Bei der Bearbeitung des Themas ergab sich, dass die Bezeichnung
„Unternehmensmodellierung mit UML“ sinnvoller ist, da sonst nur ein unverständlicher Ausschnitt des Themas beleuchtet würde. (am unmissverständlichsten wäre der englische Titel
„Enterprise modeling with UML“[1])
Diese Arbeit stellt das Konzept einer objektorientierten Modellierung von Unternehmen mit Hilfe des Modellierungssprache UML (Unified Modeling Language) vor. Dabei wird sowohl die informationstechnische Seite, wie auch die rein organisatorische Sicht gewürdigt. Sinn und Zweck dieser Modellierung ist die erfolgreiche Entwicklung von Software und Modellen für die Unternehmensorganisation durch objektorientierte Analyse und Design. Neu ist insbesondere die rein organisatorische Konstruktion eines Unternehmens und seiner Geschäftsprozesse.
Die Arbeit ist in Ihrem Ansatz theoretisch und holt teilweise weiter aus, um auch Personen ohne Vorwissen in diesem Thema die Möglichkeit zu geben, die angebotenen Lösungen zu diskutieren. Dafür wird zunächst Modellierung allgemein besprochen, die Prozessorientierung ausführlich dargestellt sowie die Anwendbarkeit der Modellierung beispielhaft verdeutlicht. Darauffolgend wird die Modellierungstechnik UML beschrieben und Ihre Anwendbarkeit erläutert. Grafische Beispiele sollen helfen, die Anforderungen an die Praxisbezogenheit so gut wie möglich zu gewährleisten.
Auf der beigelegten CD findet sich die aktuellste Version der UML, das Buch „Enterprise Modeling with UML“ von Chris Marshall und zahlreiche XML und Java-Beispiele. Das Case- Tool Rational Rose liegt in einer Evaluationsversion ebenso vor. Im Anhang ist ein Glossar zu finden.
2. Einführung
“The pace of change in the modern world requires ways to manage the complexity of business systems while embracing the opportunities that are created by that change, in particular technological change. Systems thinking provides a framework for sophisticated business models, and object technology is the means by which they implemented across global networks.”
Chris Marshall [2]
Wie Chris Marshall schon ausführt, ist die komplexe Unternehmenswelt und die damit verbundenen Systeme heute nur mit anderen Mitteln und Methoden zu managen, als mit den bislang Ausreichenden. Dabei hebt er zunächst den Begriff
„Systemdenken hervor, der von Peter Senge Anfang der Neunziger Jahre in seinem bahnbrechenden Buch „Die fünfte Disziplin“ geprägt wurde. [3] Senge führt darin aus, daß mit Beginn des Handels unter Menschen die heute entstandene Komplexität dieses Tuns alles verändert. Heute braucht man eine Unternehmensstrategie, die für den Kunden Wert (Value Concept) schafft, die im globalen Wettbewerb bestehen kann und dazu die neuen technologische Opportunitäten sinnvoll zu nutzen weiß. Dabei haben nach Senge die Unternehmen den größten Überlebensvorteil, die mit Hilfe des Systemdenkens, dem ganzheitlichen Sehen von Ursache, Konsequenz und Aktivität, sich dauerhaft erneuern und selbst regenerieren, indem sie aus Ihren Fehlern lernen; Evolution betreiben.
Im professionellen IT-Bereich ist es mittlerweile usus, dass die geschäftlichen Notwendigkeiten (Business Needs) vorgeben, welche technologischen Lösungen eingesetzt werden sollen und nicht umgekehrt, der Bock zum Gärtner gemacht wird. Senge sagt des weiteren, dass unser erhöhtes Tempo und die Vielzahl falscher Entscheidungen in einem direkten Verhältnis steht mit der Unfähigkeit, die Welt (also auch das Unternehmen) als Ganzes zu überblicken. Viel Arbeit ging deshalb in den letzten Jahren in den Aufbau und das Layout von Datenbanken, das Design von Workflows und User- Interface-Design. So wichtig diese Arbeiten nach wie vor sind, so kurzfristig und kurzsichtig sind die Lösungen mit Hinblick auf die betrieblichen Notwendigkeiten.
Die Objekttechnologie, die zweite Entwicklung von der Marshall im einleitenden Zitat spricht, wurde benutzt, um komplexe Systeme zu konstruieren und wird seit kurzem für die Konstruktion von Geschäftsmodellen angewendet. Dazu kam die Modellierungstechnik Unified Modelling Language (UML) ins Spiel. Der Hauptzweck richtet sich auf eine Komplexitätsreduktion, um die Sicht auf die Umwelt und das Unternehmen als Ganzes fokussieren. Die Komplexitätsreduktion wird beispielsweise durch das modellieren von Rollen für Aktoren und Entitäten erreicht.UML integriert hier erstmals die Daten, Funktions- und Prozesssicht in ein Modell.
Gerade weil die UML seit 1997 als Industriestandard von der OMG verabschiedet wurde und in jeder Sicht für die objektorientierte Systementwicklung unabdingbar ist, muss sie auch für Betriebswirte von Interesse sein. Die UML ist eine der interessantesten Möglichkeiten, wie Geschäftsleute Ihre Anforderungen an Technologie- und Fachexperten kommunizieren können, um Informationstechnologie sinnvoll zu gestalten.
2.1 Case-Tools und Reengineering
Abbildung in dieser Leseprobe nicht enthalten
Objektorientierter Programmablaufplan 1
Schon seit rund 20 Jahren versuchen Entwickler, Software- Engineering effizienter und ökonomischer zu gestalten. Diese Bemühungen können bislang als Illusion in die Historie der
Programmierung eingehen, so bescheiden ist die Verwendung Ihrer Ergebnisse. Die hochtrabenden Konzepte, die damals mit CASE-Tools ausgeliefert wurden, funktionierten entweder nicht oder lieferten ein solche abstrakte Theorie mit, daß man sich erst gar nicht die Mühe machte, sie zu verstehen.
Dieser Versuch der Effizienzsteigerung bekommt nun seit Ende der 90er Jahre neuen Aufschwung, vorrangig durch die Model Driven Architecture der OMG (Object Management Group) und den neuen Standard der objektorientierten Entwicklungssprachen, der Modellierungssprache UML. Mit Ihr zusammen bekommt das Konzept des effizienten Entwurfes wieder Aufschwung und hat sich allgemein mit dem Verbreitungsgrad objektorientierter Sprachen (Java, C++, Visual Net, C#) als erste Wahl in der Softwareentwicklung und quasi Standard herausgebildet. Wer von den Vorteilen objektorientierter Entwicklung überzeugt ist, der sollte sich dieser natürlich auch versichern und bei der Analyse damit auch beginnen.
Abbildung in dieser Leseprobe nicht enthalten
Ojektorientierte Darstellungstechniken 1
Neben dieser Entwicklung machte auch die Organisationslehre in der Betriebswirtschaft in den letzten Jahren immer mehr Gebrauch von den Konzepten, wie man sie vor allem in der Softwareentwicklung findet. Dies wurde begünstigt durch das erneute Aufkommen (siehe Kap. Prozessorientierung) der prozessorientierten Unternehmenssicht, vor allem aufgetaucht durch Management – Konzepte wie Business Reengineering und den Gebrauch von Prozessen bei Zertifizierungen oder beim Implementieren von Standardsoftware wie SAP R/3.
Unterstützt wird diese Entwicklung der Wiederverwendung und Polymorphie, sowie der Vererbung aus technologischer Sicht durch folgende, neu eingeführte Standards:
- Standard-Kommunikations-Protokolle in Netzwerken (TCP-IP)
- CORBA, COM+ und EJB Komponenten machen interoperable Softwarekomponenten möglich
- Komponentendesign, Methoden und Konzept und Notationen können innerhalb des UML-Standards wiederverwendet werden
- Praktische E-Business Standards mit XML werden entwickelt
Die Zahl der Möglichkeiten einer Verwendung dieses Konzeptes ist von immenser Größe, diese Arbeit kann aber nur die Methodik vorstellen. Weitere Möglichkeiten wären bspw. die Einführung von Standardsoftware, das Betreiben von Workflowmanagement, die Planung von Wissensmanagement, IT- Infrastrukturplanung bei Firmenneu- /ausgründungen o.ä. und eben die Unterstützung von Reengineering-Maßnahmen im „Krisenfall“. Da gerade Reengineering von einem nicht zu unterschätzenden Teil von effizientem Einsatz / Entwicklung von Software abhängt, werden hier die Vorteile des UML – Standards deutlich.
Ein objektorientiert -modelliertes Unternehmen ist für Entwickler besser zu verstehen und zu unterstützen als dies bspw. eine ereignisorientierte Prozesskette (eEPK) kann, da sie die holistische Betrachtung und den Gebrauch von bereits erstelltem Material nicht unterstützt.
Es bleibt festzuhalten: UML ist der Industriestandard und sie muss für Betriebswirte von Interesse sein, wenn man seine Anforderungen an Technologie- und Fachexperten effektiv kommunizieren will. Aber genauso sollte deutlich werden, daß ein modelliertes Unternehmen nicht von selbst mehr Rendite bringt oder ein Softwareunternehmen damit günstiger entwickelt, zumindest nicht automatisch. Modelle können zum
Instrumente für Bürokraten werden (siehe ISO-Normen), aber sie unterstützen Kommunikation und Gesamtbetrachtung, um Entscheidungen zu treffen, die ein Unternehmen wertvoller machen können und Ihre Arbeit effizienter.
Die Arbeit erläutert im folgenden:
I. Darstellung von Modellierungstechnik und Modellsprachen
II. Erläuterung des prozessorientierten Unternehmens
III. Der Standard Unified Modeling Language
IV. Business Engineering
3. Modellierungstechniken und Modellierungssprachen
"Wir machen uns innere Scheinbilder oder Symbole der äußeren Gegenstände, und zwar machen wir sie von solcher Art, dass die denknotwendigen Folgen der Bilder stets wieder die Bilder seien von den naturnotwendigen Folgen der abgebildeten Gegenstände." H. Hertz
Die Festlegung der zu verwendenden Modellierungstechnik ist die grundsätzlichste und bezüglich Ihres Einflusses auf die anderen Inhalte der Konventionen weitreichendste Entscheidung. Des weiteren ist die Festlegung der relevanten Objekttypen zu diskutieren und in Folge zu minimieren. Unnötige Objekttypen steigern die Komplexität und senken die Anschaulichkeit enorm.
Hinzu kommt, dass eine Auswahl der Beziehungstypen zu erfolgen hat, um Objekte miteinander in Bezug zu setzen. Layout- und Perspektivenbezug müssen beachtet werden, Namenskonventionen nach Möglichkeit vorher eingeschränkt werden, so dass ein Projektteam bei der Modellierung auf einen allgemein zugänglichen und kommunizierten Fundus von definierten Termini zurückgreifen kann. Es ist selbstverständlich, dass sich hieran strikt zu halten ist, ansonsten wird der Zweck der unternehmensweit einheitlichen Modellierung in Frage gestellt.
Der adäquate Modellierungsgrad (Feinheit) wird durch den Modellierungszweck zu Grunde gelegt. Um dies in der Praxis zu ermöglichen, werden bspw. Modellierungshandbücher vor der Analysephase erstellt, um Synonyme und Homonyme
organisatorisch auszuschließen. Die Fachwelt spricht hier von einer Fachbegriffsmodellierung. Was aber ist eigentlich gemeint, wenn man von einem Modell spricht? Da die Vorstellungen hier zwar ähnlich, aber nicht präzise sind, lohnt sich eine ausführliche Definition des Begriffes.
3.1 Fachbegriffsdefinition Modell
Darstellungen, die nur die als wichtig angesehenen Eigenschaften des Vorbildes ausdrücken, um durch diese Vereinfachung zu einem übersehbaren oder mathematisch berechenbaren oder zu experimentellen Untersuchungen geeignet sind,
werden als Modell definiert [4].
Somit ist das Modell auch gleichzeitig das abstrakte Abbild eines Systems. Ein System ist dann vorhanden, wenn Objekte samt Ihrer Wechselwirkung durch eine plausible Abgrenzung von Ihrer Umgebung ,d.h. der komplexen Realität, zu einer Gesamtheit zusammengefasst werden können. Diese Systeme können noch weiter definiert werden, im Zusammenhang der Geschäftsprozesse ist eine Beschränkung auf dynamische und statische Systeme [5] vollkommen ausreichend. Bei dynamischen Systemen verändern sich die Systemgrößen im Laufe der Zeit, bei statischen wiederum sind sie unveränderlich.
Oft ist ein System zu komplex, um es gedanklich vollständig zu erfassen und zu untersuchen. Dann tritt beim Modellbildungsprozess zu der Abstraktion noch eine Reduktion auf die (vermeintlich) wesentlichen (manchmal auch auf die am besten fassbaren) Parameter und Wechselwirkungen des Systems hinzu. Die Literatur verweist hier auf die Begriffe Isomorphie (Strukturgleichheit) und Homomorphie (Strukturähnlichkeit). Isomorphie zwischen einem Modell M und einem System S besteht dann, wenn
- jedem Element von S ein Element von M eindeutig zugeordnet ist und diese Zuordnung auch umgekehrt eindeutig ist,
- jeder Relation in S eine Relation in M eindeutig zugeordnet ist und diese Zuordnung auch umgekehrt eindeutig ist und
- eindeutig zugeordnete Relationen nur einander zugeordnete Elemente enthalten.[6]
Alle Elemente einer isomorphen Abbildung eines Systems , alle Elemente und alle Relationen des Originals sind im Modell somit zu finden, die Strukturen von Modell und Original sind gleich.[7] Bei homomorphen Abbildung eines Systems trifft dies nicht zu, die Strukturen weisen eine Ähnlichkeit auf, aber Original und Modell sind ungleich. Diese Unterscheidung muss kein Qualitätsmerkmal sein, hängt die Art der Abbildung, deren Detaillierungsgrad und Ihre Genauigkeit schließlich von der Art der Verwendung ab. Aus der Erfahrung haben sich folgende[8]
3.2 Grundsätze ordnungsmäßiger Modellierung
herausgebildet:
- Grundsatz der Richtigkeit
- Grundsatz der Relevanz
- Grundsatz der Wirtschaftlichkeit
- Grundsatz der Klarheit
- Grundsatz der Vergleichbarkeit
- Grundsatz des systemischen Aufbaus
Anhand folgender pragmatischer Fragen werden die Modelle nochmalig auf Ihre Verwendbarkeit überprüft (siehe hierzu auch Kapitel Prozessorientierung):
- Welches Original wird durch das Modell repräsentiert?
- Für wen ist das Modell?
- Wer ist der Nutzer des Modells?
- Was ist der Zweck des Modells?
Abbildung in dieser Leseprobe nicht enthalten
Abbildung: Marshall - Business Objekt 1
3.3 Notwendigkeit einer Modellsprache
Zur Beschreibung eines Modells benötigen wir einer Modellsprache, d.h. einer widerspruchsfrei konstruierten, linguistischen wie symbolischen Teilstruktur[9], die aus einer Sammlung einfacher Modellsätze besteht, deren grammatische Formen keine Unregelmäßigkeiten aufweisen (im Gegensatz zu vielen natürlichen Sprachen). Sie dient der Erkenntnis der allgemeinen Regeln in einem ideal funktionieren Regelsystem. Damit wird die Gefahr natürlich deutlich, dass in der Idealisierung ein Schärfeverlust zu befürchten ist, der zu fehlerhaften Annahmen führt, die das System wiederum unzutreffend beschreiben.
Somit kann in der Anwendung des Modellsystems und seiner Verwendung zur Erstellung eines Programmsystems zwar ein ideales Regelsystem abgebildet werden, auch wenn die
Systematik eines Betriebes nicht auf logischen Annahmen beruht. Dies führt zu unerwünschten Ergebnissen, insbesondere wenn die Interaktion von Menschen zur Entscheidungsfindung im Modellierungsprozess berücksichtigt werden musste. Dieser Grad der Einbeziehung des menschlichen Elements als Modelleigenschaft wird in Ihrer Ausprägung als mechanistisch oder als nicht-mechanistisch beschrieben, sie liefern vermutlich einer der größten Fehlerquellen in der Modellierung.[10]
[...]
[1] Enterprise Modeling with UML, Designing Succesful Software through Business Analysis, Chris Marshall, 1999, Addison Wesley
[2] Introduction of Enterprise Modeling with UML, Designing Succesful Software through Business Analysis, Chris Marshall, 1999, Addison Wesley
[3] Peter M.. Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, Doubledy Currency, 1990
[4] Krückeberg/ Spaniol (1990): Lexikon der Informatik und Informationstechnik, S. 403
[5] Schwarze (1997): Einführung in die Wirtschaftsinformatik, S. 146
[6] Krallmann, Systemanalyse, 3.Auflage 1999, Verlag Oldenbourg, S. 38
[7] Krallmann, Systemanalyse, 3.Auflage 1999, Verlag Oldenbourg, S. 39 ff
[8] Becker, Kugeler, Rosemann, Prozessmanagement, S. 67,2. Auflage, Springer Verlag 2000
[9] F.A. Brockhaus Enzyklopädie – Begriff Modellsprache
[10] Krallmann, Systemanalyse, 3. Auflage 1999, Verlag Oldenbourg, S. 32
- Arbeit zitieren
- Markus Bussmann (Autor:in), 2001, Unternehmensmodellierung mit der Unified Modeling Language (UML), München, GRIN Verlag, https://www.grin.com/document/1097
