Grundlagen der computergestützten Produktion und Logistik W1332

Grundlagen der computergestützten Produktion und Logistik W1332
Vorlesung Grundlagen der computergestützten Produktion und Logistik W1332 llllllllllllllllllll Fakultät für Wirtschaftswissenschaften W. Dangelmaier

Grundlagen der computergestützten Produktion und Logistik - Inhalt
Einführung: Worum geht es hier? System Modell Modellierung von Gegenständen Strukturmodelle (Gebildestruktur) Verhaltensmodelle (Prozessstruktur) Produktion Digitale Fabrik Planung von Produktionssystemen Wirtschaftlichkeitsrechnung Prüfungen

9. Planung von Produktionssystemen
Funktionale Struktur von Systementwicklungsaufgaben Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Problemanalyse Wir zerlegen ein abgegrenztes System in Subsysteme und Teilsysteme – wir schaffen ein System, wir systematisieren. Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Problemanalyse Die Problemanalyse ist die (gedankliche) Zerlegung einer Systemplanungsaufgabe in deren Elemente. Die Problemanalyse arbeitet dabei mit den Begriffsmerkmalen Verrichtung, Gegenstand, Sach- oder Arbeitsmittel, Zeit und Arbeitsraum. Orientiert sich die Problemanalyse vor allem am Gegenstand der Systemplanungsaufgabe, umfasst dies auch die Eigenschaften der einzelnen Untersysteme und Elemente sowie die Funktionsstruktur des Systems selbst. Versteht man Verhalten als die Änderung von Attributen, so ist auch die Gliederung nach einzelnen Aspekten bzw. die verhaltensorientierte Sicht in diese Merkmale ein – und dem Gegenstand zuzuordnen.

Problemanalyse Beispiel 1: Die Fahrradkette ist vom Fahrrad gesprungen. Der Besitzer des Rennrads hat diese Kette schon für 1200 km eingesetzt. Beispiel 2: Hörsäle der Universität Paderborn sind überfüllt.

Situationsanalyse Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Feld, das neues System abdecken soll Lösungs- möglichkeiten
9. Planung von Produktionssystemen Situationsanalyse In der Situationsanalyse hat sich das Systemteam mit dem Problem vertraut zu machen. Die Situation des Umsystems, in welches das System eingebettet werden soll, sowie die Diskurswelt werden in dieser Phase analysiert. In dieser Phase muss ein Überblick über die verschiedenen Lösungsmöglichkeiten gewonnen werden; dies ist die Grundlage für die Festlegung realistischer Zielsetzungen. In der Situationsanalyse werden die Systemgrenzen zur Gewinnung zweckmäßiger Systemgrenzen bewusst ausgedehnt, um darauf wieder auf ein vernünftiges Maß reduziert zu werden. Ergebnis der Situationsanalyse ist ein Katalog von Problemen und Möglichkeiten. Ergebnis: Katalog von Problemen und Möglichkeiten Beschreibung der Situation, vor die sich das Systemplanungsteam gestellt sieht. Feld, das neues System abdecken soll Lösungs- möglichkeiten Ausdehnen und Abspecken Ausdehnen und Abspecken

Situationsanalyse Beispiel 1: Die Fahrradkette war nicht genügend gespannt. Beispiel 2: Die Universität Paderborn hat jedes Jahr mehr Studienanfänger als es die Platzkapazität zulässt.

Zielformulierung Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Zielformulierung Aus der Problemstellung einerseits und den Ergebnissen der Situationsanalyse (Katalog von Problemen und Möglichkeiten) andererseits müssen die für die folgenden Aktivitäten erforderlichen Zielsetzungen erarbeitet werden. Das Zielsystem in Form eines Kriterienplans stellt dabei eine Reihe von Teilaspekten dar, die zur Beurteilung und Bewertung der späteren Systementwürfe dienen. Die für die Systemplanung geltenden Zielsetzungen sind zudem vom Auftraggeber zu genehmigen, um Fehlentwicklungen zu vermeiden. Sowohl seitens des Auftraggebers, als auch seitens des Systemteams können Zielsetzungen und Kriterien im Laufe der Systementwicklung ergänzt, modifiziert, konkretisiert und u. U. auch für gegenstandslos erklärt werden. Änderungen dürfen jedoch nicht einseitig und ohne die Information der übrigen Beteiligten erfolgen. Ergebnis: Kriterienplan  Reihe von Teilaspekten zur Beurteilung und Bewertung der Systementwürfe

Formale Anforderungen an ein Zielsystem (I) Terminaussage Die Ziele sollen bis zu einem bestimmten Zeitpunkt realisiert werden oder Die Ziele sollen während eines Zeitraumes ständig erreicht werden oder Die Ziele sollen auf einem bestimmten Realisierungsniveau gehalten werden Präzision der Formulierung Zielaussagen müssen präzise und eindeutig formuliert sein Quantifizierung Die einzelnen Zielelemente des Zielsystems müssen quantifizierbar sein, wenn sie als eindeutige Richtlinien gelten sollen Elastizität Veränderungen in der Motivationsstruktur und Veränderungen der Daten der umgebenden Situation muss Rechnung getragen werden

