Sie sind auf Seite 1von 428

WIRTSCHAFTSWISSENSCHAFT

EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 1 – Betriebliche Aufgaben und


Anwendungssysteme

Sie lernen in diesem Kapitel,

 den Gegenstandsbereich der Wirtschaftsinformatik kennen


(Wirtschaftsinformatik untersucht, wie (1) betriebliche Prozesse durch
(2) Einsatz von IT (3) verbessert werden können.)
 wie die Vorlesung OWIN aufgebaut und gegliedert ist
 die wichtige Aufgabe des Bestandsmanagements und die
Grundzusammenhänge des Bestellmodells kennen
 wie sich aus Bestellmengen die durchschnittlichen Bestände über die
Zeit ergeben
 eine Systematik betrieblicher Aufgaben kennen
 den Begriff Anwendungssystem als grundlegendes Konzept der
Wirtschaftsinformatik kennen
 Daten und Information als Grundbegriffe der Wirtschaftsinformatik
kennen und unterscheiden

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

1 Betriebliche Aufgaben und


Anwendungssysteme

Laudon, Laudon, Schoder (2010):


Anwendungssysteme (Kapitel 8)
Fallstudie:
Leiner Health Products

Leiner Health Products


• Größter Hersteller von Vitaminpräparaten
und Nahrungsergänzungsmitteln
• Zweitgrößter Hersteller von nicht
verschreibungspflichtigen Arzneimitteln
in den USA

Quelle: Laudon, Laudon, Schoder (2006), S. 99


© Professur für Information Systems Engineering, Prof. Dr. Holten 1-2
Wirtschaftsinformatik

Kernfrage:
Wie können (1) betriebliche Prozesse IT /
durch (2) Einsatz von IT (3) Method
verbessert werden?

Grundlegende Themenbereiche der


Wirtschaftsinformatik sind durch
folgende Fragen charakterisiert:
1. Was sind betriebliche Prozesse?
2. Was bewirkt der Einsatz von IT? Business
Process
3. Wann ist eine Verbesserung
betrieblicher Prozesse gegeben?
© Professur für Information Systems Engineering, Prof. Dr. Holten 1-3
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 1-4


Fallstudie:
Leiner Health Products

Fragen der Buchhaltung und der Finanzabteilung:


• Wie ist das Verhältnis von Einnahmen und Ausgaben?
• Wie hoch sind die offenen Außenstände?
• Wie schnell werden unsere Rechnungen bezahlt?
• Welche Finanzmittel sind wann verfügbar?
• Welche Kunden sind im Zahlungsrückstand?

© Professur für Information Systems Engineering, Prof. Dr. Holten 1-5


Fallstudie:
Leiner Health Products

Fragen im Marketing:
• Zu welchen Preisen sollen die Produkte angeboten
werden?
• Um welchen Prozentsatz lässt sich der Umsatz durch
Rabatte und Werbeaktionen steigern?
• Welche Preise und Sonderangebote sollen wann gelten?
• Sind die Kunden zufrieden?
• Werden Reklamationen zügig bearbeitet?

© Professur für Information Systems Engineering, Prof. Dr. Holten 1-6


Fallstudie:
Leiner Health Products

Fragen im Vertrieb:
• Wer sind die besten Kunden?
• Welche Produkte sind am
gewinnbringendsten?
• Welche Rechnungssummen ergeben sich aufgrund der
aktuell geltenden Konditionen und Werbeaktionen?

© Professur für Information Systems Engineering, Prof. Dr. Holten 1-7


Fallstudie:
Leiner Health Products

Fragen im Bereich Operations:


• Welche Artikel müssen besonders schnell geliefert
werden?
• Wann muss produziert werden, um pünktlich liefern zu
können?
• Welche Kapazitäten sind vorhanden, um die Aufträge zu
bearbeiten?
• Was muss für die Bearbeitung der Aufträge bestellt
werden?
• Wie viel Material soll eingekauft werden?
• Wie viel Material ist noch vorhanden?

© Professur für Information Systems Engineering, Prof. Dr. Holten 1-8


Bestandsmanagement
Lernziele

 Lernen, warum Bestandsmanagement wichtig ist


 Lernen, grundlegende Modelle des Bestandsmanagements
mathematisch zu formulieren, zu lösen und zu
interpretieren
– Bei deterministischer Nachfrage
 Verstehen, welche Annahmen dem Klassischen
Bestellmodell zugrundeliegen

© Professur für Information Systems Engineering, Prof. Dr. Holten 1-9


Typische Situation Lebensmittelhandel

Trotz... ... viele Lücken im Regal

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


 Hoher durchschnittlicher
Lagerbestände
 Hohen manuellen Planungsaufwands
 Hohen Transportkosten
 Hohen Aufwands in den Filialen
 Häufiger „Feuerlöschaktionen“
 ...

Ursachen
 Schlechtes Bestandsmanagement
 Ineffektive interne Prozesse
 Schlechte Lieferantenkoordination
 ...
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 10
Lagerbestände entlang der Supply Chain

Supply-Chain-Stufe
Lager

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Glas- Glas-
Sand Sand Glas
garn gewebe

Lami- Leiter-
Handy Handel
nat platte

Lagerbestandsarten
Unser  Endproduktbestand
Fokus  Zwischenproduktbestand Lagerbestand in
Deutschland: ca. 500
 Rohstoffbestand
Milliarden Euro
 Work-in-Progress (WIP)
 Pipelinebestand

Quelle: Deutsche Bundesbank Monatsbericht Dezember 2001

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 11


iPhone Supply Chain

Glas- Glas-
Sand Sand Glas
garn geweb
e
Supply-Chain-Stufe
Leiter
Lami-
nat
-
platte
Hand
y
Handel
Lager

Leiter-
Handy Handel
platte

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 12


Entscheidungen im
Bestandsmanagement

Wann und welche Lagerbestand

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Menge sollte ich Stück
bestellen?

Welche
Menge:
Bestell-
menge x
Wann:
Bestell-
punkt r

Zeit
Lieferzeit LT

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 13


Modellannahmen

1. Nachfragerate beträgt μ. Nachfrage ist deterministisch und

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


konstant
2. Bestellungen werden unverzüglich geliefert
3. Keine Beschränkungen der Bestellmengen
4. Keine Mengenrabatte
5. Ein einziges Produkt
6. Relevante Kosten sind (fixe und variable) Bestellkosten und
Lagerhaltungskosten
7. Ziel ist, den Bestellzeitpunkt und die Bestellmenge zu
bestimmen, die die durchschnittlichen Kosten minimieren

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 14


Grundlegende Zusammenhänge

μ Nachfragerate [Stück pro Jahr]


x Bestellmenge [Stück]

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


x
T Zykluslänge [Jahre] T
m
m
N Bestellungen pro Jahr [-]  N 
x
x
Durchschnittsbestand [Stück] 
2
Lagerbestand
Stück
x
-m

Zeit
T
Jahre
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 15
Operative (Anwendungs-)Systeme
Beispiel Fertigung und Produktion

Überblick über ein Materialwirtschaftssystem

Quelle: Laudon, Laudon, Schoder (2006), S. 92


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 17
Anwendungssystem

• Anwendungssystem (AS): Ein System, welches alle


für ein bestimmtes betriebliches Aufgabenfeld
entwickelten und eingesetzten Programme (Software),
Technik (IT) und Daten beinhaltet.

Quelle: Laudon, Laudon, Schoder (2009), S. 17


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 18
Beziehung zwischen Unternehmen und
Anwendungssystemen

Quelle: Laudon, Laudon, Schoder (2006), S. 31, 99


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 19
Arten von Anwendungssystemen

Quelle: Laudon, Laudon, Schoder (2006), S. 82


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 20
Operative Systeme
Beispiel Wareneingang in SAP

© Professur für Information Systems Engineering, Prof. Dr. Holten Quelle: Wareneingang in SAP 1 - 21
SAP

• Die SAP SE mit Sitz im baden-württembergischen Walldorf ist ein


deutscher Softwarehersteller. Nach Umsatz ist SAP der größte
europäische Softwarehersteller sowie der weltweit viertgrößte.

• Mitarbeiterzahl: über 100.000


• Gründer: Dietmar Hopp, Hasso Plattner, Claus Wellenreuther, Klaus
Tschira, Hans-Werner Hector

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 22


Operative Systeme
Beispiel Lohnbuchhaltung

Quelle: Laudon, Laudon, Schoder (2006), S. 85


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 23
Operative Systeme
Beispiel Lohnbuchhaltung

• Operatives System für die Lohnbuchhaltung


(branchenneutral)
• Überwachung der Zahlungen an die Mitarbeiter
• Datenbank besteht aus verschiedenen eindeutigen
Elementen:
• z.B. Name, Adresse, Personalnummer,
Zahlungsdatum, Betrag
• Elemente aus Datenbank werden kombiniert, um
Dokumente zu erstellen:
• Berichte für Geschäftsführung
• Berichte für Finanzämter Gehalt

• Gehaltsabrechnungen für Mitarbeiter

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 24


Anwendungssysteme auf operativer
Ebene

• Überwachung grundlegender Aktivitäten des


Unternehmens
• Hauptzweck: Beantwortung von Routinefragen
• Aufgaben, Ressourcen und Ziele sind vorgegeben und
stark strukturiert

Operative Systeme:
Anwendungssysteme, die die täglichen,
für den Geschäftsbetrieb notwendigen
Routinetransaktionen ausführen und
aufzeichnen; diese Systeme werden auf
der operativen Ebene eines
Unternehmens eingesetzt.
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 25
Operative Systeme

• Typische Fragen an operative Systeme:


"Wie viele Teile sind auf Lager?",
"Hat Herr XY schon bezahlt?"
• Beispiele für branchenneutrale operative Systeme:
• Finanz- und Rechnungswesen
• Personalwesen
• Beschaffung
• Vertrieb
• Beispiele für branchenspezifische operative
Systeme:
• Systeme für die Fertigungsindustrie,
• für Handelsunternehmen oder
• die Versicherungswirtschaft
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 26
Anwendungssysteme auf
Managementebene

• Managementinformationssysteme (MIS)
• Dienen der Planung, Kontrolle und
Entscheidungsfindung auf der mittleren
Managementebene
• Prüfen, ob alles ordnungsgemäß funktioniert
• Beschäftigen sich i.d.R. mit unternehmensinternen (statt
mit externen) Daten

Managementinformationssysteme (MIS):
Systeme auf der Managementebene eines
Unternehmens, die durch die Bereitstellung
von Standardübersichtsberichten sowie
Berichten über Abweichungen der Planung,
Kontrolle und Entscheidungsfindung dienen.
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 27
Anwendungssysteme auf
Managementebene

Zusammenspiel von MIS und operativen Systemen

Quelle: Laudon, Laudon, Schoder (2009), S. 438


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 28
Anwendungssysteme auf
Managementebene

• Erhalten ihre Daten von den operativen Systemen


• Speichern auch vergangenheitsbezogene Daten
(bspw. der Lagerbestand von vor 2 Wochen)
• Keine augenblicklichen Informationen, sondern Berichte
in Form von Zusammenfassungen
• Berichte enthalten aggregierte wöchentliche,
monatliche oder jährliche Ergebnisse
• Bspw. die Gesamtmenge an Salat, die von
einer Fast-Food-Kette im aktuellen
Quartal verbraucht wurde

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 29


Anwendungssysteme auf
Managementebene

Beispielbericht eines MIS

Quelle: Laudon, Laudon, Schoder (2009), S. 439


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 30
Anwendungssysteme auf
Managementebene

• Entscheidungsunterstützungssysteme (EUS)
• Helfen Managern beim Treffen von einmaligen
Entscheidungen
• Helfen bei Problemen ohne festgelegten Lösungsweg
• Häufig Einbeziehung externer Quellen (z.B. Aktienkurse)
• I.d.R. benutzerfreundliche, interaktive Software, die
ohne großen Schulungsaufwand benutzt werden kann

Entscheidungsunterstützungssysteme (EUS):
Systeme auf der mittleren Managementebene von
Unternehmen, die Daten mit ausgeklügelten
analytischen Modellen oder Datenanalysewerkzeugen
kombinieren, um schwach strukturierte oder
unstrukturierte Entscheidungsfindungsprozesse zu
unterstützen.

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 31


Anwendungssysteme auf
Managementebene

EUS für die Kalkulation von Seefracht

Quelle: Laudon, Laudon, Schoder (2006), S. 88


Bspw. "Wie hoch ist die optimale
Geschwindigkeit, bei der ein bestimmtes
Schiff seinen Gewinn optimieren und
gleichzeitig den Lieferplan einhalten kann?"

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 32


Anwendungssysteme auf strategischer
Ebene

• Unterstützungssysteme für die


Führungsebene (FUS)
• auch: Executive Support Systems (ESS)
• Unterstützung bei strategischen Problemstellungen
und langfristigen Trends
• Hilfe bei nicht strukturierten Entscheidungen ohne
generelles Verfahren zur Lösungsfindung
• Filtern, verdichten und verfolgen kritische Daten

Unterstützungssysteme für die Führungsebene:


Systeme auf der strategischen Ebene des
Unternehmens, die die unstrukturierte
Entscheidungsfindung insbesondere durch erweiterte
Grafik- und Kommunikationsfunktionen unterstützen
sollen.

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 33


Anwendungssysteme auf strategischer
Ebene

• Welche Auswirkungen haben Änderungen im


externen Umfeld auf das Unternehmen?

• Exemplarische Fragestellungen, die durch FUS


unterstützt werden:
• "In welchen Märkten wollen wir tätig sein?"
• "Wie wird die Beschäftigungssituation in 5 Jahren
aussehen?"
• "Welche Produkte sollen wir in den nächsten Jahren
anbieten?"
• "Können wir uns durch Unternehmenskäufe
vor zyklischen Geschäftsschwankungen
schützen?"

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 34


Anwendungssysteme auf strategischer
Ebene

Quelle: Screenshot aus MicroStrategy 8


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 35
Anwendungssysteme auf strategischer
Ebene

Modell eines typischen Unterstützungssystems für


die Führungsebene (FUS)

Quelle: Laudon, Laudon, Schoder (2006), S. 89


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 36
Beziehungen zwischen den
Anwendungssystemen

• Operative Systeme sind i.d.R. die Hauptdatenquelle für


andere Systeme
• ESS sind primär Empfänger von Daten aus den
Systemen unterer Ebenen

Quelle: Laudon, Laudon, Schoder (2006), S. 90


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 37
Anwendungssysteme aus funktionaler
Sicht

Quelle: Laudon, Laudon, Schoder (2006), S. 84


© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 38
Blickpunkt Technik – UPS

United Parcel Service (UPS)


• Gründung 1907
• Weltweit größtes Paketzustellungsunternehmen
• Täglich 13,6 Mio. Pakete und Dokumente in mehr als
200 Ländern
• Investitionen von über 1 Mrd. US-Dollar in 10 Jahren
in IT und Informationssysteme
• Verbesserung des Kundenservice
• Optimierung von Betriebsabläufen
• Kostensenkung

Das Firmenmotto:
• "Den besten Service und die günstigsten Preise."
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 39
Blickpunkt Technik – UPS

Automatisches
Paketverfolgungssystem
Paketinformationen

Informationen über Telefonische


Auslieferungsstatus Kundenanfrage
Paket mit
eindeutigem Barcode
UPS Zentralrechner

PC mit
Internetverbindung

Zustelldaten (Zeit,
Unterschrift, Fahrer, etc.)

UPS-Lieferwagen mit Delivery Information


Mobilfunkverbindung Acquisition Device (DIAD)
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 40
Blickpunkt Technik – UPS

Paketnummer

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 41


Grundbegriffe – Daten und Informationen

• Wissen: Vorstellungsinhalte, die Überzeugungen über


die Wahrheit von Feststellungen zum Inhalt haben
(Wittmann, 1959)
• Information: Explizites (sprachlich ausgedrücktes)
Wissen, das von Menschen zur Erfüllung betrieblicher
Aufgaben genutzt oder bereitgestellt wird 
Zweckorientiertes Wissen
(Wittmann, 1959)
• Daten: Zeichen (Symbole), die aufgrund von
Abmachungen Informationen in einer für die
elektronische Verarbeitung geeigneten Form darstellen
• Kommunikation: Austausch von Informationen
zwischen Menschen sowie Austausch von Daten zwischen
Maschinen
Quellen: Wittmann (1959); Holten (1999), S. 71 ff.; Teubner (1999), S. 16 ff.
© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 42
Grundbegriffe – Daten und Informationen

• Daten: Zeichen (Symbole)

• Wissen: Vorstellungsinhalte, Wahrheit von Aussagen

• Information: Zweckorientiertes Wissen

• Kommunikation:
• Austausch von Informationen zwischen Menschen
• Austausch von Daten zwischen Maschinen

UPS-Lieferwagen mit Delivery Information


Mobilfunkverbindung Acquisition Device (DIAD)

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 43


Grundbegriffe – Daten und Informationen

Daten Informationen
für die betriebliche Aufgabe
"Vertriebscontrolling"
r o ße n
Di e g ..
- MINUS - Pr ei s
e.
Vertriebsbereich:
Adalbertstr. 44 Geschäftstätte
60486 Frankfurt Südwest
bzw. Region
Pos. MwSt. EUR

1 3,5% Milch 1L E 0,55 Markt:


2 Maultaschen E 1,19
Supermarkt 122
Artikel 3 Maultaschen E 1,19
Preis
4 Korkenzieher V 4,99
5 Gerieb. Käse E 0,99
Artikel-Nr.:
12223
Summe EUR 8,91
Zahlungsweise BAR EUR 10,00

Rueckgeld EUR 1,09


Beschreibung: Maultaschen
MwSt 7% (E) von 3,92 0,26
MwSt 16% (V) von 4,99 0,69 Verkaufte Stückzahlen:
Kassen-Nr.
NETTO-UMSATZ 7,96
Bon-Nr. 7.156
Kasse: 002/0018 Bon: 0639PE01Z

Zeit-Datum
Datum 08.03.2006 Zeit 14:25:00 Zeit-Uhrzeit Kum. Jahresumsatz:
1 Monat Rückgaberecht gegen
Vorlage des Kassenbons! € 8515,64

© Professur für Information Systems Engineering, Prof. Dr. Holten 1 - 45


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 2 – Das klassische Bestellmodell

Sie lernen in diesem Kapitel,

 wozu Kostenfunktionen dienen


 wie optimale Bestellmengen und Bestellpunkte berechnet werden
 wie die optimale Bestellmenge, der Bestellpunkt und Kostengrößen mit
der Programmiersprache Python berechnet werden können
 Variablen und Zuweisungen in Python kennen
 welche Datenstrukturen es in Python gibt
 die Prinzipien von Eingabe-Verarbeitung-Ausgabe und von Programm-
gesteuerten Rechnern kennen

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

2 Das klassische Bestellmodell

Thonemann, Ulrich (2010): Operations


Management (Kapitel 5)
Fallstudie: Leiner Health Products

Leiner Health Products


• In kurzer Zeit über 150 Kunden,
u.a. Wal-Mart, Sam's Club,
Costco Wholesale Corp.

• Mehr als 4.000 verschiedene


Vitaminproduktlinien

• Produktion in 5 Fabriken

 Starkes Wachstum!
 Erfolg?

© Professur für Information Systems Engineering, Prof. Dr. Holten 2-2


Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 2-3


Fallstudie: Leiner Health Products
KRISE!

Probleme durch das schnelle Wachstum:


• Schlechtes Informationsmanagement
• Wer sind die besten Kunden?
• Welche Produkte sind am
gewinnbringendsten?
• Welche Kunden sind im Zahlungsrückstand?
• Welche Artikel müssen besonders schnell geliefert
werden?
• Einnahmen und Ausgaben wurden in der Buchhaltung
anhand der Papierunterlagen verwaltet.
• Offene Außenstände (17 Mio. USD pro Jahr weniger
Umsatzerlös)
• Wal-Mart drohte, sich andere Lieferanten zu suchen
© Professur für Information Systems Engineering, Prof. Dr. Holten 2-4
Fallstudie: Leiner Health Products
KRISE!

Wege aus der Krise…


• Beauftragen der Unternehmensberatung
Alvarez & Marsal Inc. (A&M) aus New York

Ergebnisse & Empfehlungen von A&M:


• Einige Kunden kosten Leiner mehr, als sie einbringen
• Reduzierung des Kundenstamms um 50%
• Verringerung der hergestellten Produkte um 60%
• Schließung von 3 der 5 Fabriken

© Professur für Information Systems Engineering, Prof. Dr. Holten 2-5


Fallstudie: Leiner Health Products
KRISE!

Das Hauptproblem…
• … waren die zu großen Lagerbestände
• Es wurde fast immer mehr eingekauft, als verarbeitet
werden konnte
• Beschaffungsbereich bestellte Material
nach freiem Ermessen, um Kosten zu sparen
Wann und welche
Menge sollte ich
bestellen?

© Professur für Information Systems Engineering, Prof. Dr. Holten 2-6


Bestellmodell
Grundlegende Zusammenhänge
μ Nachfragerate [Stück pro Jahr] Lagerbestand
Stück
x Bestellmenge [Stück] x

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


-m
x
Durchschnittsbestand [Stück]  x
2 2

Zeit

Hier werden unterschiedliche Dinge gleichzeitig betrachtet! Jahre

Bestellen Lagern Verkaufen


Stück pro Durchschnittlicher Stück pro Jahr
Bestellung Lagerbestand in μ
x Stück pro Jahr
x

2

Wie können unterschiedliche Dinge vergleichbar gemacht werden?

Bewertung mit Geldgrößen!

© Professur für Information Systems Engineering, Prof. Dr. Holten 2-7


Relevante Kosten Bestandsmanagement

Kosten / Jahr Erläuterung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Variable Bestellkosten  Sind proportional zur bestellten Menge
 Enthalten Einstandspreise, mengenproportionale
Transportkosten, etc.

Fixe Bestellkosten  Fallen je Bestellung an, unabhängig von der Bestellmenge


 Enthalten Verwaltungskosten, Materialhandhabungskosten,
etc., wenn diese je Bestellung anfallen
 Enthalten keine Overheadkosten, die durch die Bestellung
nicht beeinflusst werden
Lagerhaltungskosten  Fallen je gelagerter Einheit an
 Enthalten Opportunitätskosten des gebundenen Kapitals,
Kosten für den Lagerraum (wenn diese abhängig von der
gelagerten Menge sind), etc.

Fehlmengenkosten  Fallen je nicht gelieferter oder verspätet gelieferter Einheit


oder Lieferung an
 Enthalten Kosten der Nachlieferung, Loss-of-Goodwill-
Kosten, etc.
© Professur für Information Systems Engineering, Prof. Dr. Holten 2-8
Herleitung Kostenfunktion
h Lagerhaltungskostensatz [€/Stück/Jahr]
Durchschnittsbestand [Stück] 
x } Lagerhaltungskosten  h 2x [€/Jahr]
2
K Fixe Kosten je Bestellung [€/Bestellung] m
m
N  [Bestellungen/Jahr]
} Fixe Bestellkosten  K
x
[€/Jahr]
x
Kosten/Jahr c Variable Stückkosten [€/Stück]; m [Stück/Jahr]
Variable Bestellkosten = cm [€/Jahr]

Lager-
haltungs-
kosten

Fixe Bestellkosten

