Business Engineering PDF

2. Business Engineering Website: Lehr- und Lernumgebung Gedruckt von: Maya Engel Kurs: Modul M12: Wirtschaftsinformatik Datum: Dienstag, 9. April 2024, 08:41 Buch: 2. Business Engineering :...

2. Business Engineering Website: Lehr- und Lernumgebung Gedruckt von: Maya Engel Kurs: Modul M12: Wirtschaftsinformatik Datum: Dienstag, 9. April 2024, 08:41 Buch: 2. Business Engineering :  Inhaltsverzeichnis 2.1 Change Management 2.2 Wissensmanagement 2.3 Informationsmanagement 2.4 Gestaltungsebenen 2.5 ARIS 2.5.1 Ebenen 2.5.2 Sichten 2.5.2.1 Datensicht 2.5.2.1.1 Entitätstypen 2.5.2.1.2 Relationstypen 2.5.2.2 Prozesssicht 2.5.2.2.1 EPK 2.5.2.2.2 eEPK 2.5.3 Zusammenfassung :  2.1 Change Management Kurt Lewin beschreibt bereits 1963, welche Faktoren bei Veränderungen von Bedeutung sind. In seiner Feldtheorie, die als Grundlage für das Change-Management verstanden werden kann, stehen sich die Kräfte, die auf Wandel drängen, und die Kräfte, die dem Wandel entgegenstehen, einander gegenüber. Zur Herstellung eines Gleichgewichts zwischen beiden auch im Unternehmen wirkenden Kräfte, leitet er für Veränderungen ein 3- Phasen-Modell ab: (vgl. Lauer) :  2.2 Wissensmanagement "Im Silicon Valley feiern wir nicht das Scheitern. Wir feiern das Lernen." Reid Hofman, Mitgründer von LinkedIn Ein Blick auf die gesellschaftliche Entwicklung macht deutlich, warum dem Wissen heute in Unternehmen eine besondere Bedeutung zukommt: (in Anlehnung an Bildung im Zeitalter der Wissensexplosion, Zukunftsinstitut, 2012) Wissensmanagement ist die Führung und Gestaltung lernender Organisationen. (vgl. Dückert, cogneon, Wissensmanagement in der Praxis, Fachvortrag, 2014) Damit Unternehmen in zunehmend globalisierten Märkten auch weiterhin wettbewerbsfähig bleiben und wachsen können, müssen sie kreativer, dynamischer und flexibler agieren als die Konkurrenz. Mitarbeiter müssen folglich in hohem Maß motiviert und leistungsbereit seinen. Dabei kann ein etabliertes Wissensmanagement individuell das relevante bzw. erforderliche Wissen selektieren, zeitnah und aktuell liefern sowie die Transformation (kognitive Verarbeitungskomponente) unterstützen. Das Wissensmanagement soll außerdem dazu dienen, die Geschäftsprozesse enger an den Mitarbeitern und deren Wissen auszurichten, damit flexibles Wissen entstehen und für den unternehmerischen Erfolg genutzt werden kann. (vgl. Jänig, Wissensmanagement, Springer, 2004, S. 237 ) (nach Probst et al, Wissen managen, Gabler, 2010 S. 25 ff) :  Für Interessierte hier noch eine Studie zum Thema "Erfolgsfaktoren für die Steuerung impliziten Wissenstransfers in Unternehmen" von Prof. Katharina Hölzle (Universität Potsdam, 2013). :  2.3 Informationsmanagement Damit Informationssysteme dazu beitragen können, die Erfolgspotenziale des Unternehmens langfristig zu sichern und weiter auszubauen, muss die architektonische Gestaltung der Informationstechnologie aus den strategischen Unternehmensziele abgeleitet und auf die Strukturen der Wertschöpfungsprozesse ausgerichtet werden. Österle et al. haben dazu bereits 1992 die Etablierung eines entsprechenden Informationsmanagements mit folgender Aufgabenteilung empfohlen: Unternehmerische Sicht Erkennen der Potenziale von IT („informationsbewusstes“ Management) zur Lösung betriebswirtschaftlicher Kernaufgaben → Unternehmensführung Konzeptionelle Sicht Entwicklung des logischen Aufbaus von Informationssystemen und Erkennen von Integrationsmöglichkeiten → IT-Abteilung in Zusammenarbeit mit den Fachabteilungen → die Erarbeitung der entsprechenden Konzepte ist Bestandteil der folgenden Lernpakete: Fachkonzept (Verantwortung der Fachabteilungen): Lernpaket 2 (→ 2.5 ARIS ff) IT-Konzept (Verantwortung der IT-Abteilung): Lernpaket 3 (→ Data Engineering) Instrumentelle Sicht Management der Ressourcen zur Implementierung und zum Betrieb der Informationstechnologie → IT-Abteilung → die Umsetzung der Konzept Durch seinen ganzheitlichen Ansatz - vom Erkennen der IT-Potentiale bis hin zum einsatzbereiten System - trägt das Informationsmanagement dazu bei, dass die für ein Unternehmen relevante und nützliche Informationstechnologie nach den spezifischen Anforderungen des Unternehmens die Prozesse optimal unterstützen kann. :  2.4 Gestaltungsebenen Dem Business-Engineering-Ansatz folgend, dient die Informationstechnologie als „Möglichmacher“ bei Veränderungen im Unternehmen nicht als treibende Kraft. Somit ist die Systemebene zwar als Gestaltungsebene relevant, nicht aber Auslöser im Rahmen eines unternehmerischen Gestaltungsansatzes. Vielmehr muss ausgehend von den strategischen Zielen im Rahmen der Strategieebene festgelegt werden, welche Position das Unternehmen im Wettbewerbsumfeld einnehmen soll und welche sonstigen Rahmenbedingungen gelten (Partner, Zusammenhänge, Abhängigkeiten), um daraus die strategische Prozessgestaltung zu entwickeln. Darauf aufbauend werden im Rahmen der Organisationsebene die genauen ablauf- und aufbauorganisatorischen Aspekte der Prozesse entwickelt sowie die Informationsflüsse konkret beschrieben. Erst im letzten Schritt werden daraufhin im Rahmen der Systemebene die Systemanforderungen spezifiziert, die dafür notwendigen Technologien ausgewählt und die IT-Infrastruktur aufgebaut. (vgl. Alpar et al.) :  2.5 Architektur integrierter Informationssysteme (ARIS) Um gestaltete Prozesse zur Umsetzung in Informationsprozessen transparent darzustellen, empfiehlt sich aufgrund des hohen Komplexitätsgrads die Verwendung von Modellen. Daher kommt der Modellierung beim Business Engineering große Bedeutung zu. Die betriebswirtschaftliche Problemstellung wird dabei in einer formalisierten Beschreibungssprache dargestellt. Um die Komplexität von Unternehmen beherrschbar zu machen, kommen dabei sogenannte Informationsarchitekturen zum Einsatz, in denen Prozesse, Organisationsstrukturen, Funktionen, Daten und Informationsflüsse eines Unternehmens ganzheitliche beschrieben werden. (vgl. Hansen, S. 2019, 142 ff) Eine solche Informationsarchitektur stellt auch das ARIS-Haus von Scheer dar: (vgl. Scheer) :  2.5.1 Ebenen Die Unterteilung in drei Bearbeitungsebenen soll die Komplexität in IT-Projekten reduzieren. Fachkonzept Im Rahmen des Fachkonzepts werden die betriebswirtschaftlichen Anforderungen an das zu entwickelnde Informationssystem detailliert beschrieben und strukturiert dargestellt (Modellierung). Dabei werden noch keine Aussagen über das später zu entwickelnde, konkrete Informationssystem getroffen. Eine Entscheidung über die Software, die zur Realisierung der Anforderungen eingesetzt werden kann, ist erst nach der Erarbeitung eines Fachkonzepts sinnvoll möglich. Ausführende Organisationseinheit ist i.d.R. die jeweilige Fachabteilung. IT-Konzept Auf Basis des detaillierten Fachkonzepts erfolgt im Rahmen des IT-Konzepts die Auswahl und Beschreibung der geeigneten Informationstechnologie. Es erfolgt beispielsweise die Spezifikation zur notwendigen Datenbank. Außerdem werden Schnittstellen und gegebenenfalls technische Workflows konzeptioniert. Ausführende Organisationseinheit ist i.d.R. die IT-Abteilung. Implementierung Zur Implementierung zählt vor allem die technische Realisierung des Fach- und IT-Konzepts mit konkreten software-/ hardwaretechnischen Komponenten. Dabei erfolgt die Umsetzung in Rahmen eines IT-Projekts, das auch Dokumentation, Test und Schulung beinhaltet. Ausführende Organisationseinheit ist i.d.R. die IT-Abteilung :  2.5.2 Sichten in ARIS vgl. Scheer S. 21 - 176 Die Organisationssicht In der Organisationssicht werden alle aufbauorganisatorische Elemente (menschliche oder maschinelle Aufgabenträger) berücksichtigt und in der Regel in Form von Organigrammen modelliert. Aus der fachlichen Beschreibung der Aufbauorganisation (u.a. Rollenbeschreibung) wird beim IT-Konzept die Netzwerktopologie sowie das Berechtigungskonzept abgeleitet. Im Rahmen der Implementierung werden beispielsweise konkrete Kommunikationsprotokolle festgelegt. Die Funktionssicht Die Funktionssicht beinhaltet alle Arbeitsschritte, die durch Organisationseinheiten (Mensch oder Maschine) des Unternehmens zur Erfüllung operationaler Ziele ausgeführt werden (z.B. Erfassen eines Kundenauftrags) sowie die formalen Zusammenhänge zwischen einzelnen Funktionen. Bei der Modellierung kommen hierbei üblicherweise Funktionsbäume zum Einsatz. Die Leistungssicht Diese Sicht umfasst alle materiellen und immateriellen Input- und Output-Leistungen (Produkte / Dienstleistungen) des Unternehmens einschließlich der Geldflüsse. Die Datensicht Die Datensicht enthält alle Daten, die zur Datenverarbeitung notwendig sind. Unter anderem werden dort die Inputdaten der Geschäftsprozesse (Stammdaten) wie auch die Daten, die durch die Bearbeitung der Geschäftsprozesse erzeugt werden (Bewegungsdaten) dargestellt. (Details: siehe ERM) :  Die Prozesssicht Die Prozesssicht wird auch als Steuerungssicht bezeichnet. Während in allen anderen Sichten ausschließlich Beziehungen zwischen den Elementen einer Sicht abgebildet werden, erfasst die Prozesssicht die Beziehungen zwischen allen Sichten, um den Geschäftsprozess abzubilden. Dabei werden die Auslöser von Funktionen sowie die Ergebnisse von Funktionen mit den einzelnen Funktionen in einem ablauforganisatorischen Kontext dargestellt. Ergänzt werden die Funktionen dabei um die organisatorischen Elemente, von denen sie ausgeführt werden. Zudem werden die Daten beschrieben, die zur Bearbeitung erforderlich sind sowie die Leistungen, die durch die Funktion erbracht werden. (Details: siehe EPK) :  2.5.2.1 Datensicht Ein Informationssystem besteht, wie jedes System, aus Elementen, die miteinander verknüpft sind. Die Datensicht beschreibt im Fachkonzept alle relevanten Informationsobjekte (Element = Entität) und ihre jeweilige Verknüpfung (Relation) zueinander. Als Standardtechnik für die Modellierung in der Datensicht gilt seit den 1970er Jahren das Entity-Relationship-Modell von Chen. Formale Darstellung: Das ERM unterscheidet folgende Objekte zur Modellierung: Entitätstyp gleichartiger Informationsobjekte / Elemente werden zu Klassen zusammengefasst und als Entitätstyp im Modell abgebildet. Aus den Entitätstypen (z.B. Kunde) werden später im Rahmen des IT-Konzepts die Tabellen der Datenbank abgeleitet. Jede einzelne Entität (z.B. Becker GmbH) des Entitätstyps wird dann im Rahmen der Implementierung als Zeile der Tabelle abgebildet (= Datensatz). Attribut Attribute beschreiben die Ausprägungen eines Entitätstyps. Jedes Attribut hat eine Bezeichnung, einen Datentyp (z.B. ganze Zahlen, Zeichenkette) und eventuell einen bestimmten Wertebereich. Schlüsselattribute identifizieren jede Entität eindeutig und werden durch Unterstreichen entsprechend gekennzeichnet. Aus den Attributen (z.B. Kundenname, Straße, PLZ) werden später im Rahmen des IT-Konzepts die Spalten der Tabellen abgeleitet. Das Schlüsselattribut (z.B. Kundennummer) wird der Primärschlüssel der Tabelle, der die einzelnen Datensätze eindeutig identifiziert. Relationstyp Die Verbindung zwischen genau zwei Entitätstypen wird über den sogenannten Relationstyp dargestellt. Dabei empfiehlt sich die Verwendung von Verben in der Grundform, um den Relationstyp zu beschreiben. Verknüpfung: ungerichtete Kante :  Beispiel: Aus der fachlichen Modellierung wird im IT-Konzept die Tabellenstruktur abgeleitet Bei der Modellierung der Datensicht sind die nachfolgend dargestellten Besonderheiten zu beachten: :  2.5.2.1.1 Modellierung von Entitätstypen 2.5.2.1.1.1 Generalisierung/Spezialisierung Können Attribute eines Entitätstyps auf spezielle Entitätstypen übertragen werden, spricht man von einer Spezialisierung. Beispielsweise lassen sich für den Entitätstyp „Händler“ die spezialisierten Entitätstypen „Einzelhändler“ und „Großhändler“ modellieren: Wenn man Entitätstypen zu einem generellen Entitätstyp zusammenfassen kann, spricht man von einer Generalisierung. So könnten zum Beispiel in einer Bank der Entitätstyp „Privatkunde“ und der Entitätstyp „Geschäftskunde“ zu einem generalisierten Entitätstyp „Kunde“ zusammengefasst werden: (vgl. Alpar) 2.5.2.1.1.2 Aggregation/Disaggregation Kann man Entitätstypen und ihre gemeinsame Beziehung zu einem neuen Entitätstyp zusammenfassen, spricht man von einer Aggregation. wird zu Lässt sich ein Entitätstyp in mehrere Entitätstypen mit entsprechender Beziehung zerlegen, handelt es sich um eine Disaggregation wird zu :  2.5.2.1.2 Modellierung von Relationstypen 2.5.2.1.2.1 Kardinalitäten Zur Modellierung eines Beziehungstyps ist grundsätzlich im Fachkonzept zu klären, wie viele Entitäten eines Entitätstyps jeweils an Beziehungen mit Entitäten eines anderen Entitätstyps teilnehmen können. 1:1-Beziehung: für jede Entität darf eine Beziehung zu maximal einer anderen Entität bestehen. Das modellierte Beispiel lässt sich wie folgt interpretieren: Der Abteilungsleiter XY leitet genau eine Abteilung. Die Abteilung YZ wird von genau einem Abteilungsleiter geleitet. 1:n-Beziehung: Für eine Entität des ersten Entitätstyps darf eine Beziehung zu mehreren Entitäten des anderen Entitätstyps bestehen. Umgekehrt darf für eine Entität des zweiten Entitätstyps nur genau eine Beziehung zu einer Entität des ersten Entitätstyps bestehen. Das modellierte Beispiel lässt sich wie folgt interpretieren: Der Kunde 4711 erteilt mehrere Aufträge. Der Auftrag 0815 wird von genau einem Kunden erteilt. n:m-Beziehung: Die Entitäten beider Entitätstypen dürfen zu mehreren anderen Entitäten Beziehungen haben. Das modellierte Beispiel lässt sich wie folgt interpretieren: Der Lieferant 9999 liefert mehrere Artikel. Der Artikel 1111 wird von mehreren Lieferanten geliefert. (vgl. Hansen, 2019, S.157 ff) Bitte bearbeiten Sie die Übungsaufgabe 2.1! 2.5.2.4.2.2 Partizipation Zur Modellierung eines Beziehungstyps ist neben der Kardinalität außerdem noch zu klären, ob Informationsobjekte eines Entitätstyps an einer Beziehung teilnehmen müssen oder teilnehmen können. In der Min-Max-Notation werden dabei vier kombinierte Kardinalitäten unterschieden: (0,*), (0,1), (1,1) und (1,*) Beispiel für eine Modellierung mit min-max-Notationen: Das modellierte Beispiel lässt sich wie folgt interpretieren: (1,1): Jede Person muss in mindestens einem Ort (1) geboren sein. Jede Person ist in maximal einem Ort (1) geboren (ist in genau einem Ort geboren) (0,*): Der Ort kann ein Geburtsort sein, muss es aber nicht (0) sein. Der Ort kann Geburtsort von beliebig vielen (*) Personen sein. :  (vgl. Gadatsch, Datenmodellierung für Einsteiger, Springer, 2017, S.9 ff) 2.5.2.4.2.3 Rekursive Beziehung Auch Rückverflechtungen lassen sich in Informationsmodellen durch eine zyklische (rekursive) Beziehung abbilden: Bitte bearbeiten Sie die Übungsaufgabe 2.2! :  2.5.2.2 Prozesssicht In der Prozess- bzw. Steuerungssicht stehen zur Modellierung unter anderem die Grundform der Ereignisgesteuerten Prozesskette (EPK) sowie die erweiterte Ereignisgesteuerte Prozesskette (eEPK) zur Verfügung, die nachfolgend detailliert dargestellt werden sollen. :  2.5.2.2.1 Grundform der Ereignisgesteuerten Prozesskette Zur detaillierten Abbildung von Geschäftsprozessen dienen in ARIS die sogenannten Ereignisgesteuerten Prozessketten (EPK). EPKs bilden Geschäftsprozesse in Form von Ketten ab, die aus Folgen von elementaren Ereignissen und elementaren Funktionen (zur Abbildung von Aktivitäten) bestehen. (vgl. Alpar, 2016 ,S. 158 f) Dieser Modellierungsansatz wurde von der SAP in ihr Produktportfolio aufgenommen und hat sich dadurch in der Praxis als Methode zur Modellierung von Geschäftsprozessen durchgesetzt. (vgl. F. Lehmann, dpunkt, 2008, S.61) Formale Darstellung: Die EPK unterscheidet folgende Objekte zur Modellierung: Ereignis Ein Ereignis beschreibt einen eingetretenen Zustand Ereignisregeln: Ereignisse haben grundsätzlich genau eine eingehende und genau eine ausgehende Kante. Startereignisse lösen einen Prozess aus. Sie besitzen genau eine ausgehende Kante. Endereignisse bilden die Ergebnisse eines Prozesses ab. Sie besitzen genau eine eingehende Kante. Auf ein Ereignis folgt stets eine Funktion und umgekehrt. Ereignisse folgen somit nicht direkt aufeinander. Ereignisse haben keine Entscheidungskompetenz, es handelt sich um passive Elemente, die nicht über den weiteren Ablauf entscheiden. Funktion Eine Funktion beschreibt die Transformation einer Eingabe- in eine Ausgabeinformation. Sie wird von einem Ereignis oder mehreren Ereignissen ausgelöst und löst ihrerseits ein oder mehrere Ereignisse aus. Funktionsregeln: Funktionen haben genau eine eingehende und genau eine ausgehende Kante Auf eine Funktion folgt stets ein Ereignis und umgekehrt. Funktionen folgen somit grundsätzlich nicht aufeinander. Funktionen besitzen die Kompetenz, Entscheidungen über den weiteren Ablauf zu treffen. Konnektoren Konnektoren bilden die Verknüpfungsknoten in nicht rein sequenziellen EPKs. Synonym werden in Praxis und Fachliteratur die Begriffe „logischer Konnektor“, Verknüpfungsoperator, „Operator“ oder „Verknüpfung“ verwendet. Folgende Konnektoren lassen sich unterscheiden: UND [AND] ODER [OR] Ausschließliches ODER [XOR] :  Konnektorenregeln: Konnektoren sind entweder Verteiler mit einem Eingang und mehreren Ausgängen oder Verknüpfungen mit mehreren Eingängen und einem Ausgang. Alle Ein- und Ausgänge der Konnektoren sind jeweils vom gleichen Typ, d.h., sie verbinden entweder ausschließlich Ereignisse oder ausschließlich Funktionen mit dem Konnektor Nach Ereignissen folgt kein XOR- oder ODER-Konnektor zur Aufspaltung des Kontrollflusses Prozesswegweiser Durch Verwendung des Prozesswegweisers wird auf eine andere EPK verwiesen, die vorgelagert, nachgelagert oder – aus besonderen Gründen – ausgelagert ist. Ein Prozesswegweiser stellt eine besondere Form des Objekttyps „Funktion“ dar. Regeln für Prozesswegweiser: Der Prozesswegweiser steht anstelle einer Funktion in einer EPK Vor dem Prozesswegweiser steht ein Ereignis (oder mehrere). In der aufgerufenen EPK wird ein entsprechendes Ereignis nach dem Prozesswegweiser wiederholt. (vgl. J. Staud, Spinger, 2006, S. 110ff) Im Fall von eingefügten Subprozessen steht der Prozesswegweiser mitten im Kontrollfluss der EPK. Prozesswegweiser haben genau eine eingehende und eine ausgehende Kontrollflusskante. Schleifen (z.B. Prozess A ruft Prozess B, Prozess B ruft Prozess C, Prozess C ruft Prozess A auf) sind unzulässig. Verknüpfung: gerichtete Kante Unabhängig vom Objekttyp gelten die folgenden Modellierungsregeln: Ein Modell besitzt immer mindestens ein Startereignis (Prozesswegweiser können vor dem Startereignis modelliert werden) Ein Modell besitzt immer mindestens ein Endereignis (Prozesswegweiser können nach dem Endereignis modelliert werden) Es darf keine unverbundenen Modellteile geben. Kanten mit gleichem Anfangs- und Endknoten (Schleife) ist unzulässig. Mehrfachkanten zwischen zwei Objekten sind unzulässig. Erweiterungsobjekte dürfen ausschließlich mit Funktionen verbunden werden. Prozesszweige werden grundsätzlich mit dem gleichen Konnektor wieder zusammengeführt, der auch zur Aufspaltung :  verwendet wurde. (vgl. F. Lehmann, dpunkt, 2008, S. 61 ff) Beispiel: Bitte bearbeiten Sie die Übungsaufgabe 2.3! :  2.5.2.2.2 Erweiterte Ereignisgesteuerte Prozesskette (eEPK) Die einfache EPK beschränkt sich auf Ereignisse, Funktionen und Prozesswegweiser, die mittels Konnektoren und Kanten zu einem Ablaufdiagramm zusammengesetzt werden. Diese Modellierung des Prozessablaufs kann durch eine Vielzahl von Objekttypen ergänzt werden. (vgl. F. Lehmann, dpunkt, S. 78f und J. Staud, Springer, S.63 ff) Nachfolgend werden in Anlehnung an die Prozessmodellierungssoftware von SAP Signavio die beiden Objekttypen „Organisationseinheit“ und „System“ näher betrachtet werden. Bei der Modellierung erweiterter Ereignisgesteuerter Prozessketten (eEPK) ist jedoch die bereits formulierte Modellierungsregel „Erweiterungsobjekte dürfen ausschließlich mit Funktionen verbunden werden“ zu beachten. Erweiterung mit Organisationseinheiten Einer Funktion kann eine Organisationseinheit zugeordnet werden, die diese Funktion ausführen soll (z.B. Vertrieb, Einkauf, Produktionsabteilung). Die Verknüpfung zwischen Organisationseinheit und Funktion ist dabei eine ungerichtete Kante. Erweiterung mit Systemen/Systemkomponenten Eine Funktion kann um Systeme/Systemkomponenten (z.B. SAP-ERP-PP) angereichert werden, mit deren Hilfe die Funktion ausgeführt wird. Die Verknüpfung zwischen Informationseinheit und Funktion ist dabei ebenfalls eine ungerichtete Kante. Beispiel: :  Bitte bearbeiten Sie die Aufgabe 2.4! Bitte bearbeiten Sie die Aufgabe 2.5! :  2.5.3 Zusammenfassung (vgl. Hansen, 2019, S. 142 ff) Zur Verdeutlichung der einzelnen Modelle der Fachkonzeptebene können Sie auch die Lernvideos der Universität Augsburg nutzen, die Sie auf YouTube finden. :