Formale Anforderungen an ein Zielsystem (II) Kompatibilität Wenn sich die einzelnen Ziele nicht widersprechen Bei Fällen, bei denen Ziele ohne Beeinträchtigung des anderen sich nicht erfüllen lassen, muss abgewogen werden bis zu welchem Grad man beide Ziele erreichen kann Inkompatibilität durch geeignete Formulierung ausschalten Operationalität Es muss überprüft werden können, bis zu welchem Grad ein Ziel erreicht wurde Lösungsunabhängigkeit Ziele dürfen nicht von einzelnen Lösungsmöglichkeiten abhängig sein Anforderungen der Systemumwelt Ziele müssen Ziele der Systemumwelt sein

Zielgewichtung Anstatt die Zielkriterien alle einzeln zu gewichten, können sie indirekt über die relativen Gewichte der zugehörigen Oberziele schrittweise bestimmt werden Gewichte hinsichtlich Oberziel = Knotengewichte Gewichte hinsichtlich einer Stufe, also aller Zielinhalte = Stufengewichte z 40% z 100% z 20% z 14% z 26% Oberziel zu z11, z12, z13 z111, z112 Unterziel zu z11 z1 Die Zuordnung von Zielen Knotengewicht Stufengewicht

Zielbereich: Gebiete, auf die sich die Aufmerksamkeit bei der Zielsuche richtet. Zieldimension: Zielsuche ausgehend von Zielbereichen. Ziele durch Zielrichtung gekennzeichnet. Dazu Zielinhalt bzw. Zielbereich (Kosten), Zielquantum (Kostensenkung oder Kosten = €) und eventuell zeitlicher Bezugswert zu definieren (pro Jahr). Randbedingung: Randbedingungen: Angaben innerhalb des Zielbereiches, auf deren Einhaltung streng zu achten ist(z. B. gesetzliche Vorschriften, technische Mindestanforderungen, Kostengrenzen).

Zielformulierung Beispiel 1: Die Kette soll für eine lange Zeit einsetzbar sein. Beispiel 2: Die Universität Paderborn soll eine Lösung finden, die sowohl die Studenten als auch die Regierung zufriedenstellt.

Synthese von Lösungen Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Synthese von Lösungen In dieser Phase geht es darum, das System konstruktiv zu gestalten. Ein wesentliches Merkmal der Synthese besteht darin, dass versucht wird, einen möglichst umfassenden Überblick von – auf der betrachteten Systemstufe – denkbaren Lösungsmöglichkeiten zu schaffen. Wichtig ist, dass hier eine Detaillierungsstufe erreicht wird, auf der Lösungen aus bekannten Sachverhalten und Beziehungen zusammengesetzt und anschließend bewertet werden können.

Synthese von Lösungen Beispiel 1: Kette richtig spannen und anschließend Öl eintröpfeln (Kosten: 5€) Neue Kette anschaffen (Kosten: 50€)

Synthese von Lösungen Beispiel 2: Neue Hörsäle bauen Weniger Studenten aufnehmen (Zulassungsbeschränkung einführen)

Analyse von Lösungen Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Analyse von Lösungen Die Systemanalyse stellt eine kritische Untersuchung der Systemkonzepte auf ihre Funktionstüchtigkeit sowohl im Rahmen des Systems selbst als auch im weiteren Rahmen der Umwelt an. Systemsynthese und -analyse lassen sich zeitlich nicht voneinander trennen, denn im Moment des Auftauchens einer Idee setzt auch die kritische Auseinandersetzung damit (= Analyse) ein.

Analyse von Lösungen Beispiel 1: Eine Umfrage mit 160 Radsportlern ergibt folgendes Ergebnis in Bezug auf Lebensdauer der Fahrradketten (bei einer Pflege von mindestens 1 mal pro Woche): Die neue Kette harmoniert nicht mit der Schaltvorrichtung.

Analyse von Lösungen Beispiel 2: Prognostizierte Anzahl der Studierenden Bei Beibehaltung der aktuellen Zulassungsbedingungen wird sich die Anzahl der Studierenden an der Universität Paderborn in Zukunft ansteigen. Bei einer weiteren Steigerung der Studierendenzahl / weiteren Hörsälen wird der zentrale Energieverteiler zusammenbrechen. Jahr

Beispiel 3: Systementwicklung Informationssysteme sind mehr als Hardware und Software: Aufgaben, Fertigkeiten, Management, Organisationsstrukturen Einführung von neuen Informationssystemen ist eine geplante organisatorische Umgestaltung Unternehmen müssen einen Informationssystemplan entwickeln Dazu Bestimmung langfristiger sowie kurzfristiger Anforderungen an ein Informationssystem Unternehmensanalyse „kritische Erfolgsfaktoren“ (KEF) Ggf. könnte hier noch eine/zwei Folien hinzugefügt werden, die die Unternehmensanalyse (im Buch wird die Befragung einer großer Anzahl Manager vorgestellt => Datenklassen-Matrix) KEF: (im Buch: persönliche Befragung Topmanager; Erstellung KEF => Entwicklung von System)

Entwicklung von Systemen mithilfe von KEF Abbildung 14.2