Variable Bestellkosten

X Bestellmenge
© Professur für Information Systems Engineering, Prof. Dr. Holten 2-9
Herleitung Kostenfunktion

Gesamtkostenfunktion
m x
Z(x)  cm  K  h
x 2
Gesamtkosten
Kosten/Jahr

Lager-
haltungs-
kosten

Fixe Bestellkosten

Variable Bestellkosten

x* X Bestellmenge
© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 10
Optimierung Kostenfunktion

Kostensätze Kostenfunktionen
c Variable Stückkosten [€/Stück] Variable Bestellkosten = cm [€/Jahr]

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


K Fixe Kosten je Bestellung [€/Bestellung] m
 Fixe Bestellkosten  K [€/Jahr]
x
h Lagerhaltungskostensatz [€/Stück/Jahr] x
 Lagerhaltungskosten  h [€/Jahr]
2

Entscheidungsvariablen Gesamtkostenfunktion
x Bestellmenge [Stück] m x
Z(x)  cm  K  h
r Bestellpunkt [Stück] x 2

Kosten/
Gesamtkosten
Jahr
Lagerhaltungskosten

Z(x* )
Variable Bestellkosten = cm
sind NICHT entscheidungsrelevant!

Fixe Bestellkosten

x* x
© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 11
Optimierung Kostenfunktion

Gesamtkostenfunktion Z(x)
m x
Z(x)  cm  K  h x > 0:

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


x 2
Z(x)   wenn x  
x Z(x)   wenn x  0.
Daher globales Minimum
bei x > 0
Notwendige Bedingung

1. Ableitung

Konvexität?
2. Ableitung

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 12


Gesamtkosten bei optimaler
Bestellmenge
Kosten
2mK Für x = x* gilt
Tausend €/Jahr x* 
h
4 Fixe Bestellkosten

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


3 Gesamt-
kosten*
Lagerhal-
2 Lagerhaltungskosten
tungskosten

1 Fixe Bestell-
kosten
Variable Bestellkosten
0
0 10 20 30 40 Gesamte Handlingskosten * :
Bestellmenge Stück

Gesamtkosten im Optimum

Z(x* )  2Kmh  mc

* Ohne variable Bestellkosten


© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 14
Beispiel

 Die Nachfrage beträgt 20 Stück pro Woche (Ann.: 50 Wochen)


 Das Schreiben einer Bestellung kostet 10 € pro Bestellung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


 Das Entladen des LKWs kostet 10 € pro Belieferung
 Der Einkaufspreis beträgt 390 € pro Stück
 Die Transportkosten betragen 10 € pro Stück
 Die Opportunitätskosten des Kapitals betragen 25 %

Lösung

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 16


Bestimmung Bestellpunkt
Optimale Lösung
Zusätzliche Notation Lagerbestand

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


LT Lieferzeit [Jahre] Stück
r Bestellpunkt [Stück]
-m=
x = 20 -20
Lösung*
Stück/
Bestelle LT Jahre bevor die
Woche
Lieferung benötigt wird.
Der Bestellpunkt beträgt somit r = 10

 LT   Stück 
r  Re st   [Wochen] * m 
 T   Woche 
LT Zeit
T = 1 Woche Jahre
Beispiele zur Rest-Funktion (modulo)

LT = 0,5 Wochen

LT = 1,5 Wochen
* Bestellmenge ist die gleiche wie beim Basismodell
© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 18
Zusammenfassung
Bestellmengenmodell

 Das Bestellmengenmodell ist gut anwendbar in Situationen, in denen die


Nachfrage (näherungsweise) konstant und deterministisch ist

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


 Im Basismodell wird die optimale Bestellmenge so gewählt, dass die
optimale Balance zwischen fixen Bestellkosten und Lagerhaltungskosten
gefunden wird
 Bei der Erweiterung um Mengenrabatte werden zusätzlich die variablen
Bestellkosten berücksichtigt (im Basismodell sind diese eine Konstante
und brauchen daher nicht berücksichtigt zu werden)
 Das Bestellmengenmodell ist eines der grundlegenden Modelle des
Bestandsmanagements und wird häufig als Baustein für komplexere
Modelle verwendet

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 20


Programm

• Formulierung eines Algorithmus und der dazugehörigen


Datenbereiche in einer Programmiersprache.

• Schema der Ausführung eines Programms:

Eingabe Rechner Ausgabe

Programm

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 21


Anwendung: Optimale Bestellmenge
Berechnung mit PYTHON

# Berechnung optimale Bestellmenge x


2mK
D = 1000 # Nachfrage [Stück/Jahr]; verwende D statt m! x 
*
K = 20 # Fixe Bestellkosten [€] je Bestellung h
h = 100 # Lagerhaltungskostensatz [€/Stück/Jahr]

import math # mathematische Funktionen importieren wg. Wurzelfunktion

x = math.sqrt(((2*D*K)/h))
print ("optimale Bestellmenge",x,"Stück")
Lagerbestand
Stück

x
-m

x
#Berechnung Durchschnittsbestand 2

? Zeit
Jahre

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 22


Anwendung: Kostenfunktionen
Berechnung mit PYTHON
Kostenfunktionen
#Berechnung Summe Fixe Bestellkosten pro Jahr m
 Fixe Bestellkosten  K [€/Jahr]
B = K*D/x x
x
 Lagerhaltungskosten  h [€/Jahr]
print ("Summe Fixe Bestellkosten:", B, "EUR/Jahr") 2
Variable Bestellkosten = cm [€/Jahr]

#Berechnung Lagerhaltungskosten pro Jahr


L = h*x/2 Kosten
Gesamtkosten

print ("Summe Lagerhaltungskosten:", L, "EUR/Jahr")


Lager-
haltungs-
kosten

#Berechnung Summe Variable Kosten


c = 400 # Variable Kosten [€/Stück] Fixe Bestellkosten

V = D*c
Variable Bestellkosten
print ("Summe Variable Kosten:", V, "EUR/Jahr") x* X Bestellmenge

# Berechnung Gesamtkosten m x
? Z(x)  cm  K  h
x 2

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 24


Anwendung: Bestellpunkt
Berechnung mit PYTHON
#Berechnung Bestellpunkt
d = D/50 # d Nachfrage pro Woche, D Nachfrage pro Jahr, 50 [Wochen/Jahr]

x Lagerbestand
T = x/d # Zykluslänge, hier: in Wochen T Stück
m

LT = 0.5 # Lieferzeit in Wochen


 LT   Stück 
r  Re st   [Wochen] * m 
 T   Woche  LT
Zeit
Jahre
r = (LT%T)*d # % ist der Modulo-Operator, der den Rest der Division berechnet
print ("Bestellpunkt:", r, "Stück")

#Alternative Berechnung Zykluslänge in Jahren


TiJ = x/D # Zykluslänge, hier: in Jahren
LTiJ = LT/50 # LTiJ Lieferzeit in Jahren, LT Lieferzeit in Wochen, 50 [Wochen/Jahr]
r2 = (LTiJ%TiJ)*D
print ("Bestellpunkt 2:", r2, "Stück")

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 26


Optimale Bestellemenge und Kosten
PYTHON Programm

# Berechnung optimale Bestellmenge x


D = 1000 # Nachfrage [Stück/Jahr]; verwende D statt m!
K = 20 # Fixe Bestellkosten [€] je Bestellung
h = 100 # Lagerhaltungskostensatz [€/Stück/Jahr]
import math # mathematische Funktionen importieren wg. Wurzelfunktion
x = math.sqrt(((2*D*K)/h))
print ("optimale Bestellmenge",x,"Stück")
#Berechnung Durchschnittsbestand
print ("Durchschnittsbestand:", x/2, "Stück")
#Berechnung Summe Fixe Bestellkosten pro Jahr
B = K*D/x
print ("Summe Fixe Bestellkosten:", B, "EUR/Jahr")
#Berechnung Lagerhaltungskosten pro Jahr
L = h*x/2
print ("Summe Lagerhaltungskosten:", L, "EUR/Jahr")
#Berechnung Summe Variable Kosten
c = 400 # Variable Kosten [€/Stück]
V = D*c
print ("Summe Variable Kosten:", V, "EUR/Jahr")
# Berechnung Gesamtkosten
Z = L+B+V
print ("Gesamtkosten:",Z, "EUR/Jahr")

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 27


Bestellpunkt
PYTHON Programm

#Berechnung Bestellpunkt
d = D/50 # d Nachfrage pro Woche, D Nachfrage pro Jahr, 50 [Wochen/Jahr]
T = x/d # Zykluslänge, hier: in Wochen
LT = 0.5 # Lieferzeit in Wochen
r = (LT%T)*d # % ist der Modulo-Operator, der den Rest der Division berechnet
print ("Bestellpunkt:", r, "Stück")
#Alternative Berechnung Zykluslänge in Jahren
TiJ = x/D # Zykluslänge, hier: in Jahren
LTiJ = LT/50 # LTiJ Lieferzeit in Jahren, LT Lieferzeit in Wochen, 50 [Wochen/Jahr]
r2 = (LTiJ%TiJ)*D
print ("Bestellpunkt 2:", r2, "Stück")

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 28


Python Spielwiese

E-Learning-Plattform des ISE-Lehrstuhls für Python:


https://pound.wiwi.uni-frankfurt.de/spielwiesen/

Login-Daten: Daten aus Enlist (Spielwiesen-Anmeldung)


• E-Mail-Adresse
• Matrikelnummer

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 29


Alternativ: Python lokal installieren

• Diverse Python Installer sind auf http://www.python.org zu


finden.

• Verwendete
Release-Version: 3.4.0
(März 2014)

• Der Windows-Installer
installiert eine integrierte
Entwicklungsumgebung
(Interpreter & Editor)
auf dem lokalen Rechner

Quelle: http://www.python.org (07.09.2019)


© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 30
Der "Print"-Befehl

• Der Befehl "print" erzeugt eine Ausgabe. Beispiel:

print ("Hallo Welt") # Hallo Welt

• Mehrfache Ausgabe durch Kommata:

print ("Hallo", "Welt") # Hallo Welt

• Jedes Komma erzwingt ein Leerzeichen. Vermeidung der Leerzeichen


durch Konkatenation möglich.

print ("Hallo" + "Welt") # HalloWelt

print (7 + " Zwerge") # Fehler

print (str(7) + " Zwerge") # 7 Zwerge

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 31


Variablen

• Variablen sind benannte Platzhalter für Daten. Eine Variable


wird in Python durch eine Zuweisung eingeführt:

a = 10 # Zuweisung; führt die Variable „a“ ein


b = 20 # Zuweisung; führt die Variable „b“ ein
c=a+b # Zuweisung mit Ausdruck

print (c) # Ausgabe von c; liefert den Wert „30“

• "Hello World" mit Variable:

text = "Hello World"


print (text)

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 32


Variablen / Zuweisungen

a=2
b=5
c=a*b
print (c) # Ausgabe?

b=b+1
print (b) # Ausgabe?

a, b = 3, 9
a=a*b
print (a) # Ausgabe?

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 33


Listen

• Eine Liste wird durch eckige Klammern definiert:

a = [ 1, 2, 3 ]

• Die Variable a enthält nun eine Liste mit den Elementen 1, 2


und 3 als Ganzzahlen.
• Der Zugriff auf die Elemente einer Liste erfolgt über Indizes.
Die Indizes sind durchnummeriert, beginnend mit 0.

print (a[0]) # gibt die Zahl 1 aus


print (a[1]) # gibt die Zahl 2 aus
print (a[2]) # gibt die Zahl 3 aus

• Möglich ist auch:

print (a[-1]) # gibt ebenfalls die Zahl 3 aus

© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 35


Listen

• Listen können neben Strings und Numbers wiederum


Listen enthalten:

a = [ ["Artikel0001", "V"], ["Artikel0002", "E"], … ]

• Zugriff auf Listenelemente:

a[0] # ["Artikel0001", "V"]


a[0][0] # "Artikel0001"
a[1][1] # "E"

a[0][0][0] # "A" ( Strings werden als Liste von


Zeichen interpretiert )
Rep Listen
© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 36
Funktionen eines Anwendungssystems

Quelle: Laudon, Laudon, Schoder (2009), S. 20


© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 37
Anwendungssysteme – Grundaktivitäten

• Eingabe: Erfassen oder Sammeln von Rohdaten  z.B.


Artikel-Nr./Barcode für Hemd, verkaufte Stückzahl, Code für
Kaufhaus

• Verarbeitung: Transformation in eine für Menschen


verständliche Form  z. B. welche Hemden sollen hergestellt
werden? Für welche Kaufhäuser? Welche Hemden sind am
umsatzstärksten? …

• Ausgabe: Verteilen der verarbeiteten Informationen an die


zuständigen Personen  z. B. Übermittlung an Einkaufs-
/Bestellabteilung des Kaufhauses, Hemden-Produzent

• Feedback: Ausgaben werden zur Auswertung / Korrektur der


Eingabe an Personen zurückgesandt
© Professur für Information Systems Engineering, Prof. Dr. Holten 2 - 38
WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 3 – Algorithmen, Struktogramme


und Programme

Sie lernen in diesem Kapitel,

 den Begriff Algorithmus kennen


 mit welchen Kontrollstrukturen Algorithmen formuliert werden
 Pseudo-Code und Struktogramme zur Darstellung von Algorithmen
kennen
 wie Kontrollstrukturen in Python umgesetzt werden
 wie mit Python aus einer Liste von Netto-Rechnungsposten eine
Brutto-Gesamtrechnungssumme berechnet werden kann

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

3 Algorithmen, Struktogramme
und Programme
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-2


Fallstudie: Leiner Health
KRISE!

Schwachstelle: Rechnungsstellung / verfügbare Finanzen

• Konditionen: Variierende Preise,


Werbeaktionen, Sonderangebote
zu unterschiedlichen Zeiten

• Keine Rechnungsprüfung durch Marketing / Vertrieb

• Fehlerhafte Rechnungen durch Buchhaltung gestellt

• Bearbeitung von Reklamationen langsam und Papier-basiert

• Rechnungen bis zu 90 Tage unbezahlt


 Verlust von 17 Mio. USD pro Jahr

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-3


Fallstudie: Leiner Health Products

Verbesserung des Cash-Flow-Management:


• Neue Software der Firma Emagia Corp.
aus Santa Clara

• Überwachung der Kundenverträge von der Rechnungsstellung


bis zur Zahlung
• Keine Papieraufträge mehr
• Reduzierung der Außenstände in 6 Wochen um 75%

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-4


Fallstudie: Rechnungserstellung (1/2)

• Die Finanzbuchführung erhält vom Vertrieb elektronische


Auftragsbelege, bspw. in Form eines XML-Dokuments oder
durch eine zentrale Datenbank.

• Mittels der Belege sollen Kundenrechnungen erstellt werden.

• Preise sind Nettowerte („Nettopreis“).

• Ein Beleg enthält für jeden Artikel die entsprechende MwSt-


Klasse („V“ oder „E“), die jeweils für 19% oder 7%
Umsatzsteuer steht.

• Für die Rechnungserstellung muss die Bruttogesamtsumme


über alle Posten der Rechnung gebildet werden.

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-5


Fallstudie: Rechnungserstellung (2/2)

Beispieldaten:

Artikelnummer MwSt-Klasse Nettopreis


0001 V 10,00 €
0002 V 5,00 €
0003 E 1,00 €
0004 E 2,00 €
0005 V 20,00 €

MwSt-Klasse Prozent
V 19,00 %
Brutto: 44,86 €
E 7,00 %

Wie kann dieses "Rechnungsproblem" formalisiert werden?

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-6


Algorithmus

• Präzise formulierte Verarbeitungsvorschrift zur Lösung


eines Problems (z.B. durch einen Computer)

• Gibt an, wie Eingabedaten schrittweise in


Ausgabedaten umgewandelt werden
(Eingabe – Verarbeitung – Ausgabe (EVA-Prinzip))

• Genaue und eindeutige Handlungsanweisung

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-7


Ablaufstrukturen von Algorithmen

Ablaufstruktur Bedeutung

Aktivitäten werden
Sequenz nacheinander ausgeführt

Aktivitäten werden alternativ


Alternative
ausgeführt

Wiederholung / Eine Aktivität wird wiederholt


Schleife ausgeführt

Rekursion Aktivität „ruft sich selbst auf“

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-8


Struktogramm

• Eine Entwurfsmethode für die strukturierte


Programmierung
• Lösungsweg wird in elementare Ablaufstrukturen
(Sequenz, Alternative, Wiederholung) zerlegt
• Nach den beiden Entwicklern Dr. Ike Nassi und Dr. Ben
Shneiderman auch Nassi-Shneiderman Diagramm
genannt
• Genormt nach DIN 66261

Hole Aktienkurs

Aktienkurs < mein Limit


Ja Nein

Kaufe Kaufe nicht

© Professur für Information Systems Engineering, Prof. Dr. Holten 3-9


Ablaufstruktur: Sequenz

Zu lösendes Problem:
Addition zweier Zahlen, die über die Tastatur eingegeben
werden, und Ausgabe des Ergebnisses am Bildschirm.

Algorithmus:
Schritt 1: Lies Zahl Z1 ein Lies Zahl Z1 ein
Schritt 2: Lies Zahl Z2 ein Lies Zahl Z2 ein
Schritt 3: Berechne E = Z1 + Z2 Berechne E = Z1 + Z2
Schritt 4: Gib E aus Ausgabe: E

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 10


Ablaufstruktur: Alternative

• Prüfung einer Bedingung


• Verzweigung je nach Prüfergebnis

Prüfung
Bedingung
Ja Nein

Ablauf für Ablauf für nicht


erfüllte erfüllte
Bedingung Bedingung

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 11


Ablaufstruktur: Alternative

Zu lösendes Problem:
Zwei Zahlen Z1 und Z2 sind einzulesen. Falls beide Zahlen
gleich sind, ist eine entsprechende Meldung auszugeben.
Ansonsten ist die größere Zahl auszugeben.

Lies Z1 ein
Algorithmus: Lies Z2 ein
(S1) Lies Z1 ein Z1 == Z2 ?
(S2) Lies Z2 ein
Ja Nein
(S3) Falls Z1 == Z2
Dann schreibe "Z1 gleich Z2" Z1 > Z2 ?
Sonst Falls Z1 > Z2
Dann schreibe "Z1 größer als Z2" Ausgabe: Ja Nein
Sonst Z1 ist
Ausgabe: Ausgabe:
gleich Z2
schreibe "Z2 größer als Z1" Z1 ist Z2 ist
größer größer
als Z2 als Z1

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 12


Ablaufstruktur: Wiederholung mit
WHILE-Schleife

• Eine Abfolge von Anweisungen wird wiederholt, solange eine


Bedingung erfüllt ist.
• Die Prüfung der Bedingung findet vor der Ausführung der
Anweisungen statt (vorprüfende Schleife).

Solange Bedingung erfüllt ist

Schritt 1

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 13


Ablaufstruktur: Wiederholung mit
WHILE-Schleife

Zu lösendes Problem:
Die Summe über alle Posten einer Rechnung ist zu bilden.

Algorithmus:

(S1) Setze Summe auf „0“ Setze Summe auf „0“


(S2) Solange noch Rechnungsposten
vorhanden sind Solange noch Rechnungsposten
vorhanden sind
Wiederhole
Lies den nächsten Lies nächsten
Rechnungsposten, Rechnungsposten
Addiere Rechnungsposten zu
Summe hinzu Addiere Rechnungsposten zu
Summe
(S3) Schreibe Wert von Summe
Ausgabe von Summe

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 14


Ablaufstruktur: Wiederholung mit
FOR-Schleife

• Führt einen vorgegebenen Ablauf für eine vorgegebene Anzahl


an Schleifendurchläufen aus
• Auch Zählschleife genannt
• Geeignet vor allem, um indizierte oder nummerierte Mengen
durchzugehen
• Verhält sich unter Umständen genau so wie die WHILE-Schleife

Für Zähler von Anfang


bis Ende

Schritt 1

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 15


Ablaufstruktur: Wiederholung mit
FOR-Schleife

Zu lösendes Problem:
Ausgabe der Zahlen von 1 bis 42

Algorithmus:
Für i von 1 bis 42
(S1) Für i von 1 bis 42
Gib i aus
Ausgabe von i

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 16


Übung zu Struktogrammen (1)

Zu lösendes Problem:
Einlesen von drei ungleichen Zahlen, Maximum bestimmen und
ausgeben

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 17


Übung zu Struktogrammen (2)
Schleifen

Zu lösendes Problem:
Einlesen einer Zahl d und Ausgeben aller Zahlen von 1 bis d
sowie von deren Quadratzahlen

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 19


Übung zu Struktogrammen (3)
Schleifen

Zu lösendes Problem:
Einlesen einer Zahl d und Ausgabe des „Ein mal Eins“ im Bereich
von 1*1 bis d*d

i
1 2 3 4 5
k 1 1 2 3 4 5
2 4 6 8 10
3 9 12 15
4 16 20
5 25
Ausgabe

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 21


Lösung des Rechnungsproblems als
Struktogramm

Posten = Liste der Rechnungsposten

Bruttosumme = 0

Wiederhole für jeden Posten

MwStKlasse == „V“?

Ja Nein
Bruttosumme = Bruttosumme =
Bruttosumme + Bruttosumme +
Nettopreis aktueller Nettopreis aktueller
Posten *1.19 Posten *1.07

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 23


Lösung des Rechnungsproblems
in Pseudo-Code

// Zuweisungen
Posten = Liste der Rechnungsposten
Bruttosumme = 0

// Schleife
Wiederhole für jeden Posten
// Alternative
Wenn MwSt_Klasse == “V“
Bruttosumme = Bruttosumme + Nettopreis aktueller
Posten * 1.19
Sonst
Bruttosumme = Bruttosumme + Nettopreis aktueller
Posten * 1.07

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 24


Wiederholung mittels FOR
in Python

• Eine FOR-Schleife durchläuft eine Liste und führt für jedes


Element der Liste den eingeschlossenen Programmcode aus.

• Beispiel:
a = [ 98.90, 49.99, 225.50 ] # Liste
for x in a: # Für jedes x in (der Liste) a
print ("Netto:", round(x, 2) , end='') # Ausgabe
print ("Brutto:", round(x * 1.19, 2))

• Ausgabe:

Netto: 98.9 Brutto: 117.69


Netto: 49.99 Brutto: 59.49
Netto: 225.5 Brutto: 268.35

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 25


Alternative mittels IF
in Python

• Über die Ausführung alternativer Programmcodes wird durch


die Sprachkonstrukte IF, ELIF und ELSE entschieden. Dabei
werden Bedingungen überprüft, die entweder wahr (True) oder
falsch (False) sind.

• Beispiel:

x=1
Bedingung
if x < 0:
print ("Negativ") Alternative mit
Bedingung
elif x == 0:
print ("Null")
Alternative
else:
print ("Mindestens Eins")
Rep Schleifen
© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 26
Boolesche Werte

• Boolesche Variablen sind nach dem englischen Mathematiker


George Boole benannt, der den Grundstein für die binäre
Logik und die Rechentechnik legte.

• Ein boolescher Wert ist entweder True oder False.

• Logische Operatoren:
AND, OR und NOT

• Operatoren in Python:
== ist gleich? != ist ungleich?
> ist größer? < ist kleiner?
>= ist größer gleich? <= ist kleiner gleich?

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 27