Wie IT Organisationen verändern kann Detailfolien, aus meiner Sicht ganz spannend; jedoch sehr viel Text und ggf. relativ aufwendig zu erklären. Quelle: Tabelle 14.2, S.913

Abschnitte des Informationssystemplans Tabelle 14.1

Abbildung 14.1

Idealtypische Aktivitäten Im Buch werden nun die einzelnen Punkte: Systemanalyse – Wartung einzeln erklärt; Aus Platzgründen entfernt Quelle: Abbildung 14.5, S.923 Quelle: Tabelle 14.3, S.925

Bewertung von Lösungen Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Bewertung Zur Bewertung gelangen Systemvarianten, die den zuletzt gültigen Zielsetzungen entsprechen bzw. bei denen Aussicht darauf besteht, dass sie durch Modifikationen diesen Zielsetzungen genügen werden. Eine diesbezügliche Ausscheidung von Varianten wird in der Phase der Systemanalyse vorgenommen. Die Bewertung erfolgt aufgrund des Zielsystems.

Bewertung von Lösungen Beispiel 1: Kette richtig spannen und anschließend Öl eintröpfeln. Eine günstige und schnelle Lösung. Die Kette war nur für 1200 km im Einsatz, d.h. sie kann noch für mindestens 2800 km und höchstens 3800 km eingesetzt werden, wenn sie regelmäßig gepflegt wird. Neue Kette anschaffen Eine neue Fahrradkette ist teuer. Eine neue Kette kann zu gleichem Problem führen, wenn sie nicht richtig gespannt oder regelmäßig gepflegt wird.

Bewertung von Lösungen Beispiel 2: Neue Hörsäle bauen Bau von zusätzlichen Hörsälen ist teuer. Dies kann aber mit Unterstützung des Bundeslandes ermöglicht werden. Löst das Problem endgültig (bzw. für eine längere Zeit). Weniger Studenten aufnehmen (Zulassungsbeschränkung einführen) Viele Jugendliche bekommen keine Gelegenheit zu studieren.  Schlecht für die Zukunft

Entscheidung Problemanalyse (Systemziele) Situations- analyse Zielformulierung (Entwurfsziele) Synthese von Systemlösungen Analyse von Systemlösungen Bewertung von Systemlösungen Entscheidung

Entscheidung Die letztendliche Lösungsauswahl sollte grundsätzlich durch den Auftraggeber erfolgen. Ist die Entscheidung über das System bzw. die Lösung getroffen, wird das weitere Vorgehen geplant.

Entscheidung über Lösungen Beispiel 1: Es wird für die Reparatur der Fahrradkette entschieden (Kette spannen und Öl eintröpfeln), da sie noch mindestens 2800 km halten kann und die Anschaffung einer neuen Kette sehr teuer ist.

Entscheidung über Lösungen Beispiel 2: Es wird für den Bau von zusätzlichen Hörsälen entschieden, da durch ansteigende Anzahl der Studierenden mehr Geld zur Verfügung steht. Außerdem ist es wichtig potentiellen Mangel an Akademikern zu vermeiden.

Liquidierung bzw. Anstoß zur Um- oder Neugestaltung
9. Planung von Produktionssystemen Anstoß zur Vorstudie = Entscheid über Fortführung des Auftrags, Änderung der Aufgabenstellung möglich Vorstudie Studien abbrechen Hauptstudie Teilstudien Projektmanagement Systembau Systemeinführung Systembenutzung Liquidierung bzw. Anstoß zur Um- oder Neugestaltung

Vorstudie/Konzeptionsphase Abgrenzung gegen Umwelt Problemstellung überprüfen Anforderungen spezifizieren Überprüfung und Präzisierung der gewählten Ziele Prüfung der vorhandenen Ressourcen und Techniken Lösbarkeit und Wirtschaftlichkeit prüfen Hauptstudie/Entwurfsphase Festlegung von Varianten und Lösungsmöglichkeiten Optimieren der Funktionstüchtigkeit und der Zielsetzung Beurteilung von Wirtschaftlichkeit und Funktionstüchtigkeit Prioritäten in der Entwicklung

Detailstudien/Ausarbeitungsphase Lösungskonzepte für Unter- und Teilsysteme Konkretisierung bis zur Realisierungsreife Systembau/Realisierung Erstellung und Errichtung von Anlagen Herstellung von Geräten Programmierung usw. Systemeinführung Inbetriebnahme Systembenutzung

Zielsetzung Kriterienplan Planen weiteres Vorgehen
9. Planung von Produktionssystemen Vorgehens-zyklus Lebensphasen Situations-analyse Zielsetzung Kriterienplan Konzept-entwurf Konzept-analyse Bewertung Entscheidung, Auswahl Planen weiteres Vorgehen Vorstudie Hauptstudie Teilstudien Systembau System-einführung System-benutzung

Haupt- und Detailstudien Vorstudie Systembau Kennnisse über System Grad des Wissens Zulässige Unkenntnisse Zeit

Zeitpe- riode 1 2 3 4 5 Vorstudie Rahmen-konzept Haupt-studie Gesamt-konzept Teil-studien Teilkon-zept US1 Teilkon- zept US2 Teil- konzept US3 Teil- konzept US4 Phase