Lösung des Rechnungsproblems
in Python

# Zuweisung
Posten = [ ["0001", "V", 10.00], ["0002", "V", 5.00],
["0003", "E", 1.00], ["0004", "E", 2.00], ["0005", "V", 20.00] ]
Bruttosumme = 0.00
# Schleife
for Artikel in Posten:
MwSt_Klasse = Artikel[1]
Nettopreis = Artikel[2]
if MwSt_Klasse == "V":
Bruttosumme = Bruttosumme + Nettopreis * 1.19
else:
Bruttosumme = Bruttosumme + Nettopreis * 1.07
# Ausgabe
print (Bruttosumme, "€")
Ausgabe: 44.86 €
© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 28
Schleifen
in Python

• In Python können zwei Schleifentypen genutzt werden:

while <Bedingung>:
<zu wiederholende Sequenz>

for <element> in <liste>:


<Sequenz pro Element>

• Beispiel:

a=1
while a < 5:
print (a)
a=a+1

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 29


Beispiel: Fibonacci-Folge
in Python

• Berechnet eine Fibonacci-Folge mittels einer Schleife:

a, b = 0, 1 # mehrfache Zuweisung
while b < 1000: # Wiederholung
print (b) # Ausgabe
a, b = b, a+b # Folge "weiterdenken"

• Ausgabe:

1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 30


Wiederholung mittels FOR & range()
in Python

• Problemstellung: Eine bestimmte Aktivität soll n-mal


ausgeführt werden.
• Solche Zähl-Schleifen können in Python ebenfalls elegant
durch eine FOR-Schleife umgesetzt werden.
• Die FOR-Schleife arbeitet immer auf einer Liste, folglich muss
diese erst generiert werden.
• Dies erledigt die Funktion: range()

• Beispiel:

range(10) liefert folgende Sequenz als Liste:


0123456789

for i in range(10):
# mach was

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 31


Äquivalente Programme
in Python

• a=0
while a < 10:
print (a)
a=a+1

• for a in range(10):
print (a)

• for a in [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]:


print (a)

© Professur für Information Systems Engineering, Prof. Dr. Holten 3 - 32


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 4 – Koordination betrieblicher


Aufgaben und MRP II-Systeme

Sie lernen in diesem Kapitel,

 wie die ABC-Analyse zur Klassifizierung von Teilen und Material


genutzt wird
 was das MRP II-Ablaufschema ist und wie MRP II-Systeme als
wichtige Anwendungssysteme die Koordination zwischen Beschaffung,
Produktion und Vertrieb unterstützen
 wie wir Stücklisten und Gozintographen nutzen, um die für die
Produktion benötigten Teile zu bestimmen
 wie MRP als Komponente des MRP II Brutto- und Nettobedarfe an
Teilen bestimmt
 was der vorlaufverschobene Bedarf ist, und wie er berechnet wird
 was Losgrößenoptimierung ist
 wie optimale Losgrößen mit der Silver

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

4 Koordination Betrieblicher
Aufgaben und MRP II-Systeme

Thonemann, Ulrich: Operations Management


(Pearson Studium 2010) (Kapitel 6)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 4-2


Fallstudie: Leiner Health Products
KRISE!

Das Hauptproblem…
• … waren die zu großen Lagerbestände

• MRP II -System (Material Resource Planning) erstellte für


jeden Auftrag einen eigenen Materialanforderungsplan,
ohne die gesamte Kundennachfrage und die freien
Kapazitäten zu kennen

• Chaotische Bestandsführung; einige


Produkte konnten nicht produziert
und Kunden nicht beliefert werden

© Professur für Information Systems Engineering, Prof. Dr. Holten 4-3


Fallstudie: Leiner Health Products
WEGE aus der KRISE

Die Lösung von A&M:


• Verbesserung des MRP-Systems durch
Spezialisten der Firma REM Associates
• Nach der Verbesserung:
• Erfassung aktueller Kundenbestellungen, Fertigungs-
und Lieferzeiten
• Reduzierung von Lagerbeständen um 50 Mio. USD
durch präzisere Planungsdaten über
Produktionskapazitäten, Kundenanforderungen und
die künftige Nachfrage
• Pünktliche Lieferung in 95% aller Fälle
• Reduzierung der Beschaffungskosten
um 15%

© Professur für Information Systems Engineering, Prof. Dr. Holten 4-4


Abhängigkeit der Bedarfe

Endprodukt Komponenten

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Nachfragen Frage
 10 Stück nächste Woche Wann sollten welche Mengen
 4 Stück übernächste Woche Akkuschrauber, Motoren, Bürstenhalter,
Anker, et cetera produziert
Produktionsvorlaufzeiten
beziehungsweise bestellt werden, so
 Akkuschrauberfertigung: 1 Woche dass alle Nachfragen zu minimalen
- Motorfertigung: 2 Wochen Kosten erfüllt werden können? Und
. Bürstenhalterfertigung: 1 Woche wann sollten wie viele Schrauben
. Ankerwickelei: 2 Wochen bestellt werden?
- Akkufertigung: 1 Woche
...
Quelle: tedics (2005)

© Professur für Information Systems Engineering, Prof. Dr. Holten 4-5


Jährlicher Bedarf – Beispiel

Bedarf Stückkosten Verbrauch

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Stück p.a. €/Stück € p.a.
Schraube M6 1.000 0,10
Motor X1 20 500,00
Motor X2 10 800,00
Schraube M5 100 0,10
Fräskopf 1.000 10,00

Bedarf Stückkosten Verbrauch


Stück p.a. €/Stück € p.a.
Motor X1 20 500,00 10.000
Fräskopf 1.000 10,00 10.000
Motor X2 10 800,00 8.000
Schraube M6 1.000 0,10 100
Schraube M5 100 0,10 10

© Professur für Information Systems Engineering, Prof. Dr. Holten 4-6


Jährlicher Bedarf – Beispiel

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Verbrauch Kumulierter Verbrauch
Nr. % Bezeichnung € p.a. € p.a. %
1 Motor X1 10.000
2 Fräskopf 10.000
3 Motor X2 8.000
4 Schraube M6 100
5 Schraube M5 10

© Professur für Information Systems Engineering, Prof. Dr. Holten 4-8


ABC-Analyse – Generell
Kumulierter Verbrauch
Prozent
A B C

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


100
90
80
50 Prozent der Teile
70
machen 95 Prozent des
60 Periodenverbrauchs aus
50
20 Prozent der Teile
40 machen 80 Prozent des
Periodenverbrauchs aus
30
20
10
0
0 10 20 30 40 50 60 70 80 90 100
Anteil Teile
Prozent
© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 10
Behandlung unterschiedlicher Teilearten

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


A-Teile C-Teile
 Programmgesteuerte Planung  Verbrauchsgesteuerte Planung

 Exakte Bestandsrechnung  Nicht immer exakte Bestandsrechnung

 Strenge Terminkontrolle  Eingeschränkte Terminkontrolle

 Sorgfältige Festlegung von  Einfache Festlegung von Bestellmengen


Bestellmengen zum zum Beispiel mit Methoden des
Beispiel mit MRP Bestandsmanagements

B-Teile

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 11


MRP II (Material Resource Planning)

Geschäftsplanung Ermittlung
Endkundennachfrage

Aggregierte Planung

Liefertermin

Produktionsprogrammplanung (MPS)

Materialbedarfsplanung (MRP)

Produkt

Ablaufplanung

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 12


MRP (Material Requirements Planning)
im MRP II (Material Resource Planning)

Geschäftsplanung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Bruttobedarfsrechnung
Aggregierte Planung

Nettobedarfsrechnung
Produktionsprogrammplanung (MPS)

Grobterminierung
Materialbedarfsplanung (MRP)

Losgrößenoptimierung
Ablaufplanung

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 13


Bruttobedarfsrechnung
Stücklisten

- Strukturstückliste
- Strukturierende Auflistung aller Teile, die in das Produkt eingehen

- Verwendung von Stücklistenfaktoren


1
- Zur Fertigung von einem X wird ein R benötigt R X

- Gozintograph
- Stellt gesamte Stückliste für ein Endprodukt dar

B 1
Legende:
M
1
X: Motorrad
1
W M: Motor
1 B: Motorblock
R X
W: Motorwelle
2 R: Rahmen
F: Reifen
F

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 14


Bruttobedarfsrechnung
Stücklisten

• Stücklisten je Endprodukt
• Bauteil kann in mehrere Endprodukte eingehen
• Tisch 1 benötigt drei Beine

Bein Tisch 1

• Tisch 2 benötigt vier Beine

Bein Tisch 2

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 15


Bruttobedarfsrechnung

Fragestellung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Wie viele Teile und Komponenten* müssen zur Verfügung gestellt werden?

Lösung
Bruttobedarft   Stücklistenfaktorn  Losgröße der nachgelagerten Stufen,t
n

Beispiel
Endprodukte sind zwei Tische mit den gleichen Beinen. Tisch 1 benötigt drei Beine pro
Tisch. Tisch 2 benötigt vier Beine pro Tisch. Wie hoch ist der Tischbein-Bruttobedarf?
Woche t 8 9 10 11 12
Losgröße Tisch 1 100 0 60 10 20
Stücklistenfaktor Tisch 1 3 3 3 3 3
Bruttobedarf Tischbeine Tisch 1 300 0 180 30 60
Losgröße Tisch 2 0 30 0 30 10
Stücklistenfaktor Tisch 2 4 4 4 4 4
Bruttobedarf Tischbeine Tisch 2 0 120 0 120 40
Bruttobedarf Tischbeine (Tisch 1 + 2) 300 120 180 150 100
* Zugekauftes Material bezeichnen wir als Teile, zugekauftes Material, das zu Zwischenprodukten weiterverarbeitet wurde, als Komponenten
© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 16
Nettobedarfsrechnung

Fragestellung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Wie viele Teile und Komponenten müssen in den einzelnen Perioden bereit gestellt
werden?

Lösung
Nettobedarft  Bruttobedarft  geplanter Lagerzugangt  Anfangsbestandt 

Beispiel
Geplante Lagerzugänge von 20 Stück in Woche 8 und 10 Stück in Woche 9.
Anfangsbestand von 200 Stück in Woche 8
Woche t 8 9 10 11 12
Bruttobedarf Tischbeine 300 120 180 150 100
Geplanter Lagerzugang Tischbeine 20 10 0 0 0
Anfangsbestand Tischbeine 200
Nettobedarf Tischbeine 80 110 180 150 100

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 17


Grobterminierung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Fragestellung
Wie können Vorlaufzeiten (LT) in der Planung berücksichtigt werden?

Lösung
Vorlaufverschobener Nettobedarft  Nettobedarft LT

Beispiel
Die Produktion der Tischbeine benötigt eine Vorlaufzeit von LT = 1 Woche

Woche t 7 8 9 10 11 12
Nettobedarf Tischbeine 80 110 180 150 100
Vorlaufverschobener
Nettobedarf Tischbeine 80 110 180 150 100

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 18


Losgrößenoptimierung
Problemstellung

Fragestellung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Welche Mengen müssen produziert werden, so dass die vorlaufverschobenen
Nettobedarfe („Bedarfe“) kostenminimal gedeckt werden?
Beispiel
Rüstkosten: K = 200 €, Lagerhaltungskosten*: h = 10 €/Stück/Woche

Lösung 1: Woche t 7 8 9 10 11
Vorlaufverschobener
Nettobedarf Tischbeine (= „Bedarf“) 80 110 180 150 100
Losgröße 190 0 430 0 0

Kosten:

Lösung 2
Losgröße 620 0 0 0 0

Kosten:

* Werden auf Basis des Endbestands der Perioden berechnet


© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 19
Losgrößenoptimierung
Lot-for-Lot
Vorgehen
Produziere in jeder Periode den benötigten Bedarf.
Spart Lagerhaltungskosten, riskiert allerdings höhere Rüstkosten

Beispiel
 Rüstkosten: K = 200 €
 Lagerhaltungskosten*: h = 10 €/Stück/Woche

Woche t 8 9 10 11 12
Bedarf 27 22 13 19 12
Losgröße

 Kosten:

* Werden auf Basis des Endbestands der Perioden berechnet


© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 21
Losgrößenoptimierung
Feste optimale Produktionsmenge
Vorgehen
Produziere den kumulierten Bedarf einer oder mehrerer Perioden, der der optimalen
Bestellmenge am nächsten kommt!
Nutze das Bestellmengenmodell, obwohl einige Annahmen des Modells verletzt sind
(periodische statt kontinuierliche Nachfrage, dynamische statt konstante Nachfrage)
Beispiel
 Rüstkosten: K = 200 €
 Lagerhaltungskosten*: h = 10 €/Stück/Woche
 Bedarf: 27 Stück, 22 Stück, 13 Stück, 19 Stück, 12 Stück
 Durchschnittliche Nachfrage:
 Optimale Bestellmenge:

Woche t 8 9 10 11 12
Bedarf 27 22 13 19 12
Losgröße

 Kosten:

* Werden auf Basis des Endbestands der Perioden berechnet


© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 23
Losgrößenoptimierung
Silver-Meal-Heuristik
Vorgehen
 Starte mit der ersten Periode t, in der produziert werden muss, damit es zu keinen

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Fehlmengen kommt
 Berechne die durchschnittlichen Kosten je Periode, wenn nur für Periode t, Perioden t
und t+1, Perioden t, t+1 und t+2 et cetera produziert wird: Zt,t ,Zt,t 1,Zt,t 2 ,
 „Produziere für die Perioden, für die die durchschnittlichen Kosten gesunken sind“
Durchschnittliche Kosten Durchschnittliche Kosten
€/Periode €/Periode
200 200
160 150 150
120 130
90 ...
80

1 2 3 4 4 5 6 7 8

Produziere in Periode 1 Produziere in Periode 4


für Perioden 1 bis 3 für Perioden 4 bis 7
© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 25
Silver-Meal-Heuristik: Anwendung

Durchschnittliche Kosten, wenn in Periode t für Perioden t bis t + n produziert wird


1  n

Zt,t n 
n  1 
K  h k  y  Yt+k: Produktionsmenge für die Periode t+k

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


t  k
k 0 
Beispiel (K = 200 €, h = 10 €/Stück/Woche)
Woche t 8 9 10 11 12
Bedarf 27 22 13 19 12

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 26


Silver-Meal-Heuristik: Anwendung-
Fortsetzung

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Produktionsmengen und Bestände
Woche t 8 9 10 11 12
Anfangsbestand It 0
Bedarf yt 27 22 13 19 12
Losgröße xt
Endbestand It*

Kosten

*= Anfangsbestand It+1
© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 28
MRP Fallstudie

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Quelle: Thonemann (2010), S. 305

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 30


MRP-Lauf für Tische und Tischbeine mit
Silver-Meal-Optimierung
Tische Woche t 7 8 9 10 11 12 13 14
LT = 2 Wochen
Bruttobedarf 37 32 13 19 12

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


K = 200 €
h = 10 €/Stück/Woche Geplanter Lagerzugang 0 10 0 0 0
Anfangsbestand 10
Nettobedarf 27 22 13 19 12
Vorlaufverschobener Nettobedarf 27 22 13 19 12
Losgröße * 27 35 0 31

Woche t 7 8 9 10 11 12 13 14
Tischbeine
LT = 1 Woche Bruttobedarf
K = 100 €
Geplanter Lagerzugang 0 10 0 0 0
h = 1 €/Stück/Woche
Anfangsbestand 20
Nettobedarf
Vorlaufverschobener Nettobedarf
Losgröße (Berechnung auf folgendem Schaubild)
* Optimierung siehe Silver-Meal-Beispiel vorne

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 31


Optimierung Losgrößen Tischbein mit
Silver-Meal-Heuristik
Tischbeine K = 100 €, h = 1 €/Stück/Woche
Woche t 7 8 9 10 11

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Bedarf 88 130 0 124 0

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 33


MRP-Lauf für Tische und Tischbeine mit
Silver-Meal-Optimierung
Tischbeine
LT = 1 Woche
Woche t 6 7 8 9 10 11 12 13
K = 100 € Bruttobedarf 108 140 0 124 0

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


h = 1 €/Stück/Woche
Geplanter Lagerzugang 0 10 0 0 0
Anfangsbestand 20
Nettobedarf 88 130 0 124 0
Vorlaufverschobener Nettobedarf 88 130 0 124 0
Losgröße 88 130 0 124 0

Woche t 6 7 8 9 10 11 12 13
Tischfüße
LT = 1 Woche Bruttobedarf 88 130 0 124 0
K = 100 €
Geplanter Lagerzugang 0 0 0 0 0
h = 0,1 €/Stück/Woche
Anfangsbestand 150
Nettobedarf
Vorlaufverschobener Nettobedarf
Losgröße *
* Optimierung mit Silver-Meal-Heuristik (nicht dargestellt)

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 35


CHARAKTERISTIKA MRP

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


 MRP ist „Herzstück“ des MRP II
 Ausgehend vom bekannten (deterministischen und dynamischen) Bedarf
an Endprodukten werden optimale Losgrößen aller Komponenten/Teile
berechnet
 Push-System
 Zentrale Kontrolle
 Zur Losgrößenoptimierung können Heuristiken oder optimale Verfahren
eingesetzt werden
 Herausforderungen
− Sicherstellung fehlerfreier Stücklisten
− MRP-“Nervosität“
− Berücksichtigung von Kapazitätsbeschränkungen
− Bei stochastischer Nachfrage Einbau von Sicherheitsbeständen

© Professur für Information Systems Engineering, Prof. Dr. Holten 4 - 37


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 5 – Modellierung betrieblicher


Prozesse mit BPMN

Sie lernen in diesem Kapitel,

 den betrieblichen Prozess als grundlegendes Konzept der


Wirtschaftsinformatik kennen und von der klassischen Sicht der
Aktivitäten im Wertkettenmodell zu unterscheiden
 welche Prozesstypen es gibt und wie Prozesse definiert sind
 das Konzept der Prozessintegration kennen
 wie Grenzen von Prozessen identifiziert werden
 wie mit BPMN (Business Process Model and Notation) betriebliche
Prozesse modelliert werden
 wie Tasks and Flows in BPMN dargestellt werden
 welche Gateways in BPMN zur Strukturierung von Prozessen genutzt
werden können
 wie Rework in BPMN modelliert wird

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

5 Modellierung Betrieblicher
Prozesse mit BPMN

Thonemann, Ulrich: Operations Management


(Pearson Studium 2010) (Kapitel 4)

Dumas, M.; LaRosa, M.; Mendling, J.; Reijers, H.:


Fundamentals of Business Process Management;
Springer, 2013 / 2018. (Kapitel 3 und 4)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 5-2


Fallstudie: Leiner Health Products
Funktionale Gliederung

Fragen im Rahmen betrieblicher Aufgaben


• Marketing: Lässt sich der Umsatz durch Rabatte und
Werbeaktionen steigern?

• Vertrieb: Welche Rechnungssummen ergeben sich aufgrund


der aktuell geltenden Konditionen und Werbeaktionen?

• Operations: Wann muss produziert werden, um pünktlich


liefern zu können?

• Finanzen: Welche Kunden sind im Zahlungsrückstand?

© Professur für Information Systems Engineering, Prof. Dr. Holten 5-3


Fallstudie: Leiner Health Products
Prozessorientierung

• Verbesserung des MRP-Systems durch


Spezialisten der Firma REM Associates

• Integrierte Planung von Kapazitäten (Operations),


Kundenanforderungen und künftiger Nachfrage (Vertrieb /
Marketing)

• Verbesserung Cash-Flow-Management
Neue Software der Firma Emagia Corp.

• Überwachung der Kundenverträge (Marketing / Vertrieb)


von der Rechnungsstellung bis zur Zahlung
(Finanzbuchhaltung)

© Professur für Information Systems Engineering, Prof. Dr. Holten 5-4


Wertschöpfungskettenmodell

Quelle: Laudon, Laudon, Schoder (2006), S. 146


Lieferanten
Lieferanten Unternehmen Großhändler Endkunden
der Lieferanten

© Professur für Information Systems Engineering, Prof. Dr. Holten 5-5


Prozesstypen

Steuerungs-
prozesse

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


Steuerung des Strategie und Planung
Unternehmens und …
Kontrolle/Steuerung
der Kernprozesse

Kernprozesse
Auf externe Kunden Produktent- Auftrags- Auftrags- After Sales
ausgerichtet mit stehung gewinnung abwicklung Service
direktem Beitrag zu
Wertschöpfung

Unterstützungs-
Personal
prozesse

Auf interne Infrastruktur


Kunden

(Kernprozesse)
ausgerichtet mit
keinem direkten Technologie
Beitrag zu
Wertschöpfung

© Professur für Information Systems Engineering, Prof. Dr. Holten 5-6


Geschäftsprozesse

Was sind Geschäftsprozesse?


• Die Art und Weise, in der Arbeit zur Erzeugung eines
werthaltigen Produkts oder Dienstes strukturiert, koordiniert
und fokussiert wird
• Konkrete Arbeitsabläufe, die Material, Informationen und
Wissen umfassen

1 2 … 4 5 … n
Arten von Geschäftsprozessen:
• Funktionale Geschäftsprozesse: Prozesse, die sich
innerhalb eines bestimmten Unternehmensbereiches abspielen
• Funktionsübergreifende Geschäftsprozesse: Prozesse, die
sich über die Grenzen der Unternehmensbereiche hinaus
erstrecken

© Professur für Information Systems Engineering, Prof. Dr. Holten 5-7


Funktionale
Geschäftsprozesse

Funktionsbereich Geschäftsprozess

Fertigung und • Materialbeschaffung


Produktion • Das Produkt fertigen
Vertrieb und • Potenzielle Kunden identifizieren
Marketing • Das Produkt verkaufen
Finanz- und • Kreditoren bezahlen
Rechnungswesen • Jahresabschluss erstellen
• Mitarbeiter einstellen
Personalwesen • Arbeitsleistung der Mitarbeiter
bewerten

Quelle: Laudon, Laudon, Schoder (2006), S. 97


© Professur für Information Systems Engineering, Prof. Dr. Holten 5-8
Funktionsübergreifende
Geschäftsprozesse

Beispiel Auftragsbearbeitung

Quelle: Laudon, Laudon, Schoder (2006), S. 97


© Professur für Information Systems Engineering, Prof. Dr. Holten 5-9
Definition von Prozessgrenzen

• Wann beginnt oder endet eine Prozess?

• Beispiel Flughafen: Beginnt der Prozess, wenn ein Fluggast

• eincheckt?
• in das Flugzeug steigt?
• am Flughafen ankommt?
• das Haus Richtung Flughafen verlässt?

• Abhängig von der jeweils betrachteten Situation kann jede


dieser Sichtweisen eine passende Alternative sein.

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 10


Detaillierungsniveau
Beispiel Anlagenbau
Haupt-
prozesse Produktent- Auftrags- Auftrags- After Sales

© Thonemann, Ulrich: Operations Management (Pearson Studium 2010)


stehung gewinnung abwicklung Service

Teil-
prozesse Marktbe- Angebots- Vertrags-
...
arbeitung erstellung abschluss

Sub-
Kunden-
prozesse Kunden- Angebots-
kontaktauf- ...
analyse abgabe
nahme
…  Eckdaten …
Aktivitäten erheben
…  Bonität …
prüfen
…  … …

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 11