Definition Methode: Eine Methode ist die Kombination von Regeln und Operationen zur Steuerung von Informationsprozessen. Entwurfsmethode: Hilfestellung bei Erkennen von Art, Umfang und Komplexität aller Faktoren, die für den Systementwurf relevant sind. Erstellung einer Dokumentationsstruktur zur lückenlosen Fixierung partiellen Wissens zielgerichtetem Suchen nach rational erfassbaren Lösungsmöglichkeiten Arbeitsteilung und Teamarbeit Fortschritte im Entwurfsprozess durch Entscheidungen, mit denen jeweils Lösungsmöglichkeiten ausgeschieden werden. Bei Nutzung aller Informationen über ein Problem/System: Reihenfolge von Entscheidungen maßgeblich beeinflussend auf Struktur des resultierenden Systementwurfes.

Strategie ist ein umfassender Plan zur Verwirklichung eines Ziels bzw. von Grundvorstellungen mittels aufeinander einwirkender dynamischer Systeme Was ist bei der Systemgestaltung zu tun ? Wann ist es zu tun und zwar generell und speziell in einer bestimmten Situation? Wie kann es getan werden? Lineare Strategien:  Sequentielle Folgen von Aktionen mit direkter Abhängigkeit. Starr und für Pioniersituationen ungeeignet.

Zyklische Strategien: Falls zusätzliche Abhängigkeiten notwendig Rückkopplungen: Zyklische Strategie. Berücksichtigung des Erkenntnisgewinns während der Systemplanung: Neben der besseren Einsicht in das zu entwerfende System können Änderungen innerhalb der Umsysteme technologischer, organisatorischer, ökonomischer oder politischer Natur sein: Es sind Punkte zu definieren, zu denen Rückkopplungen zu weniger detaillierten Ebenen sinnvoll sind

Verzweigte Strategien: Parallele und alternative Entwurfsarbeiten. Durch Einplanung von Alternativen Anpassung der Strategie an Ergebnisse vorangegangener Arbeitsschritte möglich. Ergebnisangepasste, jeweils anschließend neu fixierte Strategien  intelligentestes Vorgehen in Pioniersituation Keine Möglichkeit der Zeit- und Kostenvoraussage Entspricht menschlicher Eigenschaft, korrekt nur auf einwandfreie Impulse zu reagieren. Traditionelle Methode: Scheibchenweise – verbessern Weiterentwicklung Neuentwicklung Beizeit- oder Geldmangel Vorteile bei instrumentell ausgerichteter Lösung

Alternativen der Systementwicklung Traditionelle Systementwicklung Inkrementelle Entwicklung Concurrent Engineering Prototyping Rapid Application Development (RAD) Joint Application Design (JAD) Flexible Modelle der Entwicklung Varianten der agilen Entwicklung Extreme Programming (XP) Zur traditionellen Entwicklung wird noch das Wasserfall-Modell vorgestellt.

Beispiel für traditionelle Systementwicklung: Wasserfall-Modell
9. Planung von Produktionssystemen Beispiel für traditionelle Systementwicklung: Wasserfall-Modell Quelle: Abbildung 14.7, S.933

Standardanwendungssoftware: Eine Menge vorgefertigter, bereits codierter Anwendungssoftware zur Lösung bekannter betriebswirtschaftlicher Fragestellungen, die kommerziell angeboten werden. Viele Anwendungen sind für alle Unternehmen mehr oder weniger gleichartig Für solche Standardprozesse erledigt ein standardisiertes System die Anforderungen vieler Unternehmen Bei speziellen Anforderungen bieten viele Standardsoftwarepakete die Möglichkeit einer benutzerdefinierten Anpassung (Customizing) Bei Verwendung von Standardanwendungssoftware beinhaltet die Systemanalyse auch die Auswahl eines Pakets, häufig über eine Ausschreibung (RFP, Request for Proposal) Ggf. rauswerfen… Begriffe im Glossar erklärt

Auswirkung der Anpassung eines Softwarepakets auf die Gesamtimplementierungskosten Quelle: Abbildung 14.9, S.946

Endbenutzerentwicklung: Die Entwicklung von Informationssystemen durch Endbenutzer mit wenig oder keiner formalen Unterstützung durch Technikspezialisten. Entwicklung von Informationssystemen unter Verwendung von Programmiersprachen der vierten Generation, Grafiksprachen und PC-Softwaretools durch Endbenutzer Oft sehr viel schneller als die traditionelle Systementwicklung

Endbenutzerentwicklung im Vergleich zur traditionellen Systementwicklung Quelle: Abbildung 14.10, S.947

Untergliederung in Untersysteme bzw. Teilsysteme Ein System wird nach örtlichen oder funktionalen Gesichtspunkten in seine Untersysteme gegliedert, deren gegenseitige Beziehung man festhält und jede Komponente als System betrachtet Das Zusammenwirken der Untersysteme muss sichergestellt sein: Um die Komplexität zu beherrschen, sind Teilsysteme/Eigenschaften isoliert zu betrachten