Business Process Model and Notation
(BPMN)

• OMG Standard, supported by many tools:


• Bizagi Process Modeller
• Signavio (http://www.signavio.com/)
• TIBCO Business Studio (free download, quite large)
• IBM Websphere Business Modeler
• ARIS
• Oracle BPA
• Business Process Visual Architect (Visual Paradigm)
• Progress Savvion Business Modeller
• …

• Microsoft Visio

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 12


BPMN from 10 000 miles…

• A BPMN process model is a graph consisting of four types of


elements (among others):

Fundamentals of Business Process


Management
Dumas, M./ LaRosa, M./ Mendling, J./ Reijers, H.,
Springer (2013, 2019)

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 13


BPMN
Tasks & Flows

Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 14
Warenausgangserfassung
Filiale / Kunde

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 15


Warenausgangserfassung
Filiale / Kunde

Erfasse Sofortige
Erfasse Kunden- Artikelmengen Übertragung
Kasse am nummer und -werte
Bezahlung mit
Kundenkarte

System (Scanning)
Reklamation /
anmelden Leergut ist NICHT von Gutschrift Übertragung am
Dienst an der abzurechnen Tagesende
Kasse
begonnen Prüfe, ob Prüfe, ob Reklamation /
Erfasse Führe Zahlungs-
Bezahlung mit Bezahlung ohne Reklamation / Leergut ist Bestimme
Reklamation / abwicklung
Kundenkarte Kundenkarte Leergut Gutschrift Zahlungsweise
Leergut durch
erfolgt abzurechnen ist abzurechnen POS/FWWS-Upload

Kommissioniere
gewünschten
Artikel Prüfe, ob Shop Shop in the Shop- Übernimm Shop
Kunde hat Laden
in the Shop- Abrechnung in the Shop-
betreten
Abrg. vorliegt liegt vor Daten

© Professur für Information Systems Engineering, Prof. Dr. Holten


Shop in the Shop-Abrechnung
liegt NICHT vor 5 - 16
Warenausgangserfassung
Filiale / Kunde

Erfasse Sofortige
Erfasse Kunden- Artikelmengen Übertragung
Kasse am nummer und -werte
Bezahlung mit
Kundenkarte

System (Scanning)
Reklamation /
anmelden Leergut ist NICHT von Gutschrift Übertragung am
Dienst an der abzurechnen Tagesende
Kasse
begonnen Prüfe, ob Prüfe, ob Reklamation /
Erfasse Führe Zahlungs-
Bezahlung mit Bezahlung ohne Reklamation / Leergut ist Bestimme
Reklamation / abwicklung
Kundenkarte Kundenkarte Leergut Gutschrift Zahlungsweise
Leergut durch
erfolgt abzurechnen ist abzurechnen POS/FWWS-Upload

Kommissioniere
gewünschten
Artikel Prüfe, ob Shop Shop in the Shop- Übernimm Shop
Kunde hat Laden
in the Shop- Abrechnung in the Shop-
betreten
Abrg. vorliegt liegt vor Daten

© Professur für Information Systems Engineering, Prof. Dr. Holten


Shop in the Shop-Abrechnung
liegt NICHT vor 5 - 17
Warenausgangserfassung
Filiale / Kunde

Erfasse Sofortige
Erfasse Kunden- Artikelmengen Übertragung
Kasse am nummer und -werte
Bezahlung mit
Kundenkarte

System (Scanning)
Reklamation /
anmelden Leergut ist NICHT von Gutschrift Übertragung am
Dienst an der abzurechnen Tagesende
Kasse
begonnen Prüfe, ob Prüfe, ob Reklamation /
Erfasse Führe Zahlungs-
Bezahlung mit Bezahlung ohne Reklamation / Leergut ist Bestimme
Reklamation / abwicklung
Kundenkarte Kundenkarte Leergut Gutschrift Zahlungsweise
Leergut durch
erfolgt abzurechnen ist abzurechnen POS/FWWS-Upload

Kommissioniere
gewünschten
Artikel Prüfe, ob Shop Shop in the Shop- Übernimm Shop
Kunde hat Laden
in the Shop- Abrechnung in the Shop-
betreten
Abrg. vorliegt liegt vor Daten

© Professur für Information Systems Engineering, Prof. Dr. Holten


Shop in the Shop-Abrechnung
liegt NICHT vor 5 - 18
Warenausgangserfassung
Filiale / Kunde

Sofortige
Übertragung

Übertragung am
Tagesende

Führe Zahlungs-
Bestimme
abwicklung
Zahlungsweise
durch
POS/FWWS-Upload

Erfasse Sofortige
Erfasse Kunden- Artikelmengen Übertragung
Kasse am nummer und -werte
Bezahlung mit
Kundenkarte

System (Scanning)
Reklamation /
anmelden Leergut ist NICHT von Gutschrift Übertragung am
Dienst an der abzurechnen Tagesende
Kasse
begonnen Prüfe, ob Prüfe, ob Reklamation /
Erfasse Führe Zahlungs-
Bezahlung mit Bezahlung ohne Reklamation / Leergut ist Bestimme
Reklamation / abwicklung
Kundenkarte Kundenkarte Leergut Gutschrift Zahlungsweise
Leergut durch
erfolgt abzurechnen ist abzurechnen POS/FWWS-Upload

Kommissioniere
gewünschten
Artikel Prüfe, ob Shop Shop in the Shop- Übernimm Shop
Kunde hat Laden
in the Shop- Abrechnung in the Shop-
betreten
Abrg. vorliegt liegt vor Daten

© Professur für Information Systems Engineering, Prof. Dr. Holten


Shop in the Shop-Abrechnung
liegt NICHT vor 5 - 19
Spezialfall stationärer Einzelhandel
Point-of-Sale (POS)

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 20


BPMN
XOR Gateways

Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 21
Exercise: Branching and Merging

Model the following fragment of a business


process for assessing loan applications
Once a loan application has been approved by the loan provider,
an acceptance pack is prepared and sent to the customer. The
acceptance pack includes a repayment schedule which the
customer needs to agree upon by sending the signed documents
back to the loan provider. The latter then verifies the repayment
agreement: if the applicant disagreed with the repayment
schedule, the loan provider cancels the application; if the
applicant agreed, the loan provider approves the application. In
either case, the process completes with the loan provider
notifying the applicant of the application status.

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 22


Exercise: Branching and Merging

Solution: Business process for assessing loan


applications

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 23


BPMN
AND Gateway

Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 25
BPMN
Order Fulfillment Example

Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 26
A little bit more on Gateways …

• Exclusive Decision / Merge


• Indicates locations within a business process
where the sequence flow can take two or more
alternative paths.
• Only one of the paths can be taken.
• Depicted by a diamond shape that contains a
marker that is shaped like an “X”.
• Parallel Fork / Join
• Provide a mechanism to synchronize parallel flow
and to create parallel flow.
• Depicted by a diamond shape that contains a
marker that is shaped like a plus sign.

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 27


BPMN
OR Gateway

Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 28
BPMN
What Join Gateway is required?

Dumas et al., 2013


B D

A ? F

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 29


BPMN
Exercise – Order Fulfillment

If the product requested is not in stock, it needs to be


manufactured before the order handling can continue. To
manufacture a product, the required raw materials have to be
ordered.

Dumas et al., 2013


Two preferred suppliers provide different types of raw
material. Depending on the product to be manufactured, raw
materials may be ordered from either Supplier 1 or Supplier 2,
or from both.
Once the raw materials are available, the product can be
manufactured and the order can be confirmed. On the other
hand, if the product is in stock, it is retrieved from the
warehouse before confirming the order. Then the process
continues normally (as shown above for Order Fulfilment).

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 31


BPMN
Exercise – Order Fulfillment

Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 32
BPMN
Rework

Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 36
BPMN Gateways

Exclusive (XOR) Parallel (AND) Inclusive (OR)

• Exclusive • Parallel split • Inclusive


decision take all branches decision take
take one branch • Parallel join one or several
• Exclusive merge proceed when all branches
Proceed when incoming depending on
one branch has branches have conditions
completed completed • Inclusive merge
proceed when all
active incoming
branches have
completed

© Professur für Information Systems Engineering, Prof. Dr. Holten 5 - 37


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 6 – Datenintegration und


Relationale Datenbanken

Sie lernen in diesem Kapitel,

 die Bedeutung der Datenintegration kennen


 das Relationale Datenmodell kennen
 warum Relationale Datenbanken zentrale Komponenten integrierter
Anwendungssysteme sind
 wie mit SQL Datenbankanfragen formuliert werden
 wie Informationen, die über mehrere Tabellen im Unternehmen verteilt
sind mittels der Verbund-Operation von SQL wieder zusammengefügt
werden können

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

6 Datenintegration und
Relationale Datenbanken

Laudon, Laudon, Schoder (2010):


Datenorganisation und Datenmanagement (Kapitel
6)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration - Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 6-2


Fallstudie: Leiner Health Products
KRISE!

Probleme durch das schnelle Wachstum:


• Schlechtes Informationsmanagement
• Wer sind die besten Kunden?
• Welche Produkte sind am
gewinnbringendsten?
• Welche Kunden sind im Zahlungsrückstand?
• Welche Artikel müssen besonders schnell geliefert
werden?
• Einnahmen und Ausgaben wurden in der Buchhaltung
anhand von Papierunterlagen verwaltet.
• Offene Außenstände (17 Mio. USD pro Jahr weniger
Umsatzerlös)
• Wal-Mart drohte, sich andere Lieferanten zu suchen
© Professur für Information Systems Engineering, Prof. Dr. Holten 6-3
Problem: Fehlende Datenintegration

• Jedes Anwendungssystem
• Speichert nur das, was benötigt wird
• Speichert so, wie benötigt
• Sieht nur den benötigten Ausschnitt aus dem Prozess
• Einige Daten werden mehrfach gespeichert -> Redundanz

Quelle: Laudon, Laudon, Schoder (2006), S. 324


© Professur für Information Systems Engineering, Prof. Dr. Holten 6-4
Problem: Fehlende Datenintegration
Zerstückelte Prozesse

Situation: Kunde ruft im Vertrieb an


Kundenfrage: „Werden alle meine Bestellmengen durch
Lagerbestand gedeckt?“
Kundendaten Bestelldaten
(Kundennummer) (Kundennummer,
Vertrieb Vertrieb Artikelnummer, Bestellmenge)

Artikeldaten
(Artikelnummer, Lagernummer)
Einkauf

Lager
(Lagernummer, Artikelnummer,
Lager Lagerbestand)

Problem: Die Information muss mühsam aus verschiedenen


Datenbeständen zusammengesucht werden!

Lösung: Datenintegration mit Relationalen Datenbanken


© Professur für Information Systems Engineering, Prof. Dr. Holten 6-5
Datenintegration

Quelle: Laudon, Laudon, Schoder (2006), S. 400


© Professur für Information Systems Engineering, Prof. Dr. Holten 6-6
Fallstudie: Leiner Health Products
Datenintegration

• Verbesserung des MRP-Systems durch


Spezialisten der Firma REM Associates

• Integrierte Planung von Kapazitäten,


Kundenanforderungen und künftiger Nachfrage

© Professur für Information Systems Engineering, Prof. Dr. Holten 6-7


Fallstudie: Leiner Health Products
Datenintegration

• Nach Verbesserung des MRP-Systems:

• Erfassung aktueller Kundenbestellungen und


Lieferzeiten

• Reduzierung von Lagerbeständen um 50 Mio. USD


durch präzisere Planungsdaten über
Produktionskapazitäten, Kundenanforderungen und
die künftige Nachfrage

• Pünktliche Lieferung in 95% aller Fälle

• Reduzierung der Beschaffungskosten


um 15%
© Professur für Information Systems Engineering, Prof. Dr. Holten 6-8
Fallstudie: Leiner Health Products
Datenintegration

Verbesserung des Cash-Flow-Management:


• Neue Software der Firma Emagia Corp.
aus Santa Clara

• Überwachung der Kundenverträge von der


Rechnungsstellung bis zur Zahlung
• Keine Papieraufträge mehr
• Reduzierung der Außenstände in 6 Wochen um 75%

© Professur für Information Systems Engineering, Prof. Dr. Holten 6-9


Datenbank-Managementsystem
Realisierung der Datenintegration

Quelle: Laudon, Laudon, Schoder (2006), S. 326


© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 10
Relationales Datenmodell

• Geht zurück auf Codd, 1970

• Grundlage von Relationalen Datenbanken

• Daten werden in Tabellen – den Relationen –


abgespeichert
 Relationenmodell

• Jede Tabelle hat einen fest strukturierten Aufbau aus


 Zeilen (Datensätze/Tupel) und
 Spalten (Attributen)

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 11


Eigenschaften einer Relation

• Keine doppelten Tupel


(eine Relation ist eine Menge!)

• Reihenfolge der Tupel ist nicht definiert

• Reihenfolge der Attribute ist nicht definiert

• Attributwerte sind atomar

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 12


Relationales Datenmodell

Quelle: Laudon, Laudon, Schoder (2006), S. 331


© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 13
Structured Query Language (SQL)

• Standard für relationale Datenbanken, ANSI (American


National Standards Institute) bzw. ISO (International
Standardization Organization) Norm für SQL 2 liegt vor,
Weiterentwicklung SQL 3

• Nicht-prozedurale, deskriptive Datenbanksprache:


eine SQL-Anfrage drückt aus, wie das gewünschte
Ergebnis aussehen soll

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 14


SQL-Anweisung
Aufbau

Struktur:
SELECT Attribut(e)
FROM Relation(en)
[ WHERE Bedingung ]
[ GROUP BY Attribut(e) ]
[ ORDER BY Attribut(e) ASC/DESC ]

Bedeutung:
Suche Attributwerte / Spalten
in Relation(en)
[ wobei gilt: Bedingung ]
[ Aggregation nach … ]
[ Sortierung nach … ]

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 15


SELECT, FROM, Sortierung

SELECT * Alle Spalten


FROM sales Tabelle „sales“
ORDER BY ID Sortierung über Spalte „ID“

ID StoreNo SalesRegion ItemNo ItemDescription UnitPrice UnitsSold


1 1 South 2005 17" Monitor 229.00 28
2 1 South 2005 17" Monitor 229.00 30
3 1 South 2005 17" Monitor 229.00 9
4 1 South 3006 101 Keyboard 19.00 30
5 1 South 3006 101 Keyboard 19.00 35
6 1 South 3006 101 Keyboard 19.00 39
7 1 South 6050 PC Mouse 8.00 28
8 1 South 6050 PC Mouse 8.00 3
9 1 South 6050 PC Mouse 8.00 38
10 1 South 8500 Desktop CPU 849.00 25
… … … … … … …

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 16


SELECT, FROM, Sortierung

SELECT ID, StoreNo, UnitsSold


FROM sales
ORDER BY ID

ID StoreNo UnitsSold
1 1 28
2 1 30
3 1 9
4 1 30
5 1 35
6 1 39
7 1 28
8 1 3
9 1 38
10 1 25
… … …

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 17


SELECT
Berechnung (*), Benennung (AS)

SELECT ID, ItemNo, UnitPrice * UnitsSold AS Turnover


FROM sales
ID ItemNo Turnover
1 2005 6412.00
2 2005 6870.00
3 2005 2061.00
4 3006 570.00
5 3006 665.00
6 3006 741.00
7 6050 224.00
8 6050 24.00
9 6050 304.00
10 8500 21225.00
11 8500 22923.00
12 8500 28017.00
13 2005 1832.00
14 2005 1832.00
15 2005 2290.00
… … …

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 18


WHERE

SELECT *
FROM sales
WHERE ItemNo = “2005“ AND StoreNo < 6
ID StoreNo SalesRegion ItemNo ItemDescription UnitPrice UnitsSold
1 1 South 2005 17" Monitor 229.00 28
2 1 South 2005 17" Monitor 229.00 30
3 1 South 2005 17" Monitor 229.00 9
13 2 South 2005 17" Monitor 229.00 8
14 2 South 2005 17" Monitor 229.00 8
15 2 South 2005 17" Monitor 229.00 10
25 3 South 2005 17" Monitor 229.00 38
26 3 South 2005 17" Monitor 229.00 30
27 3 South 2005 17" Monitor 229.00 3
37 4 North 2005 17" Monitor 229.00 18
38 4 North 2005 17" Monitor 229.00 20
39 4 North 2005 17" Monitor 229.00 4
49 5 North 2005 17" Monitor 229.00 27
50 5 North 2005 17" Monitor 229.00 25
51 5 North 2005 17" Monitor 229.00 23

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 19


SQL Aufgabe (1)

Es sind alle Verkäufe (ID, ItemNo, UnitsSold) zu listen, die


eine Stückzahl (UnitsSold) von über 60 aufweisen.

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 20


Relationales Datenmodell:
Grundoperationen
Input-Relationen

Gemeinsames Attribut

Selektion Verbund

Ergebnis-Relation Projektion
Quelle: Laudon, Laudon, Schoder (2006), S. 332

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 22


Relationale Grundoperationen
SQL-Statement
Projektion
SELECT Artikelnummer, Lieferant.Lieferantennummer,
Lieferantenname, Lieferantenadresse Input-Relationen

FROM Artikel, Lieferant Verbund


WHERE Artikel.Lieferantennummer = Lieferant.Lieferantennummer

AND ( Artikelnummer = 137 OR Artikelnummer = 152 )

Selektion

Ergebnis-Relation

Quelle: Laudon, Laudon, Schoder (2006), S. 332

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 23


Beispiel
Schema einer Banking Datenbank

account
branch account_number varchar(15)

branch_name varchar(15) branch_name varchar(15)

branch_city varchar(15) balance decimal(12,2)

assets decimal(12,2)
depositor
customer_name varchar(15)

account_number varchar(15)

customer

©Silberschatz, Korth and Sudarshan


customer_name varchar(15)

customer_street varchar(12)

customer_city varchar(15)

borrower
loan customer_name varchar(15)
loan_number varchar(15) loan_number varchar(15)
branch_name varchar(15)

amount decimal(12,2)

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 24


FROM
Kartesisches Produkt
branch

• Die FROM Clause erzeugt das Kartesische Produkt branch_name


branch_city
der Relationen einer Query assets
account
account_number

©Silberschatz, Korth and Sudarshan


• Erinnerung: branch_name

Das Kartesiche Produkt zweier Mengen kombiniert


balance
depositor
JEDES Element der ersten Menge mit JEDEM customer_name

Element der zweiten Menge account_number


customer
customer_name
customer_street
• Beispiel: customer_city
Finde das Karteschiche Produkt borrower x loan borrower
customer_name
loan_number
select * loan
from borrower, loan loan_number
branch_name
amount

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 25


Verbund versus Kartesisches Produkt

branch

• Verbund: Kombination von FROM und WHERE branch_name


branch_city
• Verknüpfe die beteiligten Relationen anhand der assets

Bedingung in der WHERE Clause


account
account_number

©Silberschatz, Korth and Sudarshan


branch_name
balance
• Beispiel: Finde die Namen (customer_name), depositor
Kreditnummern (loan_number) und den customer_name
account_number
Kreditbetrag (loan amount) aller Kunden customer

• Dazu müssen die Relationen borrower und loan customer_name


customer_street
sinnvoll verknüpft werden customer_city
borrower
customer_name
select customer_name, borrower.loan_number, loan_number

amount loan
loan_number
from borrower, loan branch_name
where borrower.loan_number = loan.loan_number amount

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 26


Verbund und zusätzliche Selektion

branch

• Beispiel: Finde die Namen (customer_name), branch_name


branch_city
Kreditnummern (loan_number) und den assets
Kreditbetrag (loan amount) aller Kunden, die ein account
account_number
Kreditkonto in der Filiale ‘Perryridge’ haben

©Silberschatz, Korth and Sudarshan


branch_name
• Kombiniere den Verbund von borrower und loan mit balance
depositor
der Selektion auf ‘Perryridge’ customer_name
account_number
customer
select customer_name, borrower.loan_number, customer_name

amount customer_street
customer_city
from borrower, loan borrower
where borrower.loan_number = loan.loan_number customer_name
loan_number
and branch_name = 'Perryridge' loan
loan_number
branch_name
amount

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 27


Verbund und Selektion

branch

Welche Konten (account) werden von den branch_name


branch_city
Filialen in ‘Brooklyn‘ (branch_city) verwaltet assets
und wie hoch ist das jeweilige Guthaben account
account_number
(balance)? branch_name
balance
depositor
customer_name

©Silberschatz, Korth and Sudarshan


account_number
customer
customer_name
customer_street
customer_city
borrower
customer_name
loan_number
loan
loan_number
branch_name
amount

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 28


Aggregation von Daten auf
Managementebene

Beispielbericht eines MIS

Quelle: Laudon, Laudon, Schoder (2009), S. 439


© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 30
GROUP BY: Aggregation

SELECT StoreNo, SUM(UnitsSold)


FROM sales
GROUP BY StoreNo

StoreNo SUM(UnitsSold) Units


800
1 325
2 132 700

3 306 600
4 267 500
5 615
400
6 727
300
7 548
200
8 257
100

0
1 2
3
4 R1
5
StoreNo 6
7
8

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 31


GROUP BY: Aggregation

SELECT ItemNo, SalesRegion, SUM(UnitsSold)


FROM sales
GROUP BY ItemNo, SalesRegion

ItemNo SalesRegion SUM(UnitsSold)


UnitsSold
2005 East 328
600,00
2005 North 117
2005 South 164 500,00
3006 East 385
400,00
3006 North 309
3006 South 223 300,00

6050 East 297 Item No


200,00
6050 North 222 8500
6050 South 151 100,00 6050
3006
8500 East 522 0,00
8500 North 234 2005
East
North
8500 South 225 South
SalesRegion

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 32


SQL Aufgabe (2)

Es sind die Umsätze pro Artikel (ItemNo) aufzulisten.

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 33


Aggregation und Verbund

branch

• Finde die Anzahl der Einlagenkunden branch_name


branch_city
(customer_name) für jede Filiale (branch_name) assets
account
account_number
branch_name
balance
depositor
customer_name
account_number
customer

©Silberschatz, Korth and Sudarshan


customer_name
customer_street
customer_city
borrower
customer_name
loan_number
loan
loan_number
branch_name
amount

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 35


SQL Spielwiese

E-Learning-Plattform des ISE-Lehrstuhls für SQL:


https://pound.wiwi.uni-frankfurt.de/spielwiesen/

1) Login-Daten: Daten aus Enlist (Tutorienanmeldung)


• E-Mail-Adresse
• Matrikelnummer

2) Veranstaltung wählen

3) Datenbank/Kennung:
g+Tutoriumsnummer
(bspw. g1;g12; etc.)

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 37


Fallstudie: Datenintegration in SAP
Vertriebsunterstützung
Angebotserstellung in SAP

Kunde

Produkt

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 38


Fallstudie: Datenintegration in SAP
Vertriebsunterstützung
Auftragserfassung in SAP

Produkt

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 39


Fallstudie: Datenintegration in SAP
Fertigungssystem
Fertigungsauftrag in SAP

Produkt

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 40


Fallstudie: Datenintegration in SAP
Fertigungssystem
Rückmeldung eines Fertigungsauftrags in SAP

Produkt

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 41


Fallstudie: Datenintegration in SAP
Finanzsystem
Fakturaerstellung in SAP

Kunde

Produkt

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 42


Fallstudie: Datenintegration in SAP
Finanzsystem
Zahlungseingang in SAP buchen

Kunde

© Professur für Information Systems Engineering, Prof. Dr. Holten 6 - 43


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 7 – Datenmodellierung mit dem


Entity-Relationship-Modell

Sie lernen in diesem Kapitel,

 wie die betrieblichen Anforderungen an die Datenintegration definiert


werden
 warum wir Schlüsselattribute in Relationen verwenden und wie wir
diese spezifizieren
 wie diese Anforderungen mit dem Entity-Relationship-Modell (ERM)
modelliert werden
 was Kardinalitäten sind und wie sie in der Min-Max-Notation
spezifiziert werden
 welche Auswirkungen die Spezifikationen von Kardinalitäten im
Datenmodell auf die Prozessabläufe haben

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

7 Datenmodellierung mit dem


Entity-Relationship-Modell

Laudon, Laudon, Schoder (2010):


Datenmanagement (Kapitel 6, 14)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 7-2


Relationales Datenmodell

Quelle: Laudon, Laudon, Schoder (2006), S. 331


© Professur für Information Systems Engineering, Prof. Dr. Holten 7-3
Primärschlüssel in Relationen

• Problem: Finden von Tuppeln in einer Relation


• Lösung: Verwendung von „Schlüsselattributen“
• Schlüssel identifiziert Tuppel eindeutig
• Eine systemfreie Zählnummer ist häufig sehr vorteilhaft

z.B. Auftrags#
Artikel#
Lieferanten#

Personal#
Arbeitsgang#

© Professur für Information Systems Engineering, Prof. Dr. Holten 7-4


Problem: Mehrere Schlüsselattribute
Beispiel: Orderbuch

Quelle: Vgl. Laudon, Laudon, Schoder (2006), S. 332


Drei Möglichkeiten der Bildung eines Schlüssels!
1. (Artikelnummer)
2. (Lieferantennummer)
3. (Artikelnummer, Lieferantennummer)

Was bedeutet das für unseren Prozess?

Problem: Wer legt diese Bedeutung fest?


Betriebswirt und Prozessverantwortlicher?
Datenbankentwickler?

© Professur für Information Systems Engineering, Prof. Dr. Holten 7-5


Problem: Mehrere Schlüsselattribute
Beispiel: Orderbuch

Quelle: Vgl. Laudon, Laudon, Schoder (2006), S. 332


1. (Artikelnummer)

2. (Lieferantennummer)

3. (Artikelnummer, Lieferantennummer)

© Professur für Information Systems Engineering, Prof. Dr. Holten 7-6


Datenstrukturorientierte IS-Modellierung

Entity/Relationship-Modell (ERM)

• Vorgeschlagen von P.P. Chen 1976

• Quasi-Standard zur datenorientierten IS-Modellierung


in der Praxis

• Viele Notationsvarianten und Erweiterungen gebräuchlich

• Besonderheiten der hier verwendeten Variante


• Min-Max-Notation der Kardinalitäten
• Leserichtung der Kardinalitäten

© Professur für Information Systems Engineering, Prof. Dr. Holten 7-8


Entity

• Reales oder abstraktes Ding/Objekt, das für den


betrachteten Realweltausschnitt von Interesse ist

• Beschrieben durch eine definierte Kombination von


Attributwerten

• Beispiel: Lieferant
Name: CBM Inc.
Adresse: 44 Winslow, Gary, In 44950
Tel: 1234567

© Professur für Information Systems Engineering, Prof. Dr. Holten 7-9


Entity-Typ

• Formale Struktur eines Entities, einschließlich


Wertebereichen der das Entity beschreibenden Attribute

• Bezeichnung als "Substantiv",


z.B. Kunde, Lieferant, Produkt, Auftrag

• Für Entity-Typen kann analog zu Relationen ein Schlüssel


als identifizierende Attributmenge definiert werden

• In der graphischen Darstellung werden die


entsprechenden Attribute unterstrichen

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 10


Entity-Typ – Graphische Darstellung

• graphisch dargestellt durch ein Rechteck; Attribute als


Ovale

• Attribute können in der graphischen Darstellung aus


Übersichtsgründen weggelassen werden

L# Name Wohnort Telefon#

Lieferant

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 11


Relationship (Beziehung)

• Logische Verknüpfung zwischen zwei Entities

• Kann zusätzlich durch Attribute beschrieben werden

• Beispiel:
Relationship „bestellt“
zwischen Kunde und Artikel
Attribute: Datum, Menge

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 12


Relationship-Typ

• Graphisch dargestellt durch Rauten; Attribute als Ovale

• Attribute können in der graphischen Darstellung aus


Übersichtsgründen weggelassen werden

• Schlüssel setzen sich aus den Schlüsseln der beteiligten


Entity-Typen zusammen

K# K#, A# Datum Menge A#

Kunde bestellt Artikel

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 13


Beispiel: Immatrikulation

• Studenten sind immatrikuliert für Studienfächer


Immatrikulation

Student Immatrikulation Studienfach

Wichtige Fragen für den Einschreibungs-Prozess:


• Soll es in unserem System Studenten geben, die nichts studieren?
• Dürfen Studenten mehrere Fächer studieren?
• Sind für ein Studienfach viele Studenten eingeschrieben?
• Muss in jedem Studienfach jemand eingeschrieben sein?

Verwendung von Kardinalitäten!

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 14


ERM Kardinalitäten
Beispiele (1)

(min,max) Immatrikulation (min,max)

(1,n) (0,m)
Student Immatrikulation Studienfach

• Studenten müssen mindestens ein Studienfach


studieren,
• sie können aber auch mehrere Studienfächer belegen
• Es kann Studienfächer ohne Studenten geben;
• für jedes Studienfach dürfen viele Studenten
eingeschrieben sein

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 15


ERM Kardinalitäten
Beispiele (2)

Bezugsnachweis / Orderbuch

(0,n) Bezugs- (0,1)


Lieferant Artikel
nachweis

• Jeder Lieferant kann mehrere Artikel liefern.


• Jeder Artikel kann maximal von einem Lieferanten
bestellt werden.

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 16


Spezialisierung / Generalisierung

• Eine Spezialisierung Mitarbeiter

beschreibt eine
Untergliederung eines Entity-
Typs in Unterkategorien
Professor

• Eine Generalisierung
beschreibt die
Zusammenfassung von
Wissenschaftlicher
Mitarbeiter

Entity-Typen in einem
übergeordneten Entity-Typ Studentische
Hilfskraft

• Die Leserichtung entscheidet


über Spezialisierung bzw.
Generalisierung

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 17


Modellierungsaufgabe (1)

Konstruieren Sie ein Entity-Relationship-Modell (ERM) in der Min-


Max-Notation zu folgender Problemstellung:
• Jeder Lehrstuhl hat unterschiedliche Mitarbeiter:
Einen Professor, viele wissenschaftliche Mitarbeiter und
studentische Hilfskräfte.
• Jede studentische Hilfskraft ist einem wissenschaftlichen
Mitarbeiter zugeordnet.
• Die wissenschaftlichen Mitarbeiter bearbeiten
unterschiedliche Aufgabengebiete, welche durch den
Professor geleitet werden.
• Jeder Mitarbeiter ist einem Lehrstuhl zugeordnet.
• Jeder Lehrstuhl bietet unterschiedliche Veranstaltungen an:
Vorlesungen, Übungen und Tutorien.

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 18


Modellierungsaufgabe (1)

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 19


Komplexes Datenmodell: Wareneingang
Uminterpretierter Relationship-Typ

Quelle: Vgl. Becker, Schütte (2004), S. 341


(0,m)

Abnehmer- (0,m)
artikel (0,m)

Uminterpretierter Entity-Relationship-Typ
(0,m) (0,m) mengenmäß.
Lagerplatz Bestand
Bestandsbuchung

Bestell- (0,m)
(0,m) position
(0,m)
(0,m)
Zeit
(0,m)
(1,m)
Vergleich
(0,m)
WE- mit Be-
stellposition
(0,m) Bestellkopf
Geschäftspartner
Abnehmer (0,m) A
(0,m)
(0,m (0,m)
(1,m)
WE-Position
Einkaufs- (0,m)
organisation WE-Kopf

D,T
(0,m) T WE-Kopf ohne
Disponent Bestellbezug

(0,m)
Geschäftspartner WE-Kopf mit
Lieferant (0,m) Bestellbezug
(1,m)

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 24


Modellierungsaufgabe (2)
Uminterpretierter Relationship-Typ

Konstruieren Sie ein Entity-Relationship-Modell (ERM) in der


Min-Max-Notation zu folgender Problemstellung:

• Kunden bestellen Artikel.


• Eine Bestellung wird anhand des Kunden und der Zeit
identifiziert. Man spricht auch vom „Bestellkopf“.
• Eine Bestellung hat mehrere, aber mindestens eine
Bestellposition.
• Eine Bestellposition verweist genau auf einen Artikel.

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 25


Modellierungsaufgabe (2)
Uminterpretierter Relationship-Typ

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 26


Retail Management
Anforderungen an die Datenbank

• Retail / Einzelhandel wird über hierarchische


Warengruppen gesteuert
• Wie kann das mit ERM abgebildet werden?
© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 28
Hierarchische Strukturen
Beispiel: Warengruppenhierarchie

000 Sortiment Warengruppe

100 Lebensmittel
101 Lebensmittel (Haltbar)
5001 Spaghetti, 500g, Hartweizen
5200 Texas-Eintopf, 500ml
102 Lebensmittel (Frisch)
Artikel
6000 Kopfsalat
200 Schreibwaren
1000 Papier, 80g, 500 Stk
1100 Textmarker 490, Orange

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 29


Warengruppe/Hierarchie als Tabellen

Warengruppe Warengruppenhierarchie
WGR WGRBEZ WGR ÜWGR
000 Sortiment 100 000
100 Lebensmittel 200 000
101 Lebensmittel (Haltbar) 101 100
102 Lebensmittel (Frisch) 102 100
200 Schreibwaren

Kann zusammengefasst werden wegen (0,1)-Kardinalität

Artikel Art.-WGr.-Zuordnung
ANR ABEZ ANR WGR
1000 Papier, 80g, 500 Stk 1000 200
1100 Textmarker 490, Orange 1100 200
5001 Spaghetti, 500g, Hartweizen 5001 101
5200 Texas-Eintopf, 500ml 5200 101
6000 Kopfsalat 6000 102

Kann zusammengefasst werden wegen (0,1)-Kardinalität

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 30


ERM Kardinalitäten
Hierarchische Strukturen

Warengruppe / Hierarchie

WGR, ÜWGR

überg. Waren-
gruppenhie-
rarchie

(0, m) unterg.
(0, 1)

Warengruppe Zuordnung Artikel


(0, m) (0, 1)

WGR WGRBEZ

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 31


Modellierungsaufgabe (3)

Konstruieren Sie ein Entity-Relationship-Modell (ERM) in der


Min-Max-Notation zu folgender Problemstellung:

• Ein Handelsunternehmen möchte eine einfache Auswertung


des Sortiments (= Artikel) konzipieren. Die Auswertung soll
auf Basis der Warengruppen erfolgen.

• Jeder Artikel ist immer genau einer Warengruppe


zugeordnet.

• Warengruppen sind in einer Hierarchie strukturiert.

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 32


Modellierungsaufgabe (3)

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 33


Netz-Strukturen: Stücklisten
Bruttobedarfsrechnung im MRP II

- Baukastenstückliste
Einstufiges Verzeichnis aller Komponenten einer Baugruppe.
D.h. es werden nur direkt untergeordnete Teile dargestellt.
- Strukturstückliste
Strukturierende Auflistung aller Teile, die in das Produkt
eingehen. Die Strukturstückliste wird in Form eines
Gozintographen angegeben. Sie ist eine Zusammenfassung
aller Baukastenstücklisten.

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 35


Beispiel: Baukastenstückliste in SAP

Stückliste "Motorrad"
Teil Menge
Motor 1
Rahmen 1
Reifen 2

Stückliste "Motor"
Teil Menge
Motorblock 1
Motorwelle 1

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 36


Beispiel: Strukturstückliste in SAP

Gozintograph:
B 1

M
1
W 1

1
R X

2
Legende:
F
X: Motorrad
M: Motor
B: Motorblock
W: Motorwelle
R: Rahmen
F: Reifen

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 37


Anwendung
MRP – Programmgesteuerte Disposition in SAP

• Stücklistenauflösung in SAP

Für die Herstellung von


einem Motorrad benötigt
man diese Komponenten…

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 38


Bruttobedarfsrechnung
Stücklisten

• Stücklisten je Endprodukt
• Bauteil kann in mehrere Endprodukte eingehen
• Tisch 1 benötigt drei Beine

Bein Tisch 1

• Tisch 2 benötigt vier Beine

Bein Tisch 2

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 39


ERM Kardinalitäten Netz-Strukturen
Beispiel Materialwirtschaft

Stückliste

0,m
0,m

0,m
Teil
0,m
0,m

Deckung des
Deckung des
Bedarfs durch
Bedarfs durch
Fertigungs-
Lagerbestand
auftrag

0,m 0,m 0,m 0,m


Lager- Fertigungs-
Bedarf
bestand 0,m 0,m auftrag

0,m 0,m

Bedarfs-
ableitung
0,m
0,m
Zeit
0,m

Fertigungs-
auftrag auf
Lager

© Professur für Information Systems Engineering, Prof. Dr. Holten 7 - 40


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 8 – Prozessintegration - Enterprise


Systems & SAP
Sie lernen in diesem Kapitel,

 was unter Prozessintegration zu verstehen ist


 die Ebenen-Struktur und Instanz von Prozessen zu unterscheiden
 was unter Cycle Time Analysis verstanden wird
 wie Process Cycle Times (Durchlaufzeiten) auf der Grundlage von
bekannten Activity Times auch bei komplexen BPMN-
Prozessstrukturen berechnet werden können
 die Begriffe ERP-System und Enterprise System kennen
 zu welchen Verbesserungen betrieblicher Prozesse Enterprise Systems
führen
 die Architektur integrierter Anwendungssysteme kennen
 das Potenzial aktueller IT-Trends für die Datenerfassung und die
Prozessintegration kennen

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

8 Prozessintegration -
Enterprise Systems & SAP

Laudon, Laudon, Schoder (2016):


Integrierte Informationsverarbeitung (Kapitel 9)

Dumas, M.; LaRosa, M.; Mendling, J.; Reijers, H.:


Fundamentals of Business Process Management;
Springer, 2013. (Kapitel 7)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 8-2


RFID - Radio Frequency Identification

• RFID - Technik
• Technik zur automatischen Identifizierung von Objekten
• Verwendet sogenannte Tags mit eingebauten Mikrochips,
welche Daten über ein Objekt und seine Position beinhaltet
• Bau sehr kleiner Transponder möglich (z.B. staubkorngroße
RFID-Chips mit 0,15mm Kantenlänge und 7,5µm Dicke)
• Chips übertragen Funksignale über kurze Entfernungen an
RFID-Sensoren. Zur Weiterverarbeitung werden diese Daten
zu Rechnern gesendet.

Quelle: Laudon, Laudon (2009), S. 217


© Professur für Information Systems Engineering, Prof. Dr. Holten 8-3
Fallstudie: RFID & Prozessintegration

• Eine Krise führte Gerry Weber in die Insolvenz

•Quelle: Gerry Weber International AG: Die RFID Einführung


• Neustart in 2020 mit Fokus auf Effizienzsteigerung
• Internationaler Fashion- und Lifestyle-Konzern
• Mehr als 430 HOUSES OF GERRY WEBER und über 2.000 Shop-
Flächen weltweit, darunter u.a. Berlin, Hamburg, Dubai, Kairo, St.
Petersburg, Moskau
• Konzernumsatz: 802,3 Mio. Euro
• Gerry Weber investiert 2,7 Mio. EUR in RFID-Technik

© Professur für Information Systems Engineering, Prof. Dr. Holten 8-4


Fallstudie: RFID & Prozessintegration

• 25 Mio. Kleidungsstücke werden


direkt in der Produktion mit einem
eingenähten RFID-Tag versehen

• RFID erhöht die Transparenz in der


Logistik und reduziert die
Fehlerquote auf ein Minimum

Quelle: Gerry Weber International AG: Die RFID Einführung


© Professur für Information Systems Engineering, Prof. Dr. Holten 8-5
Fallstudie: RFID & Prozessintegration
EPC (Electronic Product Code)

• EPC

Quelle: Gerry Weber International AG: Die RFID Einführung


• international verwendetes Codesystem für eindeutige
Identifikationsnummern, mit dem
• Produkte, logistische Einheiten (Umverpackungen,
Transportpaletten, etc.), Mehrwegtransportbehälter und
Lokationen (z. B. Anlagen, Gebäudeteile, Lagerorte)
• weltweit eindeutig gekennzeichnet und identifiziert werden
können

• Kombination RFID-Tag und EPC


• Erfassung und Verfolgung von Objekten
• ohne Sicht- und Berührungskontakt
Warenfluss
Informationsfluss

© Professur für Information Systems Engineering, Prof. Dr. Holten 8-6


Fallstudie: RFID & Prozessintegration
EPC (Electronic Product Code)

Karton Karton Karton


Karton Karton Karton
Karton
Produkt ( ( ) ) Karton
Produkt Produkt ( ( ) ) Karton
Produkt Produkt (( ))
Produkt
Produkt ( ( ) ) Produkt
Produkt ( ( ) ) Produkt
Produkt
Produkt
Produkt
Produkt
Produkt
Produkt ( Produkt
( ) ) Produkt
Produkt
Produkt( Produkt
( ) ) Produkt
Produkt
Produkt( (() ))
Produkt
Artikel Produkt
Artikel Produkt
Artikel

Mehrwegtransportverpackung (Palette)

Zentrallager
Zentrallager Einzel-/Großhandel
Hersteller

Service
Konsument

Transport
Transport Transport
Transport

Warenfluss
Informationsfluss

© Professur für Information Systems Engineering, Prof. Dr. Holten 8-7


Fallstudie: RFID & Prozessintegration
EPC (Electronic Product Code)

Transportlogistik: RFID
koppelt Warenfluss und
Informationsfluss

Warenfluss
Informationsfluss

Quelle: Gerry Weber International AG: Die RFID Einführung


© Professur für Information Systems Engineering, Prof. Dr. Holten 8-8
Fallstudie: RFID & Prozessintegration
EPC (Electronic Product Code)

Warensicherung: RFID Warenfluss


koppelt Warenfluss und Informationsfluss

Informationsfluss

Quelle: Gerry Weber International AG: Die RFID Einführung


© Professur für Information Systems Engineering, Prof. Dr. Holten 8-9
Prozessintegration

Quelle: Laudon, Laudon, Schoder (2006), S. 99


• Prozessintegration
• Kopplung von Warenfluss (Process Flow) und
Informationsfluss
Warenfluss

Informationsfluss
© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 10
Prozessintegration
Enterprise Systems - Beispiel SAP

SD FI
Vertrieb Rechnungs-
wesen
MM
Material-
CO
Controlling
wirtschaft
PP AM
Produktions- Anlagen-
planung wirtschaft

R/3
QM BASIS PS
Qualitäts. Projekt-
management System
PM WF
Instant- Workflow
haltung
HR IS
Personal- Branchen-
wirtschaft lösungen

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 11


Beispiel: Prozess Auftragsbearbeitung
Struktur und Instanz
Daten Prozess
Struktur

Vollständigkeit Bestellmenge
prüfen eintragen
(5 Minuten) (2 Minuten)
Auftrag Auftrag
erhalten bearbeitet

Instanz

• Prozessintegration: Berechnung von Prozesszeiten (Cycle


Time) für Prozessinstanzen (Process Flows)
• Im Beispiel: 5 Minuten + 2 Minuten = 7 Minuten

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 12


Prozessintegration
Cycle Time Analysis

• Cycle time: difference between a job’s start and end time


• Cycle time analysis: the task of calculating the average
cycle time for an entire process or process fragment
• Assumes that the average activity times for all involved activities
are available
• In the simplest case a process consists of a sequence of
activities on a sequential path
• The average cycle time is the sum of the average activity times
• … but in general we must be able to account for
• Alternative paths (XOR splits)
• Parallel paths (AND splits)
• Rework (cycles)

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 13


Alternative Paths – Example

• What is the average cycle time?

•Dumas et al., 2013


90%

10%

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 14


Alternative Paths

•Inspired by a slide by Manuel Laguna & John Marklund


n

CT = p1T1+p2T2+…+pnTn = pT i i
i1

pi = branching probability with


which branch Ti is taken
© Professur für Information Systems Engineering, Prof. Dr. Holten  8 - 16
Parallel Paths – Example

• What is the average cycle time?

•Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 17
Parallel Paths

• If two activities related to the same job are


done in parallel the contribution to the cycle

•Inspired by a slide by Manuel Laguna & John Marklund


time for the job is the maximum of the two
activities.

CTparallel = Max{T1, T2,…, TM}

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 19


Rework– Example

• What is the average cycle time?

•Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 20
Rework

Rework Block or Repetition Block

•Dumas et al., 2013


Rework Probability: r

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 22


Rework
Example: 1000 Objects

Number of Flow Time for


Objects Number of Cumulative Average Flow
Visit per Visit Flow Units Flow Time Time
1 1000 3000 3000 3
2 500 1500 4500 4,5
3 250 750 5250 5,25
4 125 375 5625 5,625
5 62,5 187,5 5812,5 5,8125
Observation: 6
7
31,25
15,625
93,75
46,875
5906,25
5953,125
5,90625
5,953125
8 7,8125 23,4375 5976,5625 5,9765625
Cycle Time 9 3,90625 11,71875 5988,28125 5,98828125
10 1,953125 5,859375 5994,140625 5,994140625
converges 11 0,9765625 2,9296875 5997,070313 5,997070313
12 0,48828125 1,46484375 5998,535156 5,998535156
T/(1-r) 13 0,244140625 0,732421875 5999,267578 5,999267578
… …
© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 23
Rework
Example: 1000 Objects

Flow Time
Number of for
Objects Number of Cumulative Average
Visit per Visit Flow Units Flow Time Flow Time
1 1000 3000 3000 3
2 200 600 3600 3,6
3 40 120 3720 3,72
4 8 24 3744 3,744
5 1,6 4,8 3748,8 3,7488
Observation: 6
7
0,32
0,064
0,96
0,192
3749,76
3749,952
3,74976
3,749952
8 0,0128 0,0384 3749,9904 3,7499904
Cycle Time 9 0,00256 0,00768 3749,99808 3,74999808
10 0,000512 0,001536 3749,999616 3,749999616
converges 11 0,0001024 0,0003072 3749,999923 3,749999923
T/(1-r) 12
13
0,00002048
0,000004096
0,00006144
0,000012288
3749,999985
3749,999997
3,749999985
3,749999997
… …
© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 24
Rework

• Many processes include control or inspection


points where, if the job does not meet certain
standards, it is sent back for rework

•Dumas et al., 2013


CT = T/(1-r)

1
Remember the geometric series: r
n 1
n 1

1 r
, r 1

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 25


Rework At Most Once– Example

• What is the average cycle time?

•Dumas et al., 2013


© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 26
Calculate Cycle Time!

Assumptions: Activity Cycle Time


Check completeness 1 day
1) Application is incomplete Check credit history 1 day
in 20 % of the cases Check income sources 3 days
2) Credit is granted in 60% Assess application 3 days