Horizontale Vorgehensweise (von-innen-nach-außen/von-außen-nach-innen) Bei der Von-außen-nach-innen Vorgehensweise werden zuerst die Fragen nach den verlangten Leistungen und den Außenbeziehungen eines Systems beantwortet Dann wird untersucht, wie das System und die Komponenten entworfen werden können Bei der Anwendung der Von-innen-nach-außen Taktik werden erst Komponenten entwickelt und dann ihre Adaption an die Umwelt versucht

Beispiel: Entwurf eines PPS-Systems Von-innen-nach-außen: Zuerst Algorithmen und Ablauf definieren Dialogmasken und Datenerfassung definieren ( Gefahr: Daten können nicht beschafft werden) Von-außen-nach-innen: Dialogmasken und Datenerfassung definieren Algorithmen und Ablauf definieren (Algorithmen haben riesige Komplexität

Modelle im Systementwicklungsprozess Gestaltung von Informationssystemen im Rahmen des Systementwicklungsprozesses wird durch Modelle unterstützt Fachkonzepte DV-Konzepte Sichten Modelle sind Repräsentationen der Realität Sie repräsentieren ihre Originale aber in der Regel immer nur für bestimmte (erkennende oder handelnde) Subjekte (die Modellbenutzer) innerhalb bestimmter Zeitspannen unter Einschränkung auf bestimmte (gedankliche und tatsächliche) Operationen In der Wirtschaftsinformatik dienen Modelle vorwiegend der Beschreibung realer, soziotechnischer Systeme, ihrer Strukturen und Prozesse (Schütte, 2001)

Datenmodellierung Beschreibung der Struktur der Datenbasis eines Informationssystems Kernkomponenten sind Datenobjekttypen mit zugehörigen Attributen und Beziehungen Bekanntes Metamodell zur Datenmodellierung ist das Entity-Relationship-Modell (ERM) (vgl. Kapitel 4: Datenorganisation und Datenmanagement)

Datenflussansatz Quelle: Abbildung 14.11, S.956

Objektorientierter Ansatz Objektorientierte Entwicklung verwendet Objekt als Grundeinheit für Systemanalyse und -entwicklung und basiert auf den Konzepten von Klasse und Vererbung Kombination von Daten und spezifischen Prozessen, die an diesen Daten ausgeführt werden Hohe Verbreitung der Unified Modeling Language (UML) als Modellierungssprache Quelle: Abbildung 14.12, S.957

Definition "Ein Geschäftsprozess ist eine strukturierte, messbare Menge von Aktivitäten, die einen bestimmten Output für einen Kunden oder Markt produzieren. Es ist ein zeitlicher und örtlicher Ordnungsrahmen für Arbeitsaufgaben, der einen Anfang, ein Ende und eindeutig identifizierbare Inputs und Outputs hat.„ Davenport (1993) Beispiel: Produktion eines Motors, Wareneingang Beispiel: Geschäftsprozess Produktion Produktion Einzelteile Auto Input Output Karosserie- bau Lackierung End- montage Teilprozesse Zeit: 4 Tage Zeit: 1 Tag Zeit: 2 Tage Anfang Ende Hauptprozess

Geschäftsprozessorientierter Ansatz Betonen die Hinwendung von einer primär statischen und strukturorientierten Sicht eines Informationssystems zu einer dynamischen und verhaltenstheoretischen Sicht Modellierung umfasst neben Aufgabenebene auch Aufgabenträgerebene Weitverbreiteter geschäftsprozessorientierter Modellierungsansatz ist die Architektur integrierter Informationssysteme (ARIS) Ganzheitliche Betrachtung von Geschäftsprozessen Organisationssicht Funktionssicht Datensicht Leistungssicht Steuerungssicht (Integration der anderen Sichten)

Architektur integrierter Informationssysteme (Aris)
9. Planung von Produktionssystemen Architektur integrierter Informationssysteme (Aris) Quelle: Abbildung 14.16, S.963

9. Planung von Produktionssystemen - ARIS
Halbformale Darstellung der Ausgangssituation (z.B. Fehler bei der Auftrags- bearbeitung) Betriebswirtschaftliche Problemstellung Organisation (Welche Organisationseinheiten existieren?) Fachkonzept DV-Konzept Implementierung Fachkonzept Daten (Welche Informationen sind relevant?) Fachkonzept Fachkonzept DV-Konzept Funktion (Welche Funktionen werden durchgeführt?) DV-Konzept DV-Konzept Implementierung Implementierung Implementierung Steuerung Zusammenhang zwischen Daten, Funktion und Organisation

Verteilte Datenbanken
9. Planung von Produktionssystemen - ARIS Methoden Vorgangsketten- diagramm Ausgangssituation = relevante Bereiche für die Geschäftsprozessmodellierung Organigramm Organisation Netztopologie Protokolle: Ethernet, TCP/IP, Token Ring, etc. Ereignisgesteuerte Prozessketten (EPK) Entity- Relationship- Modell (ERM) Funktionsbaum Verteilte Datenbanken Fenster, Masken Trigger Daten Struktogramme Module Funktion Relationen Datenbank- beschreibung Programmsteuerung Programme Steuerung

9. Planung von Produktionssystemen - ARIS
Interaktionsmodell Org 1 Organisation Org 3 Org 2 Org 4 Org 5 E 1 F 1 ET 1 ET 2 ET 2 F 11 Org 2 F 11 F 12 E 2 F 111 ET 3 F 12 F 112 Daten Steuerung Funktion

Ereignisgesteuerte Prozesskette (EPK) Inhalt Darstellung der Ablauforganisation (=Prozesse) von Unternehmen als Folge von Funktionen und Ereignissen Darstellung der Verbindungen zwischen den Objekten der Daten-, Funktions- und Organisationssicht Für jede Funktion können Start- und Endereignisse angegeben werden Ereignisse sind Auslöser und Ergebnis von Funktionen Grundelemente der Prozessmodellierung: Ereignisse Funktionen Verknüpfungsoperatoren: UND, ODER, XOR

Ereignisgesteuerte Prozessketten Die ereignisgesteuerte Prozesskette beschreibt einen Geschäftsprozess als zeitlich-logische Abfolge betriebswirtschaftlicher Aufgaben Die zentralen Konstrukte zur Modellierung des Kontrollflusses sind Ereignisse (Events) Funktionen Verknüpfungsoperatoren (Konnektoren) Kontrollflusskanten Ereignisgesteuerte Prozessketten (ePK) sind semiformale grafische Darstellungen, die hauptsächlich dazu benutzt werden, um Geschäftsprozesse bzw. deren Modelle (Schemata) darzustellen ePKs stellen eine gebräuchliche, allgemein bekannte und werkzeuggestützte Methode der Geschäftsprozessmodellierung dar und werden darüber hinaus für das Geschäftsprozessmanagement eingesetzt

Basiselemente einer EPK
9. Planung von Produktionssystemen Basiselemente einer EPK Bezeichnung Symbol Definition Ereignis Ein Ereignis beschreibt das Eingetretensein eines Zustands, der eine Folge von Funktionen auslosen kann (z.B. „Auftrag eingegangen“) Funktion Eine Funktion (Aktivität) ist die Transformation eines Input- in eine Outputgröße und hat einen Bezug zu den Sachzielen der Unternehmung (z.B. „Auftrag erfassen“) Verfeinerung Eine Funktion kann durch eine weitere EPK detailliert werden. Dies wird durch ein zusätzliches Symbol neben der Funktion angezeigt. Prozessschnittstelle Die Prozessschnittstelle verweist auf einen vorhergehenden oder nachfolgenden Prozess. Ergänzend können die Objekte angegeben werden, die von einem Prozess an einen anderen Prozess übertragen werden. Konnektoren Die Konnektoren beschreiben unterschiedliche Formen der Prozessverzweigung. Es ist hierbei zwischen dem UND, dem INKLUSIVEN ODER und dem EXKLUSIVEN ODER zu unterscheiden Kontrollfluss Der Kontrollfluss gibt den zeitlich-sachlogischen Ablauf von Ereignissen und Funktionen wieder, d.h. er verdeutlicht, in welcher Reihenfolge die Funktionen ausgeführt werden. x

Ereignis Ein Ereignis beschreibt einen eingetretenen betriebswirtschaftlich relevanten Zustand eines Informationsobjektes, der den weiteren Ablauf eines Geschäftsprozesses steuert oder beeinflusst. grafische Darstellung: Kunden- anfrage geprüft Informationsobjekt Zustands- veränderung

Funktion Eine Funktion ist eine fachliche Aufgabe bzw. Tätigkeit an einem (Informations-) Objekt zur Unterstützung eines oder mehrerer Unternehmensziele Die Funktion ist Träger von Zeiten und Kosten. grafische Darstellung: Informationsobjekt Verrichtung Kundenanfrage prüfen

Verfeinerung Auftrag angenommen Auftrag prüfen Auftrag bearbeiten Auftrag geprüft Auftrag disponieren Auftrag bearbeitet

Prozessschnittstelle
9. Planung von Produktionssystemen Prozessschnittstelle Auftrags- annahme Auftrag eingetroffen Auftrag annehmen Auftrag angenommen Prozessschnittstelle Auftragsbearbeitung Auftragsannahme Auftrag angenommen Auftrag prüfen Auftrags- bearbeitung Auftrag geprüft

UND-Split: Parallelität wird durch UND-Verknüpfung modelliert
9. Planung von Produktionssystemen UND-Split: Parallelität wird durch UND-Verknüpfung modelliert Ein Ereignistyp ist Auslöser mehrerer Funktionstypen Antrag genehmigt Kundenkartei aktualisieren Kunde informieren Nach einem Funktionstyp treten mehrere Ereignistypen auf Kundendaten verfügbar Antragsdaten erfassen Tarif bekannt Kunden- nummer vergeben Prämie berechnen

UND-Join: Parallele Zweige können wieder zusammengeführt werden
9. Planung von Produktionssystemen UND-Join: Parallele Zweige können wieder zusammengeführt werden Mehrere Ereignistypen lösen gemeinsam einen Funktionstypen aus Kunden- nummer bekannt Prämie berechnet Versicherungs- schein ausfüllen Kundennummer vergeben berechnen Ein Ereignistyp tritt nach mehreren Funktionstypen ein Vertragsdaten bekannt Kundennummer vergeben Prämie berechnen Versicherungs- schein ausfüllen

ODER-Split: Verzweigungen werden durch ODER bzw. XOR modelliert
9. Planung von Produktionssystemen ODER-Split: Verzweigungen werden durch ODER bzw. XOR modelliert XOR: Genau ein Nachfolgepfad Antrag genehmigt genehmigen abgelehnt XOR ODER: Mehrere Nachfolgepfade möglich Kranken- versicherung Antragsdaten erfassen Pflege-

ODER-Join: Verzweigungen können ebenfalls wieder zusammenlaufen
9. Planung von Produktionssystemen ODER-Join: Verzweigungen können ebenfalls wieder zusammenlaufen XOR: Genau ein Pfad wurde durchlaufen Ablehnung geschickt Kopie ablegen Vertrag XOR ODER: Mehrere Pfade konnten durchlaufen werden Belegdaten erfasst Beleg verschicken Beleg kopiert

Der Prozess Urlaubsantrag als EPK
9. Planung von Produktionssystemen Der Prozess Urlaubsantrag als EPK XOR Wunsch nach Urlaub Antrag abgelehnt Antrag genehmigt Urlaubsantrag ausfüllen Mitarbeiter informieren Antrag ausgefüllt Mitarbeiter informieren Urlaubskartei aktualisieren kein Urlaub Antrag genehmigen Urlaub genehmigt

Regeln zu Prozessmodellierung: Splits
9. Planung von Produktionssystemen Regeln zu Prozessmodellierung: Splits XOR UND ODER XOR XOR UND Kein ODER bzw. XOR nach einem einzelnen Ereignis!!

Warum sind diese Verknüpfungen verboten?
9. Planung von Produktionssystemen Warum sind diese Verknüpfungen verboten? Kunde per Brief informieren Antrag genehmigt Beispiel: Kunde telefonisch informieren XOR Antrag genehmigt Kunde per Brief informieren Kunde telefonisch XOR Beispiel:

Regeln und Konventionen zur Erstellung ereignisgesteuerter Prozessketten Zu den verschiedenen Verbindungen zwischen Objekten sowie den allgemeinen Notationen einer ePK gehören einige Regeln und Konventionen: Regel 1: Ein ePK-Modell muss mit einem Ereignis, dem sogenannten Startevent, beginnen Regel 2: Ein ePK-Modell muss mit einem Ereignis, dem sogenannten Endevent, enden Regel 3: Funktionen und Ereignisse müssen abwechselnd vorkommen Regel 4: Bezüglich jeder Verbindung zwischen Ereignissen und Funktionen gilt, dass jedes Event und jede Funktion nicht mehr als einen Input- und einen Output-Konnektor haben dürfen

Beispiel: Ereignisgesteuerte Prozessketten
9. Planung von Produktionssystemen Beispiel: Ereignisgesteuerte Prozessketten EPK: Wareneingangsbearbeitung EPK: Fertigungsdurchführung Wareneingangs-bearbeitung Ware ist eigentroffen Bestellung Ware ist freigegeben Fertigungs-termin ist eingetreten Lieferschein prüfe Ware Warenein-gangstelle Prüfergebnis V XOR durchführen Fertigung Fertigung Ware ist freigegeben Ware ist gesperrt Ware wurde abgelehnt V Fertigungs-durchführung Qualitätsprüfung Material ist eingelagert Fertigungs-auftrag ist abgeschlossen

Erweiterte EPK (eEPK) Beispiel
9. Planung von Produktionssystemen Erweiterte EPK (eEPK) Beispiel Kundenauftrag eingetroffen Kunden- auftrag Kundenauftrag erfassen Vertrieb Kundenauftrag erfasst Produkt- daten Auftrags- daten Kundenangebot techn. prüfen Technischer Vertrieb Kunden- auftrag KA techn. nicht machbar KA techn. machbar

EPK - Abschließende Bemerkungen EPK sind eine weit-verbreitete Modellierungsmethode für Geschäftsprozesse EPK werden eingesetzt u.a. von SAP AG zur Modellierung von SAP Businsess Workflow IDS Scheer AG als Basis der ARIS eBusiness Suite EPK sind nicht automatisierbar Ereignisse sind nur verbal beschrieben Können für Verzweigungen nicht interpretiert werden nicht geeignet für Workflow-Modellierung / Ablaufsteuerung EPK sind nur eingeschränkt geeignet für Simulation Probleme mit der Semantik der ODER-Verknüpfungen wie werden Entscheidungen getroffen wann werden Entscheidungen getroffen Fehlende semantische Fundierung EPK nur für Modellierung auf Fachebene

Frage 1: Ereignisgesteuerte Prozessketten (EPK) Gegeben sind die folgenden Ausschnitte aus unterschiedlichen EPK: a) b) c) d)

Richtig Falsch EPK a) und c) sind syntaktisch korrekt. EPK b) ist syntaktisch korrekt. Ersetzt man im EPK c) den ODER-Operator durch einen XOR-Operator, ist EPK c) sinnvoll. EPK d) ist sinnvoll. EPK b) ist falsch, da auf ein Ereignis niemals zwei Funktionen folgen dürfen.

Frage 2: Ereignisgesteuerte Prozessketten (EPK) Nachdem sich das Finanzamt angekündigt hat, informiert der Firmenchef eines mittelständischen Unternehmens seinen Buchhalter und seine Sekretärin. Die Sekretärin kümmert sich darum, dass ein Besprechungsraum frei geräumt wird, in dem die Beamten des Finanzamtes arbeiten können. Parallel dazu holt sich der Buchhalter bei dem Steuerberater des Unternehmens Rat. Nach der Beratung durch den Steuerberater stellt der Buchhalter schon einmal mögliche, benötigte Unterlagen zusammen. Beide Tätigkeiten sollten vor der Prüfung abgeschlossen sein. Gehen Sie davon aus, dass diese Beschreibung korrekt in eine EPK übersetzt wurde. Richtig Falsch In dieser EPK wird mindestens ein UND-Operator verwendet. In dieser EPK wird mindestens ein ODER-Operator verwendet. In dieser EPK werden mindestens ein UND- und mindestens ein ODER-Operator verwendet. In dieser EPK kommen nur die Organisationseinheiten „Firmenchef“ und „Sekretärin“ vor. In dieser EPK gibt es zwei Startereignisse.