•Dumas et al., 2013


of the cases Make credit offer 1 day
Notify rejection 2 days

application incomplete 20 % Check credit Granted 60% Make credit


history offer

Check 80% Assess


completeness application
Application Application
Check
received Notify processed
income
denied 40% rejection
sources

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 28


Fallstudie: Leiner Health Products
Enterprise Systems – Belege

• MRP-System:
• Kundenanforderungen
• Kundenbestellungen
• Lieferzeiten
• Lagerbestände
• Produktionskapazitäten

• Cash-Flow-Management:
• Kundenverträge
• Rechnungsstellung
• Zahlung

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 30


Fallstudie: Prozessintegration mit SAP
Belege und Belegflüsse

Quelle: Stahlknecht; Hasenkamp, 2005

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 31


Fallstudie: Prozessintegration mit SAP

1. 2. 3.
Anfrage Angebot Auftrag
(10000394) (20000276) (8415)

4. 6. 8. Waren- 10.
Waren- Fertigungs- ausgangs- 9.
Zahlungs-
bestellung auftrag beleg Faktura
beleg
(90033326)
(3400309) (60002705) (5000509) (10004448)

5. Waren- 7. Waren-
eingangs- eingangs-
beleg beleg
(30004353) (30004578)

Belege dokumentieren den Prozessfluss,


d.h. die Prozessinstanz

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 32


Fallstudie: SAP
1. 2. 3.
Anfrage Angebot Auftrag
(10000394) (20000276) (8415)

Vertriebsunterstützung 4.
Waren-bestellung
(3400309)
6.
Fertigungs-auftrag
(60002705)
8. Waren-
ausgangs-beleg
(5000509)
9.
Faktura
(90033326)
10.
Zahlungs-beleg
(10004448)

Angebotserstellung in SAP 5. Waren- 7. Waren-


eingangs-beleg eingangs-beleg
(30004353) (30004578)

Angebotsnr.:
20000276

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 33


Fallstudie: SAP
1. 2. 3.
Anfrage Angebot Auftrag
(10000394) (20000276) (8415)

Vertriebsunterstützung 4.
Waren-bestellung
(3400309)
6.
Fertigungs-auftrag
(60002705)
8. Waren-
ausgangs-beleg
(5000509)
9.
Faktura
(90033326)
10.
Zahlungs-beleg
(10004448)

Auftragserfassung in SAP 5. Waren- 7. Waren-


eingangs-beleg eingangs-beleg
(30004353) (30004578)

Auftragsnr.:
8415

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 34


Fallstudie: SAP
1. 2. 3.
Anfrage Angebot Auftrag
(10000394) (20000276) (8415)

Produktionssystem 4.
Waren-bestellung
(3400309)
6.
Fertigungs-auftrag
(60002705)
8. Waren-
ausgangs-beleg
(5000509)
9.
Faktura
(90033326)
10.
Zahlungs-beleg
(10004448)

Fertigungsauftrag in SAP 5. Waren-


eingangs-beleg
(30004353)
7. Waren-
eingangs-beleg
(30004578)

Fert.Auftr.:
60002705

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 35


Fallstudie: SAP
1. 2. 3.
Anfrage Angebot Auftrag
(10000394) (20000276) (8415)

Produktionssystem 4.
Waren-bestellung
(3400309)
6.
Fertigungs-auftrag
(60002705)
8. Waren-
ausgangs-beleg
(5000509)
9.
Faktura
(90033326)
10.
Zahlungs-beleg
(10004448)

Rückmeldung eines Fertigungsauftrags in SAP 5. Waren-


eingangs-beleg
(30004353)
7. Waren-
eingangs-beleg
(30004578)

Warenein-
gangsbeleg:
30004578

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 36


Fallstudie: SAP
1. 2. 3.
Anfrage Angebot Auftrag
(10000394) (20000276) (8415)

Finanzsystem 4.
Waren-bestellung
(3400309)
6.
Fertigungs-auftrag
(60002705)
8. Waren-
ausgangs-beleg
(5000509)
9.
Faktura
(90033326)
10.
Zahlungs-beleg
(10004448)

Fakturaerstellung in SAP 5. Waren-


eingangs-beleg
(30004353)
7. Waren-
eingangs-beleg
(30004578)

Rechnungsnr.:
90033326

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 37


Fallstudie: SAP
1. 2. 3.
Anfrage Angebot Auftrag
(10000394) (20000276) (8415)

Finanzsystem 4.
Waren-bestellung
(3400309)
6.
Fertigungs-auftrag
(60002705)
8. Waren-
ausgangs-beleg
(5000509)
9.
Faktura
(90033326)
10.
Zahlungs-beleg
(10004448)

Zahlungseingang in SAP buchen 5. Waren-


eingangs-beleg
(30004353)
7. Waren-
eingangs-beleg
(30004578)

Zahlungsbeleg:
100004448

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 38


Fallstudie: Prozessintegration mit SAP
BPMN 1/4

Prozessinstanz

Anfrage
(10000394)

Kunde
bereits im
System?

Prüfen, ob Kunde ja
Kundenanfrage
bereits im System
bearbeiten
ist
Kundenanfrage geht ein
Kundenstamm-
daten anlegen
nein

Kunden
-stammdaten
© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 39
Fallstudie: Prozessintegration mit SAP
BPMN 2/4

Prozessinstanz

Anfrage Angebot Auftrag


(10000394) (20000276) (8415) Stückliste
[s.o.]

Angebot erzeugen
Kundenauftrag Benötigtes Lagerbestand
und an Kunden
bearbeiten Material ermitteln prüfen
schicken

Konditionen Material- Material-


stammdaten stammdaten

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 40


Fallstudie: Prozessintegration mit SAP
BPMN 2/4

Prozessinstanz

Anfrage Angebot Auftrag


(10000394) (20000276) (8415) Stückliste
[s.o.]

Angebot erzeugen
Kundenauftrag Benötigtes Lagerbestand
und an Kunden
bearbeiten Material ermitteln prüfen
schicken

Konditionen Material- Material-


stammdaten stammdaten

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 41


Fallstudie: Prozessintegration mit SAP
BPMN 2/4

Prozessinstanz

Anfrage Angebot Auftrag


(10000394) (20000276) (8415) Stückliste
[s.o.]

Angebot erzeugen
Kundenauftrag Benötigtes Lagerbestand
und an Kunden
bearbeiten Material ermitteln prüfen
schicken

Konditionen Material- Material-


stammdaten stammdaten

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 42


Fallstudie: Prozessintegration mit SAP
BPMN 2/4

Prozessinstanz

Anfrage Angebot Auftrag


(10000394) (20000276) (8415) Stückliste
[s.o.]

Angebot erzeugen
Kundenauftrag Benötigtes Lagerbestand
und an Kunden
bearbeiten Material ermitteln prüfen
schicken

Konditionen Material- Material-


stammdaten stammdaten

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 43


Fallstudie: Prozessintegration mit SAP
BPMN 3/4

Prozessinstanz

Bestellung Warenein-
(3400309) gangsbeleg
(30004353)

Ausreichend viel
Material
vorhanden?

Lagerstand nein Materialeingang


Material bestellen
überprüfen erfassen

ja

Lieferanten-
stammdaten

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 44


Fallstudie: Prozessintegration mit SAP
BPMN 4/4

Prozessinstanz
Auftrag (8415)
[s.o]

Fertigungs- Warenein- Warenaus- Faktura Zahlungsbeleg


auftrag gangsbeleg gangsbeleg (90033326) (10004448)
(60002705) (3004578) (500509)

Fertigungsauftrag Fertigungsauftrag Warenausgang Zahlungseingang


Faktura erstellen
anlegen rückmelden buchen buchen

Arbeitsplan

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 45


Fallstudie: Prozessintegration mit SAP
BPMN 4/4

Prozessinstanz
Auftrag (8415)
[s.o]

Fertigungs- Warenein- Warenaus- Faktura Zahlungsbeleg


auftrag gangsbeleg gangsbeleg (90033326) (10004448)
(60002705) (3004578) (500509)

Fertigungsauftrag Fertigungsauftrag Warenausgang Zahlungseingang


Faktura erstellen
anlegen rückmelden buchen buchen

Arbeitsplan

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 46


Fallstudie: Prozessintegration mit SAP
BPMN 4/4

Prozessinstanz
Auftrag (8415)
[s.o]

Fertigungs- Warenein- Warenaus- Faktura Zahlungsbeleg


auftrag gangsbeleg gangsbeleg (90033326) (10004448)
(60002705) (3004578) (500509)

Fertigungsauftrag Fertigungsauftrag Warenausgang Zahlungseingang


Faktura erstellen
anlegen rückmelden buchen buchen

Arbeitsplan

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 47


Fallstudie: Prozessintegration mit SAP
BPMN 4/4

Prozessinstanz
Auftrag (8415)
[s.o]

Fertigungs- Warenein- Warenaus- Faktura Zahlungsbeleg


auftrag gangsbeleg gangsbeleg (90033326) (10004448)
(60002705) (3004578) (500509)

Fertigungsauftrag Fertigungsauftrag Warenausgang Zahlungseingang


Faktura erstellen
anlegen rückmelden buchen buchen

Arbeitsplan

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 48


Fallstudie: Prozessintegration mit SAP
BPMN 4/4

Prozessinstanz
Auftrag (8415)
[s.o]

Fertigungs- Warenein- Warenaus- Faktura Zahlungsbeleg


auftrag gangsbeleg gangsbeleg (90033326) (10004448)
(60002705) (3004578) (500509)

Fertigungsauftrag Fertigungsauftrag Warenausgang Zahlungseingang


Faktura erstellen
anlegen rückmelden buchen buchen

Arbeitsplan

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 49


Fallstudie: Leiner Health Products
Effekte der Prozessintegration

• Reduzierung von Lagerbeständen um 50 Mio. USD


• Pünktliche Lieferung in 95% aller Fälle
• Reduzierung der Beschaffungskosten
um 15%
• Reduzierung der Außenstände in 6 Wochen um 75%

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 50


Beispiel: Enterprise Systems
Effekte der Prozessintegration

• Beispiel Lucent Microelectronics


• Einführung eines Oracle Enterprise Systems
• Reduzierung der Durchlaufzeit von Geschäftsprozessen von
10-15 Tagen auf weniger als 8 Stunden
• Reduzierung der Logistikkosten von 1,5% auf 1% der
Einnahmen

• Beispiel Colgate Palmolive


• Einführung einer SAP Enterprise Software
• Halbierung der Zeit zwischen Auftragseingang und
Auslieferung
• Anstieg der rechtzeitigen Auslieferungen von 91,5% auf
97,5%
• Reduzierung der internen Lagerhaltung um 30%

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 51


Prozessintegration
Enterprise Systems

Architektur von unternehmensweiten Anwendungssystemen

•Quelle: Laudon, Laudon, Schoder (2006), S. 98


© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 52
Wie kommen die Daten ins System?

Riebels betriebswirtschaftlich
Technische ISMA- Architektur (IWH)
inhaltliche ISMA-Architektur
ISMA Endbenutzer/
(Sonderrechnungen)
Data-
Routinemäßig EIS Mining
OLAP-
Auswertungs-
Ad Hoc -Tools
Tool
tools

Verteilte
Auswertungsrechnungen Data Marts/
OLAP
MOLAP ROLAP

Archivierungssystem
Grundrechnung
der Ereignisse Zentrales
Data Metadaten-
Zahlungsansprüche Warehouse bank Data
Mengen Management
Zahlungen Warehouse
Tool Data Warehouse i.e.S.

Quelle: Holten (1999), S. 109


Import und Transformation
(Monitoren, Extraktoren und Integration) Importschicht
Doppisches Datensammlungen unstrukturierte
operatives Daten Daten aus Hosts, Externe Quellen
Buchhaltungs- diverser partieller (Textfiles,
System Filesystemen usw. (www, Nachrichten- Datenquellen
system Informationssysteme RDBMS Bilder usw.) dienste)
Jahresabschluss-

?
rechnung
Urdatensammlung

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 53


Warenausgangserfassung
Datenerfassung: Scanning

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 54


Fallstudie: RFID bei Wal-Mart (1/2)

Wal-Mart:
• 600 Geschäfte, 130 Lager, 60.000 Lieferanten
• Wal-Mart ist bekannt für sehr effiziente Distribution
• Dennoch steigen nun die Distributionskosten bei Wal-
Mart schneller als bei den Wettbewerbern

• RFID als Lösung zur Kostensenkung


• Wal-Mart macht eigene RFID Daten (Bestand, Lagerort) für
Lieferanten frei zugänglich
• Datenintegration von RFID und Point-of-Sale (PoS)
ermöglicht ein verbessertes Lagermanagement, wodurch
die Bestellkoordination optimiert wird
• Produkte ständig auf Lager vorrätig  Verkaufssteigerung

• Ziel: Sicherung der Marktvorteile.

Quelle: Laudon, Laudon (2009), S. 219


© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 55
Fallstudie: RFID bei Wal-Mart (2/2)

• Nachteile – hohe Kosten


• Einführungskosten für RFID Hard- und Software
20 Mio. USD
• Großlieferant mit ca. 15 Mio. Paletten und Kisten hat
Zusatzkosten von ca. 6 Mio. USD pro Jahr
• Wal-Mart will 130 Lager mit RFID ausstatten

• Realisierte Vorteile
• 30% Reduktion der Out-of-stock-rate durch
Datenkombination von RFID und PoS
• Großlieferant Pacific Coast Producers konnte durch
Datenkombination feststellen, welche Wal-Mart-Märkte
besser oder schlechter sind

Quelle: Laudon, Laudon (2009), S. 219


© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 56
RFID - Einsatzmöglichkeiten

Datenträger als Einsatz hitzefester


elektronischer Laufzettel in Datenträger bei
der Produktion Einbrennlackierung

Behältertracking in
32 KByte entsprechen ca. 15 – 20 Seiten
Förderanlagen
Lieferschein
Quelle: Baumer Ident, 2003

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 57


RFID - Einsatzmöglichkeiten

Einsatzmöglichkeiten:
• Logistik
• Waren- und Bestandsmanagement
• Fahrzeugidentifikation
• Identifikation von Personen
(dt. Reisepässe seit Nov. 2005)
• Kontaktlose Chipkarten (Goethecard)
• Zutrittskontrolle

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 58


RFID - Leistungsmerkmale

Leistungsmerkmale eines Tags


• Energieversorgung:
• Aktiv: Batterie
• Passiv: magnetisches bzw. elektromagnetisches Feld des
Lesegerätes
• Speichertechnologie:
• Read-only (preisgünstig)
• Read-write (ausgestattet mit
beschreibbarem Speicher)
• Mehrfachzugriffsverfahren
• Integrierte Sensorik
• Unterschiedliche Frequenzbereiche

© Professur für Information Systems Engineering, Prof. Dr. Holten 8 - 59


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 9 – Prozessqualität und ihre


Messung

Sie lernen in diesem Kapitel,

 welche Maße die Güte von Prozessen abbilden


 wie Little’s Law hilft, die Zusammenhänge von Throughput, Inventory
und Flow Time zu analysieren
 wie die Durchlaufzeit indirekt mittels Little’s Law bestimmt werden
kann
 wie die theoretische Durchlaufzeit eines Prozesses bestimmt wird
 die Critical Path Method kennen und wie der kritische Pfad die
Durchlaufzeit determiniert
 wie Flow Units für die Prozessanalyse bestimmt werden

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

9 Prozessqualität und ihre


Messung
Anupindi, R. et al.: Managing Business Process Flows (2006)
(Chapters 3 and 4)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 9-2


Fallstudie: Leiner Health Products
Prozessintegration / MRP-System

• Reduzierung von Lagerbeständen um 50 Mio.


USD
• Pünktliche Lieferung in 95% aller Fälle

© Professur für Information Systems Engineering, Prof. Dr. Holten 9-3


Beispiele Enterprise Systems

• Beispiel Lucent Microelectronics


• Reduzierung der Durchlaufzeit von Geschäftsprozessen
von 10-15 Tagen auf weniger als 8 Stunden
• Reduzierung der Logistikkosten von 1,5% auf 1% der
Einnahmen

• Beispiel Colgate Palmolive


• Halbierung der Zeit zwischen Auftragseingang und
Auslieferung
• Anstieg der rechtzeitigen Auslieferungen von 91,5% auf
97,5%
• Reduzierung der internen Lagerhaltung um 30%

© Professur für Information Systems Engineering, Prof. Dr. Holten 9-4


Fallstudie: J.C. Penney

Beteiligte Partner
J.C. Penney Kaufhaus (Roseville) TAL Apparel Ltd. (Hongkong)
Nordamerikanische Kaufhauskette Weltgrößter Hersteller von Oberhemden
Eigene Hemdenmarke "Penney" Calvin Klein, Tommy Hilfiger, Ralph Lauren ...

Hemden-Produzent (Taiwan)
Teil der TAL Group

Quelle: Laudon, Laudon, Schoder (2006), S. 25 f.


© Professur für Information Systems Engineering, Prof. Dr. Holten 9-5
Fallstudie: J.C. Penney
6
Pakete

5
J.C.P.
Lager- Warenbestand
häuser Produktions- & Versand-
Versandstatus mitteilung
J.C. Penney 7 Hemden-
Kaufhäuser TAL Apparel Ltd. produzent
Verkaufsprognose- Zuweisung Art.-Nr.
Kassen- system, Logistik- & & Barcode
system 2 Prod.plan.-System 4
3
1 Verkaufs- Anzahl Hemden
datensatz Größen
Schnitte
1 Hemd Farben
weiß
bügelfrei
Marke "Penney" Dauer bis zur Auslieferung: 1 Tag Produktion
Kragenweite 16
Ärmellänge 32/33 Erhöhung der Liefergenauigkeit auf 100%
Kunde
Verkaufsprognosesystem
Anweisung
Erfassung des erfasst Verkaufsdaten
an Hemdenproduzenten
Verkaufsdatensatzes in Taiwan,
direkt aus
die
bei den Nordamerika
Mengen in & legt idealen
zu produzieren,
Kaufhäusern Nordamerika
4
3
7
2
6
1
5
Abruf
Vorab von
Versand
welche
 Warenbestand,
Übermittlung
Warenbestand
Käufer kauft
der
von 1 fest
Pakete
einzelnen
Automatische von
weißes,
direkt Produktions-
Logistik-
Übermittlung anund
bügelfreies
an Kaufhäuser
Kaufhäusern das & der
VersandmitteilungenVersandstatus
an J. C.
(Umgehung
benötigt werden; von
Penney
Produktionsplanungssystem
Hemd Marke „Penney“,
der J.über
C.von
Inhalt
Kragenweite
Lagerhäuser)
Zuweisung
Verkaufsprognosesystem von und
bestimmt
16, &
Artikel-Nr.
TAL
Penney
Barcode
Apparel direkt
Bestimmungsort
Ärmellänge
Ltd.
 bei
32/33
Produktionsplan
in TAL
der
(Anzahl
Rückmeldungen
HongkongApparel
 Pakete
Erfassung Ltd.
imStatus
Kassensystem
zu produzierender
über Hemden,
an TAL ApparelGrößen,
Ltd. Schnitte und Farben)
© Professur für Information Systems Engineering, Prof. Dr. Holten 9-6
Fallstudie: J.C. Penney

Informations- und Warenfluss


1 Käufer kauft 1 weißes, bügelfreies Hemd der Marke „Penney“, Kragenweite 16,
Ärmellänge 32/33  Erfassung im Kassensystem
Erfassung des Verkaufsdatensatzes direkt bei den Kaufhäusern in Nordamerika
2  Automatische Übermittlung an das Verkaufsprognosesystem von TAL
Apparel Ltd. in Hongkong
Verkaufsprognosesystem erfasst Verkaufsdaten aus Nordamerika & legt idealen
3 Warenbestand fest  Logistik- und Produktionsplanungssystem bestimmt
Produktionsplan (Anzahl zu produzierender Hemden, Größen, Schnitte und Farben)
Anweisung an Hemdenproduzenten in Taiwan, die Mengen zu produzieren,
4 welche von einzelnen Kaufhäusern benötigt werden; Zuweisung von Artikel-Nr. &
Barcode  Rückmeldungen über Status an TAL Apparel Ltd.

5
Vorab Übermittlung von Versandmitteilungen an J. C. Penney über Inhalt und
Bestimmungsort der Pakete

6 Versand der Pakete direkt an Kaufhäuser (Umgehung der Lagerhäuser)

7 Abruf von Warenbestand, Produktions- & Versandstatus von J. C.


Penney direkt bei TAL Apparel Ltd.
© Professur für Information Systems Engineering, Prof. Dr. Holten 9-7
Fallstudie: J.C. Penney

Vorteile für J.C. Penney


• Reduktion der Warenbestände
• Vorher: Lagerhäuser für 6 Monate, Kaufhäuser für 3 Monate
• Heute: Lagerbestand nahezu Null  Reduktion Lager-
haltungskosten & Reduktion der nicht verkauften Artikel
• Verbesserung der Verkaufsprognosen
• Vorher: Veraltetes System  häufig zu hoch eingeschätzt
• Heute: falls schnellerer Abverkauf als prognostiziert  TAL sendet
erforderlichen Nachschub per Luftfracht
• Reduktion der Kosten für Bestellbearbeitung
• Eigene Lagerarbeiter: 29 Cent pro Hemd
• TAL: 14 Cent pro Hemd + Auffüllung des Bestandes
• Reduktion der Time-to-market
• Neue Hemdenmodelle innerhalb von 4 Monaten getestet und auf
dem Markt

© Professur für Information Systems Engineering, Prof. Dr. Holten 9-8


Fallstudie: J.C. Penney

Vorteile für TAL Apparel Ltd.


• Preiswerte asiatische Fertigungsbetriebe  TAL bewältigt
Logistik- und Produktionsaufgaben besser und zu niedrigeren Kosten
als Kunden (Spezialisierung)
• Leistungsfähiges Informationssystem  Koordination der
Niederlassungen und Fabriken in Hongkong, Taiwan, Thailand,
Malaysia, Indonesien, China & Mexiko mit Hilfe eines auf
Internettechnik basierenden Netzwerks
• Weltgrößter Hersteller mit vielen Kunden  Skaleneffekte

Unternehmen verwandeln sich in vernetzte Firmen


 Austausch von Daten per Internet & Netzwerk-
technik

© Professur für Information Systems Engineering, Prof. Dr. Holten 9-9


Process Flow Measures
Average Flow Rate
Process Boundaries

R
R = Average Flow Rate [unit / time]
= Throughput

• The average flow rate, or throughput, R is the average


number of flow units that flow through (into and out of) the
process per unit of time
Managing Business Process
Flows
Ravi Anupindi et al., Pearson (2006 or later)

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 10


Process Flow Measures
Average Inventory
Process Boundaries

I = Average Inventory [unit]

• The average inventory is the total number of flow units


present within process boundaries

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 11


Process Flow Measures
Average Flow Time
Process Boundaries

T
T = Average Flow Time [time]

• The average flow time is the average (of the flow times)
across all flow units that exit the process during a specific span
of time

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 12


Process Flow Measures
Little's law
Process Boundaries

I
Average Inventory I=RxT
R
Average
Flow Rate
T
Average
Flow Time
Average Average
Average Inventory = X
Flow Rate Flow Time

For a given level of throughput in any process,


the only way to reduce flow time is to reduce
Rep Little’s Law inventory and vice versa
© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 13
Increase of Inventory Turns

© Hopp, Spearman: Factory Physics (2008), p. 184


MRP JIT
“crusade” movement
© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 14
Measuring Flow Time

Direct Approach:

• During a given month, a sample of 50 applications was


taken in the branch in Bockenheim

• The average flow time was determined to be (estimate


using the direct approach):

T = 20.85 working days

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 15


Measuring Flow Time

Indirect Approach:
• During the considered month 200 applications were
processed
• Working days during that month = 20

200  applications   applications 


R  10  
20 days   day 
• The number of applications in process was counted four
times during the month and I = 215
• Little´s Law:

I 215  applications 
T    21.5 days 
R  applications 
10  
 day 
© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 16
Theoretical Flow Time

• The theoretical flow time of a process is the minimum


amount of time required for processing a typical flow unit
without any waiting

• It includes only the activity-time component of the process,


ignoring completely the impact of waiting

• Theoretical flow time represents an idealized target for an


actual flow time that can only rarely be achieved in practice

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 17


Activity Time and Theoretical Flow Time

• Activity time is the time required by a typical flow unit to


complete the activity once

• activity time [time]

• The activity times of a flow unit at various activities, coupled


with the sequence in the various activities performed during a
process, allows us to compute theoretical flow time

• Example:
• A process consist of three activities A, B, and C, that must
be performed sequentially

• Each activity requires 10 minutes activity time

• Theoretical Flow Time = 10 + 10 + 10 = 30 minutes


© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 18
Example: Wonder Shed Inc.

• Wonder Shed Inc. manufactures mobile storage sheds

• The manufacturing process involves the procurement of sheets


of steel that will be used to form both the roof and the base of
each shed

Process Flowchart of a single storage shed:

3 5
Inputs Start 1 7 8 End Outputs

2 4 6
Process

Quelle: Vgl. Anupindi, R. et al. (2006), S. 77


© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 19
Example: Wonder Shed Inc.

Activity Time
Activity
(minutes)
1 Separate 10
2 Punch the base 25
3 Punch the roof 20
4 Form the base 5
5 Form the roof 10
6 Subassemble the base 10
7 Assemble 10
8 Inspect 30

• Two paths connecting the beginning and end of the process:

Quelle: Vgl. Anupindi, R. et al. (2006), S. 81


© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 20
Critical Path Method

• Most processes consist of a combination of sequential and parallel


activities

• This results in a process chart that contains several paths running


from process start to finish

• For each path, theoretical flow time of that path is the sum of the
activity times of the activities that constitute the path

• The path exhibiting the highest theoretical flow time in the


process flowchart is called critical path

• A flow unit can exit the process only after all the activities along all
the paths are completed

• Theoretical flow time of the process must be the same as the


theoretical flow time of the critical path

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 22


Critical Path Method

• The critical activities of a process are extremely important for


managing flow time since they determine the flow time of the
entire process

• A delay in completing any critical activity results directly in a


corresponding delay in processing the flow unit and thus a
delay of the entire process

• Activities that are not critical can be delayed, to a degree,


without affecting the flow time of the process

• Uncritical activities require a reduced level of monitoring by


management

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 23


Example: Wonder Shed Inc.

• Theoretical flow time path 1 (roof):

________________________ minutes

• Theoretical flow time path 2 (base):

___________________________ minutes

 The theoretical flow time of the process is __ minutes

 Path ________________ is the critical path

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 24


Was sind “Flow Units”?
Alle Modelle
Ein Motorrad? Welches Modell? des VW-Konzerns?

Eine Bank-Transaktion?
Ein “Deal”?

Ein Bachelor-Abschluss?
Welcher?

Hängt vom Zweck der Prozessanalyse ab


Detaillierungsniveau!
© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 26
Defining the Flow Unit

• The right choice when defining the flow unit depends on the
nature and purpose of the analysis

• A product manager who is concerned with the performance of


one special product defines the process flow as consisting of
the relevant product only

• From the perspective of the entire company we must broaden


our definition of flow unit to encompass the entire product mix
• Homogeneous flow units are weighted equally
• Heterogeneous flow units (size, cost, price, profitability) are
weighted according to the emphasis we place on certain
attributes

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 27


Defining the Flow Unit

• Golden Touch Securities is charged with releasing research


reports for the benefit of Golden's customers and brokers

• Two types of research reports:

• Major reports  Production takes 10 working days

• Minor reports  Production takes 6 working days

• In a typical month, 20 major und 40 minor reports are


released on average

• T=?

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 28


Defining the Flow Unit

Equal weightage:

• Each report is counted as equal and single flow unit

R=

T=

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 29


Defining the Flow Unit

Variable weightage:

• A manager at Golden Touch decides to treat each minor report


as the equivalent of one-half of a major report

R=

T=

© Professur für Information Systems Engineering, Prof. Dr. Holten 9 - 31


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 10 – Determinanten von


Durchlaufzeiten

Sie lernen in diesem Kapitel,

 wie Rework (Wiederholung) aufgrund von Qualitätsproblemen als


Komponente der Durchlaufzeiten modelliert wird
 das Just-in-Time Konzept kennen
 wie mittels Puffern (Buffers) Wartezeiten modelliert werden
 dass Wartezeiten einen großen Teil der Durchlaufzeiten ausmachen
 was Flow Time Efficiency ist
 welche generellen Möglichkeiten zur Verkürzung der Durchlaufzeiten
unterschieden werden

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

10 Determinanten von
Durchlaufzeiten
Anupindi, R. et al.: Managing Business Process Flows (2006)
(Chapters 3 and 4)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 2


Fallstudie: Lightnin
Rework

• Lightnin — Tochterunternehmen der SPX Corporation


• Produktion von Industriemixern und Rührern
• 60-70 Mitarbeiter im Vertrieb
• 100 Mitarbeiter in Produktion und Kundendienst
• Geräte werden individuell konfiguriert
• Bisher: Sehr ineffizientes Bestellsystem

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 3


Fallstudie: Lightnin
Rework

Vorher Nachher
• Dauer einer Bestellung: ca. 3-29 Tage • Reduktion der Bestelldauer um 50-80%
• 920.000 USD für IT-Mitarbeiter und • 440.000 USD für IT-Mitarbeiter und
Datentypisten Datentypisten
• 8 Mio. USD für fehlerhafte Bestellungen • 24.000 USD für Online
• Kosten insgesamt: 8,92 Mio. USD Bestellannahmeservice
• 62.500 USD für Softwarelizenzen
• Kosten insgesamt: 526.500 USD

© Professur für Information Systems Engineering, Prof. Dr. Holten Quelle: Laudon, Laudon, Schoder (2006), S. 190 10 - 4
Fallstudie: Lightnin
Rework

Bisheriges System Neues System


1. Erfassung der Kundenanfrage per 1. Kundenanfrage trifft ein
Hand 2. Mitarbeiter konfigurieren Mixer
2. Erstellung von Entwürfen und über Web-Schnittstelle
Preisangebot anhand bestehender 3. Automatische Erstellung von
Kataloge Stücklisten und CAD-Zeichnungen
3. Versand der Dokumente per Post 4. Bestätigung durch Kunden
oder FAX 5. Übertragung in ERP-System
4. Aushandlung des Preises 6. Manuelle Eingriffe in den Ablauf
5. Aufnahme der endgültigen aufgrund von Spezialaufträgen
Bestellung durch jederzeit möglich
Vertriebsmitarbeiter
6. Kontrolle durch Bestellannahme
7. Eingabe in Computersystem
8. Produktion

Ineffizient, teuer und fehleranfällig

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 5


Rework, Visits, and Work Content

• Rework may require that activities be repeated several times before


a unit is completed
 We refer to this repetitions as visits to an activity
 The number of visits measures the frequency of rework

• The work content of an activity is activity time multiplied by


average number of visits at that activity

• work content [time] = activity time [time] * visits

• Work content measures the total amount of time required to perform


an activity during the transformation of a flow unit

• Using the work content – rather than the activity time – in the
computations of the critical path gives us a more accurate estimate of
the theoretical flow time of a process

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 6


Example: Wonder Shed Inc.

• Activity times and work content at Wonder Shed Inc.:

Activity
time Work content
Activity Number of visits
(minutes)
(minutes)
1 Separate 10 1 10
2 Punch the base 25 1.2 30
3 Punch the roof 20 1.1 22
4 Form the base 5 1.2 6
5 Form the roof 10 1.2 12
6 Subassemble the base 10 1.3 13
7 Assemble 10 1 10
8 Inspect 30 1.2 36

• Path 1 (roof): Start  1  3  5  7  8  End

• Path 2 (base): Start  1  2  4  6  7  8  End

Quelle: Vgl. Anupindi, R. et al. (2006), S. 85


© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 7
Example: Wonder Shed Inc.

• Using the work content, theoretical flow time of path 1 (roof) is

___________________ = 90 minutes

• Using the work content, theoretical flow time of path 2 (base) is

_______________________ = 105 minutes

• Theoretical flow time path 1 without rework = 80 minutes

• Theoretical flow time path 2 without rework = 90 minutes

 Rework increases the theoretical flow time of the critical path


by _________

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 8


Fallstudie: Just-In-Time (JIT) und
Warenloses Lager

• US-Hospitale nutzen Baxters Web-Katalog


• System erzeugt Liefer-, Zahlungs-,
Rechnungs- und Lagerbestandsdaten &
voraussichtliches Lieferdatum
• 80 Distributionszentren in den USA 
Auslieferung innerhalb weniger Stunden
• Baxter liefert direkt in OP und interne
Lager
• Baxter fungiert als Lager  "warenloser
Lagerbestand" aus Sicht der
Krankenhäuser

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 10


Fallstudie: Just-In-Time (JIT) und
Warenloses Lager

“Buffers”

Quelle: Laudon, Laudon, Schoder (2006), S. 153


© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 11
Computing Flow Time

• As a flow unit travels through the process from entry to exit, it


typically undergoes a sequence of activities interspersed with periods
of waiting in buffers

Flow Time = Theoretical flow time + Waiting time

• Combining theoretical flow time with waiting time allows us the


appliance of the following procedure:

• We treat waiting in each buffer as an additional (passive) activity


with activity time equal to the amount of time in that buffer
• We add waiting times in buffers to the theoretical flow time of the
appropriate path
• We obtain the average flow time of the process by finding the
path whose overall length (activity time + waiting time) is longest

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 12


Example: Wonder Shed Inc.
Flow Chart

• Wonder Shed Inc. manufactures mobile storage sheds


• Process Flowchart of a single storage shed:

3 5
Inputs Start 1 7 8 End Outputs

2 4 6
Process

Activity Time
Activity
(minutes)
1 Separate 10
2 Punch the base 25
3 Punch the roof 20
4 Form the base 5
5 Form the roof 10
6 Subassemble the base 10
7 Assemble 10
8 Inspect 30

Quelle: Vgl. Anupindi, R. et al. (2006), S. 77


© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 13
Example: Wonder Shed Inc.

• Assumption: R = 16.5 sheds/hour

• Average inventories of roofs and bases in waiting buffers:

Average Number Average Number


Buffer
of Bases of Roofs
2 30 -
3 - 25
4 10 -
5 - 20
6 20 -
7 10 15
8 20 20
Total 90 80

Quelle: Vgl. Anupindi, R. et al. (2006), S. 83


© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 14
Example: Wonder Shed Inc.

• Average number of roofs waiting in various buffers Iw= 80

• Average amount of waiting time Tw for a typical roof is 291


minutes:

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 15


Example: Wonder Shed Inc.

Flow Time = Theoretical flow time + Waiting time

T = T t + Tw

= 80 [minutes] + 291 [minutes]

= 371 [minutes]

 The average flow time for a roof is 371 minutes

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 17


Example: Wonder Shed Inc.

• Average number of bases waiting in various buffers Iw = 90

• The average waiting time Tw for a base is 327 minutes:

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 18


Example: Wonder Shed Inc.

Flow Time = Theoretical flow time + Waiting time

T = Tt + Tw

= 90 [minutes] + 327 [minutes]

= 417 [minutes]

 We obtain an average flow time of 417 minutes for the bases

 Because 417 > 371 minutes, the path traversed by a base


remains the critical path!

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 20


Example: Unfallklinik Frankfurt
Rework & Waiting

• Unfallklinik Frankfurt would like to reduce waiting time for


patients during the X-ray service

• Start of process: a patient leaves the physician's office

• End of process: Both the patient and the completed X-ray


film are ready to enter the physician's office
for diagnosis

• T = average flow time = 154 [minutes]


(random sample of 50 patients was observed over a two-week period)

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 21


Example: Unfallklinik Frankfurt
Rework & Waiting

Activity Description
Start Patient leaves the physician‘s office.
1 Patient walks to the X-ray lab.
2 The X-ray request travels to the X-ray lab by a messenger.
3 An X-ray technician fills out a standard form based on the information supplied by the
physician.
4 The receptionist receives from the patient information concerning insurance, prepares
and signs a claim form, and sends it to the insurer.
5 Patient undresses in preparation for X-ray.
6 A lab technician takes X-rays.
7 A darkroom technician develops X-rays.
8 The lab technician checks X-rays for clarity. If an X-ray is not satisfactory, activities 6
to 8 are repeated. (On average 80% of X-rays are found satisfactory the first time
around, while 20% require a retake)
9 Patient puts on clothes a gets ready to leave lab.
10 Patient walks back to the physician‘s office.
11 The X-rays are transferred to the physician by a messenger.
End Patient and the X-rays arrive at the physician‘s office.

Quelle: Vgl. Anupindi, R. et al. (2006), S. 87


© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 22
Example: Unfallklinik Frankfurt
Rework & Waiting

• Flowchart for the X-Ray-Service process at Unfallklinik


Frankfurt

1 9 10
80%
Start 4 5 6 7 8 End

20%
2 3 11

Quelle: Vgl. Anupindi, R. et al. (2006), S. 87

• Four activity paths through the process:


Path 1: Start  1  4  5  6  7  8  9  10 End
Path 2: Start  2  3  4  5 6  7  8  9  10 End
Path 3: Start  1  4  5 6  7  8  11 End
Path 4: Start  2  3  4  5 6  7  8  11 End

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 23


Example: Unfallklinik Frankfurt
Rework & Waiting

Activity Time Number of Visits Work Content per


Activity
(minutes) Per Flow Unit Flow Unit (minutes)
Start - 1 -
1 7 1 7
2 20 1 20
3 6 1 6
4 5 1 5
5 3 1 3
6 6 1.25 7.5
7 12 1.25 15
8 2 1.25 2.5
9 3 1 3
10 7 1 7
11 20 1 20
End - 1 -

Quelle: Vgl. Anupindi, R. et al. (2006), S. 88


© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 24
Example: Unfallklinik Frankfurt
Rework & Waiting

• Theoretical flow time based on work content:

• Path 1 : ________________________________________

• Path 2: _________

• Path 3: _________

• Path 4: _________

 _____ is the critical path

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 25


Example: Unfallklinik Frankfurt
Rework & Waiting

Theoretical flow time


Flow-time efficiency =
Average flow time

Flow-time efficiency =

 Waiting time corresponds to ________________________


_________________________

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 27


Levers for Managing Theoretical Flow
Time

• The theoretical flow time is determined by the total work


content of its critical path

• The only way to reduce the theoretical flow time is to shorten


the length of the critical path

• There are three basic approaches:

1. Eliminate: Reduce the work content of a critical activity

2. Work in parallel: Move some work content off the critical


path to activities inside an uncritical path

3. Select: Modify the product mix

© Professur für Information Systems Engineering, Prof. Dr. Holten 10 - 29


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 11 – Management von Kapazitäten


und Engpässen

Sie lernen in diesem Kapitel,

 was Ressourcen und Unit Loads sind


 wie der Durchsatz (Flow Rate / Throughput) bestimmt werden kann
 wie die theoretische Kapazität bestimmt wird
 wie Kapazitäten genutzt werden, um Dienstleistungsprozesse zu steuern
 wie die Engpässe (Bottlenecks), die den Durchsatz (Throughput) des
gesamten Systems limitieren, identifiziert werden
 welche Möglichkleiten es gibt, Bottlenecks zu beseitigen und die
Kapazität des Gesamtsystems zu erhöhen
 was das Ziel von Geschäftsprozessen ist
 was mit Improvement Spiral gemeint ist

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

11 Management von Kapazitäten


und Engpässen
Anupindi, R. et al.: Managing Business Process Flows (2006)
(Chapter 5)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 2


Fallstudie: Digitalisierung
e-Tickets der Bahn (1/6)
Ziele der Einführung von e-Tickets:
• Anpassung der Dienstleistungen auf gesteigerte Internetnutzung
• Senkung der Prozesskosten beim Buchungsprozess
• Verbesserung der Distributionspolitik durch flexible
Buchungsmöglichkeiten
• Buchung bis 10 Minuten vor der Abfahrt
• Rund um die Uhr
• Von jedem beliebigem Computer oder von mobilen Geräten aus

Herausforderungen:
• Kundenfreundlicher Ablauf:
• leichte Bedienbarkeit,
• unkomplizierte Abwicklung
• Unterbindung von Betrug:
• durch illegale Kopien,
• durch Ticketfälschung
• Funktionalität in Bezug auf den Einsatzbereich

Quellen: DB Vertrieb GmbH, Oliver Krülle (24.01.2008); Krülle, Swatman: e-Ticketing Strategy and
Implementation in an Open Access System. The case of Deutsche Bahn (2006);
Kriha, Roland: Internet Security aus Software-Sicht (2008)
© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 3
Fallstudie: Digitalisierung
e-Tickets der Bahn (2/6)

Besonderheiten bei Bahntickets: Offenes Zugangssystem


• Flexibilität in der Nutzung von Verbindungen und Pausen zwischen den Reisen
• Kein Check-In
• Keine Bindung der Passagieranzahl an Sitze
• Keine Passagierlisten pro Zug
• Stornierung möglich

Bedingungen für ein neues Ticket-System


• Kontrollierende Instanzen in den Zügen sind offline
• Machbarkeit eines Barcodeverfahrens im Homeprint-Bereich
• Schnelle Lesbarkeit und hohe Fehlerkorrektur im Zug
• Einhaltung der Sicherheits- und Datenschutzanforderungen und Richtlinien des Konzerns

e-Ticket
• Ticket kann über einen Computer bzw. über ein mobiles Endgerät erworben werden
• Bahn erstellt eine sichere Signatur durch Nutzung eines geheimen Schlüssels
(Private-Key)
• Überprüfung im Zug über Mobile Terminals (MT) mittels Public-Key der Bahn

Voraussetzungen:
• Anmeldung auf Bahn.de
• Personenbezogene, nicht übertragbare Tickets

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 4


Fallstudie: Digitalisierung
e-Tickets der Bahn (3/6)
Abwicklungsprozess

Beim Online-Kauf über PC bzw. über ein mobiles Gerät:


• Kunden-, Zahlungs-, Karten- und Ticketdaten werden an die Deutsche Bahn (DB)
übermittelt
• e-Ticket wird erstellt und beinhaltet eine fälschungssichere digitale Signatur der DB
• Kunde erhält das e-Ticket auf dem mobilen Gerät bzw. druckt das auf dem PC erhaltene
e-Ticket aus

Im Zug:
• 2D-Barcode des e-Tickets wird im MT eingescannt
• Digitale Signatur der DB wird mithilfe des Public Keys überprüft  Echtheitsprüfung
• Karte des Kunden wird gelesen
• Ergebnis der Überprüfung wird im MT gespeichert

Nach der Kontrolle:


• Bei der Abrechnung (z.B. bei Schichtende) findet ein Datenabgleich mit der zentralen
Datenbank statt, um eine Wiederverwendung des e-Tickets zu vermeiden
• Eine unzulässige Wiederverwendung wird dem Kunden in Rechnung gestellt
Aufträge

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 5


Fallstudie: Digitalisierung
e-Tickets der Bahn (4/6)
Buchung Online
Online-Anfrage
Identifikation des Portals durch SSL
Übermittlung von Kunden- & Buchungsdaten

bahn.de
Erstellung des e-Tickets
Kunde

Buchungsdaten

Ticket

Erstellung einer fälschungssicheren


Signatur mithilfe des DB
Private Key: Datenbank
Private Keys der Bahn
Bahn
(geheimer Schlüssel)

Aufträge

Quelle: Angelehnt an DB Vertrieb GmbH, Oliver Krülle (24.01.2008)


© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 6
Fallstudie: Digitalisierung
e-Tickets der Bahn (5/6)
Im Zug

Buchungsdaten

Deutsche Bahn
Kunde

MT

Überprüfung der Signatur mithilfe


Public Key: des Public Keys der Bahn DB
Bahn  Prüfung der Echtheit
Datenbank

Kontroll-
Aufträge
daten MT
Bahn

Quelle: Angelehnt an DB Vertrieb GmbH, Oliver Krülle (24.01.2008)


© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 7
Fallstudie: Digitalisierung
e-Tickets der Bahn (6/6)

Kundenportal Bahn.de: Einführung des e-Tickets (2001) als


Grundlegend für den Erfolg von bahn.de

Entwicklung der Online- Hohe Besucher- und Nutzungszahlen


Einnahmen 2002-2007  5,5 Mio Besucher pro Monat
in Mio. EUR 757  2,5 Mio Reiseauskünfte pro Tag
 40.000 Online-Tickets pro Tag
583
Großes Privat- und Firmenkundenportal
440  4,2 Mio registrierte Privatkunden
 85 Großkunden
260
 24000 Klein- und Mittelstandskunden

120
40

2002 2003 2004 2005 2006 2007

Quelle: DB Vertrieb GmbH, Oliver Krülle (24.01.2008)


© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 8
Unit Loads

• Since activities are performed by resources, we define the unit


load of a resource unit as the total amount of time the
resource works to process each flow unit

• A unit load is the sum of the work contents of all activities


that utilize that resource unit

• Tp [time] = unit load of a resource unit in resource pool p

Managing Business Process


Flows
Ravi Anupindi et al., Pearson (2006 or later)

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 9


Example: NewLife Finance (1)

• Health Maintenance Organizations (HMO) provide their


customers with all-inclusive medical service for a fixed monthly
fee

• To secure services, HMOs contract with physicians and


hospitals that provide their services on a fee-per-services basis

• When members of an HMO receive medical service, the


providing physician or hospital submits a claim to the HMO for
reimbursement

• NewLife Finance is a service provider to HMOs

• For a small fee, it performs the entire claims processing


operation on behalf of the HMO

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 10


Example: NewLife Finance (2)

• Processing a physician claim consists of the following operations:

1. Arriving claims are opened by NewLife's mailroom clerk and are


date-stamped
2. Data entry clerks enter date-stamped applications – first in, first
out - into NewLife's claims processing system. Claims are
checked for proper formatting and completeness. If a claim is not
legible, fully completed, or properly formatted, it must be sent
back to the physician. Once entered, claims are stored in a
processing inventory called “suspended claims”
3. Claims are assigned to a claim processor for initial processing
4. Processed claims are transferred by the system to a claim
supervisor for inspection and possible alterations
5. Claims are returned to their original claim processors who
complete the transaction and issue instructions to account
payable for settlement

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 11