Frage 3: Ereignisgesteuerte Prozessketten (EPK) Ein Kunde spricht in einem Fahrrad-Fachgeschäft einen Verkäufer an und bittet ihn um ein Beratungsgespräch. Der Verkäufer fragt den Kunden, ob er Interesse an einem Mountainbike, an einem Rennrad oder an einem Treckingrad hat. Nachdem der Kunde sich entschieden hat, ermittelt der Verkäufer für Mountainbikes und Treckingräder die benötigte Rahmengröße für den Kunden, bei Rennrädern wird in dem Fachgeschäft nur eine einzige Rahmengröße angeboten. Im nächsten Schritt erkundigt sich der Verkäufer nach der Preisvorstellung des Kunden. Danach zeigt er dem Kunden drei unterschiedliche Modelle (drei verschiedene Mountainbikes, drei verschiede Rennräder oder drei verschiedene Treckingräder), die alle jeweils den Ansprüchen des Kunden entsprechen. Anschließend entscheidet sich der Kunde für eines dieser Modelle, möchte mehr Modelle sehen da er noch unentschlossen ist, oder beendet das Verkaufsgespräch.

Richtig Falsch Modelliert man den beschriebenen Prozess als EPK, so enthält diese mindestens einen XOR-Operator. Modelliert man den beschriebenen Prozess als EPK, so enthält diese mindestens einen UND-Operator. Modelliert man den beschriebenen Prozess als EPK so enthält diese neben der Organisationseinheit „Verkäufer“ keine weitere Organisationseinheit. Modelliert man den beschriebenen Prozess als EPK, so enthält diese genau ein Startereignis. Eine EPK muss immer mit einer Funktion beginnen und aufhören.