Example: NewLife Finance (3)

• Activity Work Contents at NewLife Finance:

Table 5.1, Anupindi, R. et al. (2006), p. 103


Work Content per claim
Activity Resource
(minutes)
Mailroom Mailroom clerk 0.6
Data entry Data-entry clerk 4.2
Initial processing Claims processor 4.8
Inspection Claims supervisor 2.2
Final processing Claims processor 1.8

• Unit load of the claims processor:

Tp = 4.8 + 1.8 = 6.6 [minutes]

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 12


Example: NewLife Finance (4)

• Resource Unit Loads at NewLife Finance

Table 5.2, Anupindi, R. et al. (2006), p. 104


Unit Loads (Tp) per
Resource-Pool p
claim (minutes)
Mailroom clerk 0.6
Data-entry clerk 4.2
Claims processor 6.6
Claims supervisor 2.2

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 13


Flow Rate Measurement

• The average flow rate (throughput) R of a process can be


determined by the following three-step procedure:

1. Observe the process over a given, extended period of time

2. Measure the number of flow units that are processed by


the process over the selected period of time

3. Compute the average number of flow units per unit of time

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 14


Theoretical Capacity

• The theoretical capacity of a resource unit is its


maximum sustainable flow rate if it were fully utilized

• The theoretical capacity of a resource pool is the sum of


the theoretical capacities of all the resource units in that pool

• No process can produce output any faster than its bottleneck


– the resource pool of a process with the lowest theoretical
capacity

Therefore, we define the theoretical capacity of


a process as the theoretical capacity of the
theoretical bottleneck

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 15


Theoretical Capacity

• Load batch: Number of flow units that a resource can process


simultaneously
• load batch [unit]

• Given unit load Tp [time] and load batch LB [unit], the


theoretical capacity of a resource unit (in resource pool p) is
calculated as follows:

 unit 
Theorectical Capacity of ressource unit   =
 time 
1
 LB unit 
Tp time 

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 16


Theoretical Capacity

• If all resource units of the resource pool are identical, then the
theoretical capacity of a resource pool p (Rp) is given by
the number of resources in resource pool p (cp) times the
theoretical capacity of a resource unit in pool p
• Load batch per resource LB [unit], unit load Tp [time], cp

 unit 
Theoretical capacity of resource pool R p  time  =
 
1
cp   LB unit 
Tp  time 

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 17


Example: NewLife Finance (5)

• Load batch is 1 [unit]

Table 5.3, Anupindi, R. et al. (2006), p. 105


Theoretical Capacity Theoretical Capacity
Unit Load (Tp ) per Number of Units in
of a Resource Unit of a Resource Pool
Resource Pool p claim (minutes) the Resource Pool
(1/Tp) (claims per (claims per minute)
(Table 5.2) (cp)
minute) (Rp=cp/Tp )

Mailroom clerk 0.6 1


Data-entry clerk 4.2 8
Claims processor 6.6 12
Claims supervisor 2.2 5

• The theoretical bottleneck is

• The theoretical capacity of the process is

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 18


Theoretical Capacity

• Scheduled availability: Amount of time that a resource is


scheduled for operation
• Scheduled availability (SAV) [time1/time]

 unit 
Theorectical Capacity of ressource unit   =
 time 
1  time1 
 LB unit   SAV  
Tp time1  time 

 unit 
Theoretical capacity of resource pool R p  time  =
 
1  time1 
cp   LB unit   SAV  
Tp time1  time 

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 20


Example: Theoretical Capacity

• cp = number of resource units = 2 ovens


• Tp = unit load = 15 [minutes]
• load batch = 10 [loaves/oven]
• scheduled availability = 450 [minutes/day]

• Using the formula above we estimate the theoretical


capacity of the resource pool to be:

Rp=

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 21


Example: NewLife Finance

• Scheduled availability: Impact on theoretical capacity


• Load batch is 1 [unit]

Table 5.4, Anupindi, R. et al. (2006), p. 107


Scheduled Unit Load Number of
Theoretical Capacity of Theoretical Capacity
availability per claim Units in
Resource a Resource Unit: SAV * of a Resource Pool
[minutes/day] [minutes] Resource
(1/Tp) * LB (claims per day)
SAV Tp Pool

Mailroom clerk 450 0.6 1

Data-entry
clerk
450 4.2 8
Claims
processor
360 6.6 12

Claims
supervisor
240 2.2 5

The theoretical capacity of the process is 545 claims per day!


Why?

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 23


Throughput and Capacity Utilization

• The capacity utilization of a resource pool p measures the


degree to which resources are effectively utilized by a process

Throughput
p 
theoretical capacity of resource pool p
R
p 
Rp

• The capacity utilization of the process is defined as the


capacity utilization of the bottleneck resource pool

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 25


Example: NewLife Finance (6)

• Assumption: R = 480 claims/day

Table 5.5, Anupindi, R. et al. (2006), p. 108


Theoretical
Capacity of a Capacity
Resource Pool p Resource Pool Rp Utilization p
(claims per day)
Mailroom clerk 750
Data-entry clerk 857
Claims processor 655
Claims supervisor 545

• The theoretical capacity of the process is 545 claims per day!


Why?
• The capacity utilization of the entire process is 88%!
Why?
© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 26
Improving Processes

• To improve theoretical capacity we must increase the


theoretical capacity of each theoretical bottleneck

• Why is this meaningful?

• Because it is consistent with THE GOAL of the company!

• What is the goal?

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 28


What is the Goal of a Company?

• Since Aristotle (d. 322 BC) metaphysics involved four “causes”


(Hopp, Spearman 2008, p. 201)

• Material cause: the material from which an object or


system is made
• Efficient cause: the thing that made the object or system
• Formal cause: the pattern or essence of the system or
object
• The final cause is the end or purpose for which the object
or system is made

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 29


The Goal: Making Money

• The company exists to make money


(Goldratt, Cox 1984, p. 40)

• The goal of a manufacturing organization is to make money


and everything else is a means to achieve the goal
(Goldratt, Cox 1984, p. 59)

• The final cause of a manufacturing system is to make money


now and in the future in ways that are consistent with our core
values
(Hopp, Spearman 2008, p. 201, 206)

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 30


Levers for Managing Throughput

• Since the theoretical capacity of the resource pool is the sum of the
theoretical capacities of each resource in the pool, increasing the
theoretical capacity of a resource pool requires at least one of the
following actions:

• Decrease unit load on the bottleneck resource pool


 work faster and smarter
• Increase the number of resource units in the bottleneck resource
pool
 increase scale of process
• Increase the scheduled availability of the bottleneck resource
pool
 work longer
• Reducing the time wasted by setups
• Reducing resource idleness

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 31


The Improvement Spiral

• Increase throughput of a process by identifying its bottleneck


and increasing its capacity

• Once the capacity of the bottleneck is increased it is replaced


by some other resource whose capacity is now the lowest
 new Bottleneck

• This leads to the spiral of throughput improvement:

1. Identify the process bottleneck


2. Increase the capacity of this bottleneck until it is no longer a
bottleneck
3. Identify the new bottleneck and repeat step 2

© Professur für Information Systems Engineering, Prof. Dr. Holten 11 - 32


WIRTSCHAFTSWISSENSCHAFT
EN
Professur für Information Systems
Engineering

Prof. Dr. Roland Holten


www.ise.wiwi.uni-frankfurt.de

Lernziele Kapitel 12 – E-Commerce und


Soziotechnische Systeme

Sie lernen in diesem Kapitel,

 den Begriff Supply Chain Management (SCM) und Beispiele für E-


Commerce kennen
 grundlegende Organisationseinheiten in SAP kennen
 was mit vertikaler Daten- und Prozessintegration gemeint ist
 was ein Data Warehouse ist
 die Abgrenzung von Informationssystem und Anwendungssystem sowie
den Begriff Soziotechnisches System kennen
 wichtige Theorien aus dem Bereich Information Systems kennen

Campus Westend  Theodor-W.-Adorno-Platz 2, RuW-Gebäude, R. 2.219  D-60629 Frankfurt am Main


Information Systems Engineering
Prof. Dr. Roland Holten

12 E-Commerce und
Soziotechnische Systeme

Laudon, Laudon, Schoder (2010):


Anwendungssysteme (Kapitel 7,9 und 10)
Gliederung der Vorlesung
Themenblöcke und Kapitel

I. Betriebliche Aufgaben und Prozesse


1. Betriebliche Aufgaben und Anwendungssysteme
2. Das klassische Bestellmodell
3. Algorithmen, Struktogramme und Programme
4. Koordination Betrieblicher Aufgaben und MRP II-Systeme
5. Modellierung Betrieblicher Prozesse mit BPMN

II. IT-Einsatz zur Integration Betrieblicher Prozesse


6. Datenintegration und Relationale Datenbanken
7. Datenmodellierung mit dem Entity-Relationship-Modell
8. Prozessintegration – Enterprise Systems & SAP

III. Verbesserung Betrieblicher Prozesse


9. Prozessqualität und ihre Messung
10. Determinanten von Durchlaufzeiten
11. Management von Kapazitäten und Engpässen
12. E-Commerce und Sozio-Technische Systeme

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 2


Sich erweiternder Einflussbereich von IS

• ~1950: Technische Veränderungen


• ~1960-70: Steuerungsmöglichkeiten
• ~1980-90: Kernaktivitäten des Unternehmens
• Heute: Digitale Informationsnetze (Internet)

Quelle: Laudon, Laudon, Schoder (2009), S. 32


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 3
Das vernetzte Unternehmen

Quelle: Laudon, Laudon, Schoder (2009), S. 37


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 4
Fallstudie: Google Wallet

• Bezahlsystem für Smartphones startet

Quelle: http://www.google.com/wallet/#overview
Tap, pay, and save with
Google Wallet.

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 5


Fallstudie: Google Wallet

Payments

Quelle: http://www.google.com/wallet/#overview
Look for these symbols at
checkout.

Tap your phone on the


reader.
Your phone sends payment,
and, at some merchants,
offers and loyalty
information.

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 6


Fallstudie: Google Wallet

Quelle: http://www.google.com/wallet/#overview
Offers & Loyalty

Your Google Offers


automatically sync to
your Google Wallet.

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 7


Informationsflüsse im E-Business

Quelle: Laudon, Laudon, Schoder (2006), S. 191


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 8
Neue Organisationen – vernetzte
Unternehmen

• Zunehmende Flexibilität
• Massenfertigung kundenindividueller Produkte
(mass customization)

• Beispiel Lands’ End:


Anfertigung maßgeschneiderter
Jeans

• Neudefinition von Unternehmensgrenzen


• Verbundene Geschäftspartner mit gemeinsamen
Verantwortlichkeiten
• Beispiel J. C. Penney & TAL Apparel Ltd.
© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 9
Disintermediation

• Definition
„Die Eliminierung von Organisationseinheiten oder
Geschäftsprozessschritten, die für bestimmte
Vermittlungstransaktionen in der Wertschöpfungskette
verantwortlich sind."

Quelle: Laudon, Laudon, Schoder (2006), S. 185


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 10
Supply Chain Management (SCM)

Legende:
Informationsfluss
Materialfluss

Quelle: Laudon, Laudon, Schoder (2006), S. 101


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 11
Beispiel: Logistikkette vor SCM
Einführung

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 12


Beispiel: Logistikkette mit SAP

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 13


Efficient Frontier

Inefficient
Fed Ex

© Hopp, Spearman 1996, 2000


Cost

Efficient Frontier

Infeasible
US Postal Service

Speed

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 14


Electronic Data Interchange

Quelle: Laudon, Laudon, Schoder (2006), S. 298


• Electronic Data Interchange (EDI) als Beispiel für
eine überbetriebliche Integration zweier
Anwendungssysteme.
• EDI ist ein standardisiertes Format für den Austausch
von betriebswirtschaftlichen Daten.

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 15


Fallstudie: Nibco

• NIBCO Inc.
• Gegründet 1904 in Elkhart, Indiana
• Führender Hersteller von Produkten zur
Flusskontrolle, bspw. Armaturen, Rohre oder Ventile
• Produkte für private und industrielle Bauprojekte
• Ca. 3000 Mitarbeiter
• Ca. 500 Mio. USD Einnahmen pro Jahr

Quelle: Fallstudie basiert auf Alter (2002), S.507f.


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 16
Fallstudie: Nibco

• Geschäftsprozesse basieren auf einer Vielzahl


unterschiedlicher und inkompatibler IT-Systeme
 Keine Kommunikation zwischen den
Anwendungen!

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 17


Fallstudie: Nibco

• Projekt-"Kickoff" am 30. September


• "Go-live"-Termin geplant am 29. November im Folgejahr
(zzgl. 30 Tage Puffer)
• Projekt umfasst 10 Fabriken und 4 Verteilungszentren
• Projektteam bestehend aus
• 3 Teams für Geschäftsprozesse (je 7-8 Personen)
• 1 Team für Change Management
• 1 Team für technische Aspekte

• Zusammenarbeit aller Teams in einem riesigen Büro


• Insgesamt über 150 Vollzeitmitarbeiter im Projekt
• Telefone wurden im Flur installiert, um die Arbeit nicht
zu stören

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 18


Fallstudie: Nibco

• Größte Herausforderung:
Entwicklung gemeinsamer Prozessabläufe und
Datenstrukturen für alle bislang unabhängige
Fabriken

• Es wurden keine neuen Mitarbeiter eingestellt  Nicht


am Projekt Beteiligte mussten die Arbeit der
Projektmitarbeiter übernehmen

• Folge: Geringere Produktivität, Lieferausfälle, finanzielle


Engpässe, schwächere Kundenbetreuung

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 19


Fallstudie: Nibco

• Gesamtkosten von ca. 18 Mio. USD inkl. Schulungen und


Beratungen
• Unternehmensweites, integriertes SAP-System
• Interaktive Webseiten mit Online-Shop  NIBCO.com
• NIBCOpartner.com  Kundenportal
• Möglichkeit, Bestellungen
per EDI entgegenzunehmen
• "Vendor-managed inventory"
für effizientere
Materialwirtschaft

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 20


Fallstudie: Nibco

Quelle: www.nibco.com (01.02.2011)


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 21
Fallstudie: Nibco

• Motivation der stark belasteten Mitarbeiter über ein extra


eingeführtes Bonus-System ( höhere Gehälter)

• Angestrebter "Go-live"-Termin nicht eingehalten.


Verzögerung um einen Monat bis 30. Dezember

• Danach: Längere Einarbeitungszeit, insb. in den


Bereichen FI, PP und SD. Einige Mitarbeiter äußerten den
Wunsch, zum alten System zurückzukehren.

• CEO: "SAP has been well-suited to our needs. We rolled


it out on Jan. 1st, but getting there nearly killed us."

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 22


Wichtige Begriffe in SAP

Organisationseinheiten in SAP
• SAP bildet Unternehmen beliebiger Art und Größe ab
• Abbildung im System erfolgt mit Organisationsstrukturen
• Organisationsstrukturen gliedern ein Unternehmen
organisationstheoretisch im System

Mandant
• Oberste Hierarchieebene der Organisationseinheiten in SAP
• Mandant kann Konzern, Unternehmen oder Betrieb abbilden
• Mandant ist eine handelsrechtlich, organisatorisch und
datentechnisch abgeschlossene Einheit
• Getrennte Stammsätze und eigenständiger Satz an Tabellen

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 23


Wichtige Begriffe in SAP

Bei jeder Anmeldung am SAP-System muss der Mandant


eingegeben werden:

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 24


Wichtige Begriffe in SAP

Buchungskreis
• Problem:
Verschiedene Unternehmensbereiche brauchen u.U. jeweils
abgeschlossene Buchhaltung im externen Rechnungswesen
• Organisationsstruktur hierfür: Buchungskreis
• Kleinste organisatorische Einheit mit einer in sich
abgeschlossenen Buchhaltung
• Erstellung der gesetzlich geforderten Bilanz und GuV möglich
• 1 Mandant kann mehrere Buchungskreise haben (1:n)
• Beispiel: Mandant = Konzern  Buchungskreise = einzelne
Firmen

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 25


Wichtige Begriffe in SAP

Werk
• Organisatorische Gliederung bzw. Strukturierung eines
Unternehmens aus logistischer Sicht
• Abgrenzung verschiedener Produktions-, Beschaffungs-,
Instandhaltungs- und/oder Dispositionsstätten
• Betriebswirtschaftlich: Werk = Betriebsstätte oder
Niederlassung
• 1 Buchungskreis kann mehrere Werke umfassen (1:n)

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 26


Wichtige Begriffe in SAP

Mandant

Buchungskreis Buchungskreis
1000 3000

Werk/ Filiale Werk/ Filiale Werk/ Filiale Werk/ Filiale


1000 1100 xxxx xxxx

Konzern Mandant

Tochter - Buchungskreis
Unternehmen
unternehmen

Werk Werk

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 27


Wichtige Begriffe in SAP

Stammdaten
• Datensätze, die über einen längeren Zeitraum in der
Datenbank bleiben
• Bspw. Kreditoren, Lieferanten, Materialien, Konten usw.
• Stammdaten werden zentral angelegt
(anwendungsübergreifend)
• Stammdaten können modulübergreifend verwendet werden

Beispiel
• Die für einen Kunden erfassten Stammdaten können z.B. für
einen Kundenauftrag, eine Lieferung, eine Rechnung, eine
Zahlung etc. verwendet werden. Im Kundenstamm sind die
Daten für Buchhaltung und Vertrieb gemeinsam enthalten

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 28


Wichtige Begriffe in SAP

Sichten auf Materialstammdaten:


• Zentrale Quelle zum Abruf materialspezifischer Daten
• Nutzung durch sämtliche Komponenten des SAP-
Logistiksystems
• Keine Datenredundanz durch Integration aller Materialdaten in
einem einzigen Datenbankobjekt
• Gemeinsame Nutzung der Daten bspw. durch die Bereiche
Einkauf, Bestandsführung, Disposition, Rechnungsprüfung

Sichten fassen die


Daten zusammen, die
von einem bestimmten
Bereich (z.B. Einkauf)
gepflegt werden müssen
© SAP-HCC
© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 29
Wichtige Begriffe in SAP

Sichten auf Materialstammdaten:

Einkaufsdaten Material- Materialplanungsdaten


stamm-
satz

...
Bestandsführungsdaten
Buchhaltungsdaten

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 30


Wichtige Begriffe in SAP

Sichten auf Materialstammdaten:

© SAP-HCC

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 31


Integrierte Anwendungssysteme

• Vertikale Integration?

Quelle: Laudon, Laudon, Schoder (2006), S. 98


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 32
Data Warehouse

Datenarchiv: "Snapshots" zu gewissen Zeitpunkten

Extrahiert, sammelt, standardisiert, verdichtet,


organisiert für die Entscheidungsträger relevante
Datenbestände (intern & extern)

 Man spricht auch von „Business Intelligence“

4 Eigenschaften eines DWH:


1. Zeitabhängig
2. Themenbezogen
3. Integriert
4. Nicht flüchtig

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 33


Data Warehouse

Quelle: Laudon, Laudon, Schoder (2009), S. 307

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 34


Data Warehouse & OLAP

OLAP = Online Analytical Processing

Quelle: Laudon, Laudon, Schoder (2006), S. 338


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 35
Wachstum der Informationsökonomie

Angaben für Deutschland


Primärer Sekundärer Tertiärer
Sektor Sektor Sektor
1950 24,6 % 42,9 % 32,5 %
2011 1,6 % 24,6 % 73,8 %

Quelle: Laudon, Laudon, Schoder (2009), S. 9


Statistisches Bundesamt Deutschland: http://www.destatis.de (22.08.2012)
© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 36
IT-Investitionen und Performance

Quelle: Laudon, Laudon, Schoder (2009), S. 29


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 37
Core Issue of Information Systems
Engineering

• How can we use IT to


IT /
improve business Method
processes?

• Traditionally IT Strategy
follows Business Strategy

• „The interplay between


strategy, IT, and the
environment is complex, Business
messy, and chaotic” Process
El Sawy et al. 2010, ISR, 21:4

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 38


Informationssystem und
Anwendungssystem

Quelle: Laudon, Laudon, Schoder (2009), S. 18


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 39
Informationssystem und
Anwendungssystem

• Informationssystem (IS): Ein System, das für die


Zwecke eines Teils eines bestimmten Unternehmens
geschaffen bzw. in diesem Betrieb eingesetzt wird. Es
enthält die dafür notwendigen Anwendungssysteme und
ist in die Organisation des Unternehmens eingebettet.
IS sind daher Soziotechnische Systeme.

• Anwendungssystem (AS): Ein System, welches alle


für ein bestimmtes betriebliches Aufgabenfeld
entwickelten und eingesetzten Programme (Software),
Technik (IT) und Daten beinhaltet.

Quelle: Laudon, Laudon, Schoder (2009), S. 17


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 40
Sociotechnical Systems Framework

Social IT /
Structure Method

Business
Person Trist & Bamforth, Human Relations (1951) 4
Process Bostrom & Heinen, MISQ (1977) 1

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 41


Verflachung von
Organisationsstrukturen

Quelle: Laudon, Laudon, Schoder (2006), S. 53


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 42
Was ist eine Organisation?
Verhaltenstheoretische Definition

Organisationsstruktur
Hierarchie
Arbeitsteilung
Regeln, Verfahren
Geschäftsprozesse
Prozess
Rechte/Verpflicht-
ungen
Privilegien/Verant-
wort lichkeiten
Werte
Normen
Menschen

Quelle: Laudon, Laudon, Schoder (2006), S. 127


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 43
Was ist eine Organisation?
Technisch-mikroökonomische Definition

Quelle: Laudon, Laudon, Schoder (2006), S. 126


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 44
Wechselwirkung von IT und
Organisation - Agency-Kosten

• Was sind Agency-Kosten?

• Unter Agency Kosten versteht man in der


Principal-Agency-Theorie die Kosten, die
durch asymmetrische Verteilung von
Informationen und deren Vermeidung
aufgebracht werden müssen
(Koordinationskosten)

• Insbesondere Steuerungs-, Kontroll-,


Signalisierungs- und Residualkosten

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 45


Wechselwirkung von IT und
Organisation - Agency-Kosten

• IT reduziert Agency-Kosten, da sie Managern erlaubt,


mehr Arbeitnehmer zu führen und zu überwachen

Quelle: Laudon, Laudon, Schoder (2006), S. 136


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 46
Wechselwirkung von IT und
Organisation - Transaktionskosten

• Was sind Transaktionskosten?

 Diejenigen Kosten, die durch die Inanspruchnahme


eines Marktes entstehen

 Insbesondere Such-, Anbahnungs-, Informations-,


Verhandlungs-, Vereinbarungs-, Abwicklungs-,
Kontroll-, etc. Kosten

• Einsatz von Internet-Technologien kann zur Senkung von


Transaktionskosten beitragen

© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 47


Wechselwirkung von IT und
Organisation - Transaktionskosten

• IT kann dazu beitragen, die Transaktionskosten und


damit die Teilnahmekosten auf einem Markt zu senken

Quelle: Laudon, Laudon, Schoder (2006), S. 135


© Professur für Information Systems Engineering, Prof. Dr. Holten 12 - 48

Das könnte Ihnen auch gefallen