Frage 4: Alternativen der Systementwicklung Sie haben verschiedene Alternativen der Systementwicklung kennengelernt. Erläutern Sie kurz das Wasserfall-Modell (Traditionelle Systementwicklung). Für welche Art von Projekten der Systementwicklung wird das Wasserfall-Modell häufig eingesetzt? Welche Vor-und Nachteile birgt das Vorgehen bei der Systementwicklung nach dem Wasserfall-Modell?

Frage 5: Systementwicklung Richtig Falsch Geschäftsprozesse sollten insbesondere für nicht regelmäßig auftretende Aktivitäten definiert werden. Dies hilft den beteiligten Mitarbeitern dabei auch im Rahmen dieser Aktivitäten stets die richtigen Schritte auszuführen. Die Unterstützung von Geschäftsprozessen durch IT kann zu erheblichen Verbesserungen bei der Prozessdurchlaufzeit führen. Aus diesem Grund sollten Unternehmen ihre IT stets möglichst genau an die bestehenden Prozesse anpassen. Geschäftsprozessmanagement beinhaltet Workflow-Management, Geschäftsprozessmodellierung, Qualitätsmanagement und Änderungsmanagement, Werkzeuge für die standardisierte Neueinrichtung der Geschäftsprozesse und die Überwachung und Analyse von Prozessen. Informationssysteme setzen sich vor allem aus Hardware und Software zusammen. Idealtypisch werden während der Systementwicklung nach dem Wasserfallmodell die folgenden Phasen durchlaufen: Systemanalyse, Systementwurf, Programmierung, Testen, Migration und Produktion und Wartung.

Frage 6: Für welche Arten von Projekten wird das Wasserfall-Modell häufig eingesetzt? Frage 7: Was sind die Vor- und Nachteile des Wasserfall-Modells?

Grundlagen der computergestützten Produktion und Logistik W1332

Ähnliche Präsentationen

Präsentation zum Thema: "Grundlagen der computergestützten Produktion und Logistik W1332"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Grundlagen der computergestützten Produktion und Logistik W1332

Ähnliche Präsentationen

Präsentation zum Thema: "Grundlagen der computergestützten Produktion und Logistik W1332"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback