Diplomarbeit2 7

Einsatz von Simulationsprogrammen zur Vermittlung komplexer

betriebswirtschaftlicher Prozesse

DIPLOMARBEIT

zur Erlangung des akademischen Grades

eines Magisters
der Sozial- und Wirtschaftswissenschaften
Eingereicht bei Herrn

Ao.Univ.-Prof.
Dr. Kurt PROMBERGER
Institut für Strategisches Management, Marketing und Tourismus
Fakultät für Betriebswirtschaft
Universität Innsbruck
Von Lukas PAA
Innsbruck, Februar 2009

Verzeichnisse:
Inhaltsverzeichnis 3
Abbildungsverzeichnis 81
Tabellenverzeichnis 81
Literaturverzeichnis 82
2
I. Inhaltsverzeichnis
1 EINFÜHRUNG ........................................................................................................................... 6
1.1 PROBLEMSTELLUNG ................................................................................................................. 6

1.2 DARLEGUNG DES THEMAS........................................................................................................ 6
1.3 ZIELE DER ARBEIT ................................................................................................................... 7
1.4 ABGRENZUNG DER ARBEIT ....................................................................................................... 7
1.5 W ISSENSCHAFTLICHE BEARBEITUNG DES THEMAS .................................................................... 7
2 ERP-SYTEME ........................................................................................................................... 8
2.1 ENTWICKLUNG ......................................................................................................................... 8

2.2 MERKMALE VON ERP-STANDARDLÖSUNGEN........................................................................... 10
II
2.3 MERKMALE VON ERP -SYSTEMEN ......................................................................................... 12
2.4 ERP IN DER LEHRE ................................................................................................................ 13
3 PLANSPIELE .......................................................................................................................... 14
3.1 GESCHICHTE DER PLANSPIELE ............................................................................................... 14

3.2 W AS SIND PLANSPIELE........................................................................................................... 15
3.3 PHASEN EINES PLANSPIELS .................................................................................................... 15
3.3.1 Vorbereitungsphase.................................................................................................... 16
3.3.2 Durchführungsphase .................................................................................................. 16
3.3.3 Auswertungsphase ..................................................................................................... 16
3.4 EINSATZ ................................................................................................................................ 16
3.5 PLANSPIELMETHODE .............................................................................................................. 17
3.6 VORTEILE DER VERWENDUNG VON PLANSPIELEN .................................................................... 18
3.7 ARTEN VON PLANSPIELEN ...................................................................................................... 20
3.7.1 Unterscheidungsmerkmale ökonomischer Planspiele................................................ 21
3.7.1.1 Betrieblicher Umfang ......................................................................................... 21
3.7.1.2 Konkretisierungsgrad ......................................................................................... 21
3.7.1.3 Interaktion zwischen Teilnehmergruppen .......................................................... 22
3.7.1.4 Determiniertheit des Modells ............................................................................. 22
3.7.1.5 Regelgebundenheit ............................................................................................ 23
3.7.1.6 Zusammensetzung der Spielgruppen ................................................................ 23
3.7.1.7 Nutzung rechnerischer Hilfsmittel ...................................................................... 23
3.7.1.8 Komplexität des Modells .................................................................................... 23
3.7.2 IT-basierte Planspiele ................................................................................................. 24
4 AUSWAHL PLANSPIEL UND ERP SYSTEM ........................................................................ 24
4.1 AUSWAHL ERP...................................................................................................................... 25

4.2 AUSWAHL PLANSPIEL ............................................................................................................. 26
4.2.1 Überblick ..................................................................................................................... 27
4.2.2 Ablauf .......................................................................................................................... 28
3
4.2.3 Planung und Disposition im Modellbetrieb ................................................................. 30
4.2.3.1 Zielplanung......................................................................................................... 30
4.2.3.2 Primärbedarf ...................................................................................................... 31
4.2.3.3 Dispositive Entscheidungen ............................................................................... 31
4.2.3.3.1 Disposition (Beschaffung).............................................................................. 32
4.2.3.3.2 Disposition (Eigenfertigungsprodukte) .......................................................... 33
4.2.3.4 Kapazitäten ........................................................................................................ 34
4.2.3.5 Kosten ................................................................................................................ 35
5 SEMIRAMIS UND SCSIM ALS PLANSPIEL.......................................................................... 36
5.1 SZENARIO ............................................................................................................................. 36

5.1.1 Beschreibung des Szenarios ...................................................................................... 37
5.1.2 Anforderung an die Teilnehmer .................................................................................. 38
5.2 VORGEHENSWEISE BEI DER ENTWICKLUNG ............................................................................. 38
5.2.1 Grundlegende Stammdaten ....................................................................................... 38
5.2.2 Preise .......................................................................................................................... 40
5.2.3 Wochenzeitmodelle .................................................................................................... 43
5.2.4 Produktionsplan .......................................................................................................... 44
5.2.5 Auftragsarten .............................................................................................................. 44
5.2.6 Materialbedarfsplanung .............................................................................................. 46
5.2.7 Filter für den Datenaustausch .................................................................................... 48
5.3 DATENAUSTAUSCH ................................................................................................................ 48
5.3.1 Datentransfer von Semiramis nach SCSim ................................................................ 49
5.3.1.1 Vertriebsaufträge ............................................................................................... 49
5.3.1.2 Beschaffungsaufträge ........................................................................................ 51
5.3.1.3 Produktionsaufträge ........................................................................................... 52
5.3.1.4 Wochenzeitmodelle ............................................................................................ 54
5.3.2 Transformation von XML-Dokumenten....................................................................... 56
5.3.2.1 Eigenschaften und Vorteile von XML ................................................................. 56
5.3.2.1.1 Medienunabhängiges publizieren in mehreren Sprachen ............................. 56
5.3.2.1.2 Definition von plattformunabhängigen Protokollen zum Datenaustausch ..... 57
5.3.2.1.3 Automatische Verarbeitung übertragener Daten durch Software ................. 57
5.3.2.1.4 Datenverarbeitung mit preisgünstiger Software ............................................ 57
5.3.2.1.5 Benutzerdefinierte Präsentation von Informationen ...................................... 57
5.3.2.1.6 Auffinden von Informationen durch „Informationen über die Informationen“ . 58
5.3.2.2 Aufbau von XML Dokumenten ........................................................................... 58
5.3.2.3 XSLT .................................................................................................................. 59
5.3.2.4 Umsetzung der Datentransformation ................................................................. 60
5.3.3 Datentransfer von SCSim nach Semiramis ................................................................ 65
5.3.3.1 Wareneingang aus Produktion........................................................................... 66
5.3.3.2 Wareneingang aus Beschaffung ........................................................................ 67
4
5.3.4 Umsetzung der Datentransformation.......................................................................... 69
5.4 ABLAUF ................................................................................................................................. 72
5.5 KOMPROMISSE UND PROBLEME .............................................................................................. 78
6 ZUSAMMENFASSUNG UND AUSBLICK .............................................................................. 79
5
1 Einführung
1.1 Problemstellung
ERP-Systeme finden in immer mehr Unternehmen Verwendung. Am Arbeitsmarkt ist die Nachfrage
nach Absolventen mit ERP-Erfahrung groß, die Zahl derer, die wirklich schon Erfahrung im
Umgang mit einer Software haben, jedoch gering. Dies ist unter Anderem ein Grund warum es
sinnvoll erscheint, ERP-Systeme in der Hochschullehre einzusetzen. Zusätzlich helfen sie den
Studierenden, einen besseren Überblick über realitätsnahe betriebliche Prozesse zu erlangen, die
in der Praxis erfolgreich angewendet werden. Das betriebliche Know-how, welches sich in IT-
gestützten Informationssystemen, zu denen auch die Gattung der ERP-Systeme zu zählen sind,
1
wieder findet, stellt oftmals auch eine Ansammlung verschiedenster „best-practice“ Prozesse dar.
In der universitären Lehre werden aus Zeitmangel meist nur die Navigation im System, die
grundlegende Anlage von Stammdaten und einzelne Prozesse wie Beschaffung und Vertrieb
behandelt. Komplexere Bereiche wie die Produktion oder die Materialbedarfsplanung werden nur
selten, in speziell auf diesen Bereich ausgerichteten Lehrveranstaltungen, behandelt. Durch diese
eingeschränkte Einsatzweise, bzw. die bestehenden Möglichkeiten des Einsatzes von ERP-
Systemen werden wichtige Standardprozesse im Rahmen einer umfassenden Ausbildung
vernachlässigt.
1.2 Darlegung des Themas
Da die abgebildeten Prozesse in den Frameworks/Modulen der Produktion die unternehmerische

Realität widerspiegeln, fördern sie auch das Verständnis der Studierenden für die Bereiche
Produktionsplanung und Materialbedarfsplanung. Aus diesem Grund erscheint es sinnvoll, diese in
den Unterricht mit einzubinden. Da diese Komponenten sehr komplex sind, soll ein Planspiel
entwickelt werden, dass ein ERP-System mit einem Simulationsprogramm verbindet, um die
Logiken und Prozesse der Produktion und Produktionsplanung zu verdeutlichen.
II
Dazu wird das ERP -System „Semiramis“ mit „SupplyChainSimulation“(SCSim), einem Programm,
das Beschaffung, Produktion und Vertrieb weit weniger komplex abbildet als eine ERP-Software,
verknüpft. SCSim wurde von der Fachhochschule Karlsruhe entwickelt und ist über
http://www.iwi.hs-karlsruhe.de/scs/start zugänglich. Beide Programme sollen nach einer Planungs-,
Umsetzungs- und Analysephase zusammen als Planspiel in der Hochschullehre eingesetzt
werden.
1
Vgl. Hawking, (2004)
6
1.3 Ziele der Arbeit
Durch die Kombination der beiden Programme in einem Planspiel haben Studierende zum Einen
die Möglichkeit, eine ERP-Software kennenzulernen, was die Employabiliät genauso steigert wie
ihr Verständnis für betriebsinterne Prozesse.
Zum Anderen ist es möglich, die „Blackbox“ Produktion aufzubrechen ohne den Rahmen einer
universitären Lehrveranstaltung zu sprengen. Um das Planspiel erfolgreich zu bestreiten, müssen
sich die Studierenden ausführlich mit den Logiken und Prozessen der Produktion in
„SupplyChainSimulation“(SCSim) auseinandersetzen. Dabei gilt es zu verstehen, welche
Einzelteile zu welchem Zeitpunkt bestellt werden müssen, um für den Produktionsprozess
rechtzeitig im Lager zu sein. Des Weiteren muss geplant werden, welche Ressourcen durch die
Produktion belegt werden und wie lange diese benötigt werden. Auch die Entscheidung, ob es sich
lohnt Überstunden zu veranlassen, muss kalkuliert werden. Da die Studierenden die Produktion
über mehrere Perioden im voraus von Hand planen müssen, wächst ihr Verständnis für den
Produktionsprozess. Dadurch fällt es anschließend leichter, ihnen die Produktion sowie die
Materialbedarfsplanung in Semiramis zu erklären.
Desweiteren wird der Umgang mit dem ERP-Programm Semiramis in Form eines Planspiels
spielerisch vermittelt und durch die Wiederholung in jeder Periode gefestigt.
1.4 Abgrenzung der Arbeit
Es ist nicht Ziel dieser Arbeit, das gesamte Planspiel durchzuführen und zu evaluieren. Es wird
lediglich ein Testdurchlauf durchgeführt. Es wird dabei auf Probleme und Verbesserungspotential
geachtet. Darauf aufbauend kann entschieden werden, ob das Planspiel für den regulären Einsatz
in der Lehre reif und geeignet ist.
1.5 Wissenschaftliche Bearbeitung des Themas
Die Arbeit gliedert sich grob in zwei Teile: Den ersten der beiden bilden die Punkte 2 und 3, in
welchen Grundlagen zu ERP-Systemen und Planspielen behandelt werden. Im zweiten Teil stehen
dann das Zusammenspiel und –wirken der beiden Programme sowie ihre Implementierung und
Verwendung in der Lehre im Vordergrund. Dies wird in den Punkten 3 und 4 abgehandelt.
Zu Beginn der Arbeit werden die Problemstellung, die Zielsetzung und der Aufbau der Arbeit
dargelegt.Die theoretische Abhandlung von ERP-Systemen und Planspielen bilden den folgenden
Abschnitt. Darin werden zuerst ERP-Systeme beschrieben: Was ERP-Systeme auszeichnet, aus
welchen Bedürfnissen sie entstanden sind, wie sie sich entwickelt haben und was in Zukunft von
ihnen erwartet werden kann. Des Weiteren wird erläutert, welche Relevanz sie für die universitäre
Lehre haben und in welcher Form und welchem Ausmaß sie bereits in der Hochschullehre
verwendet werden.
7
Anschliessend werden Planspiele mit ihrer Entstehung, ihrem Sinn und Zweck, sowie ihrer
Verwendung in der Ausbildung von Studenten bearbeitet. Dabei wird besonders auf
betriebswirtschaftliche Planspiele eingegangen.
In Punkt 4 werden die Idee und das Ziel des sinnvollen Zusammenspiels eines ERP-Systems und
einer Supply Chain Simulation (Planspiel) beschrieben. Im Anschluss werden die Schnittstellen
und die mögliche Kombination der beiden Programme erläutert und in einem Pflichtenheft
festgehalten. Dabei wird zuerst auf das gewählte Szenario und auf die Vorgehensweise bei der
Entwicklung sowie der technischen Umsetzung eingegangen. Unter anderem werden auch
Grenzen und Ungenauigkeiten einer bidirektionalen Integration dargestellt. Das Ergebnis der
technischen Umsetzung wird in einem fortlaufenden Iterationsprozess solange adaptiert, bis ein
mehrwertorientierter und handhabbarer Einsatz in der Lehre ermöglicht wird.
2 ERP-Syteme
Der Begriff ERP steht für Enterprise Resource Planning und bezeichnet ganzheitliche
Softwarelösungen, die den organisatorischen Ablauf aller Bereiche eines Unternehmen, steuern,
kontrollieren und auswerten. ERP-Software unterscheidet sich von anderen
betriebswirtschaftlichen EDV-Programmen dadurch, dass nicht nur einzelne Bereiche durch das
Programm abgebildet und unterstützt werden, sondern das gesamte Unternehmen integriert IT-
mäßig abgebildet wird. Während andere Softwareprodukte funktional orientiert sind, arbeiten ERP-
Programme prozessorientiert. Allen ERP-Anbietern ist gemeinsam, dass sie versuchen, mit ihren
2
Lösungen den Informationsfluss im Unternehmen als Ganzes zu erfassen und abzubilden.
ERP-Software kann als das unumstrittene Rückgrat der Unternehmens-IT gesehen werden. Sie
hält die Unternehmensfinanzen zusammen und liefert die Datenbasis für Controller, da alle Daten
aus Finanzen, Produktion, Vertrieb, Einkauf, Lager und die Zusammenarbeit mit Kunden und
Lieferanten dort zusammenfließen und stets aktuell und konsistent allen zur Verfügung stehen.
3
Dieser zentrale Datenpool bildet somit die Basis für strategische Entscheidungen
2.1 Entwicklung
Die Entstehung heutiger ERP-Systeme geht bis in die 1960er-Jahre zurück und steht in engem
Zusammenhang mit der Verwendung elektronischer Datenverarbeitung in Unternehmen. Zu
Beginn haben diese Anwendungen das Ziel gehabt, isolierte, funktional ausgerichtete Aufgaben zu
optimieren. Dazu wurden Karteikartensysteme durch Datenbanken abgelöst und die Planung statt
von Hand, mit Hilfe von Tabellenkalkulationsprogrammen durchgeführt. Ausgehend vom
Primärbedarf wurde durch Auflösung der Stücklisten der Sekundärbedarf, sprich Halbfabrikate,
Rohstoffe und Zukaufteile, kalkuliert. Diese Material Requirements Planning Systeme (MRP)
2
Vgl. Promberger (2003), S. 39
3
Vgl.Weiss (2006), http://www.cio.de/_misc/article/printoverview/index.cfm?pid=183&pk=821328&op=lst> (17.9.2008)
8
ermöglichten eine bedarfsorientierte Materialdisposition, die eine mengen- und termingerechte
Planung erlaubte. Ob ein so ermittelter Produktionsplan durchgeführt werden konnte war nicht
garantiert, da keine Verfügbarkeitsprüfung der Ressourcen durchgeführt werden konnte.
In den folgenden Jahren wurden MRP-Systeme um die Aspekte der Kapazitäts- und
Terminplanung erweitert. Diese erweiterten Softwareanwendungen, die auch Funktionalitäten für
die Bereiche Beschaffung, Fertigung und Lager bereitstellten, wurden Manufacturing Resource
Planning-Systeme (MRP II) genannt. MRP II-Systeme berücksichtigen in ihrer Planung auch
Informationen aus dem betrieblichen Tagesgeschäft, wie Lagerbewegungen, offene Bestellungen
und geplante, aber nicht erledigte Produktionsaufträge. Dadurch können die Kapazitäten der
Ressourcen dem ermittelten Produktionsplan angepasst werden. Die Planungsstufen
Materialbedarfsplanung, Kapazitätsplanung und Terminplanung werden in dieser Reihenfolge
durchgeführt. In jeder Stufe muss auf die Ergebnisse des vorhergehenden Schrittes gewartet
werden, was als Schwachpunkt von MRP II-Sytemen gesehen wird, da dies in langen
Planungszyklen resultiert.
Zeitgleich zu dieser Entwicklung wurden auch für das Rechnungswesen Anwendungen entwickelt.
Diese wurde durch die hohe Standardisierung der Prozesse durch gesetzliche
4
Rahmenbedingungen, begünstigt .
Mitte der 1980er-Jahre bedienten sich MRP II-Systeme der Entwicklungen für den
Aufgabenbereich des Rechnungswesens und integrierten diese sowie die
Unternehmensfunktionen Einkauf und Personalwesen in ein System. Sie werden als Enterprice
Resource Planning Systeme (ERP-Systeme) bezeichnet. Sie bilden den gesamten Datenfluss
innerhalb eines Unternehmens ab, und speichern alle Informationen in einem Datenpool, auf den
alle unternehmensinternen Bereiche über verschiedene Komponenten oder Module zugreifen
5
können .
Das Internet bewirkte in den letzten Jahren eine funktionelle Weiternetwicklung von ERP-Software
in den Bereichen Kommunikation, Interaktion und Geschäftsabwicklung. So können Mitarbeiter
jederzeit und von jedem Ort der Welt auf das System zugreifen um Informationen einzuholen oder
zu bearbeiten. Kommunikations-Standards wie „Extensible Markup Language“ (XML) und
Webservices vereinfachen den Datenaustausch im innerbetrieblichen sowie zwischenbetrieblichen
Umfeld.
Dies kommt auch der Integration des Supply Chain Management (SCM) Gedankens in ERP-
Systemen zu Gute. SCM zielt auf die Planung, Optimierung und Steuerung der gesamten
Logistikkette über die Unternehmensgrenzen hinaus. Um den gesamten Wertschöpfungsprozess,
von der Rohstoffgewinnung bis hin zum Endkunden, zeit- und kostenoptimal zu gestalten, bedarf
es einer effektiven und zuverlässigen Kommunikation zwischen vertikal verbundenen Partnern.
Erweiterte ERP-Systeme die sowohl „web-basiert“ sind als auch Geschäftsprozesse über die
II
Unternehmensgrenzen hinaus abbilden, werden ERP -Systeme genannt.
4
Vgl. Rautenstrauch, C.; Schulze, T.,(2003), S. 314
5
Vgl. Wannenwetsch, H.; Nicolai, S.,(2004), S. 73
9
2.2 Merkmale von ERP-Standardlösungen
Bildet eine betriebswirtschaftliche Software alle Geschäftsprozess eines Unternehmens in

mehreren Modulen und in einer standardisierten Vorgehensweise ab und weist es zusätzlich einen
gewissen Grad an technischer und betriebswirtschaftlicher Flexibilität auf, so kann sie als ERP-
Software klassifiziert werden. Im Folgenden werden diese Charakteristika weiter erläutert.
Das entscheidende Merkmal von ERP-Systemen ist der Aufbau des gesamten Systems auf einer
einzelnen Datenbasis, die von allen Modulen verwendet wird. Dadurch werden Redundanzen
vermieden und Konsistenz gewährt. Man spricht hierbei auch von Integration, welche sich
einerseits auf die gemeinsame Verwendung der Daten (Datenintegration), andererseits auf die
6
durchgängige Verarbeitung mehrerer Geschäftsprozesse (Prozessintegration) bezieht.
Integration findet auch zwischen unterschiedlichen Unternehmensfunktionen und operativen
Einheiten eines Unternehmens statt. So löst beispielsweise eine Änderung der Lieferadresse eines
Kunden durch den Kundenservice ein Update in allen anderen Teilbreichen aus. Da sämtliche
Benutzer auf den selben Datenpool zugreifen, stehen allen immer alle relevanten Informationen in
Echtzeit zur Verfügung, was zu Folge hat, dass nur betriebswirtschaftlich konsistente
7
Transaktionen durchgeführt werden.
FIBU,
KORE
Qualitäts- Human
manage- Resour-
ment ces
Einkauf,
Material ERP- Control-
wirt- System ling
schaft
Distribu-
tion,
PPS
Disposi-
tion
Vertrieb
8
Abbildung 1: Der Integrationsgedanke bei ERP-Systemen
Typischerweise sind ERP-Lösungen in Module oder Komponenten wie Finanzwesen und

Controlling, Produktionsplanung und –steuerung, Einkauf und Logistik, Vertrieb und Versand sowie
Personalwesen untergliedert. Wie die Namensgebung bereits verrät, sind die Module auf
6
vgl. Gadatsch (2008): S. 255f
7
vgl. Friedl/Hilz/Pedell (2002): S. 164
8
eigene Darstellung in Anlehnung an Davenport, (1998)
10
bestimmte Arbeitsplatztypen ausgerichtet. Mitarbeiter eines bestimmten Bereichs arbeiten meist
nur mit dem für sie ausgerichteten Modul. Das macht es für den Anwender einfacher, weil er sich
nur in einem Modul auskennen muss. Für das Unternehmen bietet es eine gewisse Sicherheit,
dass jeweils nur Angestellte des betreffenden Bereichs entsprechende Daten einsehen, ändern,
oder Transaktionen durchführen können.
Der modulare Aufbau bietet für Unternehmen die Möglichkeit, aufbauend auf dem Basissystem nur
einzelne Module zu erwerben beziehungsweise zu implementieren. Neben finanziellen Aspekten
des Kaufs von Modulen ist auch zu beachten, dass die Implementierung eines ERP-Systems
zeitintensiv ist, da unter Umständen Geschäftsprozesse an das System angepasst (Business
9
Process Reengineering) und mit Sicherheit Mitarbeiterschulungen durchgeführt werden müssen.
10
Zusätzlich scheint es unmöglich, ohne die Hilfe von Experten auszukommen. Erscheint es
sinnvoller, zu Beginn oder überhaupt nur einzelne Komponenten zu verwenden, statt alle Module
für alle Bereiche des Unternehmens auf einmal zu implementieren, („Big Bang“), können durch den
modularen Aufbau Kosten- und Zeitaufwand reduziert oder auf einen längeren Zeitraum verteilt
11
werden.
Ein weiterer wesentlicher Punkt einer Standardsoftware ist eine konsistente Benutzeroberfläche
bezüglich des Designs und Bildschirmaufbaus, genauso wie der Menüführung und
Tastenbelegung. Dies fördert die Benutzerfreundlichkeit und damit die Einstellung der Angestellten
gegenüber dem System.
Wie der Name „betriebswirtschaftliche Standardsoftware“ schon sagt, zeichnen sich ERP-Systeme
durch eine Prozessstandardisierung aus. Dies garantiert zu einem gewissen Grad eine
Allgemeingültigkeit der abgebildeten Prozesse. Somit sind ERP-Programme branchen- und
grössenunabhängig (Skalierbarkeit). Oft stellen die verwendeten Standardprozesse „best-
12 13
practice“Prozesse dar. Darunter versteht man die beste Art, einen Prozess durchzuführen. Mit
14
der Implementierung eines ERP-Systems werden durch Business Process Re-engineering
ineffiziente Prozesse den neuen „Musterprozessen“ angepasst, was in Einsparungen im Bereich
15
der Gesamtbetriebskosten resultiert.
Da es nicht immer realisierbar oder sinnvoll ist die Prozesse eines Unternehmens dem System
anzupassen, bieten diese die Möglichkeit, die Prozesse im System in einem gewissen Rahmen an
die betriebsinterne Realität anzupassen. Dies ist zum einen durch das Customizing, sprich im
System vorgesehene Anpassungsoptionen, oder durch Ergänzungsprogrammierungen möglich.
Jedoch ist anzumerken, dass Unternehmen die die Implementierung als Anlass und Chance
sehen, ihre Vorgehensweisen zu überdenken und gegebenenfalls in Richtung des ERP-Systems
16
zu optimieren, den größten Nutzen erfahren.
9
Vgl. Gadatsch, (2008); S 11
10
Vgl. Davenport, (2000)
11
Vgl. Hansen/Neumann (2005) S.534
12
Vgl. Hawking, (2004)
13
Vgl. Sumner, (2005)
14
Vgl. Sumner, (2005) S.19
15
Vgl. mySAP ERP (2005)
16
Vgl. Davenport, (2000)
11
2.3 Merkmale von ERPII-Systemen
II
Die folgenden Punkte sind spezielle Merkmale von ERP -Systemen.
Das Internet ist heute beinahe überall zu erreichen und bietet somit enorme Möglichkeiten für ein
Web-basiertes ERP-System. Die Mehrzahl der Produkte auf dem Markt hat sich damit zufrieden
gegeben, ihre bereits bestehenden Systeme um die Webfähigkeit zu ergänzen. Dies hat zu Folge,
dass die dadurch entstandene Architektur komplex und schwer administrierbar ist. Um die
Chancen, die das Internet bietet, optimal nutzen zu können, brauchen Anwender Produkte, die
17 II
eine direkte Unterstützung des Internets bieten. ERP -Systeme heben sich durch diese
Weiterentwicklung von ihren Vorgängern ab.
Für Anwender ist es von großem Vorteil, wenn sie ihre vorhandenen Systeme weiterverwenden
können. Außerdem wird das Risiko des totalen Verschwindens eines Herstellers vom Markt sowie
II
das eines Herstellermonopols minimiert. Alle ERP Systeme sind plattformunabhängig gestaltet.
Dies bietet auch den Vorteil, dass bei einem Systemwechsel nicht auch das ERP-System
18
gewechselt werden muss.
Die zukünftige Entwicklung und das Wachstum eines Unternehmens vorherzusagen ist enorm
II
schwierig. Deshalb sind ERP -Systeme darum bemüht, Lösungen anzubieten, die unabhängig von
der Größe eines Unternehmens verwendet werden können. Besonders wichtig dabei ist, dass
Unternehmen nicht zu einem anderen Produkt wechseln müssen, nur weil ihre ERP-Software die
Last der Transaktionen nicht mehr bewältigen kann. Das ERP-System muss also in der Lage sein,
19
mit dem Unternehmen zu wachsen.
Wegen der Ungewissheit zukünftiger Entwicklung sowohl von Unternehmen als auch von
Softwarelösungen, wird von modernen ERP-Produkten leichte Integrierbarkeit und
Standardschnittstellen erwartet. Je reifer Integrationskonzepte werden, desto bedarfsorientierter
sind sie. ERP-Hersteller erfüllen diese Anforderung am besten, wenn sie ihre Produkte mit
20
führenden Plattformen integrieren. Moderne ERP-Systeme unterstützen offene Architekturen wie
XML, Java, PHP oder Webservices.
Besonders für Mittelständische Unternehmen ist es angenehm, wenn sie eine integrierte IT-Lösung
aus einer Hand erhalten. Dies bietet den Vorteil, dass sie sich nicht über zusätzliche
Softwarelösungen informieren müssen und sich auch nicht um die Integration von
II
Zusatzanwendungen kümmern müssen. Daher wird von ERP -Systemen verlangt, die gesamte
Business-Software die ein Unternehmen zur Abwicklung aller Geschäftsprozesse benötigt, zu
21
liefern.
17
Gümbel (2005), S.6
18
Vgl. Gümbel (2005), S.6
19
20
21
12
Application Service Providing (ASP) beschreibt Applikationen, die dem Client nur temporär zur
Verfügung gestellt werden. Für den Anwender hat dies einerseits den Vorteil, dass deutlich
weniger IT-Ressourcen und Wartungsaufwand benötigt wird. Andererseits bedeutet dies, dass sie
für den User auch außerhalb seines Arbeitsplatzes jederzeit über das Internet verfügbar ist. ASP
ermöglicht auch KMUs ansonsten Kosten und Wartungsintensive Systeme zu nutzen, und erlaubt
22
ihnen somit, sich auf ihre Kernaufgaben zu konzentrieren.
2.4 ERP in der Lehre

Mit der steigenden Anzahl von Implementierungen von ERP-Systemen ist auch die Nachfrage
nach ERP-Wissen und Fähigkeiten gestiegen. Viele Universitäten sind auf diesen Trend
23
aufmerksam geworden und haben ERP-Systeme in ihr Lehrangebot aufgenommen. Dabei sind
drei verschiedene Methoden zu unterscheiden.
- Der traditionelle Ansatz:
Beim traditionellen Ansatz haben die Studenten weder Zugang zu einem ERP-System
noch sehen sie wie darin navigiert wird. Es werden in Form einer Vorlesung
theoretische Grundlagen vermittelt. Dies ist die kostengünstigste aber auch am
wenigsten lernintensive Methode, ERP-Systeme zu unterrichten. Der Fokus dieser
24
Lehrweise liegt in der theoretischen Vermittlung von Wissen bezüglich ERP-Systeme.
- Der Hands-on Ansatz:
Der Hands-on Ansatz konzentriert sich weniger auf theoretische Inhalte. Jeder
Studierende hat Zugang zu einem ERP-System und erlernt dort verschiedenste
Fertigkeiten. Die Studierenden werden mit Aufgaben konfrontiert, die sie im System
bearbeiten müssen. Dadurch haben sie direkten Kontakt zum System und die größte
Chance, sich Wissen langfristig anzueignen. Ein bedeutender Vorteil liegt darin, dass
die Studierenden durch „experiental learning“, also die Möglichkeit etwas
auszuprobieren, Fehler zu entdecken und zu verbessern und sich frei im System
bewegen zu können, den intensivsten Lerneffekt zu erfahren. Zudem wird der
praktische Umgang mit dem System von Studierenden als die angenehmste Methode
25
empfunden, sich Wissen und Fertigkeiten zu ERP-Systemen anzueignen.
- Der simulierte Hands-on Ansatz:
Der Unterschied zum Hands-on Ansatz liegt darin, dass die Studierenden keinen
Zugang zum System haben. Trotzdem sehen sie wie man verschiedene Aufgaben
erledigen kann. Sie verfolgen Operationen am System über einen Bildschirm, können
aber nicht selbst in den Prozess eingreifen. Somit geht die Möglichkeit, aus Fehlern zu
lernen, verloren.
22
Vgl. Gümbel (200) S.8
23
Vgl. Hawking, P., McCarthy, B., Stein, A. (2005)
24
vgl. Noguera/Watson, (2004), S. 58
25
vgl. Watson/Schneider, (1999), S.4
13
Auch wenn der Hands-on-Ansatz der für die Hochschule kosten- und zeitintensivste ist, verspricht
er den größten Nutzen für die Studierenden. Das im Rahmen dieser Diplomarbeit entwickelte
Planspiel verwendet den Hands-on-Ansatz. Zudem wird der Umgang mit einem ERP-System durch
die Gestaltung als Planspiel spielerisch vermittelt und geübt.
3 Planspiele
Heutzutage wird von Bildungseinrichtungen immer mehr gefordert, dass Schüler bzw. Studierende
nicht als passive, rezeptive Objekte, sondern als aktive, handelnde, kooperative und
selbstbestimmte Subjekte begriffen werden. Des Weiteren soll eine Lernatmosphäre bestehen, die
zu verantwortungsvollen, produktiven und kreativen Tätigkeiten motiviert, und somit den
Anforderungen der Berufswelt gerecht wird. Dazu werden vermehrt Konzepte gesucht und auch
verwendet, die Schlüsselqualifikationen durch handlungsorientiertes Lernen vermitteln. Ein
Konzept das diesen Anforderungen gerecht wird, ist das Planspiel. Es gilt als eine besondere Form
eines dynamischen Modells, in dem sich die Teilnehmenden mit Konfliktsituationen innerhalb eines
durch Regeln festgelegten Rahmens, unter einer bestimmten Zielsetzung, in einer Gruppe
26
auseinandersetzen.
Im Folgenden wird auf die Entstehung und die Eigenschaften von Planspielen und deren
Verwendung in der Lehre eingegangen. Den letzten Punkt bilden IT-basierte Planspiele, welche
immer mehr an Bedeutung und Verwendung gewinnen und auch im Rahmen dieser Diplomarbeit
verwendet wurden.
3.1 Geschichte der Planspiele
Die ersten Planspiele wurden bereits im 17. Jahrhundert angewendet und etablieren sich heute
zunehmend in der betrieblichen und schulischen Aus- und Weiterbildung. Sie bieten eine effiziente
Möglichkeit, klassische Lehrmethoden zu ergänzen.
Der Stammbaum des Planspiels geht zurück auf Kampfspiele in Indien sowie das in Persien
entstandene Schachspiel um 800 v. Chr. Diesen traditionellen Kampfspielen lag bereits die Idee
zugrunde, die auch zum Erfolg aktueller Planspiele beiträgt: eine Möglichkeit zu schaffen,
Vorgänge in der realen Welt besser zu verstehen und Entscheidungen risikofrei treffen zu können.
Das erste komplexere Spiel das in der Literatur einheitlich erwähnt wird ist das „Königsspiel“, das
1664 von Christopher Weikhmann in Ulm entwickelt wurde. Dabei handelte es sich um eine
27
erweiterte Schachvariante, die militärische Details stärker berücksichtigte. In den folgenden drei
Jahrhunderten entwickelten sich diese Spiele vom klassischen Schachbrett über Landkarten bis
hin zum Geländeprofil. Die Anfänge der betriebswirtschaftlichen Anwendung dieser Methoden
26
Vgl. Rebmann (2000), S.1
27
Vgl. http://www.ghs-kosim.de/cosim_history.html (7.9.2008)
14
liegen am Anfang des 20. Jahrhunderts. Nach dem zweiten Weltkrieg verstärkten sich die
Bemühungen, die Potentiale solcher Simulationen auch für die Wirtschaft nutzbar zu machen. Das
erste Modell - die "Top Management Decision Simulation" - wurde hierfür 1956 von der "American
Management Association" entwickelt. Seit dem hat sich eine Vielzahl von
Unternehmensplanspielen, die sich hinsichtlich ihrer Komplexität und Differenziertheit bei der
28
Abbildung bestimmter unternehmerischer Teilbereiche unterscheiden, entwickelt. Dr. Walter E.
Rohn, Gründer der “deutschen Planspiel-Zentrale“, sieht in Planspielen ein enormes Potential:
“Planspiele sind mit die lernintensivsten Weiterbildungsinstrumente der Zukunft. Sie simulieren
ganz wirklichkeitsbezogen die Berufstätigkeit der Führungskräfte. Mit Ihnen lernt man zeitsparend,
29
systematisch und risikofrei erfolgreiches Management!“
3.2 Was sind Planspiele
Da diese Arbeit als Diplomarbeit eines Betriebswirtschaftslehre-Studiums verfasst wird, wird im

Folgenden auf betriebswirtschaftliche Planspiele eingegangen.
Ein betriebswirtschaftliches Planspiel bzw. Unternehmensplanspiel ist eine modellhafte Abbildung

von Unternehmen oder Teilbereichen davon. Die Teilnehmer eines Planspiels übernehmen
einzeln, oder in Gruppen, die Führung eines Unternehmens. Dabei konkurrieren sie mit anderen
Unternehmen an einem simulierten Markt. Durch ihre Entscheidungen beeinflussen die Teilnehmer
den Erfolg ihres Unternehmens. So lernen sie unternehmensinterne Prozesse und
Zusammenhänge kennen. Zusätzlich werden sie erkennen, welche internen und externen Faktoren
Einfluss auf den wirtschaftlichen Erfolg eines Betriebes haben. Des Weiteren lernen sie mit
Zielkonflikten in der Unternehmensleitung umzugehen. Sie können die theoretisch erlernten
betriebswirtschaftliche Methoden und Informationsmittel praktisch anwenden und sammeln
Erfahrungen im Umgang mit Entscheidungen unter Unsicherheit. Zusätzlich müssen sie die
Entscheidungen im Team und unter Zeitdruck treffen.
Planspiele bieten ein hohes Maß an Lerntransfer durch erlebte Erfahrungen, was zum einen in
größerem Engagement für das Planspiel und die zugrunde liegende Theorie resultiert und zum
30
anderen die erlernten und erfahrenen Inhalte stärker im Gedächtnis verankert.
3.3 Phasen eines Planspiels

Der Ablauf von Planspielen kann in drei Phasen unterschieden werden: Vorbereitungs-,
Durchführungs- und Auswertungsphase. Diese Phasen sind nicht als separierte Einheiten sondern
viel mehr als von einander abhängige Prozessschritte zu verstehen. So müssen Erkenntnisse aus
28
Vgl, Orth, (1999); S.1
29
http://www.dpsz.de/zitate.htm (7.9.2008)
30
Vgl. http://www.topsim.com/de/ueber_planspiele/methode/ (26.09.2008)
15
früheren Phasen in die Entscheidungsfindung der folgenden Phase hineinfließen. Der gesamte
31
Durchlauf dieser drei Phasen wird auch als Makrozyklus bezeichnet.
3.3.1 Vorbereitungsphase
Die Vorbereitungsphase betrifft vor allem den Spielleiter. Seine Aufgabe ist es, entweder ein
passendes Planspiel auszuwählen und zu besorgen, oder eines zu entwickeln. Anschließend muss
dieses, falls es sich um ein IT-basiertes Planspiel handelt, installiert werden. Die Teilnehmer
werden in Gruppen eingeteilt und erhalten eine Einführung in die Problemstellung und den Ablauf
des Planspiels. Aufgabe der Teilnehmer ist es dann ihre strategischen und operationalen Ziele zu
32
formulieren.
3.3.2 Durchführungsphase
Die Durchführungsphase stellt das eigentliche Planspiel dar. Sie besteht in der Regel aus
mehreren sich wiederholenden Perioden, welche auch als Mikrozyklen bezeichnet werden. Zu
Beginn jeder Periode haben die Teilnehmer die Aufgabe, die Ausgangssituation und eventuell die
Ergebnisse der vorherigen Periode zu analysieren. Anschließend treffen sie auf Basis dieser
Informationen ihre Entscheidungen und geben diese in das System oder ein Formular ein. Aufgabe
des Spielleiters in der Durchführungsphase ist die Überwachung und Kontrolle des Spielflusses.
33
Außerdem steht er bei Problemen als Berater bereit.
3.3.3 Auswertungsphase
Diese Auswertungsphase bildet zeitlich gesehen den letzten Abschnitt. Dabei werden der
Gesamtspielverlauf analysiert, die Ergebnisse der einzelnen Phasen beobachtet und auch die
Strategien und Ergebnisse der einzelnen Gruppen verglichen und diskutiert. Falls vorhanden kann
auch eine Ideallösung präsentiert werden. Ziel der Auswertungsphase ist es, das erlernte Wissen
der Teilnehmer noch einmal zu vertiefen und Feedback von den Teilnehmern zum Planspiel zu
34
erhalten, um es eventuell weiterzuentwickeln.
3.4 Einsatz
Der Einsatz von betrieblichen Planspielen kann nach dem Einsatzort und der Zielgruppe
unterschieden werden. In Unternehmen können sie für die Aus- und Weiterbildung von
Führungskräften genauso wie die Schulung von Mitarbeitern genutzt werden. An
31
Vgl. Mahlke, (2006), S. 9
32
Vgl. Mahlke, (2006), S. 9
33
Vgl. Mahlke, (2006), S. 10
34
Vgl. Mahlke, (2006), S. 10
16
Bildungseinrichtungen können Studierenden und Auszubildenden jedes Leistungsniveaus mit Hilfe
35
von Planspielen komplexe Inhalte und Prozesse vermittelt werden.
3.5 Planspielmethode
Um der Forderung nach der Bildung von anwendbarem Wissen und sozialen Kompetenzen
gerecht zu werden und um die Visionen selbstorganisierten erfahrungsbezogenen Lernens in die
Praxis umsetzen zu können, bedarf es geeigneter Trainingsmaßnahmen und
36
Ausbildungsmethoden. Die „Swiss Austrian German Simulation And Gaming Association“
(SAGSAGA) verwendet den Überbegriff "Planspielmethoden" für zahlreiche erfahrungsorientierte
Lernformen wie z.B. Rollenspiele, Improvisationen, Unternehmenstheater, Teamübungen,
37
Lernspiele, Computersimulationen und (Unternehmens-)Planspiele.
All diesen Lernformen sind die Vorgabe komplexer Probleme und die Lösung dieser in Gruppen
gemeinsam. Auf diese Weise können Teilnehmer durch eine erfahrungsorientierte Lernform
erleben, welche Dynamiken und Faktoren in den realitätsnahen Abbildungen der Modelle wirksam
sind. Erfahrungsorientierte Lernformen fördern zum einen die Motivation und das Engagement der
38
Teilnehmer, zum anderen ermöglichen sie es, komplexe Inhalte und Prozesse zu vermitteln.
Somit werden den Teilnehmern die Fähigkeiten mit komplexen Systemen adäquat umzugehen,
sowie in solchen Systemen sinnvolle Handlungsstrategien zu planen und umzusetzen, vermittelt.
Des Weiteren wird die Sozialkompetenz der Beteiligten gefördert, da sie in einem weitgehend
angstfreien Klima, Kommunikations- und Organisationsstrukturen durch eigenständiges Handeln
39
erproben können. Erfahrungsbasiertes Lernen kann in vier Phasen unterschieden werden,
welche auch für Planspiele große Bedeutung haben:
- Konkret erfahren: Lernende machen entweder in der Realität oder in einer Simulierten
Umgebung eine Erfahrung
- Reflektieren und beobachten: Eine Erfahrung wird aus einer gewissen Distanz
beobachtet und analysiert
- Verallgemeinern: Die Analyse führt zu Annahmen, welche dann verallgemeinert
werden können
- Anwenden und prüfen: Die gewonnenen Annahmen können in der Realität oder im
Planspiel angewendet und getestet werden
35
Vgl. http://www.topsim.com/de/ueber_planspiele/methode/ (26.9.2008)
36
http://www.sagsaga.org/page10-400.html (1.10.2008)
37
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
38
Vgl. Rebmann (2001); S.2
39
17
anwenden und
konkret erfahren
prüfen
reflektieren und
verallgemeinern
beobachten
40
Abbildung 2: Die vier Phasen des erfahrungsbasierten Lernens
Während des Ablaufs eines Planspiels werden diese Schritte mindestens einmal durchlaufen. „Die
Teilnehmerinnen diskutieren - beispielsweise um einen Spielentscheid auszuhandeln - und
reflektieren und verallgemeinern dabei sehr oft bisherige Erfahrungen und Annahmen. Die
Spielentscheide werden am Ende der Spielrunde vom Planspielmodell ausgewertet. Die Resultate,
welche die Teilnehmerinnen anschließend erhalten, erlauben eine Prüfung der im Spiel
41
entwickelten Hypothesen. Weitere Erfahrungen folgen in den nächsten Spielrunden“
Entscheidend für den Lernerfolg ist eine sorgfältige Analyse der Ergebnisse eines Planspiels, was
als „Debriefing“ bezeichnet wird. Dabei werden die Erfahrungen der Teilnehmer ausgetauscht und
ausgewertet.
3.6 Vorteile der Verwendung von Planspielen

Die bedeutendsten Vorteile, die die Verwendung von Planspielen mit sich bringen, werden in den
Folgenden Punkten dargestellt:
- Der Einsatz von Planspielen fördert die Motivation: In der Planspielliteratur gilt es als
unbestritten, dass bei Teilnehmern und auch Leitern von Planspielen, bereits vor Beginn des
Planspiels, die Motivation groß ist. Dies wird als „Eingangsmotivation“ bezeichnet. Auch in der
Durchführungs- und Auswertungsphase ist das Engagement der Beteiligten höher als bei
42
herkömmlichen Unterrichtsmodellen. “Neben dem Neuheitseffekt werden als erklärende
Faktoren insbesondere die Konkurrenz- und Wettbewerbssituation, die Zielgerichtetheit des
Vorgehens sowie die Eigenaktivität der Lernenden herangezogen, die zu Lern- und
43
Leistungsmotivation, Lernfreude, Interesse und Spaß am Lernen beitragen.“
- Planspiele fördern den Erwerb von Schlüsselqualifikationen wie die Planungs- und
Entscheidungsfähigkeit, die Handlungsfähigkeit und Kritikfähigkeit, sowie das
40
Eigene Abbildung in Anlehnug an Ulrich, (2002)
41
Ulrich, (2002), S.2
42
Vgl. Rebmann (2001), S.30
43
18
Problemlöseverhalten. Daneben werden durch die Bearbeitung des Planspiels in Teams, vor
allem während der Gruppenarbeitsphasen, Sozialkompetenzen wie Kommunikations-,
44
Kooperations-, und Teamfähigkeit gefordert und gefördert.
- Durch das Lernen am Modell wird auf interaktive Weise gelernt. Die Teilenehmer agieren in
einem Umfeld mit starkem Realitätsbezug, das zeitlich gerafft und jederzeit wiederholbar ist.
Da sich die Zyklen eines Planspiels wiederholen, erhalten die Teilnehmer Feedback zu ihren
getroffenen Entscheidungen und können aus diesen Erfahrungswerten lernen. Gerade bei IT-
basierten Planspielen kann zusätzlich der Umgang mit einer Technologie oder einem
45
Programm eingeübt werden.
- Planspiele fördern den Wissenserwerb. Zur erfolgreichen Bewältigung eines Planspiels muss
Wissen erworben und sinnvoll angewendet werden. Daher ist es notwendig, Zusammenhänge
zu erkennen und zu verstehen. Es wurde empirisch belegt, dass sich in Planspielen
erworbenes Wissen stärker und länger einprägt und dass komplexe Sachverhalte und
46
Problemlösungen vereinfacht vermittelt werden können.
- Planspiele unterstützen eine selbstorganisierte und praxisorientierte Lernkultur. Diese

Lernkultur basiert auf Lernen durch Erfahrung. Die Teilnehmer handeln in einer realen und
komplexen Umgebung. Diese authentischen und realitätsnahen Situationen kreieren
47
Erlebnisse und lehren durch Erfahrungen.
- Da die Aufgaben eines Planspiels meist in Gruppen bewältigt werden müssen, fördern sie die
Teamfähigkeit der Teilnehmer. Dabei stellt neben dem Treffen von Entscheidungen auch die
48
Kommunikation eine bedeutende Rolle.
- Planspiele bieten den Vorteil, Probehandeln, Experimente und gewagte Aktionen zu erlauben.
Vor allem aber können Entscheidungen gefällt werden, deren Konsequenzen in der Simulation
zwar gespürt werden, aber ohne großen Schaden bleiben. Gerade dieses Probehandeln
gewährleistet einen großen Vorteil bezüglich des Lerneffekts im Vergleich zu anderen
49
Methoden.
44
45
46
47
48
49
19
- Durch die realitätsnahe Simulation von Prozessen werden Relevante Faktoren und
Dynamiken spezifischer Umwelten für den Teilnehmer erlebbar. Die Phasen, die während der
Bearbeitung eines Planspiels durchlaufen werden, korrespondieren mit den Phasen des
Lernprozesses: Aktives experimentieren - Erfahrungen sammeln - Reflexion über sachliche
und gruppendynamische Aspekte des Erlebten - Generalisierung und Formulierung von
Konsequenzen. Durch die Wiederholung dieser Phasen in jeder Periode des Planspiels
50
werden die Erlebnisse und gewonnenen Erkenntnisse vertieft.
- In Planspielen entsteht Wissen nicht durch die kognitive Verarbeitung äußerer Reize, sondern
als aktive Konstruktion, die innerhalb einer Gruppe vollzogen wird. Ein Vorteil davon ist, dass
die Teilnehmer generiertes Wissen aktiv anwenden müssen und die Resultate aus ihren
Handlungsweisen anschließend analysieren. Des Weiteren werden die Vor- und Nachteile
einzelner Entscheidungen in der Gruppe diskutiert bevor sie verabschiedet werden, was für
die Teilnehmer den Austausch von Perspektiven bedeutet. Auch die Tatsache, dass eine
Reihe verschiedener Szenarien in denen verschiedene Rollen angenommen werden können
51
durchgespielt werden, steigert die Perspektivenvielfalt.
- Gerade Im Bereich der Entwicklung von Problemlösefähigkeiten innerhalb einer Gruppe ist es
wichtig, dass Fehler begangen werden dürfen. Planspiele stellen fehlerfreundliche Umwelten
dar, in denen die Konsequenzen harmlos bleiben. Dadurch können Erfahrungen ohne Risiko
52
gesammelt werden.
Ein weiterer positiver Aspekt von Planspielen ist, dass alle bisher genannten Vorteile auf
53
spielerische Art erzielt werden.
3.7 Arten von Planspielen
In der Literatur finden sich die verschiedensten Ansätze zur Klassifizierung von Planspielen. Als
Grundlage für die Klassifizierung dienen beispielsweise die Unterscheidung nach dem
Verwendungszweck (Forschung, Planung, Entscheidung, Prognose, Theoriebildung und Lehre),
die Unterscheidung nach dem zugrundeliegenden Inhaltsbereich (militärische, ökonomische,
ökologische, politische, technische, naturwissenschaftliche und Verwaltungsspiele), oder auch die
54
Unterscheidung nach den Adressaten (Schüler, Studierende und Arbeitnehmer). Obwohl die
Typisierungsansätze teilweise als wenig aussagekräftig beurteilt werden, da sie in der Regel nicht
überschneidungsfrei sind und meist kein Zusammenhang zwischen den einzelnen Typen besteht,
50
51
52
53
54
Vgl. Rebmann (2001); S. 17
20
55
bieten sie doch einen gewissen Grad an Transparenz bei der Vorauswahl von Planspielen. Da
sich diese Arbeit mit der betriebswirtschaftlichen Lehre auseinandersetzt, werden im Folgenden
Unterscheidungsmerkmale ökonomischer Planspiele erläutert.
3.7.1 Unterscheidungsmerkmale ökonomischer Planspiele
Ökonomische Planspiele können unter anderem nach dem abgebildeten betrieblichen Umfang,
dem Konkretisierungsgrad, der Interaktion zwischen den Teilnehmergruppen, der Determiniertheit
des Modells, der Regelgebundenheit, der Zusammensetzung der Spielgruppen, der Nutzung
rechnerischer Hilfsmittel und der Komplexität des verwendeten Modells differenziert werden. Auf
Grund der großen Anzahl der Konstellationsmöglichkeiten der Ausprägungen dieser Kriterien ist
eine Vielzahl von möglichen Planspielen denkbar. Allerdings kann unter Umständen nicht jedes
Planspiel anhand jedes Kriteriums eindeutig klassifiziert werden. Als Grundlegende
Klassifizierungskriterien sind die im Folgenden beschriebenen Unterscheidungsmerkmale jedoch
nützlich.
3.7.1.1 Betrieblicher Umfang
Unternehmensplanspiele lassen sich nach dem Umfang der abgebildeten Unternehmensbereiche

unterscheiden. Generelle Planspiele bilden ein Unternehmen mit seinen wesentlichen
Teilbereichen als Ganzes ab und vermitteln dadurch betriebswirtschaftliche Zusammenhänge und
Interdependenzen zwischen den betriebsinternen Abteilungen sowie zwischen Unternehmen und
Beschaffungs- bzw. Absatzmärkten. Spezielle Planspiele hingegen konzentrieren sich auf die
Darstellung eines ausgewählten Unternehmensbereichs. Dieser wird detailliert behandelt, um den
Teilnehmern bei der Aus- und Weiterbildung in Spezialgebieten zu dienen. Beide Formen sind
sowohl für die betriebliche als auch die schulische und universitäre Aus- und Weiterbildung
56
geeignet. Die Auswahl hängt von den verfolgten Ausbildungszielen ab.
3.7.1.2 Konkretisierungsgrad
Es gibt Planspiele die mit anonymen Erzeugnissen, Materialien und Märkten arbeiten, die für
verschiedene Branchen anwendbar sind. Diese werden als abstrakte Modelle bezeichnet und
finden hauptsächlich in der Ausbildung an Berufsbildenden Schulen und Universitäten
Verwendung, da sie allgemeingültige Kenntnisse und Fertigkeiten vermitteln die dann auf spezielle
Branchen übertragen werden können. Allerdings ist zu bemerken, dass eine allgemeine
Modellformulierung das Verständnis und das Vorstellungsvermögen für den Modellbertrieb
anfänglich erschweren kann. Konkrete Modelle auf der anderen Seite sind realitätsnäher, da sie
das abgebildete Unternehmen mit Produkten, Materialien und Märkten sowie die Daten und
55
Vgl Rebmann (2001); S.18
56
Vgl. Orth, (1999); S.18
21
Problemstellung konkret beschreiben. Das hat die Vorteile, dass sich der Teilnehmer mehr unter
dem Modell vorstellen kann und auf branchenspezifische Eigenschaften ausführlicher eingegangen
werden kann. Konkrete Planspiele werden vermehrt in der betrieblichen Aus- und Weiterbildung
verwendet, mit dem Ziel, die Teilnehmer erworbene Kenntnisse und Fähigkeiten direkt in einem
57
realen Betrieb umsetzten lassen zu können.
3.7.1.3 Interaktion zwischen Teilnehmergruppen
Allgemein können Planspiele mit nur einer Planspielgruppe (Soloplanspiele) von solchen bei denen
mehrere Gruppen in Konkurrenz zueinander stehen (Konkurrenzplanspiele) unterschieden werden.
Letztere wiederum werden in interaktive Planspiele, bei denen die Entscheidungen einer Gruppe
Einfluss auf das Ergebnis der Entscheidung der anderen Gruppen haben und nicht-interaktive bzw.
isolierte Modelle, bei denen die Entscheidungen der Gruppen keinen Einfluss auf die Konkurrenz
haben, unterteilt. Konkurrenzplanspiele scheinen einen positiven Effekt auf die Lernmotivation und
das Engagement der Teilnehmer zu haben, was durch eine interaktive Gestaltung, bei der gute
Entscheidungen einen positive Einfluss auf das eigene, und negativen Einfluss auf das
58
Betriebsergebnis der Konkurrenz hat, verstärkt wird.
3.7.1.4 Determiniertheit des Modells
Nach diesem Kriterium werden deterministische und stochastische Modelle unterschieden. Treffen
die Teilnehmer ihre Entscheidungen unter Sicherheit und mit einem eindeutigen Zusammenhang
zwischen Entscheidung und Ergebnis, so handelt es sich um ein deterministisches Modell. Selbst
bei diesen können für die Teilnehmer Unsicherheiten auftreten, die sich aus der Komplexität des
Modells und der daraus resultierenden Intransparenz der Entscheidungssituation ergeben.
Zusätzlich beeinflussen bei interaktiven Planspielen die Entscheidungen der Konkurrenz die
Eigenen, was auch als Unsicherheit der Resultate der eigenen Entscheidungen betrachtet werden
kann.
Stochastische Modelle verwenden von vorn herein Zufallselemente wie zum Beispiel
Abweichungen der Lieferzeiten oder Mitarbeiterstreiks. Es sollte darauf geachtet werden, dass
nicht zu viele Zufallselemente den Spielverlauf prägen, da das gesamte Planspiel ansonsten als
Glücksspiel empfunden wird. Dies würde sich negativ auf die Lernmotivation und den
59
Ausbildungserfolg auswirken.
57
Vgl. Orth (1999); S.19
58
Vgl. Orth (1999); S.20
59
Vgl. Orth (1999); S.21
22
3.7.1.5 Regelgebundenheit
Starre Modelle lassen den Teilnehmern bei der Entscheidungsfällung nur die Auswahl zwischen
vorgegebenen Variablen und zu welchem Zeitpunkt wie viel bestellt, produziert, vertrieben oder
ähnliches werden soll. Dies kann bei einem längeren Spielverlauf zu einer Standardisierung des
Entscheidungsprozesses führen, was wiederum die Motivation und den Lerneffekt vermindert.
Durch die Ergänzung um freie Spielelemente, die der subjektiven Beurteilung der Spielleitung
unterliegen, kann die Entscheidungsphase offener und kreativer gestaltet werden. Diese werden
60
freie Modelle genannt.
3.7.1.6 Zusammensetzung der Spielgruppen
Zumeist werden Planspiele in Gruppen bearbeitet, da dies durch die Zusammenarbeit der
Teilnehmer nicht nur die Qualität ihrer Entscheidungen, sondern auch soziale Kompetenzen wie
Kooperationsfähigkeiten und Kommunikationsfähigkeiten gefördert werden. Aber auch die
61
Variante, ein Planspiel von einzelnen Personen bearbeiten zu lassen, besteht.
3.7.1.7 Nutzung rechnerischer Hilfsmittel
Planspiele können auch nach der Verarbeitung der Planspielinformationen und –daten differenziert
werden. Bei sogenannten Handspielen werden die Daten mit Hilfe von Taschenrechnern, Tabellen
und Diagrammen händisch ermittelt. Bei Maschinenspielen hingegen übernimmt der Computer die
Kalkulation der Daten. Dies hat den Vorteil, dass auch komplexere Modelle verwendet werden
können, ohne dass die Berechnung zeitaufwendig oder fehleranfällig wäre. Ein weiterer Vorteil von
Planspielen, die am PC durchgeführt werden, ist dass die Resultate sehr anschaulich mit Hilfe von
62
Diagrammen veranschaulicht werden können.
3.7.1.8 Komplexität des Modells
Die Komplexität eines Planspiels ist abhängig von der Anzahl der Variablen und den
Verknüpfungen zwischen ihnen. Bei der Auswahl eines Planspiels ist daher darauf zu achten, dass
die Komplexität in einer vernünftigen Relation zum Wissensniveau der Teilnehmer steht. Planspiele
bei denen die Komplexität verändert werden kann, haben den Vorteil dass sie für verschiedene
Wissensniveaus verwendet werden können und auch mit wachsender Erfahrung der Teilnehmer
63
an Komplexität zunehmen können.
60
Vgl. Orth (1999); S.21
61
Vgl. Orth (1999); S.22
62
Vgl. Orth (1999); S.23
63
Vgl. Orth, (1999); S.24
23
3.7.2 IT-basierte Planspiele
IT-basierte Planspiele unterschieden sich von anderen Planspielen lediglich dadurch, dass sie auf
Computern entwickelt wurden und auch auf ihnen durchgeführt werden. Diese Art der Planspiele
hat mit der Zugänglichkeit von PCs stark an Bedeutung gewonnen. IT-basierte Planspiele fallen
unter die Rubrik des „Computer Assisted Learning“ (CAL). Bei CAL-Planspielen steht der
64
Lernaspekt in Bezug auf einen analytischen Denkstil im Vordergrund . Rebmann nennt die
65
folgenden positiven Aspekte bei der Verwendung von PCs zur Durchführung von Planspielen:
- Entscheidungen sind sofort und beliebig oft wiederholbar
- Die Ergebnisse der Entscheidungen können sofort überprüft werden.
- Eine große Speicherkapazität steht zur Verfügung
- Das System ist jederzeit verfügbar
- Der PC bietet zusätzliche Werkzeuge und Funktionen die bei der Planung genauso wie der
Präsentation der Ergebnisse hilfreich sein können
- Es besteht eine Vernetzungsmöglichkeit mit Datenbanken und Multimediatechniken
- Abstrakte und komplexe Zusammenhänge können veranschaulicht werden
- PCs an sich bewirken eine gewisses Motivationspotential
- Man kann risikolos und kostengünstig Probehandeln
- Es besteht die Möglichkeit der Prozessanalyse
- Feedbackoptionen können benutzt werden
- Der Spielverlauf wird dokumentiert
- Der Teilnehmer hat die Möglichkeit spielerisch und risikofrei mit neuen Technologien
umzugehen
4 Auswahl Planspiel und ERP System

Ziel dieser Diplomarbeit ist es, zwei Programme auf eine Weise zu verknüpfen die es ermöglicht,
Studenten den Produktionsprozess näher zu bringen. Dazu wurden ein ERP-System und ein
Planspiel ausgewählt. Die Anforderung an beide Systeme war, dass sie eine gemeinsame
Schnittstelle unterstützen, die den Datenaustausch gewährleistet. Des Weiteren muss es möglich
sein, die Prozesse des einen Systems im Anderen abzubilden. Die beiden Systeme, die diesen
Anforderungen entsprechen, sind SCSim und Semiramis. Beim ersten handelt es sich um ein
Planspiel welches die SupplyChain simuliert. Von den Teilnehmenden wird verlangt, Beschaffung
und Produktion möglichst effizient zu gestalten um ihre produzierten Güter gewinnbringend am
Markt zu vertreiben. SCSim unterstützt XML sowohl für den Datenimport als auch Export.
Zusätzlich ist zu erwähnen, dass eine Kooperation zwischen der Leopold Franzens Universität
Innsbruck und der Hochschule Karlsruhe für Technik und Wirtschaft besteht, welche das Planspiel
entwickelt hat.
64
Vgl. Grob H., Grießhaber W., (1995); S. 6
65
24
Semiramis ist ein ERP-System, welches einerseits erlaubt, die von SCSim vorgegebenen
Prozesse abzubilden und andererseits Schnittstellen für den Datenaustausch mittels XML
66
vorgesehen hat. Ein weiterer bedeutender Grund für die Verwendung diese ERP-Systems ist die
vollständig Internet-kompatible Architektur. Das bedeutet, dass alle Anwendung über URLs
addressiert werden. Somit ist auf der Client-Seite keine Installation notwendig, alles was benötigt
67
wird ist ein Interzugang und ein Browser. Dies ist für die Verwendung in der Lehre optimal.
Weiters sind die Entwickler von Semiramis um die Benutzerfreundlichkeit bemüht. Oberster
Grundsatz ist die Abstimmung auf den Benutzer, der sich möglichst intuitiv im System zurecht
68
finden soll. Eine Studie der Universität Innsbruck belegt die überlegene Performance von
Semiramis gegenüber eines Konkurrenzproduktes gemessen an der empfundenen
69
Benutzerfreundlichkeit der Anwender.
Beide Systeme werden im Folgenden beschrieben.
4.1 Auswahl ERP
Semiramis ist eine ERP-Lösung die speziell für Klein- und Mittelbetriebe entwickelt wurde. Das
70
Produkt ist seit etwa vier Jahren auf dem Markt und wird von über 220 Unternehmen verwendet.
Die Cross Industrie Software AG aus Hannover hat zusammen mit der österreichischen KTW
Software und Consulting GmbH das komplette System in Java umgesetzt. Das Ergebnis ist ein
Produkt, das sich ausschließlich im Browser bedienen lässt und somit eine Grundvoraussetzung
II
für ein ERP -System erfüllt. Heute liegen die Entwicklung, Vermarktung und Partnerbetreuung in
den Händen der SoftM Semiramis GmbH & Co. KG mit Sitz in Hannover. Das Unternehmen ist
71
eine 100%-ige Tochter der SoftM Software und Beratung AG. Die Client-Server-Kommunikation
erfolgt über HTTP (Hypertext Transfer Protocol), was dem Anwender gewohnte Bedienhilfen wie
Drag and Drop und die Anzeige von Kontextmenüs erlaubt.
66
Vgl. Gumbel (2005); S.20
67
Vgl. Gümbel (2005); S.16
68
Vgl. Gümbel (2005); S.16
69
Vgl. Hinterhuber, Promberger, Piazolo (2006)
70
Vgl. http://www.openpr.de/pdf/187283/Semiramis-und-Partner-auf-der-CeBIT-2008-Halle-5-C16-Semiramis-4-4-und-
Branchenloesungen.pdf (17.1.2009)
71
Vgl. http://www.openpr.de/pdf/187283/Semiramis-und-Partner-auf-der-CeBIT-2008-Halle-5-C16-Semiramis-4-4-und-
Branchenloesungen.pdf (17.1.2009)
25
72
Abbildung 3: Systemarchitektur von Semiramis
Das System weist den für ERP-System typischen modularen Aufbau auf. Die einzelnen
Frameworks setzen auf einer System Engine mit integriertem Web-Server auf. Die Semiramis
Engine ist mit Oracle-Software, IBMsDB2 und Microsofts SQL kompatibel. Die Datenbank, hier in
grün dargestellt, ist in einen Bereich für Systemkonfiguration (Administration), ein Repository für
Entwicklerdaten, eine OLTP Engine (Online Transaction Processing) für Stammdaten und
Bewegungsdaten sowie einen Olap-Server (Online analytical Processing) für statistische
Informationen unterteilt73
Alle Semiramis Applikationen sind wie ein Web-Server über URL`s (Uniform Resource Locator)
erreichbar. Somit ist das System für den Anwender überall erreichbar und am Client-PC werden so
gut wie keine Ressourcen beansprucht. Die Anwendung der Software können über COM, CORBA
(Common Object Request Broker Architecture), oder Soap (Simple Object Access Protocol) mit
Fremdanwendungen gekoppelt werden. Des Weiteren erlaubt Semiramis den Datenaustausch für
systemübergreifende Geschäftsprozesse durch XML (Extensible Markup Language) und EDI
(Electronic Data Interchange).74
4.2 Auswahl Planspiel
SupplyChainSimulation ist ein von der Hochschule Karlsruhe für Technik und Wirtschaft
entwickeltes, rechnergestütztes Planspiel. Es fordert von den Teilnehmern, die wesentlichen
72
Aus: http://www.semiramis.com/semiramis/servlet/pages/de/19068;jsessionid=BFE56A14A91222358306DB8F5688D16E
73
Vgl. Computerwoche, März 2003; Java-ERP Semiramis startet durch (18.1.2009)
74
Vgl. Computerwoche, März 2003; Java-ERP Semiramis startet durch (18.1.2009)
26
Probleme bei der Steuerung der industriellen Produktion zu lösen. Dabei müssen Aufträge für die
Beschaffung und Produktion erteilt werden, sowie die Produktionskapazitäten optimiert werden.
Ziel ist es, den gesamten Produktionsprozess so zu gestalten, dass das Betriebsergebnis am Ende
möglichst optimal ist.
Das Hauptaugenmerk liegt auf der Planung und Steuerung des Produktionsprozess, weswegen die
Bereiche Entwicklung, Marketing und Vertrieb, das Personalwesen sowie Finanzierung und
Investitionsentscheidungen bewusst nicht berücksichtigt werden. So gut wie alle unter Punkt „4.3
Auswahl Planspiel“ aufgeführten Beschreibungen sind dem auf der Internetseite http://www.iwi.hs-
karlsruhe.de/scs/start verfügbaren Handbuch entnommen.
4.2.1 Überblick
Der Modellbetrieb produziert Kinder-, Damen- und Herrenfahrräder welche zum Einen aus
Eigenfertigungsprodukten und zum Anderen aus Kaufteilen gefertigt werden. Die Produkte sowie
die Produktionsstruktur und der Ablauf sind im Modell vorgeschrieben und können nicht verändert
werden. Der Betrieb besteht aus 14 Arbeitsplätzen und einem Lager. Zu Beginn einer
Planspielrunde hat das Lager von allen Kaufteilen einen bestimmten Vorrat, der jedoch nicht als
Ideallagerbestand gesehen werden kann.
Für Planung, Disposition und Steuerung des Betriebsablaufs stehen den Teilnehmern folgende
Informationen zur Verfügung:
- Stücklisten für die drei Enderzeugnisse (Struktur- und Mengenstücklisten)
- Fertigungspläne mit Rüst- und Fertigungszeiten
- Arbeitsplatzdaten (Kapazität und Platzkosten)
- Teilestammdaten Anhang mit Ident-Nummer, Bezeichnung, Wert, Anfangsbestand; für
Kaufteile sind zusätzlich Wiederbeschaffungszeit, Bestellkosten, Normal- und
Diskontpreise sowie Diskontmengen angeben
- Der Primärbedarf (Vertriebswunsch) für die drei Enderzeugnisse wird von der Spielleitung
für die jeweils nächste Periode in verbindlicher Form vorgegeben; für einige Folgeperioden
werden Prognosen veröffentlicht
Auf Basis des Primärbedarfs muss entschieden werden, welche Materialien in welcher Menge
beschafft werden, welche Halbfabrikate und Endprodukte in welcher Menge produziert werden und
welche Kapazitäten dafür benötigt und bereitgestellt werden. Dies geschieht unter
Berücksichtigung von Lagerbeständen, erwarteten Lieferungen, prognostizierter Nachfrage und mit
dem Ziel, das Betriebsergebnis, die Liefertreue, die Durchlaufzeiten, Auslastung und Herstellkosten
zu optimieren.
27
75
Abbildung 4: Elemente des Fertigungsbetriebs
4.2.2 Ablauf
Das Planspiel ist in mehrere Perioden unterteil die jeweils einer Arbeitswoche entsprechen. Die
Teilnehmer führen in Gruppen einen eigenen Modellbetrieb, der unabhängig von den anderen
Gruppen wirtschaftet und keinen Einfluss auf den Ablauf und die Ergebnisse der anderen hat.
Entscheidungen werden jeweils zu Beginn einer Planperiode für die gesamte Periode festgelegt
und über die Internetseite www.scsim.de eingegeben. Während der Periode kann in den
Produktionsablauf nicht mehr eingegriffen werden.
Zu Beginn wird von der Spielleitung der Primärbedarf für die erste Periode, sowie Prognosen für
die darauffolgenden Perioden, angegeben. Auf Basis der Nachfrage und den oben genannten
Informationen wie Stücklisten, Fertigungspläne, Arbeitsplatzdaten und Teilestammdaten können
die Teilnehmer berechnen, was in welcher Periode produziert und beschafft werden muss.
Beschaffungsaufträge werden anhand des Primärbedarfs für die laufenden Periode und dem
prognostizierten Bedarf für die folgenden Perioden ermittelt. Dabei ist auf die Lieferzeit und die
Lieferzeitschwankungen zu achten um die benötigten Teile mengen- und termingerecht verfügbar
zu haben.
Fertigungsaufträge werden in diesem Modellbetrieb nicht als Ganzes sonder in Losgrößen von
jeweils 10 Stück abgearbeitet. Dies verkürzt die Durchlaufzeit und erleichtert die Planung.
Die Kapazitäten sind für jede Periode anpassbar. Jeder Arbeitsplatz ist mindestens 8 Stunden pro
Arbeitstag besetzt, kann aber durch Überstunden und Schichtbetrieb auf bis zu 24 Stunden
75
SCSim Handbuch (2008); S. 4
28
ausgebaut werden. Die Kapazitäten sind für jeden Arbeitsplatz einzeln definierbar, ohne Rücksicht
auf andere Arbeitsplätze, aber für die gesamte Woche bzw. Periode gleich.
Folgende Abbildung vermittelt einen Überblick über alle Arbeitsplätze und den gesamten
Fertigungsprozess. Jeder Arbeitsplatz ist, anders als in Abbildung 5 zu sehen, nur einmal
vorhanden. Es ist zu beachten, dass nur Teile und Halbfabrikate, die in der Abbildung eine
Bezeichnung haben, auch gelagert werden können. Teile und Baugruppen ohne Bezeichnung
werden von Arbeitsplatz zu Arbeitsplatz direkt weitergegeben und können nicht aus dem Lager
bezogen werden.
76
Abbildung 5: Fertigungsdurchlauf
Im Fertigungsdurchlaufplan ist zu sehen, welche Materialen und Kaufteile benötigt werden und
welche Eigenfertigungsprodukte produziert werden. Es gibt für jedes der drei Endprodukte einen
eigenen Fertigungsdurchlaufplan aus dem die Einzelfertigungszeiten und Rüstzeiten ersichtlich
sind.
Am Ende jeder Periode stehen den Teilnehmern mehrere Tabellen über die Ergebnisse ihres
Modellbetriebs zur Verfügung, anhand derer sie analysieren können, wie gut ihre Planung und ihr
Erfolg war.
Die Kosten für die gesamte Produktion errechnen sich aus:
- Materialkosten: Normal- oder Diskontpreise; anteilige Bestellkosten
- Maschinenkosten: Kostensatz je Maschine; Fertigungs- und Rüstzeiten je Arbeitsplatz
- Lohnkosten: Kostensatz je Mitarbeiter bei Normalschicht, 2./3. Schicht oder Überstunden,
Fertigungs- und Rüstzeiten je Arbeitsplatz
76
SCSim Handbuch; S. 6
29
- Lagerkosten: durchschnittlicher Lagerwert; Lagerkostensatz
- Leerkosten: Leerzeiten je Arbeitsplatz; Maschinen- und Lohnkostensatz je Arbeitsplatz
- Ausschusskosten
- Konventionalstrafen
Aus den durchschnittlichen Herstellkosten, einem vorgegebenen Verkaufspreis von € 200,00 für
jeden Fahrradtyp und dem erzielten Absatz wird das Ergebnis der Normalaufträge berechnet. Für
Direktverkäufe der drei Enderzeugnisse errechnet sich das Ergebnis aus einem einzugebenden
Verkaufspreis, den Herstellkosten der Vorperiode und der abgesetzten Menge. Wurde eine
Konventionalstrafe bei Nichtlieferung bzw. Teillieferung von Direktverkäufen vereinbart, so wird
diese auf der Basis der nicht gelieferten Teile berechnet, in der Ergebnisliste ausgewiesen und in
den Ergebnissen aus Direktverkäufen verrechnet.
4.2.3 Planung und Disposition im Modellbetrieb
Um möglichst effizient zu wirtschaften müssen die Teilnehmenden versuchen, ihre Lagerbestände

zu minimieren und trotzdem eine hohe Liefertreue zu erzielen. Dazu gilt es mehrere Parameter zu
beachten, was im Folgenden erläutert wird.
4.2.3.1 Zielplanung
Um den Erfolg einer Planperiode messen zu können, sollen vor der Periode die folgenden Größen
kalkuliert werden damit am Ende der Periode die Soll- mit den Ist-Werten verglichen werden
können:
- Liefertreue: der Quotient aus der Gesamtmenge der gelieferten Endprodukte und dem
Primärbedarf aller Endprodukte
Liefermengen (P1 + P2 + P3)
‫= ݁ݑ݁ݎݐݎ݂݁݁݅ܮ‬
Primärbedarf (P1 + P2 + P3)
- Durchlaufzeit: Dauer von Beginn eines Auftrages in der Fertigung bis zum
Fertigstellungszeitpunkt
- Kapazitätsauslastung: Der Quotient aus produktiv genutzter Kapazität und bereitgestellter
Kapazität
produktiv genutze Kapazität
‫ݐ݅ݖܽ݌ܽܭ‬ä‫= ݃݊ݑݐݏ݈ܽݏݑܽݏݐ‬
bereitgestellte Kapazität
- Bestandsvolumen: Durchschnittlicher Lagerwert
- Herstellkosten: Durchschnitt der Herstellkosten der drei Endprodukte
- Betriebsergebnis: Differenz aus Umsatz und Aufwand
30
4.2.3.2 Primärbedarf
Der Primärbedarf, also die Menge an Endprodukten die am Ende der Planperiode verkauft werden
soll, wird von der Spielleitung vorgegeben. Dabei sind die Stückzahlen für die kommende Periode
exakt und verbindlich, für die Folgeperioden nur Prognosen. Der Vertriebswunsch gilt als erfüllt und
die Liefertreue 100 prozentig, wenn innerhalb der jeweiligen Periode die geforderten Stückzahlen
aus dem Lager entnommen werden können.
Kann bis zum Ende der Periode nicht die gesamte Nachfrage gedeckt werden, verringert sich der
Vertriebswunsch für die folgende Periode im Verhältnis der verringerten Liefertreue, jedoch
maximal um 50%.
Nicht gelieferte Stückzahlen gehen nicht verloren, sie sollen vielmehr in der folgenden Periode
zusätzlich zum neuen Vertriebswunsch produziert und geliefert werden.
Das folgende Beispiel verdeutlicht die Berechnung des Primärbedarfs, nachdem in der Vorperiode
eine nicht 100 prozentige Liefertreue erreicht wurde.
Periode 3 P1 P2 P3 Summe
Vertriebswunsch 200 100 200 500
Gelieferte Menge 150 100 150 400
Lieferfähigkeit 75% 100% 75% 80%
Lieferrückstand 50 0 50 100
77
Tabelle 1: Liefertreue in Periode 3
Periode 4 P1 P2 P3 Summe
Vertriebswunsch 200 100 100 400
Reduzierter Vertriebswunsch 150 100 70 320
Rückstand aus Periode 3 50 0 50 100
Zu liefern in Periode 4 200 100 120 420
78
Tabelle 2: Liefertreue in Periode 4
4.2.3.3 Dispositive Entscheidungen
Aus dem durch die Spielleitung vorgegebenen Vertriebswunsch und den Prognosen ergibt sich der
Absatzplan des Modellbetriebes. Auf Basis dieses Absatzplanes lässt sich, unter Berücksichtigung
der Kapazitäten, ein Produktionsprogramm erstellen. Dieses legt fest, welche Endprodukte, in
welcher Periode, in welcher Menge produziert werden. Egal nach welcher Methode man vorgeht
um das Produktionsprogramm festzulegen, liefert es die Grundlage für Entscheidungen bezüglich
Beschaffungsaufträgen, Produktionsaufträgen und Produktionskapazitäten.
77
Eigene Darstellung in Anlehnung an SCSim Handbuch (2008); S.12
78
Eigene Darstellung in Anlehnung an SCSim Handbuch (2008); S.12
31
4.2.3.3.1 Disposition (Beschaffung)
Ausgehend vom Primärbedarf kann der Bedarf an Kaufteilen und Halbfabrikaten durch stufenweise
Auflösung der Stücklisten ermittelt werden. Dabei werden auch Lagerbestände und bereits
laufende Produktions- und Beschaffungsaufträge berücksichtigt.
Der entscheidende Faktor bei der Beschaffung von Kaufteilen ist die Wiederbeschaffungszeit
(WBZ), also die Zeit zwischen der Bestellung, dem ersten Tag der Periode, und dem Tag des
Lagereingangs. Die Wiederbeschaffungszeit wird in Vielfachen einer Periode angegeben und
schwankt.
Beispiel: Wiederbeschaffungszeit = Mittelwert + Abweichung
WBZ(K58) = 1,6 ± 0,5 Perioden
WBZ(K58) = 8 ± 2,5 Tage
Zu beachten ist zusätzlich dass ein Kaufteil erst am Folgetag des Lagereingangs für die Produktion
verwendet werden kann. Bei der Ermittlung der Lieferzeitabweichung wird angenommen, dass die
Häufigkeitsverteilung der unterschiedlichen Lieferzeiten einer Normalverteilung entspricht. Daraus
ergibt sich, dass mit einer Wahrscheinlichkeit von 86% die Lieferzeit im Bereich Mittelwert ±
Abweichung liegt. Weder die Bestellmenge, noch die Reihenfolge der Eingabe der
Beschaffungsaufträge haben Einfluss auf die Lieferzeit.
Für alle Kaufteile können Eilaufträge eingegeben werden. Diese liefern in der Hälfte der
angegebenen Lieferzeit ohne Abweichung, kosten jedoch das zehnfache eines normalen Auftrages
an Bestellgebühren.
32
79
Abbildung 6: Lieferzeit
4.2.3.3.2 Disposition (Eigenfertigungsprodukte)

Da durch die Erzeugung eines Produktionsauftrages für ein Endprodukt, nicht automatisch eine
Auflösung der Stückliste erfolgt, die für alle Unterstufen Produktionsaufträge auslöst, muss in jeder
Periode entschieden werden, ob für ein bestimmtes Produkt bzw. Halbfabrikat, ein
Fertigungsauftrag zu starten ist und wenn ja, in welcher Menge. Auch die zur Verfügung stehenden
Kapazitäten müssen wiederum berücksichtigt werden
Die Reihenfolge, in der die Fertigungsaufträge eingegeben werden, bestimmt auch die Reihenfolge
der Bearbeitung. Für einen Artikel können auch mehrere Fertigungsaufträge in derselben Periode
veranlasst werden, falls es den Teilnehmern sinnvoll erscheint. Da viele Produkte dieselben
Arbeitsplätze durchlaufen bilden sich Warteschlangen, die in der Reihenfolge ihrer Eingabe, bzw.
ihrer Ankunft vom vorherigen Arbeitsplatz abgearbeitet werden. Sind für einen Fertigungsauftrag
an einem Arbeitsplatz nicht ausreichend Materialien vorhanden, so wird er in 10er Losen
abgearbeitet, bis das Material ausgeht. Ist von Anfang an nicht genug Material vorhanden um 10
Stück zu bearbeiten wird der nächste Fertigungsauftrag in der Reihe vorgezogen. Dies wiederholt
sich sooft, bis das benötigte Material für den ersten Produktionsauftrag eintrifft.
Während der Planperiode kann die Reihenfolge der Fertigungsaufträge nicht mehr beeinflusst
werden.
79
SCSim Handbuch (2008); S.21
33
Materialen die für ein Produkt an einem und den folgenden Arbeitsplätzen benötigt werden sind für
dieses Produkt weder aus dem Lager bezogen, noch reserviert. Ist ein Produkt an der Reihe
produziert zu werden, werden jeweils die nötigen Unterstufen, die gebraucht werden um eine
Teilmenge des Fertigungsauftrages von 10 Stück herzustellen, aus dem Lager bezogen. Damit
wird verhindert, dass ein Auftrag alle Teile reserviert und somit andere Fertigungsaufträge
behindert.
Für die Bearbeitung eines Auftrags sind drei Bedingungen zu erfüllen:
- Er muss an erster Position der Warteschlange liegen,
- Für mindestens eine Teilmenge von 10 Stück müssen die nötigen Unterstufen im Lager
sein,
- Der Arbeitsplatz muss freie Kapazitäten haben.
4.2.3.4 Kapazitäten
Anhand der Fertigungsaufträge für Eigenfertigungs- und Endprodukte lässt sich für jeden
Arbeitsplatz ein Kapazitätsbedarf ermitteln. Die Kapazitäten der einzelnen Arbeitsplätze müssen
dieser Nachfrage angepasst werden um die Bearbeitung aller Aufträge zu ermöglichen.
Für jeden Arbeitsplatz sind für jedes Produkt, das dort gefertigt wird, verschiedene Rüst- und
Fertigungszeiten vorgegeben. Somit lässt sich der Kapazitätsbedarf exakt ermitteln. Falls aus der
Vorperiode noch Aufträge an diesem Arbeitsplatz abzuarbeiten sind, müssen diese ebenfalls
berücksichtigt und zum Bedarf addiert werden. Der so errechnete Kapazitätsbedarf stellt den
Mindestbedarf dar, da durch unvermeidliche Leerzeiten eine kontinuierliche Nutzung des
Arbeitsplatzes nicht möglich ist.
Die minimale Kapazität pro Arbeitsplatz, die nicht mehr verringert werden kann, beträgt 8 Stunden
pro Tag. Werden diese Kapazitäten nicht genutzt, entstehen, durch Lohn- und Maschinenkosten,
Leerkosten. Übersteigt der Kapazitätsbedarf die Mindestauslastung der Arbeitsplätze besteht die
Möglichkeit durch eine oder zwei weitere Schichten, bzw. einzelne Überstunden, die Kapazität auf
bis zu 24 Stunden pro Tag zu erhöhen. Für jeden Arbeitsplatz können die Kapazitäten individuell
angepasst werden, jedoch bleibt die Kapazitätsanpassung für die gesamte Periode gleich. Die
erste Schicht beträgt 8 Stunden, die nicht reduziert werden können. Reichen diese nicht aus, kann
man entweder eine zweite Schicht mit wiederum 8 Stunden veranlassen, oder Überstunden bis
maximal 4 Stunden zur ersten Schicht hinzufügen. Ebenfalls kann eine dritte Schicht oder 4
Überstunden nach der zweiten Schicht veranlasst werden.
34
80
Abbildung 7: Kapazitäten
4.2.3.5 Kosten
In jeder Periode werden die Herstellkosten der drei Endprodukte errechnet, die sich aus den
folgenden Positionen zusammensetzen:
- Materialkosten:
- Materialkosten sind alle Kosten die durch den Einkauf von Materialien und Teilen
entstehen. Für jede Bestellung fällt unabhängig von der Bestellmenge, eine
Bestellpauschale an, welche sich für Eil-Bestellungen verzehnfacht. Der Stückpreis eines
Artikels reduziert sich um 10%, wenn die Bestellmenge gleich oder größer der
Diskontmenge ist.
- Lohnkosten:
- Lohnkosten errechnen sich aus der Fertigungszeit pro Stück und Arbeitsplatz, multipliziert
mit dem Lohnkostensatz (abhängig vom Lohnsatz für die jeweilige Schicht, bzw.
Überstunden) plus anteilige Rüstkosten. Durch Leerzeiten entstandene Lohn-Leer-Kosten
werden aufsummiert und auf die verkauften Endprodukte umgelegt.
- Maschinenkosten:
Die Maschinenkosten errechnen sich wie die Lohnkosten aus den jeweiligen
Fertigungsminuten pro Arbeitsplatz, mal dem entsprechenden Maschinenkostensatz plus
den anteiligen Rüstkosten. Die Leerkosten werden wie bei den Lohnkosten verrechnet.
- Anteilige Lagerkosten:
- Die Lagerkosten werden als Prozentsatz des Lagerwertes kalkuliert. Bis zu einem
durchschnittlichen Lagerwert von € 250.000,00 wird mit einem Lagerkostensatz von 0,6%
pro Woche bzw. Periode gerechnet. Übersteigt der Lagerwert € 250.000,00 so müssen
80
SCSim Handbuch (2008); S.25
35
neue Lagerflächen angemietet werden, wodurch € 5.000,00 Zusatzkosten entstehen, und
die Differenz zwischen dem Lagerwert und € 250.000,00 wird mit einem Lagerkostensatz
von 1,2% bewertet. Die Summe der Lagerkosten wird wiederum auf die verkauften
Endprodukte umgelegt.
- Anteilige Leerkosten:
- Wie bereits erwähnt, werden die durch Leerzeiten entstandenen Lohn- und
Maschinenkosten auf die verkauften Endprodukte der jeweiligen Periode umgelegt.
5 Semiramis und SCSim als Planspiel
In diesem Abschnitt wird auf die Umsetzung der Idee, das Modul der Produktion in einem ERP-
System mit Hilfe eines Planspiels in die Lehre zu integrieren, eingegangen. Wie bereits in Punkt
4.1. erläutert, wurde dazu das ERPII-System Semiramis mit dem Simulationsplanspiel „Supply
Chain Simulation“ in Form eines Planspiel zusammengeführt. In den folgenden Punkten wird zuerst
auf das hierfür entwickelte Szenario, die Umsetzung, und im Anschluss auf die dabei aufgetretenen
Probleme eingegangen.
5.1 Szenario
Zu Beginn des Projekts wurden verschiedene Möglichkeiten, wie die beiden ausgewählten
Programme kombiniert werden könnten, durchdacht. Das verwendete Szenario wurde gewählt, da
es zum einen sinnvoll, zum anderen technisch relativ einfach realisierbar eingeschätzt wurde. Es
bildet die von SCSim vorgegebenen Prozesse in beiden Programmen ab.
Die Verknüpfung der beiden Programme verlangt eine Abstimmung zwischen ihnen bezüglich der
abgebildeten Daten und Prozesse. Da das Simulationsplanspiel „Supply Chain Simulation“ nur
schwierig verändert, und somit kaum an ein anderes Programm angepasst werden kann, wurden
sämtliche Anpassungen die nötig waren, um die Prozesse in beiden Programmen zu
synchronisieren, in Semiramis vorgenommen. Eine Auflistung aller Adaptionen und Einstellungen
in Semiramis wird in Punkt 5.2. erläutert. Durch die Abbildung aller Informationen aus SCSim in
Semiramis ist es möglich, dieselben Prozesse mit denselben Resultaten in beiden Programmen zu
simulieren. Dies war die Voraussetzung dafür, dass ein Informationsaustausch zwischen beiden
Programmen stattfindet, der zu konsistenten Ergebnissen führt.
36
5.1.1 Beschreibung des Szenarios
Das ausgewählte und umgesetzte Szenario sieht wie folgt aus:
Abbildung 8: Planspielverlauf
Das Planspiel setzt sich aus mehreren, gleich ablaufenden Perioden zusammen. Zu Beginn jeder
Periode erhalten die Teilnehmer den Primärbedarf, also die Menge der fertigen Fahrräder,
Fahrräder die sie
am Ende einer Periode vertreiben sollen, als Vertriebsanfrage in Semiramis. Dies bildet den
Ausgangspunkt für die Planung der zu beschaffenden Artikel und der zu produzierenden Menge an
Endprodukten. Mit Hilfe der Materialbedarfsplanung wird
wir der gewünschte
ewünschte Produktionsplan ermittelt.
Dieser beinhaltet auch Aufträge für die Beschaffung, um den Lagerbestand von Materialien für die
laufende sowie die kommenden Perioden zu sichern. Die dadurch definierten Informationen über
Beschaffung, Produktion inklusive
inklu Ressourcenkapazitäten und Vertrieb werden dann nach SCSim
transferiert, wo die Simulation des Prozesses erfolgt. Die von SCSim errechneten Ergebnisse
werden wiederum nach Semiramis importiert. Daraus resultieren verschiedene Stati der
ausgegebenen Aufträge
träge aus Beschaffung, Produktion und Vertrieb:
Vollständig erfüllte Aufträge werden erledigt und werden damit auch in der Lagerhaltung verbucht.
Teilweise erledigte Produktionsaufträge werden mit genau der Menge,
Menge die tatsächlich produziert
wurde, eingelagert,
gert, die Restmenge bleibt mit dem Produktionsauftrag im System und wird in der
folgenden Periode abgearbeitet.
Kann nicht die geforderte Menge vertrieben werden,
werden sondern nur ein Teil davon, so bleibt auch der
Vertriebsauftrag mit der Differenz aus Primärbedarf
Primärbedarf und gelieferter Menge für die nächste Periode
offen.
Gar nicht erledigte Aufträge bleiben in ihrer ursprünglichen Form im System, bis sie erledigt
werden.
Aufträge können nie gelöscht werden. Sobald sie ausgegeben wurden, bleiben sie im System, bis
sie erledigt werden.
Durch den Import der genannten Aufträge mit den dazugehörigen Informationen über die Stati, sind
in Semiramis alle Daten vorhanden, um die Planung für die nächste Periode, mit dem Ziel den
neuen Primärbedarf zu decken, durchzuführen. Somit
Somit beginnt die nächste Periode mit demselben
Ablauf.
37
5.1.2 Anforderung an die Teilnehmer
Durch die Kombination der beiden Programme in einem Planspiel müssen Studierende zum einen
die ERP-Software Semiramis soweit beherrschen, dass sie einen Geschäftsprozess, der
Beschaffung, Produktion und Vertrieb durchläuft, bearbeiten können. Mit einem ERP-System
praktische Erfahrung zu haben steigert die Employabilität eines Absolventen genauso wie das
Verständnis für betriebsinterne Prozesse. Zum anderen müssen sich die Studierenden ausführlich
mit den Logiken und Prozessen der Produktion in „SupplyChainSimulation“(SCSim)
auseinandersetzen. Dabei gilt es zu verstehen, welche Einzelteile zu welchem Zeitpunkt bestellt
werden müssen, um für den Produktionsprozess rechtzeitig im Lager zu sein. Des Weiteren muss
geplant werden welche Ressourcen durch die Produktion belegt werden, und wie lange diese
benötigt werden. Auch die Entscheidung, ob es sich lohnt Überstunden zu veranlassen muss
kalkuliert werden. Da die Studierenden die Produktion über mehrere Perioden im voraus von Hand
planen müssen, wächst ihr Verständnis für den Produktionsprozess. Dadurch fällt es anschließend
leichter, ihnen die Produktion, sowie die Materialbedarfsplanung in Semiramis zu erklären.
5.2 Vorgehensweise bei der Entwicklung
Nachdem die verwendeten Programme und das Szenario gewählt waren, wurde die Abbildung des
gesamten Produktions-, sowie Beschaffungs- und Vertriebsprozesses mit allen, diesen zu Grunde
liegenden, Daten aus SCSim in Semiramis durchgeführt. Dazu wurde ein eigener Mandant erstellt,
auf dem schrittweise alle Adaptionen durchgeführt wurden. Dieser Semiramis-Mandant war zu
Beginn leer. Das heißt, es sind keine Stammdaten wie Artikel oder Partner im System hinterlegt,
nicht jedoch dass überhaupt keine Informationen vorhanden sind. In diesem Fall handelt es sich
um einen Vorlagemandanten der Art „Basis Deutschland“, was unter Anderem bedeutet dass
Konten- und Steuerklassifikationen bereits im System angelegt sind, dass ein Werkskalender
vorhanden ist, dass Lademittel und Verpackungseinheiten vorgegeben werden, dass die
Standardsprache deutsch festgelegt ist und dass bei der Anschrift eine fünfstellige Postleitzahl vom
System verlangt wird.
5.2.1 Grundlegende Stammdaten
Im folgenden Abschnitt wird beschrieben wie die Stammdaten der Artikel, Partner und Ressourcen
angelegt wurden.
Zu erst wurden alle Artikel die im Simulationsplanspiel SCSim verwendet werden angelegt. Diese
setzen sich zusammen aus drei Endprodukten, 27 Eigenfertigungsprodukten (Halbfabrikate) und
29 Kaufteilen (Materialien). Die genaue Auflistung der Artikel ist in Tabelle 3 zu sehen.
Jeder Artikel wird in der Ansicht Basis angelegt, wo eine eindeutige Kennung und die Bezeichnung
festgelegt werden. Zusätzlich wird in der Basisansicht die Basiseinheit, also die Einheit in der der
Artikel gehandelt wird, definiert. In diesem Fall ist die Basiseinheit für alle verwendeten Artikel
38
„Stück“, die Kennung besteht jeweils aus den Buchstaben P für Endprodukte, K für Kaufteile, und E
für Eigenfertigungsteile und einer Zahl. Des Weiteren wird in dieser Ansicht die Verpackung des
Artikels hinterlegt. Der Artikel „P1“, mit der Bezeichnung „Kinderfahrrad“ wird beispielsweise zu
einem Stück pro Karton verpackt, und jeweils vier solcher Kartons werden zu einer Palette
zusammengefasst.
Bei den drei Endprodukten, die mit einem P in der Artikelkennung charakterisiert sind, handelt es
sich um Vertriebsartikel. Daher wird als nächstes die Ansicht Vertrieb angelegt. Dort ist eine
Klassifikation anzugeben, die in der späteren Verwendung beispielsweise die Suche erleichtert.
Für den Artikel P1 lautet diese: „Fahrrad-Enderzeugnis“. In der Rubrik Lieferdaten wurde die
Checkbox „Verfügbarkeitsprüfung“ aktiviert, was zur Folge hat, dass bei Eingabe eines
Vertriebsauftrags geprüft wird, ob dieser Artikel in der gewünschten Menge verfügbar ist.81
In der Ansicht Rechnungswesen, werden unter der Rubrik Klassifikationen die zu verwendenden
Steuersätze, sowie die relevanten Konten, wie beispielsweise die Bestandskonto -Klassifikation
„Bestände-Enderzeugnisse“ für die Endprodukte hinterlegt. Allen Artikel werden unter der Rubrik
Bewertungspreise Preise hinterlegt, welche aus den Teilestammdaten aus dem SCSim-
Handbuch82 übertragen wurden. Die Sicht Rechnungswesen wird für alle Artikel angelegt.
Die Ansicht Lagerlogistik ist ebenfalls für alle Artikel angelegt worden. Dabei wurde allerdings
nichts Spezielles angegeben, sondern nur die Ansicht geöffnet und mit den aus der Basis
übernommenen Werten für die Klassifikation und das Lademittel gespeichert.
Die Ansicht Disposition legt fest wie die jeweiligen Artikel bezogen werden. So wird den K-Artikeln,
die beschafft werden müssen, unter der Rubrik Dispositionsdaten als Bedarfsdeckung „externe
Beschaffung“ hinterlegt. Des Weiteren ist es für die spätere Planung interessant wie lange es
dauert den Artikel wieder zu beschaffen. Unter der Rubrik Beschaffungsdaten wird daher die
Wiederbeschaffungszeit hinterlegt, die aus den vorgegebenen Werten von SCSim kalkuliert wird.
Des Weiteren verlangt das System nach einem Lieferanten, von dem die Materialien bezogen
werden. Dazu wurde ein Partner angelegt, dem in der Basis eine eindeutige Kennung, ein Name
und eine Adresse zugeordnet wurden. Anschließend wurde die Ansicht „Lieferant“ bearbeitet, wo
eine Klassifikation, die Lieferbedingungen und die Preise hinterlegt wurden. Die berechneten
Preise werden in Form einer Preislistung unter der Rubrik Rechnungsdaten hinterlegt, worauf
später genauer eingegangen wird. Nachdem der Partner als Lieferant definiert wurde, kann in der
Ansicht Rechnungswesen die Checkbox „Kreditor“ aktiviert werden. Zusätzlich werden weitere
Kreditorendaten zum Zahlungsprozess festgelegt. Nach demselben Schema wird auch ein Kunde
angelegt, an den die Endprodukte vertrieben werden. Statt der Ansicht Lieferant wird die Ansicht
Kunde mit ähnlichen Informationen über Lieferung und Preis angelegt, und in der
Rechnungswesen-Sicht die Checkbox Debitor aktiviert.
Den Eigenfertigungsteilen und Endprodukten wird unter der Sicht Disposition nur die
Bedarfsdeckungsart „Produktion“ hinterlegt.
Für alle „E“ und „P“ Artikel (Eigenfertigungsteile und Endprodukte) muss die Produktionssicht
angelegt werden. Dort wird die vom System vorgeschlagene Einstellung, dass bei mehrstufiger
81
Vgl. Semiramis Hilfe „Vertriebsaufträge“(2007); S.5
82
Vgl SCSim-Handbuch (2008); S. 56
39
Einlastung eine Artikelauflösung durchgeführt wird, beibehalten. Das bedeutet, dass für
Halbfabrikate Produktionsvorschläge erzeugt werden, falls für das übergeordnete Produkt ein
Produktionsauftrag veranlasst wird. Außerdem wird unter der Rubrik Produktionsdaten hinterlegt,
dass Produktionsaufträge in Splittmengen von 10 Stück aufgeteilt werden, wie es auch in SCSim
erfolgt.
Zuletzt muss noch angegeben werden, welche Materialien, in welcher Reihenfolge und Menge
benötigt werden, um den Artikel zu produzieren. Dies erfolgt durch die Hinterlegung eines
Produktionsplans unter der Rubrik Produktionsverfahren. Welche Informationen ein
Produktionsplan beinhaltet und aus welchen Komponenten er sich zusammensetzt wird später
erläutert.
Allen „K“-Artikeln (Kaufteile) muss die Beschaffungssicht angelegt werden, welche mit den
Vorschlagswerten gespeichert wird.
Damit sind alle Artikel mit den erforderlichen Sichten, sowie ein Lieferant von dem Materialien
beschafft werden, und ein Kunde an den Fertigprodukte vertrieben werden, im System vorhanden.
Die Artikel werden in einem Standard-Lagerort aufbewahrt, welcher in der Vorlage des Mandanten
bereits angelegt ist. Daher ist die nächste Aufgabe Ressourcen für die Produktion festzulegen.
Dafür werden die vierzehn Ressourcen im Framework Produktion angelegt, die SCSim für den
Produktionsprozess verwendet. Jeder Arbeitsplatz erhält eine eindeutige Kennung in Form einer
Zahl und eine Bezeichnung. Als Kapazitätstyp wird „Zeitabhängig“ ausgewählt, was bedeutet, dass
die Ressource nicht unbeschränkt, sondern nur die im Wochenzeitmodell festgelegte Zeit zur
Verfügung steht. Ein Wochenzeitmodell fast Zeitmodelle und Schichten zusammen, was später
genauer erklärt wird. Als Terminierungsverfahren wird „Punktgenau“ ausgewählt, was bedeutet,
dass die Zeiten im Produktionsauftrag auf die Minute genau kalkuliert und dargestellt werden.83
Zusätzlich zu den Arbeitsplätzen wird auch ein Mitarbeiter als Ressource angelegt. Dieser wird in
den Arbeitsgängen den Ressourcen zugeordnet.
5.2.2 Preise
Preise sind sowohl beim Einkauf der Materialien, als auch beim Verkauf der Endprodukte ein
wichtiger Aspekt. Obwohl im Planspiel die Berechnung des Betriebsergebnisses in SCSim erfolgt
wurden auch in Semiramis Beschaffungs- und Vertriebspreise festgelegt. Diese wurden aus der
Teilestammdaten-Liste aus dem SCSim Handbuch übernommen. In Semiramis wurde im
Framework Beschaffung und der Anwendung Beschaffungspreislistungen eine Kaufteil-Preislistung
angelegt, welcher ein Gültigkeitszeitraum und eine Preisliste hinterlegt wurden. Die Preisliste für
die Kaufteile umfasst alle 29 Beschaffungsartikel, wobei für jeden der Standardpreis in Euro und
ein Mengenrabatt definiert sind. Der Mengenrabatt wird in Prozent angegeben und beträgt für
jeden Artikel 10%, falls die Bestellmenge die angegebene Staffel erreicht oder übersteigt. Die
genauen Werte hierfür sind in Tabelle 3 zu finden. Die Preislistung wird dem Lieferanten unter der
Rubrik Rechnungsdaten hinterlegt. Wird ein Beschaffungsauftrag an diesen Lieferanten
83
Vgl. Semiramis Hilfe, „Ressourcen“ (2005); S: 6
40
ausgegeben, werden automatisch die Preise aus der der Preislistung hinterlegten Preisliste
gezogen, falls im Beschaffungsauftrag im Positionseditor unter dem Karteireiter Preise die
Preisherkunft „Preisliste“ oder „Preisliste, manuelle“ ausgewählt wurde.
Ähnlich ist es bei den Vertriebspreisen, die für die drei Endprodukte festgelegt sind. Die Preise
werden wiederum in einer Vertriebspreisliste angegeben, welche einer Vertriebspreislistung
hinterlegt ist. Diese ist dem Kunden unter der Rubrik Rechnungsdaten hinterlegt. Dadurch werden
beim Verfassen eines Vertriebsauftrages an den entsprechenden Kunden, die Preise automatisch
aus der Vertriebspreisliste gezogen. Falls die Vertriebspreise automatisch gezogen werden sollen,
muss im Vertriebsauftrag, im Positionseditor, unter dem Karteireiter Preise die Preisherkunft
„Preisliste“ ausgewählt werden.
Teil- Bezeichnung Ver- Teile- Dis- Wieder- Abwei- Lager- Bestell-

Nr. wen- wert cont- beschaf- chung menge kosten
dung [€] menge fungszeit +/- [Stück] [€]
[Stück] [Perioden] [%]
K21 Kette K 5,00 300 1,8 0,4 300 50,00

K22 Kette D 6,50 300 1,7 0,4 300 50,00
K23 Kette H 6,50 300 1,2 0,2 300 50,00
K24 Mutter 3/8“ KDH 0,06 6.100 3,2 0,3 6.100 100,00
K25 Scheibe 3/8“ KDH 0,06 3.600 0,9 0,2 3.600 50,00
K27 Schraube 3/8“ KDH 0,10 1.800 0,9 0,2 1.800 75,00
K28 Rohr ¾“ KDH 1,20 4.500 1,7 0,4 4.500 50,00
K32 Farbe KDH 0,75 2.700 2,1 0,5 2.700 50,00
K33 Felge cpl. H 22,00 900 1,9 0,5 900 75,00
K34 Speiche H 0,10 22.000 1,6 0,3 22.000 50,00
K35 Konus KDH 1,00 3.600 2,2 0,4 3.600 75,00
K36 Freilauf KDH 8,00 900 1,2 0,1 900 100,00
K37 Gabel KDH 1,50 900 1,5 0,3 900 50,00
K38 Welle KDH 1,50 300 1,7 0,4 300 50,00
K39 Blech KDH 1,50 1.800 1,5 0,3 900 75,00
K40 Lenker KDH 2,50 900 1,7 0,2 900 50,00
K41 Mutter ¾“ KDH 0,06 900 0,9 0,2 900 50,00
K42 Griff KDH 0,10 1.800 1,2 0,3 1.800 50,00
K43 Sattel KDH 5,00 2.700 2,0 0,5 1.900 75,00
K44 Stange ½“ KDH 0,50 900 1,0 0,2 2.700 50,00
K45 Mutter ¼“ KDH 0,06 900 1,7 0,3 900 50,00
K46 Schraube ¼“ KDH 0,10 900 0,9 0,3 900 50,00
K47 Zahnkranz KDH 3,50 900 1,41 0,1 900 50,00
K48 Pedal KDH 1,50 1.800 1,0 0,2 1.800 75,00
41
K52 Felge cpl. K 22,00 600 1,6 0,4 600 50,00
K53 Speiche K 0,10 22.000 1,6 0,2 22.000 50,00
K57 Felge cpl. D 22,00 600 1,7 0,3 600 50,00
K58 Speiche D 0,10 22.000 1,6 0,5 22.000 50,00
K59 Schweißdraht KDH 0,15 1.800 0,7 0,2 1.800 50,00
1P Kinderfahrrad 156,13 100
2P Damenfahrrad 163,33 100
3P Herrenfahrrad 165,08 100
4E Hinterradgruppe K 40,85 100
5E Hinterradgruppe D 39,85 100
6E Hinterradgruppe H 40,85 100
7E Vorderradgruppe K 35,85 100
8E Vorderradgruppe D 35,85 100
9E Vorderradgruppe H 35,85 100
10 E Schutzblech h. K 12,40 100
11 E Schutzblech h. D 14,65 100
12 E Schutzblech h. H 14,65 100
13 E Schutzblech v. K 12,40 100
14 E Schutzblech v. D 14,65 100
15 E Schutzblech v. H 14,65 100
16 E Lenker cpl. KDH 7,02 300
17 E Sattel cpl. KDH 7,16 300
18 E Rahmen K 13,15 100
19 E Rahmen D 14,35 100
20 E Rahmen H 15,55 100
26 E Pedal cpl. KDH 10,50 300
29 E Vorderrad mont. H 69,29 100
30 E Rahmen u. Räder H 127,53 100
31 E Fahrrad o. Ped. H 144,42 100
49 E Vorderrad cpl. K 64,64 100
50 E Rahmen u. Räder K 120,63 100
51 E Fahrrad o. Pedal K 137,47 100
54 E Vorderrad cpl. D 68,09 100
55 E Rahmen u. Räder D 125,33 100
56 E Fahrrad o. Pedal D 142,67 100
84
Tabelle 3: Teilestammdaten
84
Handbuch SCSim (2008); S. 57
42
5.2.3 Wochenzeitmodelle
Zur Definition der theoretischen Kapazitäten der zeitabhängigen Ressourcen werden

Wochenzeitmodelle festgelegt, welche Zeitmodelle und Schichten zusammenfassen.
85
Abbildung 9: Zuordnung der Wochenzeitmodelle zu Ressourcen
Zur Abbildung der Kapazitätsverhältnisse aus SCSim wurden in Semiramis fünf Schichten
angelegt. Eine Frühschicht, mit 8 Stunden, die nicht reduziert werden kann, ist als Vorschlagswert
bei allen Kapazitäten hinterlegt. Um die Kapazität zu steigern, kann eine Spätschicht und eine
Nachtschicht mit jeweils 8 Stunden hinzugefügt werden. Zusätzlich ist es möglich zu der ersten
oder zweiten Schicht Überstunden minutengenau zu veranlassen. Dazu wurde eine „Sonderschicht
Tag“ und eine „Sonderschicht Abend“ erstellt. Um zu gewährleisten, dass dies für jede Ressource
individuell möglich ist, wurde für jede Ressource ein Wochenzeitmodell, für die „Frühschicht +
Überstunden“ und die „Spätschicht + Überstunden“ angelegt. Dem Wochenzeitmodell „Spätschicht
+ Überstunden“ sind die Schichten „Frühschicht“, „Spätschicht“ und „Sonderschicht Abend“
hinterlegt. Den ersten beiden Schichten sind jeweils Zeitmodelle mit 8 Stunden hinterlegt. Da die
„Sonderschicht Abend“ für jede Ressource unterschiedlich gestaltet werden kann, sind für jede der
14 Ressourcen ein Zeitmodell „Überstunden Abend“ sowie ein Zeitmodell „Überstunden Tag“ im
System angelegt.
85
Semiramis Hilfe: Wochenzeitmodelle (2005); S.4
43
5.2.4 Produktionsplan
Ein Produktionsplan stellt die elementaren Informationen für die Produktion dar, und fasst
Stücklisten und Arbeitspläne zusammen.
86
Abbildung 10: Zusammensetzung eines Produktionsplans
In Semiramis wurden 30 Produktionspläne, für die drei Endprodukte und alle Halbfabrikate
angelegt. Jedem Produktionsplan ist eine eigene Stückliste hinterlegt, die angibt, welche
Materialien für den jeweiligen Produktionsschritt in welcher Menge benötigt werden. Eine Tätigkeit,
die im Produktionsprozess ausgeführt wird, wird als Arbeitsgang bezeichnet. Einem Arbeitsgang
muss mindestens eine Ressource zugeordnet werden. Alle Arbeitsgänge die für die Produktion
eines Artikels durchgeführt werden müssen, werden in einem Arbeitsplan zusammengefasst. Dabei
werden auch die Reihenfolge und eventuelle Abhängigkeiten der Arbeitsgänge untereinander
berücksichtigt.
Den Arbeitsgängen wurden jeweils ein zugehöriger Arbeitsplatz (Ressource) und ein Mitarbeiter
zugeordnet, genauso wie Bearbeitungs- und Rüstzeiten. Insgesamt sind 14 Arbeitsgänge angelegt
worden, einer für jeden Arbeitsplatz. Diese werden in zwölf Arbeitsplänen zusammengefasst,
wobei einzelne Arbeitsgänge in mehreren Arbeitsplänen verwendet werden.
Somit sind in einem Produktionsplan die folgenden Informationen zusammengefasst:
- Welche Materialien und Halbfabrikate werden in welcher Menge und Reihenfolge benötigt?
- Welche Arbeitsschritte sind für die Produktion nötig, und welche Ressourcen werden dafür
wie lange besetzt?
5.2.5 Auftragsarten
Die Aufträge aus Beschaffung, Produktion und Vertrieb stellen im Gegensatz zu den Stammdaten
Prozesse oder Funktionen dar. Die dort verarbeiteten Informationen werden als Bewegungsdaten
bezeichnet. Der Ablauf dieser Aufträge wird teilweise durch die Einstellungen in den
Beschaffungs-, Produktions- und Vertriebsauftragsarten definiert. Diese enthalten Vorschlagswerte
und Einstellungen für die eigentlichen Aufträge.
86
Semiramis Hilfe: Produktionspläne (2006); S.2
44
In der Beschaffungsauftragsart wird die Lieferbedingung, also die Vereinbarungen zwischen Käufer
und Verkäufer, die Versandbedingungen, ob per Post, Spedition oder Kurier transportiert wird, und
der Lagerort auf dem die erworbenen Artikel gelagert werden angegeben. Für das Planspiel wurde
ein Standardbeschaffungsauftrag ausgewählt. Da in SCSim keine Transportkosten vorgesehen
sind, wurde die Lieferbedingung „Frei Haus“ gewählt. Der Versand wird über eine Spedition
abgewickelt und die Artikel werden auf das Standardlager geliefert.
Ähnlich wie die Beschaffungsauftragsart legt auch die Vertriebsauftragsart fest von welchem Lager
die Waren genommen werden und wie sie versandt werden. Zusätzlich können Rechnungsdaten
hinterlegt werden. Im Karteireiter Lieferdaten wurde dem Standard-Auftrag vom Typ
„Kundenauftrag“ das Standardlager als Bezugsquelle angegeben. Die Lieferung erfolg „Frei Haus“
und es bestehen keine Lieferrestriktionen, was bedeutet, dass auch Teilmengen der vereinbarten
Menge geliefert werden können. Im Karteireiter „Rechnungsdaten ist als Preisherkunft „Preisliste,
manuell“ angegeben was bedeutet, dass falls eine Vertriebspreislistung für den entsprechenden
Kunden und Artikel vorhanden ist, die Preise automatisch gezogen werden, wenn nicht, sie
manuell eingegeben werden können. Da eine Vertriebspreisliste beim Kunden hinterlegt ist,
werden die Preise automatisch gezogen.
Alle in den Eingabefeldern der Produktionsauftragsart festgelegten Daten, werden automatisch in
alle neuen Produktionsaufträge dieser Art übernommen. Als erstes wurde der Terminierungstyp
„vorwärts einstufig“ mit Kapazitätslimits festgelegt. Die Terminierung erfolgt während der
Einlastung der Produktionsaufträge und berechnet die Beginn- und Enddaten des gesamten
Produktionsauftrages, sowie der einzelnen Arbeitsgänge. Es kann zwischen acht verschiedenen
Terminierungstypen unterschieden werden. Die acht möglichen Typen ergeben sich aus der
Kombination der folgenden Kriterien:
- Vorwärts bzw. rückwärts
- Einstufig bzw. mehrstufig
- Mit Kapazitätslimits bzw. ohne Kapazitätslimits
Bei der mehrstufigen Einlastung kann ein Produktionsartikel aus Lagerartikeln (K-Teile) und
Halbfabrikaten (E-Teile) bestehen, die noch produziert werden müssen.87 Bei der einstufigen
Einlastung werden nur Artikel vom Lager verwendet, um den Artikel zu produzieren. Vorher
erstellte Halbfabrikate stehen als Lagerartikel zur Verfügung. Der Terminierungstyp vorwärts gibt
an, dass ausgehend vom frühest möglichen Beginn-Termin, der Endtermin errechnet wird. Die
Produktionsaufträge werden unter Berücksichtigung der Machbarkeit möglichst früh eingelastet.
Die Machbarkeit hängt von den Kapazitäten der benötigten Ressourcen ab, die Verfügbarkeit von
Materialien wird jedoch nicht berücksichtigt. Dieses Terminierungsverfahren wurde gewählt, da es
von den Teilnehmern die manuelle Veranlassung von Produktionsaufträgen verlangt. Im Verlauf
des Planspiels kann der Terminierungstyp auf „mehrstufig“ umgestellt werden, wodurch die
Teilnehmer erkennen können, welche Arbeitserleichterung ein solches System bringen kann. Für
den Anfang ist es aber übersichtlicher, wenn der Produktionsplan händisch erstellt wird.
87
Vgl. Semiramis Hilfe, Einlastung (2005); S.2
45
In der verwendeten Produktionsauftragsart wird auch das Lager, von dem Materialien und
Halbfabrikate genommen werden, und auf das die produzierte Ware gebracht wird, angegeben.
5.2.6 Materialbedarfsplanung
Die Materialbedarfsplanung in Semiramis liefert Informationen darüber, welche Artikel in welcher

Menge und zu welchem Termin produziert oder beschafft werden müssen.88 Dabei ist die Planung
des Ressourcenbedarfs in der Materialbedarfsplanung inkludiert. Ziel der Materialbedarfsplanung
ist es, einen möglichst optimalen Produktionsmix zu erarbeiten und damit eine effiziente
Auslastung der einzelnen Ressourcen zu erreichen.
Grundlage für die sinnvolle Durchführung der Materialbedarfsplanung ist das Vorhandensein von
Produktionsartikeln, denen Produktionspläne mit Stücklisten und Arbeitsplänen hinterlegt sind.
Somit können die für die Deckung des Primärbedarfs benötigten Artikel, die jeweiligen Mengen und
die dazu notwendigen Ressourcenkapazitäten berechnet werden. Der Primärbedarf wird durch die
angegebenen Artikel und Mengen in ausgegebenen Vertriebsaufträgen festgelegt. Zusätzlich wird
der Primärbedarf für die Zukunft durch den Import von Prognosen bestimmt. Der Bedarf wird
anschließend mit den verfügbaren Beständen auf dem Lager verglichen. Zusätzlich werden bereits
veranlasste, aber noch nicht beendete Aufträge aus Produktion und Beschaffung berücksichtigt.
Auch eventuell festgelegte Mindestbestände in der Dispositionssicht der Artikel spielen eine Rolle.
Auf Grund dieser Daten werden automatisch Produktions- und Beschaffungsvorschläge erzeugt,
die vom Bearbeiter der Planung überprüft und gegebenenfalls angepasst werden können, um dann
in Beschaffungs- und Produktionsaufträge umgewandelt zu werden.
88
Vgl. Semiramis Hilfe; Materialbedarfsplanung (2006); S.2
46
89
Abbildung 11:Einbettung der Materialbedarfsplanung innerhalb des Produktionsprozesses
Die Materialbedarfsplanung bietet die folgenden Vorteile:

- Alle Möglichkeiten und Optionen können unbegrenzt oft angepasst werden, bis bei
optimaler Auslastung ein optimaler Produktionsmix erreicht wurde.
- Die Materialbedarfsplanung generiert automatisch Produktions- und
Beschaffungsvorschläge, welche ohne weitere manuelle Eingaben in Produktions- und
Beschaffungsaufträge umgewandelt werden können.
In der Anwendung „Materialbedarfsplanung“ wird der Lagerort festgelegt, der in der Planung
berücksichtigt wird. Es werden also nur Bestände auf diesem Lager, und Bedarfsverursacher bzw.
–decker berücksichtigt, die diesen Lagerort zugeordnet haben. Im Planspiel wird das
Standardlager verwendet. Im Karteireiter Planungsdaten wird zusätzlich angegeben, dass keine
Vorschläge aus Beschaffung, Produktion oder Vertrieb berücksichtigt werden. Im Karteireiter
Disposition wird festgelegt, dass alle Dispositionsdaten (Losgröße, Mindestbestand, Meldebestand)
der entsprechenden Artikel berücksichtigt werden.
89
Semiramis Hilfe: Materialbedarfsplanung (2006); S.3
47
5.2.7 Filter für den Datenaustausch
In Semiramis können durch den Business Integration Service Daten aus den Datenbanken
exportiert werden. Exportierte Daten werden als XML (*.xml), „Text durch Trennzeichen getrennt“
(CSV, *.csv) oder „Unicode-Text durch Tabulator getrennt“ (*.xls)auf den Knowledge Store
gespeichert. Für das Planspiel werden die Informationen als XML-Dokumente exportiert, „da
beliebig komplexe Daten in einer einzigen Datei gespeichert werden können, das Schema der
Datei vorgegeben und überprüft werden kann und Änderungen des Datenmodells problemlos
integriert werden.“90 Zusätzlich bietet SCSim die Möglichkeit die Simulationsdaten in Form einer
XML-Datei zu importieren. „Mit XML können strukturierte Daten in einer Textdatei gespeichert
werden. Die Beschreibungssprache ermöglicht die Definition, Übertragung, Überprüfung und
Interpretation von Daten zwischen Applikationen und eignet sich besonders für den strukturierten
Datenaustausch. Bei XML-Dokumenten erfolgt eine Trennung von Inhalt, Struktur und Information
zur Darstellung. XML wird vom W3C als Standard koordiniert und definiert.“91
Um Daten zu exportieren muss ein Filter angelegt werden, der definiert, welche Business Entity mit
welchen Attributen exportiert wird. Für den Datenaustausch im Rahmen des Planspiels wurden fünf
Filter für den Export aus Semiramis, und einer für den Import angelegt. Die Filter für den Export
müssen so gewählt werden, dass sie alle Informationen enthalten, die SCSim für die Simulation
benötigt. Zudem ist es sinnvoll nicht unnötig viele Attribute zu exportieren, um die Datenmenge
während des Transfers möglichst gering zu halten. Die fünf Filter, die für den Datenaustausch
zwischen Semiramis und SCSim benötigt werden sind:
- Filter für Vertriebsaufträge
- Filter für Beschaffungsaufträge
- Filter für Produktionsaufträge
- Filter für Ressourcen
- Filter für Wochenzeitmodelle
5.3 Datenaustausch
Der folgende Abschnitt beschreibt den Datenaustausch zwischen Semiramis und SCSim. Es wird
in chronologischer Reihenfolge vorgegangen. Dabei wird zuerst auf die Informationen eingegangen
die SCSim von Semiramis für die Simulation benötigt. Zusätzlich wird für jedes Formular
(Vertriebswunsch, Bestellung, Arbeitsaufträge und Arbeitszeiten) ein beispielhafter Ausschnitt des
Datenexports aus Semiramis als XML gezeigt. Dadurch wird die Herkunft der Daten
veranschaulicht. Aus Platzgründen werden nur Ausschnitte der XML-Dokumente gezeigt, die
jedoch die Struktur des Dokuments widerspiegeln.
Anschließend wird auf die Transformation, also die strukturelle Anpassung der XML-Dokumente an
die vorgegebene Input-Struktur von SCSim eingegangen. Dabei wird zuerst die Extensible Markup
90
Semiramis Hilfe „Daten exportieren“ (2005); S. 2
91
Semiramis Hilfe „Daten exportieren“ (2005); S. 2
48
Language (XML) und die zur Transformation verwendete Programmiersprache XSLT eingegangen.
„Bei XSLT handelt es sich um eine sogenannte turing-vollständige Programmiersprache zur
92
Transformation von XML-Dokumenten“ . Unter Turing-Vollständigkeit versteht man die Fähigkeit
eines Programms, theoretisch jede Funktion berechnen zu können, sprich universal
93
programmierbar zu sein.
Dieselben beiden Punkte finden sich auch in der Beschreibung des Datentransfers von SCSim
nach Semiramis wieder. Zuerst werden die benötigten Daten und deren Herkunft definiert,
anschließend die Umsetzung der Transformation beschrieben.
5.3.1 Datentransfer von Semiramis nach SCSim

Im Folgenden werden jeweils die Eingabeformulare von SCSim „Simulation (Form)“ der
Internetseite www.scsim.de dargestellt, um zu verdeutlichen welche Eingaben erforderlich sind.
Jeweils nach dem Eingabeformular werden relevante Ausschnitte aus den exportierten XML-
Dokumenten dargestellt.
5.3.1.1 Vertriebsaufträge
Der nötige Input für das Fenster „Vertriebswunsch & Direktverkauf“ (Abb.13), besteht aus der
Menge aller drei Endfabrikate P1, P2 und P3. Somit müssen aus Semiramis Vertriebsaufträge
(SalesOrder) mit mindestens den Daten „Artikel“ und „Menge“ exportiert werden.
94
Abbildung 12: Vertriebswunsch & Direktverkauf
Exportiert man in Semiramis über die Anwendung „Daten exportieren“ im Framework „System-
Management“ mit dem Filter „SALESORDER“, so er hält man ein XML-Dokument, das unter
anderem die Werte „TotalQuantity/Amount“ und „Item/number“ enthält. Der relevante Ausschnitt
92
Koch, (2007); S. 9
93
Vgl. Becker, (2004); S.119
94
Screenshot: SCSim
49
dieses Exports ist nachfolgend zu sehen, wobei in diesem Fall nur der Artikel „P1“ mit einer Menge
von 200 Stück vertrieben werden soll.
SalesOrder xmlns="com.cisag.app.sales.obj.SalesOrder">
ns="com.cisag.app.sales.obj.SalesOrder">
<number>VA0001</number>
<Details>
<totalQuantity>
<amount>200</amount>
</totalQuantity>
<Item>
<number>P1</number>
</Item>
</Details>
Folgende Abbildung verdeutlicht den Datenaustausch bezüglich der Vertriebsdaten. Aus

Semiramis werden unter anderem die Attribute „Artikel“ und „Menge“
„ “ exportiert. Dieses XML-
XML
Dokument wird denn
n mit Hilfe von XSLT in ein XML-Dokument
XML Dokument transformiert, welches mit SCSim
kompatibel ist.
• Daten: Artikel, Menge

XML • Export aus Semiramis: Vertriebsaufträge
• Transformation
XSLT
XML • SCSim kompatibel
Abbildung 13:: Verlauf des Transfers der Vertriebsdaten
50
5.3.1.2 Beschaffungsaufträge
Abbildung 14 zeigt, welche Eingaben SCSim bezüglich eines Beschaffungsauftrages von
Semiramis benötigt. Der K-Artikel der bestellt werden soll, muss angegeben werden, die
dazugehörige Menge und der Bestellmodus.
95
Abbildung 14: Bestellungen
Exportiert man mit dem Filter „PurchaseOrder“ sind die Werte Artikel und Mengen enthalten, für
den Bestellmodus gibt es in Semiramis kein vorgesehenes Feld. Für die Umsetzung des Planspiels
wird im Positionseditor, unter dem Karteireiter „Allgemeines“ im Feld „Bezug“ einen Wert
eingetragen, der keinen Einfluss auf den Prozess in Semiramis hat, aber den Bestellmodus für
SCSim definiert.
Wie im untenstehenden Ausschnitt zu sehen ist, sind die Werte für den Artikel, „Item/number K34“,
die Menge, „totalQuantity/amount 3200“ und den Modus, „reference 5“ im Export enthalten.
Weiter unten sind dieselben Informationen für den Artikel „K36“ gegeben, jedoch mit dem Wert „4“
im Bezug. Daran kann man erkennen, dass zwei unterschiedliche Bestellmodi verwendet wurden.
Dabei steht der Wert „5“ für eine Normalbestellung und der Wert „4“ für eine Eilbestellung.
<PurchaseOrder xmlns="com.cisag.app.purchasing.obj.PurchaseOrder">
<Details>
<totalQuantity>
</totalQuantity>
<reference>5</reference>
<Item>
<number>K34</number>
</Item>
</Details>
<Details>
<totalQuantity>
95
Screenshot: SCSim
51
</totalQuantity>
<reference>4</reference>
<Item>
</Item>
</Details>
Folgende Abbildung veranschaulicht den Transfer der Beschaffungsdaten.
• Daten: Artikel, Menge, Referenz

XML • Export aus Semiramis: Beschaffungsaufträge
• Transformation
XSLT
• Daten: Artikel, Menge, Modus
Abbildung 15:: Verlauf des Transfers der Beschaffungsdaten
5.3.1.3 Produktionsaufträge
SCSim verlangt für die Festlegung von Arbeits-
Arbeits bzw. Produktionsaufträgen die Angabe des zu
produzierenden E- oder P-Artikels
Artikels und die dazugehörige Menge. Die Reihenfolge ergibt sich aus
den vorgesehenen Produktionsbeginnzeiten in Semiramis.
52
96
Abbildung 16: Arbeitsaufträge
Der Folgende Ausschnitt aus dem exportierten Produktionsauftrag lässt erkennen, dass sowohl der
zu produzierende Artikel („item/number P1“) und die gewünschte Menge („quantity/amount 10“) als
auch die Beginnzeit der Produktion („dates/currentBeginDate2007-10-12T04:00:00.000Z“) mit dem
12.Oktober 2007 um 04:00 Uhr definiert ist.
<ProductionOrder xmlns="com.cisag.app.production.obj.ProductionOrder">
<number>PA0001</number>
<quantity>
<amount>10</amount>
</quantity>
<dates>
<currentBeginDate>2007-10-12T04:00:00.000Z</currentBeginDate>
</dates>
<Item>
<number>P1</number>
</Item>
Theoretisch könnte über die Beginnzeit der Produktion auch die Reihenfolge der
Produktionsaufträge für SCSim festgelegt werden. Da Semiramis jedoch aufgrund der definierten
Losgröße von zehn Stück für jeden Artikel mehrere Produktionsaufträge mit kleinen Mengen und
zu unterschiedlichen Zeitpunkte generiert, müssen diese für den Import in SCSim
zusammengefasst werden. Somit muss auch die Reihenfolge teilweise ignoriert werden.
96
Screenshot:SCSim
53
XML • Export aus Semiramis: Produktionsaufträge
• Transformation
XSLT
Abbildung 17:: Verlauf des Transfers der Produktionsdaten
5.3.1.4 Wochenzeitmodelle
Im Fenster Arbeitszeiten in SCSim kann die Kapazität jeder
jeder Ressource einzeln festgelegt werden.
Dies ist zum einen möglich, indem man statt einer Schicht eine zweite oder sogar dritte Schicht
veranlasst, zum anderen indem man Überstunden (Mehrarbeit) zusätzlich zur angegebenen
Schicht festsetzt.
97
Abbildung 18: Arbeitszeiten
97
Screenshot:SCSim
54
Dafür ist der Export von zwei Business Entitys nötig. Zuerst müssen die Ressourcen mit dem
hinterlegten Wochenzeitmodellen exportiert werden. Die Wochenzeitmodelle selbst müssen auch
exportiert werden, da dort wiederum die Zeitmodelle hinterlegt sind, welche die exakte Kapazität
einer Ressource definiert.
Die erste der beiden Export-Dateien beinhaltet die Identifikation der Ressource („Ressource/code
101“) und das hinterlegte Wochenzeitmodell („TimeModel/code 151“). Die Bezeichnung
„TimeModel“ für „Wochenzeitmodell“ ist irreführend, in Semiramis aber so festgelegt.
<Resource xmlns="com.cisag.app.production.obj.Resource">
<code>101</code>
<TimeModel>
<code>151</code>
</TimeModel>
</Resource>
Falls Überstunden geleistet werden, muss das entsprechende Wochenzeitmodell, dem die
Zeitmodelle hinterlegt sind, exportiert werden. Im folgenden Ausschnitt aus der exportierten Datei
kann man erkennen, welche Zeitmodelle („ModelMonday/code 110“ und „ModelMonday/code 140“)
dem Wochenzeitmodell hinterlegt sind. Auch die exakte Verfügbarkeit in Minuten kann abgelesen
werden.
<WeekTimeModel xmlns="com.cisag.app.general.obj.WeekTimeModel">
<code>151</code>
<Details>
<ModelMonday>
<code>110</code>
<availableTime>28800000</availableTime>
</ModelMonday>
<ModelMonday>
<code>140</code>
</ModelMonday>
</Details>
</WeekTimeModel>
55
• Daten: Ressource, Wochenzeitmodell
XML • Export aus Semiramis: Ressource & Wochenzeitmodel
• Transformation
XSLT
• Daten: Arbeitsplatz, Schicht

98
Abbildung 19:: Verlauf der Transformation der Ressourcendaten
5.3.2 Transformation von XML-Dokumenten

XML
Sowohl Semiramis als auch SCSim unterstützen das Format XML.
XML. Extensible Markup Language
hatt sich als universelles Konzept zur Beschreibung und Transformation unterschiedlichster Daten
über das Web etabliert. Seit Februar 1998 steht die XML 1.0 Empfehlung des W3C (World Wide
W
99
Web Consortium) zur Verfügung
Für den Datentransfer wird XML und XSLT verwendet. In Diesem Teil der Arbeit wird auf die
zugrundeliegende Technik und Logik der verwendeten Technologien eingegangen.
5.3.2.1 Eigenschaften und Vorteile von XML

XML wurde entwickelt, um Daten
aten zu transportieren und zu speichern, nicht
nicht um sie darzustellen. In
XML kann jeder Tag selbst definiert
efiniert werden. Das Activity Statement des W3C liefert die folgenden
Aspekte die durch XML ermöglicht werden sollen:
5.3.2.1.1 Medienunabhängiges publizieren in mehreren Sprachen

Jedes Unternehmen hat das Bedürfnis etwas zu publizieren bzw.
bzw zu kommunizieren. Der
traditionelle Weg hierzu ist, die Information zu drucken und weiterzureichen, was jedoch verlangt,
verlangt
die Struktur und Semantik der Informationen zu verändern. Dieser Weg ist anfällig für Fehler und
98
Screenshot: SCSim
99
Vgl Bach, (2000), S 19f
56
zugleich umständlich. Die Alternative ist, die Daten elektronisch weiter zu leiten, wobei man sich
entscheiden muss in welchem Format die Daten verarbeitet werden sollen.
Im Rahmen der Globalisierung gewinnt die Forderung nach Mehrsprachigkeit stärker an
Bedeutung als je zuvor. Informationen in andere Sprachen zu übersetzen ist aufwendig und
kostenintensiv.
XML bietet die Möglichkeit die Grunddaten so beizubehalten, dass sie sowohl in unterschiedlichen
Sprachen als auch für verschiedene Ausgabeziele aufbereitet werden können, ohne die
Grunddaten selbst zu verändern. Dies erspart Kosten und Mühen und bietet eine gewisse
100
Flexibilität in Betracht der zukünftigen Verwendung der Daten.
5.3.2.1.2 Definition von plattformunabhängigen Protokollen zum Datenaustausch

Die Interaktion zwischen Unternehmen oder auch einfach zwischen verschiedener Software wird
durch XML drastisch vereinfacht. Die Schwierigkeit in der Kommunikation zwischen verschiedenen
Systemen liegt in der Verwendung unterschiedlicher Formate. Für den elektronischen Austausch
von Bestell-, Rechnungs- und Produktionsdaten entwickelten große Industrieunternehmen das
Format EDI (Electronic Data Interchange), welches einen Standard für den Datenaustausch
festlegte. Die Software ist allerdings teuer und die Anwendung des Standards selbst sehr komplex
und beratungsintensiv.
XML ermöglicht den format- und systemunabhängigen Datenaustausch und ist zugleich effektiv
101
und kostengünstig nutzbar.
5.3.2.1.3 Automatische Verarbeitung übertragener Daten durch Software

Die Informationstechnologie dient idealerweise der effizienten und konsistenten Verarbeitung und
Haltung von Daten. Die Verarbeitung der Daten soll automatisch verlaufen, und das nicht nur
innerhalb eines Systems, sondern auch zwischen Systemen. XML ermöglicht die Automatisierung
102
eines Datenflusses zwischen Systemen, z.B. in Kombination mit Webservices.
5.3.2.1.4 Datenverarbeitung mit preisgünstiger Software

XML lässt eine so flexible Struktur zu, dass das Datenformat von einer Großzahl von
Anwendungen verarbeitet und im Optimalfall auch gelesen und verstanden werden kann. Somit
103
wird es möglich die Kosten für die Datenverarbeitung gering zu halten.
5.3.2.1.5 Benutzerdefinierte Präsentation von Informationen

Wenn der Addressat von Informationen diese nicht in einer ihm vorgeschriebenen Weise
präsentiert bekommt, sondern er eine ihm dienliche Anzeigemethode wählen kann, bietet dies
100
Vgl. Bach, (2000); S.22
101
Vgl. Bach, (2000; S.23
102
Vgl. Bach, (2000); S.23
103
Vgl. Bach, (2000); S.23
57
einen Nutzenzuwachs. Durch die Verwendung von XML sollen verschieden
104
Repräsentationsmöglichkeiten gewährleistet werden.
5.3.2.1.6 Auffinden von Informationen durch „Informationen über die Informationen“

Der letzte Punkt beschäftigt sich mit dem gezielten Auffinden gespeicherter Daten. Durch den
strukturierten und rationalen Aufbau von XML-Dokumenten erleichtern sie das Auffinden von
speziellen Daten.
Die Strukturbeschreibungen sind die sogenannten Informationen über Informationen, welche als
Metadaten bezeichnet werden. Die Ebene der Metadaten erlaubt es, den Kontext in dem eine
105
Information gefunden werden soll zu definieren.
5.3.2.2 Aufbau von XML Dokumenten

Jedes XML-Dokument beginnt mit einer Deklaration welche mindestens die folgende Form hat:
<?xml version="1.0" ?>
Zusätzlich können in der Deklaration die Attribute „encoding“, welches die verwendete
Zeichencodierung definiert und „standalone“, welches angibt ob externe Entitäten berücksichtigt
werden müssen, stehen.
Als nächstes folgt die Dokumenttypdeklaration. Diese zeigt an, auf welchem Schema die XML-
Datei basiert. Im Schema wird festgehalten, wie das Dokument strukturiert ist. Dadurch kann ein
XML-Parser Fehler in der Dokumentstruktur erkennen und darauf aufmerksam machen. Der
Verweis innerhalb des XML-Dokuments sieht beispielsweise wie folgt aus:
<?xml-stylesheet type="text/css" href="bezeichnung.css" ?>
Anschließend folgt das root-Element. Es darf in einer XML-Datei nur ein root-Element geben. Alle
anderen Elemente sind Child-Elemente des root-Elements. Elemente werden in spitzen Klammern
geschrieben und bestehen aus einem Start- und einem End-Tag. Der Inhalt eines Elements
befindet sich zwischen Start- und End-Tag.
<name>Maier</name>
Jedes Element kann wiederum ein oder mehrere Child-Elemente enthalten. Dadurch lässt sich die
Struktur des XML-Dokuments wie die Verästelung eines Baumes betrachten.
Es ist darauf zu achten, dass ein XML-Dokument den Wohlgeformtheitsbeschränkungen genügt.

Dies bedeutet, dass alle Elemente korrekt geschachtelt werden und dass es zu jedem Start-Tag
auch einen passenden End-Tag geben muss.
104
Vgl. Bach, (2000); S.24
105
Vgl. Bach, (2000); S.24
58
Ein sehr einfaches aber komplettes XML-Dokument könnte wie folgt aussehen:
<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<?xml-stylesheet type="text/css" href="bezeichnung.css" ?>
<bezeichnung>
<name>Maier</name>
</bezeichnung>
5.3.2.3 XSLT
XSLT (Extensible Stylesheet Language Transformation) ist eine Programmiersprache die zur
Transformation von XML-Dokumente verwendet wird.
Es können zwei Hauptanwendungsgebiete von XSLT unterschieden werden:
- POP (Presentation Oriented Publishing): Transformation von XML-Dokumenten zum Zweck
der Darstellung. Mögliche Zielsprachen sind XHTML, SMIL, SVG oder DocBook. Dies wird
auch als Abwärtstransformation bezeichnet.
106
- MOM (Message Oriented Middleware): Transformationen zum Zweck des Datenaustauschs ,
was auch als Seitwärtstransformation betitelt wird.
XSLT besitzt die folgenden Merkmale:

- Es verwendet Baumstrukturen als Modelle von XML-Dokumenten
- XSLT-Stylesheets definieren die Umwandlung der Eingabe-Baumstruktur in eine Ausgabe-
Baumstruktur
- Für den Zugriff auf Teile des Eingabebaums werden XPath-Ausdrücke verwendet
- Mittels Vorlagen (Templates) wird die Baumstruktur des Ausgabedokuments
festgelegt. In diesen Templates sind Regeln definiert die festlegen, auf welche Weise der
107
Ausgabebaum generiert werden soll.
Eine Umwandlung Mittels XSLT benötigt mindestens zwei Dokumente:

- Ein XML-Dokument das transformiert werden soll (Quelldokument)
- Ein Dokument das die Transformationsvorschriften beinhaltet (Stylesheet)
Das Prinzip der Transformation läuft immer nach demselben Schema ab:
- Zuerst wird das XML-Quelldokument von einem Parser, der die enthaltenen Informationen
analysiert, eingelesen und interpretiert
- Anschließend wird das XSLT-Dokument vom Parser eingelesen und ebenfalls interpretiert
- Dann liest der XSLT-Prozessor beide Dokumente ein
- Der Prozessor wandelt das Quelldokument auf Grundlage der im XSLT-Dokument stehenden
108
Anweisungen in das gewünschte Zieldokument um
106
Vgl. Koch, (2007); S.10
107
Vgl. Koch, (2007); S.10
108
Vgl. Koch, (2007); S.13
59
5.3.2.4 Umsetzung der Datentransformation
Der Datenaustausch zwischen Semiramis und SCSim soll alle Informationen,
Information die SCSim zur
Simulation braucht,, in einem XML-Dokument
XML mit vorgegebener Struktur,
Struktur zusammenfassen.
Nachfolgende Graphik veranschaulicht den Datenaustausch. Aus Semiramis werden Daten
bezüglich
glich Vertrieb, Beschaffung, Produktion, Ressource und Zeitmodell
Zeitmodell als XML-Dokumente
XML
exportiert. Diese werden anschließend durch einen XSLT-Prozessor
Prozessor umgewandelt. Ergebnis der
Transformation ist ein XML-Dokument,
Dokument, welches alle relevanten Daten enthält und in einer für den
Import in SCSim kompatiblen Struktur vorliegt.
Abbildung 20: Datentransfer von Semiramis nach SCSim
Die Transformation der Daten stellt eine Seitwärtstransformation dar, da sowohl das Quell-
Quell als
auch das Zieldokument XML-Dokumente sind.
Das XSLT Dokument, welches die Struktur und Datenherkunft des Zieldokuments definiert,
definiert sieht
wie folgt aus:
<?xml version="1.0" encoding="UTF-8"
encoding ?>
<xsl:stylesheet version="2.0"
version
xmlns:xsl="http://www.w3.org/1999/XSL/Transform
http://www.w3.org/1999/XSL/Transform"
xmlns:n5="com.cisag.app.general.obj.WeekTimeModel
com.cisag.app.general.obj.WeekTimeModel"
xmlns:n4="com.cisag.app.production.obj.Resource
com.cisag.app.production.obj.Resource"
xmlns:n3="com.cisag.app.production.obj.ProductionOrder
com.cisag.app.production.obj.ProductionOrder"
xmlns:n2="com.cisag.app.purchasing.obj.PurchaseOrder
com.cisag.app.purchasing.obj.PurchaseOrder"
xmlns:n1="com.cisag.app.sales.obj.SalesOrder
com.cisag.app.sales.obj.SalesOrder" exclude-result
result-prefixes="n5
n4 n3 n2 n1 xsl" >
<xsl:template match="n1:semiramis">
match
<input>
<user game="1"
game group="1" period="1"/>
<qualitycontrol
qualitycontrol type="no" losequantity="0" delay="0"/>
delay
<sellwish
sellwish>
<xsl:for-each select="n1:SalesOrder/n1:Details
n1:SalesOrder/n1:Details">
<item>
60
<xsl:attribute
name="article"><xsl:value-of
select="substring(n1:Item/n1:number,2)"/></xsl:attribute>
<xsl:attribute
name="quantity"><xsl:value-of
select="n1:totalQuantity/n1:amount"/></xsl:attribute>
</item>
</xsl:for-each>
</sellwish>
<orderlist>
<xsl:apply-templates
select="document('02_PurchaseOrder.xml')"/>
</orderlist>
<productionlist>
select="document('03_ProductionOrder.xml')"/>
</productionlist>
<workingtimelist>
select="document('04_Resource.xml')"/>
</workingtimelist>
</input>
</xsl:template>
<xsl:for-each select="n2:PurchaseOrder/n2:Details">
<order>
<xsl:attribute name="article"><xsl:value-of
select="substring(n2:Item/n2:number,2)"/></xsl:attribute>
<xsl:attribute name="quantity"><xsl:value-of
select="n2:totalQuantity/n2:amount"/></xsl:attribute>
<xsl:attribute name="modus"><xsl:value-of
select="n2:reference"/></xsl:attribute>
</order>
</xsl:for-each>
</xsl:template>
<xsl:for-each-group
select="//n3:ProductionOrder|//n3:ProductionOrder/n3:Details" group-
by="n3:Item/n3:number">
<xsl:if test="substring(current-grouping-key(),1,1) !=
'K'">
<production>
<xsl:attribute name="article"><xsl:value-of
select="substring(current-grouping-key(),2)"/></xsl:attribute>
<xsl:attribute name="quantity"><xsl:value-
of select="sum(current-group()/n3:quantity/n3:amount)"/></xsl:attribute>
</production>
</xsl:if>
</xsl:for-each-group>
</xsl:template>
<xsl:for-each select="n4:Resource[n4:code != 'MA100']">
<workingtime>
<xsl:attribute name="station"><xsl:value-of
select="n4:code mod 100"/></xsl:attribute>
61
<xsl:attribute name="shift"><xsl:value-of
select="substring(n4:TimeModel/n4:code,1,1)"/></xsl:attribute>
<xsl:variable name="currCode"
select="n4:TimeModel/n4:code"/>
<xsl:choose>
<xsl:when test="$currCode mod 100 = 0">
<xsl:attribute
name="overtime">0</xsl:attribute>
</xsl:when>
<xsl:otherwise>
<xsl:attribute
name="overtime"><xsl:value-of
select="document('05_WeekTimeModel.xml')/n5:semiramis/n5:WeekTimeModel[n5
:code =
$currCode]/n5:Details[position()=last()]/n5:ModelMonday/n5:availableTime
div 60000"/></xsl:attribute>
</xsl:otherwise>
</xsl:choose>
</workingtime>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
Das Stylesheet ist ein im XML-Format verfasstes Dokument, welches die
Transformationsvorschriften enthält. XSLT-Dokumente beginnen, genauso wie XML-Dokumente,
mit der XML-Deklaration. Anschließend kommt das root-Element </xsl:stylesheet> in dem
auch die Version festgelegt werden muss. Damit das Dokument als XSLT-Dokument angesehen
wird, muss außerdem der Namespace xsl mit der URL http://www.w3.org/1999/XSL/Transform
109
definiert werden.
Die Namespacedeklaration wie zum Beispiel
xmlns:n5="com.cisag.app.general.obj.WeekTimeModel" definieren auf welche XML-
Dokumente für die Transformation zugegriffen werden soll. Dadurch kann verhindert werden, dass
bei der Verwendung mehrerer XML-Dokumente Konflikte bezüglich der Bezeichnung der Elemente
110
auftreten. Der Namespace-URI wird einem spezifischen Präfix zugeordnet, in diesem Beispiel
„n5“. Dabei muss der Namensraum im XSL-Dokument mit dem im XML-Dokument
übereinstimmen.
Das Ziel der Verwendung von XML-Namespaces besteht darin, Elemente und Attribute aus
unterschiedlichen Markup-Vokabeln eindeutig zu identifizieren. „Ein XML-Namespace ist eine
Sammlung von Namen, die von einem Verweis auf einen URI (Uniform Resource Identifier)
111
identifiziert und in XML-Dokumenten als Element- und Attributnamen verwendet werden.“
Zu Beginn des eigentlichen Inhalts des Dokuments werden einige Fixwerte festgelegt, die ins
Zieldokument geschrieben werden, ohne dass sie einen weiteren Input verlangen. Diese geben
unter anderem den Gruppenennamen und die Periode in der sich die Simulation befindet, an.
109
Vgl. http://www.w3schools.com/Xsl/ (10.2.2009)
110
Vgl. http://www.w3schools.com/Xsl/ (10.2.2009)
111
http://msdn.microsoft.com/de-de/library/ms950779.aspx (10.2.2009)
62
Unter dem Element „sellwish“ soll der Parser im Dokument „n1“ also dem Vertriebsauftrag
(SalesOrder), zum Element „item“ unter „Details“ gehen, und dort die Werte aus „amount“ und
„number“ ziehen. Das Template „xsl:for-each“ legt fest, dass der Parser das Eltern-Element
„Details“ sooft nach den gesuchten Elementen durchsucht, bis er alle Geschwister-Elemente
durchlaufen hat. Die Werte aus dem Element „number“ werden im Zieldokument dem Element
„article“ zugeordnet. Zuvor werden die Werte jedoch insofern verändert, dass ihnen die erste Stelle
der Bezeichnung gelöscht wird. So wird beispielsweise aus der Artikelbezeichnung „P1“ in
Semiramis der Artikel „1“ in SCSim. Der Befehl für diese Aktion lautet „substring“: danach wird die
Datenherkunft definiert und anschließend mit der Ziffer nach dem Komma angegeben, ab welcher
Stelle die Werte übernommen werden.
Das Element „quantity“ im Zieldokument zieht seine Daten aus dem Element „amount“ im
exportierten Vertriebsauftrag.
Danach werden für die Elemente „orderlist“, „productionlist“ und „workingtimelist“ die
Quelldokumente definiert.
Anschließend werden für die untergeordneten Elemente dieser Elemente die
Transformationsvorschriften festgelegt. So müssen aus jedem exportierten Beschaffungsauftrag
(PurchaseOrder) Werte für die Elemente „article“, „quantity“ und „modus“ in das Zieldokument
geschrieben werden. Über die bekannten Templates werden die genauen Elemente des
Quelldokuments für die nötigen Informationen angesprochen und gegebenenfalls verändert.
Das Zieldokument fordert bezüglich der Produktionsaufträge Daten für die Elemente „article“ und
„quantity“. Die passenden Informationen kommen aus dem Quelldokument „ProductionOrder“ aus
den Elementen „number“ und „amount“. Allerdings gibt es zwei verschiedene Ebenen im
Quelldokument in denen diese Elemente vorkommen. Die Daten aus beiden müssen ins
Zieldokument transferiert werden.
<xsl:for-each-group
select="//n3:ProductionOrder|//n3:ProductionOrder/n3:Details" group-
by="n3:Item/n3:number">
Dieses Template definiert mehrere Dinge:
For-each-group: gruppiert die Elemente nach dem unter „group-by“ definierten Element.
- "//n3:ProductionOrder|//n3:ProductionOrder/n3:Details": im Quelldokument
“n3” soll sowohl unter dem Element „ProductionOrder”, als auch unter dem untergeordneten
Element „Details“ nach den Elementen „number“ und „amount“ gesucht werden. Dies wird
durch folgendes Symbol definiert: „|“
- group-by: definiert nach welchen Elementen die Werte im Zieldokument gruppiert werden
sollen.
Der Befehl „sum“ mit dem anschließend angegebenen Element „amount“ veranlasst, dass die
Mengen aus dem Quelldokument im Zieldokument nach Artikelkennungen summiert werden. Dies
hat zur Folge, dass jeder Artikel nur einmal in der Productionlist in SCSim vorkommt. Dadurch geht
leider die genaue Reihenfolge der Produktionsaufträge verloren. Da in Semiramis jedoch weit
63
mehr als die in SCSim mögliche Anzahl an Produktionsaufträgen generiert wird, ist dies die einzige
Möglichkeit.
Als letztes werden noch die Ressourcen mit den dazugehörigen Schichten und Überstunden
festgelegt. Als erstes wird die Ressource mit dem „code“ „MA100“ ausgeschlossen.
Die workingtimelist besteht immer aus 13 Positionen und erhält Daten aus den Exporten
„Ressource“ und „WeekTimeModell“. Die in Semiramis angelegte Ressource „MA100“ (Mitarbeiter)
wird in Scsim nicht verwendet und daher ausgeschlossen.
Die Werte der „station“ bleiben immer unverändert. Falls
<TimeModel><code>100</code></TimeModel> wird der Wert von “shift” 1 und „overtime“ 0. Das
XSL-Dokumnet schreibt vor, dass für den Wert „shift“ jeweils die erste Ziffer des Wertes aus
„TimeModel/code“ genommen wird.
Der folgende Ausdruck definiert, dass wenn der Wert des TimeModel durch 100 dividiert wird und
der Rest 0 beträgt, auch der Wert von „overtime“ 0 beträgt. Somit werden für die Zeitmodelle 100,
200 und 300 automatisch keine Überstunden veranlasst.
<xsl:when test="$currCode mod 100 = 0">
<xsl:attribute name="overtime">0</xsl:attribute>
Hat „TimeModel“ jedoch einen anderen Wert also 100, 200 oder 300, so muss aus dem XML-
Dokument „WeekTimeModel“ der Wert für die Überstunden ermittelt werden.
Dieser Wert ist als „code/availableTime“ in 1/1000 Sekunden angegeben. Dieser Wert kann
variieren und muss in Minuten umgerechnet werden. Dies wird in folgendem Ausschnitt fetsgelegt:
- <xsl:otherwise>
- <xsl:attribute name="overtime">
<xsl:value-of
select="document('05_WeekTimeModel.xml')/n5:semiramis/n5:Week
TimeModel[n5:code =
$currCode]/n5:Details[position()=last()]/n5:ModelMonday/n5:av
ailableTime div 60000" />
Die Vorgehensweise für alle „TimeModel“ ist in der untenstehenden Tabelle zusammenfassend
dargestellt. Es ist darauf zu achten, dass das „TimeModel“ mit dem „WeekTimeModel“
übereinstimmt.
64
„shift“ „WeekTimeModel“ „overtime“
„TimeModel“
100 1 Nicht relevant 0
151-165 1 <code>140</code> =availableTime
<availableTime>14400000</availableTime> →14400000/1000sek
=240min
251-265 2 <code>150</code> 240min
Tabelle 4: Ressourcenkapazitäten
Das Ergebnis dieser Transformation ist ein XML-Dokument, das in SCSim über die Anwendung
„Simulation (XML-File)“ auf http://www.iwi.hs-karlsruhe.de/scs/start importiert werden kann. Der
Import löst gleichzeitig auch die Simulation der gesamten Planspielperiode aus. Anschließend
können die Ergebnisse anhand verschiedenster Tabellen und Diagramme analysiert werden.
Zusätzlich ist eine Gesamtdarstellung der Ergebnisse als XML-Dokument vorhanden. Die
Ergebnisse sollen wieder in Semiramis importiert werden. Dazu muss die Struktur des XML-
Dokuments mit Hilfe von XSLT transformiert werden.
5.3.3 Datentransfer von SCSim nach Semiramis

Der Datenimport in Semiramis kann manuell über die Anwendung „Daten importieren“ oder
automatisch über die Anwendung „Daten automatisch importieren“, beide im Framework „System-
Management“, erfolgen. Bei beiden Methoden müssen die zu importierenden Dateien auf den
Knowledge Store gespeichert werden. Auf diesen kann Semiramis zugreifen und die Daten
verwenden.
Nach der Simulation in SCSim müssen die erledigten oder teilweise erledigten Produktions- und
Beschaffungsaufträge an Semiramis gemeldet werden. Dies geschieht über den Import von
Wareneingängen. Da die Produktionsaufträge in Losgrößen zu 10 Stück aufgesplittet werden, gibt
es zwar Arbeitsaufträge, die nicht komplett erledigt wurden, was beim Import nach Semiramis
jedoch keine Produktionsaufträge in den Status „teilweise erledigt“ bewegt. Da in Semiramis alle
Produktionsaufträge mit einer zu produzierenden Menge von 10 Stück eingelastet wurden, werden
solche entweder erledigt oder nicht.
65
5.3.3.1 Wareneingang aus Produktion
Um die produzierte und beschaffte Ware an Semiramis zu melden, muss ein „Wareneingang“
importiert werden. Für den Import eines Wareneingangs von produzierten Waren in Semiramis
sind mindestens die folgenden Werte für die Basis anzugeben:
- Lieferempfänger (InventoryOrganizationPartner)
- Wareneingangsart (ReceiptOfGoodsType)
Für die Wareneingangsposition aller Wareneingangsarten sind mindestens die folgenden Attribute
als Details zwingend:
- Lieferscheinposition (deliverySlipDetailNumber)
- Artikel (Item)
- Gesamtmenge (totalQuantity)
- Lagerort (storageArea.warehouse)
Die in Semiramis zu importierende Datei sieht beispielsweise wie folgt aus:
<?xml version="1.0" encoding="UTF-8"?>
<semiramis xmlns="com.cisag.app.purchasing.obj.ReceiptOfGoods"
xsi:schemaLocation="com.cisag.app.purchasing.obj.ReceiptOfGoods
ReceiptOfGoods.xsd" created="2008-03-07T10:17:50.529Z" locale="en-US-
XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
nlsMode="MULTI_LANGUAGE" dateTimeMode="COMPACT">
- <ReceiptOfGoods xmlns="com.cisag.app.purchasing.obj.ReceiptOfGoods">
<deliverySlip />
- <InventoryOrganizationPartner>
<number>00000</number>
</InventoryOrganizationPartner>
- <ReceiptOfGoodsType>
<code>200</code>
</ReceiptOfGoodsType>
<SupplierPartner xsi:nil="true" />
- <Details>
<deliverySlipDetailNumber>0</deliverySlipDetailNumber>
- <totalQuantity>
- <Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
- <storageArea>
<warehouse>100</warehouse>
</storageArea>
- <Item>
<number>P1</number>
</Item>
</Details>
</ReceiptOfGoods>
</semiramis>
Der Wert „ReceiptOfGoodsType“ signalisiert, ob es sich um einen Wareneingang aus Produktion

oder Beschaffung handelt (100 für Beschaffung, 200 für Produktion).
Die „Ergebnisliste XML“ aus SCSim enthält die folgend dargestellten Informationen aus der
Produktion, die Restlichen müssen ergänzt werden.
<completedorders>
66
<order period="1" id="1" item="51" quantity="100" cost="13757,00"
averageunitcosts="137,57">
<batch id="1" amount="10" cycletime="70" cost="1384,70" />
</order>
</completedorders>
Bis auf die Menge kann kein Wert direkt übernommen werden. Für Wareneingänge aus Produktion
muss bei den Artikeln der Buchstabe P oder E vor der jeweiligen Ziffer ergänzt werden. Alle
anderen Werte, die Semiramis verlangt, sind gar nicht vorhanden und müssen hinzugefügt werden.
Die Wareneingänge aus Produktion werden ein Mal pro Periode, direkt nach der Simulation, in
SCSim gebucht. Da die Produktionsaufträge in Losgrößen von 10 Stück erstellt werden, gibt es
entweder erledigte Aufträge die komplett rückgemeldet werden, oder nicht erledigte Aufträge die
noch abgearbeitet werden müssen. Die erledigten Produktionsaufträge werden als Wareneingang
importiert.
Die noch nicht erledigten Produktionsaufträge werden von der Materialbedarfsplanung
berücksichtigt. Dabei ist zu beachten, dass einmal ausgegebene Produktionsaufträge, die in
SCSim veranlasst wurden, in Semiramis nicht gelöscht werden dürfen, da in SCSim keine
Möglichkeit besteht diese zu entfernen.
5.3.3.2 Wareneingang aus Beschaffung
Um die beschaffte Ware an Semiramis zu melden, muss ein Wareneingang aus Beschaffung
importiert werden. Dabei sind für die Basis folgende Werte anzugeben:
- Lieferempfänger (InventoryOrganizationPartner)
- Wareneingangsart (ReceiptOfGoodsType)
- Fremdbelegsnummer (deliverySlip)
- Lieferpartner (SupplierPartner)
Für die Wareneingangsposition aller Wareneingangsarten sind mindestens die folgenden Attribute
zwingend:
- Lieferscheinposition (deliverySlipDetailNumber)
- Artikel (Item)
- Gesamtmenge (totalQuantity)
- Lagerort (storageArea.warehouse)
Die „Ergebnisliste XML“ enthält nicht alle geforderten Informationen. Das bedeutet, dass die
fehlenden Informationen ergänzt werden müssen. Dies geschieht mit Hilfe des XSLT-Prozessors.
67
Eine XML-Datei für einen entsprechenden Minimal-Datensatz mit fachlichen Attributen für einen
Wareneingang aus Beschaffung hat z. B. den folgenden Inhalt:
<semiramis xmlns="com.cisag.app.purchasing.obj.ReceiptOfGoods"
xsi:schemaLocation="com.cisag.app.purchasing.obj.ReceiptOfGoods
ReceiptOfGoods.xsd" created="2008-03-07T10:17:50.529Z" locale="en-US-
XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
nlsMode="MULTI_LANGUAGE" dateTimeMode="COMPACT">
<ReceiptOfGoods xmlns="com.cisag.app.purchasing.obj.ReceiptOfGoods">
<deliverySlip>0</deliverySlip>
<SupplierPartner>
</SupplierPartner>
<InventoryOrganizationPartner>
<ReceiptOfGoodsType>
<code>100</code>
<Details>
<totalQuantity>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<storageArea>
</storageArea>
<Item>
</Item>
</Details>
</ReceiptOfGoods>
Der Wert „ReceiptOfGoodsType“ beträgt „200“, was signalisiert, dass es sich um einen
Wareneingang aus Beschaffung handelt
Der folgende Ausschnitt ist wiederum aus der „Ergebnisliste XML“, jedoch für die Wareneingänge
aus Beschaffung.
<inwardstockmovement>
<order orderperiod="1" id="2" mode="5" article="36" amount="500"
time="10080" materialcosts="4000,00" ordercosts="100,00"
entirecosts="4100,00" piececosts="8,20" />
<order orderperiod="1" id="1" mode="5" article="34" amount="3200"
time="12960" materialcosts="320,00" ordercosts="50,00"
entirecosts="370,00" piececosts="0,12" />
</inwardstockmovement>
Bis auf die Menge kann auch hier kein Wert direkt übernommen werden. Für die Artikel muss
jeweils ein E vor der Ziffer ergänzt werden. Alle anderen Werte die Semiramis verlangt müssen
ergänzt werden.
Die erhaltenen Lieferungen der Beschaffungsartikel werden als Wareneingänge gebucht und über
die Anwendung „Eingangsrechnungen“ fakturiert, bevor sie komplett erledigt sind.
Noch nicht eingegangene Lieferungen, die jedoch bestellt wurden, werden nicht rückgemeldet und
bleiben dadurch offen. Die Materialbedarfsplanung berücksichtigt diese offenen Bestellungen mit
68
den erwarteten Lieferdaten.
5.3.4 Umsetzung der Datentransformation

Die Datentransformation von SCSim nach Semiramis wird mit demselben Programm durchgeführt
wie für den Import in SCSim. Die dafür verwendeten Dateien wurden bereits beschrieben. In
diesem Abschnitt wird auf das XSL-Dokument eingegangen, welches die Struktur und den Ablauf
der Transformation vorschreibt. Das dazu verwendete Programm ist Kernow 1.6.1b3.
Das XSL-Dokument, das die Transformation der Daten von SCSim nach Semiramis regelt, sieht
wie folgt aus.
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="com.cisag.app.purchasing.obj.ReceiptOfGoods" exclude-result-
prefixes="xsl" >
<xsl:template match="/results">
<semiramis>
select="inwardstockmovement|completedorders"/>
</semiramis>
</xsl:template>
<xsl:template match="inwardstockmovement">
<ReceiptOfGoods>
<SupplierPartner>
</SupplierPartner>
<code>100</code>
<xsl:for-each select="order">
<Details>
<totalQuantity>
<amount>
<xsl:value-of
select="@amount"/>
</amount>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<storageArea>
</storageArea>
<Item>
<number>
<xsl:choose>
69
<xsl:when test="some $x in
(1,2,3) satisfies $x=@article">P<xsl:value-of
select="@article"/></xsl:when>
(4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,26,29,30,31,49,50,51,54,55,
56) satisfies $x=@article">E<xsl:value-of select="@article"/></xsl:when>
(21,22,23,24,25,27,28,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,
52,53,57,58,59) satisfies $x=@article">K<xsl:value-of
select="@article"/></xsl:when>
</xsl:choose>
</number>
</Item>
</Details>
</xsl:for-each>
</ReceiptOfGoods>
</xsl:template>
<xsl:template match="completedorders">
<ReceiptOfGoods>
<SupplierPartner>
</SupplierPartner>
<code>200</code>
<xsl:for-each select="order">
<Details>
<totalQuantity>
<amount>
<xsl:value-of
select="@quantity"/>
</amount>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<storageArea>
</storageArea>
<Item>
<number>
<xsl:choose>
(1,2,3) satisfies $x=@item">P<xsl:value-of select="@item"/></xsl:when>
(4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,26,29,30,31,49,50,51,54,55,
56) satisfies $x=@item">E<xsl:value-of select="@item"/></xsl:when>
(21,22,23,24,25,27,28,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,
52,53,57,58,59) satisfies $x=@item">K<xsl:value-of
select="@item"/></xsl:when>
</xsl:choose>
</number>
</Item>
</Details>
70
</xsl:for-each>
</ReceiptOfGoods>
</xsl:template>
</xsl:stylesheet>
Das Ergebnis dieser Transformation muss ein XML-Dokument mit der Struktur von
„08_ReceiptOfGoods.xml“ sein. Da in Semiramis Wareingänge aus Beschaffung und Produktion
über dieselbe Anwendung verbucht werden, werden aus SCSim sowohl Werte aus der Bestellliste,
wie der erledigten Produktionsaufträge in einem XML-Dokument dargestellt. Allerdings unter zwei
getrennten Eltern-Elementen, die jeweils eine andere Wareneingangsart darstellen:
Dabei ist für Wareneingang aus Beschaffung Folgendes zu beachten:

- <deliverySlip>0</deliverySlip> wird als Fixwert eingetragen
- <SupplierPartner><number>20010</number></SupplierPartner> wird als Fixwert
eingetragen
- <InventoryOrganizationPartner><number>00000</number></InventoryOrganizationPartner
> wird als Fixwert eingetragen
- <ReceiptOfGoodsType><code>100</code></ReceiptOfGoodsType> bedeutet dass es
sich um einen Wareneingang aus Beschaffung handelt. Dass heißt, werden die Werte aus
der Datei „07_output.xml“ aus dem Bereich <inwardstockmovement> genommen, muss
<ReceiptOfGoodsType> den Wert 100 haben.
- <xsl:template match="inwardstockmovement"> befiehlt Informationen aus
dem Abschnitt “Inwardstockmovement” zu beziehen
- <deliverySlipDetailNumber>0</deliverySlipDetailNumber> wird als Fixwert eingetragen
- <totalQuantity><amount>3200</amount> erhält ihren Wert aus <order article="34"
amount="3200" />. Da die Mengen als Attribute angegeben warden, wird über
<xsl:value-of select="@amount" /> auf diese zugegriffen.
- <Uom><code>Stk</code></Uom> wird als Fixwert eingetragen
- <storageArea><warehouse>100</warehouse></storageArea> wird als Fixwert eingetragen
- <Item><number>K34</number></Item> erhält ihren Wert aus <order article="34"
amount="3200" />, der Buchstabe K muss ergänzt werden.
- <Item>
- <number>
- <xsl:choose>
- <xsl:when test="some $x in
(21,22,23,24,25,27,28,32,33,34,35,36,37,38,39,40,41,42,4
3,44,45,46,47,48,52,53,57,58,59) satisfies $x=@article">
K
<xsl:value-of select="@article" />
71
</xsl:when>
</xsl:choose>
</number>
</Item>
- Der obenstehende Abschnitt legt fest, dass falls der Artikel in SCSim einen der in
Klammern stehenden Werte hat, ein K ergänzt wird.
Für Wareneingänge aus Produktion ändert sich lediglich die Wareneingangsart, und die
Datenherkunft der Menge und des Artikels:
- <ReceiptOfGoodsType><code>200</code></ReceiptOfGoodsType> hat den Wert
200, da es sich um einen Wareneingang aus Produktion handelt. Das bedeutet, wenn
die Werte aus der Datei „07_output.xml“ aus dem Bereich <completedorders>
kommen, muss <ReceiptOfGoodsType> den Wert 200 haben.
- <totalQuantity><amount>100</amount> erhält ihren Wert aus <order item="51"
quantity="100">
- <Item><number>E51</number></Item> erhält ihren Wert aus<order item="51"
quantity="100"> Der Buchstabe K wird auf selbe Weise wie bei Wareneingängen aus
Beschaffung ergänzt.
Die Datei, die man durch die Transformation erhält, entspricht der Struktur der Datei
„08_ReceiptOfGoods.xml“, welche über den Knowledge Store in Semiramis importiert wird.
5.4 Ablauf
Im Folgenden wird der Ablauf des Planspiels beschrieben, wobei sowohl auf die Aufgaben der
Studierenden, als auch auf den Datenaustausch eingegangen wird.
Beim Modellbetrieb handelt es sich um ein Unternehmen, dass drei Typen von Fahrrädern
produziert: Kinder-, Damen- und Herrenfahrräder. Aufgabe der Teilnehmer ist es, auf Grund einer
vorgegebenen Nachfrage, Entscheidungen über Bestellungen, Produktionsaufträge und
Produktionskapazitäten zu treffen. Ziel ist es, die vorhandenen Ressourcen möglichst effizient zu
nutzen.
72
Abbildung 21:: Ablauf des Planspiels
Das Planspiel ist in mehrere jeweils gleich ablaufende Perioden unterteilt und wird in Teams von
ca. 3-6
6 Personen bearbeitet. Jedes Team hat seinen eigenen Mandanten,
Mandanten, da sich die Gruppen
ansonsten gegenseitig die Einstellungen der Zeitmodelle oder Mindestbestände verstellen würden.
Zu Beginn jeder Periode teilt
tei die Spielleitung den Gruppen über eine
e Vertriebsanfrage in
Semiramis die am Ende der Periode zu liefernde
liefernde Menge der drei Endprodukte mit. Die Gruppen
wandeln diese in Vertriebsangebote um, welche wiederum zur Generierung von Vertriebsaufträgen
dienen. Nachdem der Vertriebsauftrag, in dem der angefragte Leistungsumfang mit Menge und
Termin definiert ist, abgespeichert
bgespeichert wurde, kann die Auftragsbestätigung erzeugt und ausgegeben
werden. Dies erfolgt in der Anwendung „Vertriebsaufträge“ mit Hilfe des „Aktionen-Button“
„Aktionen und der
Aktion „Auftragsbestätigung
tigung erzeugen und ausgeben“. Anschließend sind die Menge und der
de
Termin für die Auslieferung der Artikel im System und für die Materialbedarfsplanung relevant.
Aufgabe der Teilnehmer ist es jetzt, für die laufende Periode die Ressourcenkapazitäten über
Schichten und Zeitmodelle möglichst optimal an den Produktionsplan anzupassen und für die
folgenden Perioden Materialien zu beschaffen. Dafür stehen ihnen mehrere Hilfsmittel zur
Verfügung. Zum Einen
inen können sie mit den Formularen aus dem SCSim Handbuch händisch einen
Produktionsplan erstellen. Dies erscheint vor allem in den ersten Perioden sehr sinnvoll, um den
Studenten einen Überblick über die Logiken und Prozesse der Produktionsplanung zu vermitteln.
Die manuell ermittelten Ergebnisse sollten die folgenden Informationen enthalten:
enthalten
- Die Menge der zu beschaffenden Materialien und deren Bestellmodus
- Die Menge der zu produzierenden
produzierende Halbfabrikate und Endprodukte und die Reihenfolge in der
diese bearbeitet werden sollen
- Die Kapazitäten der einzelnen Ressourcen
73
Anschließend kann in Semiramis die Materialbedarfsplanung durchgeführt werden. Diese generiert
Beschaffungsvorschläge für Materialien abhängig vom Bedarf in der laufenden Periode, dem
prognostizierten Bedarf der folgenden Perioden und dem in der Dispositionssicht der
Beschaffungsartikel festgelegten Mindestbestand. Produktionsvorschläge werden abhängig vom
gewählten Terminierungsverfahren, dem aktuellen Lagerbestand und dem gewünschten
Liefertermin erstellt. Die Produktionsvorschläge können anschließend in Produktionsaufträge
umgewandelt werden. Dadurch werden die benötigten Ressourcen für die jeweiligen
Produktionsschritte reserviert und in der Anwendung „Ressourcenauslastung“ sichtbar. Dort
können die Teilnehmer erkennen, welche Ressourcen wie stark ausgelastet sind. Bei Bedarf
können die Kapazitäten der Arbeitsplätze angepasst werden. Dies kann so oft wiederholt werden,
bis die Auslastung optimal erscheint. Die Anpassung der Kapazitäten erfolgt über das
Wochenzeitmodell und die jeweils dazugehörigen Zeitmodelle, die der Ressource hinterlegt sind.
Sind Kapazitäten und Produktionsplan ausreichend aufeinander abgestimmt, können die
Produktionsvorschläge über die Aktion „Produktionsaufträge erzeugen, einlasten, freigeben und
ausgeben“ weiterbearbeitet werden. Nach diesem Schritt ist für die jeweilige Periode bezüglich der
Produktion alles erledigt.
74
112
Abbildung 22: Prozessablauf Produktionsaufträge
Die Beschaffungsvorschläge werden von der Materialbedarfsplanung aufgrund des Bedarfs an

Materialien, dem angegebenen Mindestbestand und der Wiederbeschaffungszeit kalkuliert. Ein
Beschaffungsvorschlag stellt eine Empfehlung dar, welche Artikel mit welcher Menge bis zu
welchem Zeitpunkt bestellt werden sollen. Die Bestellmenge ist dabei die Menge des Artikels die
bestellt werden muss, damit der Bestand nicht unter den in der Dispositionssicht des Artikels
definierten Mindestbestand absinkt. Der Mindestbestand der Beschaffungsartikel ist zu Beginn auf
Null festgelegt. Dies ist zwar nicht sinnvoll, jedoch sollen sich die Teilnehmer selbst Gedanken
über sinnvolle Mindestbestände machen. Dies sollte unter Berücksichtigung der
Wiederbeschaffungszeit und dem prognostizierten Bedarf in den folgenden Perioden geschehen.
Die Teilnehmer haben also die Möglichkeit, den Beschaffungsbedarf manuell zu berechnen und
auch manuell als Beschaffungsaufträge einzugeben. Außerdem können sie vernünftige
Mindestbestände kalkulieren und Beschaffungsvorschläge durch die Materialbedarfsplanung
generieren lassen. In diesem Fall können die automatisch erzeugten Beschaffungsvorschläge in
der Abfrageanwendung „Beschaffungsvorschläge“ individuell angepasst oder gelöscht werden,
112
Semiramis Hilfe „Produktionsvorschläge“ (2007); S.3
75
bevor sie über die Aktion „Beschaffungsaufträge erzeugen“ in Beschaffungsaufträge umgewandelt
werden. Den Beschaffungsaufträgen muss noch hinzugefügt werden, in welchem Bestellmodus
(„Normal“ oder „Eil“) sie ausgegeben werden. Dies erfolgt über die Angabe einer Ziffer im
Positionseditor, unter dem Karteireiter „Allgemeines“ im Feld „Bezug“. Angaben in diesem Feld
haben keine Auswirkungen auf den Prozess in Semiramis sondern dienen nur als Möglichkeit,
zusätzliche Informationen zu verarbeiten. Im Rahmen des Planspiels wird es dazu verwendet, den
Bestellmodus für die Simulation in SCSim festzulegen. Wird im Feld „Bezug“ der Wert 5
eingetragen, werden die Materialien „Normal“ bestellt, wird der Wert 4 eingetragen, wird im „Eil“-
Modus bestellt. Die Materialbedarfsplanung kann die durch den „Bezug“ veränderten Lieferzeiten
nicht berücksichtigen.
113
Abbildung 23: Prozessablauf Beschaffungsaufträge
Nachdem Produktionsaufträge, Ressourcenkapazitäten und Beschaffungsaufträge festgelegt

wurden, werden alle nötigen Informationen aus Semiramis exportiert um in SCSim importiert zu
werden. Der Datenexport aus Semiramis erfolgt über die Anwendung „Daten exportieren“ im
Framework „System-Management“. Dazu werden die in Punkt 5.2.7. erläuterten Filter verwendet.
Beispielhaft exportierte XML-Dokumente für alle sieben Business Entitys finden sich im Anhang.
Diese Dateien finden sich nach dem Export auf dem Knowledge Store, von wo aus sie mit Hilfe
eines Programms zu einem XML-Dokument zusammengefasst werden, das wie folgt aussehen
kann.
113
Aus Semiramis Hilfe „Beschaffungsvorschläge“ (2007); S.4
76
<input>
<user game="1" group="1" period="1" />
<qualitycontrol type="no" losequantity="0" delay="0" />
<sellwish>
<item article="1" quantity="200" />
</sellwish>
<selldirect>
<item article="1" quantity="0" price="0.0" penalty="0.0" />
</selldirect>
<orderlist>
<order article="34" quantity="3200" modus="5" />
<order article="36" quantity="500" modus="5" />
</orderlist>
<productionlist>
<production article="51" quantity="130" />
</productionlist>
<workingtimelist>
<workingtime station="1" shift="1" overtime="240" />
</workingtimelist>
</input>
Um aus den fünf XML-Dokumenten (Vertriebsauftrag, Beschaffungsauftrag, Produktionsauftrag,

Wochenzeitmodell und Zeitmodell) die aus Semiramis exportiert wurden, die relevanten Daten
(Vertriebsmenge, Vertriebsartikel, Bestellartikel, Bestellmenge, Bestellmodus, Produktionsartikel,
Produktionsmenge, Produktionsreihenfolge, Ressource, Schichten und Überstunden) in ein
Dokument zusammenzufassen, wird ein XSL-Stylesheet und ein XSLT-Prozessor verwendet.
Die Simulation erfolgt durch den Import der „Import-XML“ File in die Anwendung „Simulieren (XML-
Datei)“. Nach der Simulation stehen die Resultate der Planperiode gesammelt in der „Ergebnisliste
XML“ bereit. Daneben sind auch eine Vielzahl von Tabellen und Graphiken zur genauen Analyse
der Prozesse und Ergebnisse der Planperiode vorhanden. Dadurch ist es den Teilnehmern
möglich, die Ursachen für den Verlauf der Planperiode und deren Ergebnisse zu analysieren.
Für den weiteren Verlauf des Planspiels müssen die Ergebnisse aus Produktion und Beschaffung,
also welche Artikel in welcher Menge produziert oder empfangen wurden, in Semiramis gebucht
werden. Dazu muss eine XML-Datei, die alle nötigen Attribute für den Import als Wareneingang
enthält, auf den Knowledge Store gespeichert werden. Der Datenimport in Semiramis kann
77
manuell über die Anwendung „Daten importieren“ oder automatisch über die Anwendung „Daten
automatisch importieren“, beide im Framework „System-Management“, erfolgen.
Sobald die Daten im System sind, können sie mit den entsprechenden Produktions- und
Beschaffungsaufträgen verknüpft und gebucht werden. Dadurch sind für die kommenden Perioden
alle relevanten Informationen in Semiramis gespeichert. Die neuen Lagerbestände sind im System,
die sich für die meisten Artikel durch den Verbrauch von Materialien und das Eintreffen von
Lieferungen geändert haben. Noch nicht erledigte Produktions- und Beschaffungsaufträge sind
noch im System und müssen abgearbeitet bzw. abgewartet werden. Diese werden auch von der
Materialbedarfsplanung berücksichtigt.
Die Buchung der Wareneingänge aus Beschaffung und Produktion stellt das Ende einer
Planperiode dar. Anschließend können die Teilnehmer mit Hilfe der Tabellen und Graphiken, die
SCSim automatisch erstellt, die abgelaufene Periode analysieren. Dabei sollte besonders auf
Probleme geachtet werden, beispielsweise wo Produktionsengpässe auftraten oder welche
Lagerbestände sich dem Ende neigen. Aufbauend auf dieser Analyse kann, sobald der
Primärbedarf für die nächste Periode bekannt gegeben wurde, ein neuer Produktionsmix erstellt
werden.
5.5 Kompromisse und Probleme

Die Umsetzung des Planspiels hat einige Schwierigkeiten in der technischen Umsetzung mit sich
gebracht. Die Grundlage für die Verknüpfung der beiden Programme bildet die Abbildung der
Prozesse aus SCSim in Semiramis. Dabei wurde versucht, so detailgetreu wie möglich alle
Einzelheiten in Semiramis mit einzubeziehen. Dies war in einem Punkt jedoch nicht möglich: Im
Semiramis Standard können keine stochastischen Wahrscheinlichkeiten bezüglich der Lieferzeiten
abgebildet werden.
In SCSim werden Lieferungen innerhalb eines bestimmten Zeitraums erwartet. In Semiramis wird
ein konkreter Wert angegeben, der die Wiederbeschaffungszeit, also die kalkulierte Zeit zwischen
Bestellung und Eintreffen der Lieferung, festlegt. Für das Planspiel selbst stellt diese
Ungenauigkeit kein Problem dar. Da in Semiramis der Produktionsmix erstellt wird, in SCSim
jedoch die eigentliche Simulation stattfindet, beeinflussen die fixen Lieferzeiten in Semiramis nur
die Planung, nicht jedoch die simulierte Realität. Man könnte sogar soweit gehen und behaupten,
dass dies der Realität in Unternehmen sehr nahe ist. Im System wird mit bestimmten Werten, die
selbst nicht zu beeinflussen sind, geplant. Ob diese dann mit der Realität übereinstimmen, zeigt
sich erst in der Zukunft.
Eine weitere Unvollständigkeit stellt der Bestellmodus dar. In SCSim kann bei der Bestellung
gegen einen höheren Preis eine kürzere Lieferzeit veranlasst werden. In Semiramis wird dies im
Rahmen des Planspiels bei der Generierung von Beschaffungsaufträgen als „Bezug“ definiert. Der
Wert des Feldes bewirkt zwar eine Veränderung des Bestellmodus bei der Simulation in SCSim,
hat jedoch keinen Einfluss auf die Materialbedarfsplanung. Dies hat für die Teilnehmer die Folge,
78
dass die Materialbedarfsplanung nur mit der „normalen“ Lieferzeit rechnet. Werden für bestimmte
Artikel „Eilbestellungen“ veranlasst, so müssen die Auswirkungen der veränderten Lieferzeiten auf
den Produktionsmix von den Studierenden selbst berechnet werden.
In Semiramis werden, falls sie mit Hilfe der Materialbedarfsplanung generiert werden, sehr viele
Produktionsaufträge mit Losgrößen zu jeweils 10 Stück ausgegeben. Da SCSim jedoch nur eine
begrenzte Anzahl bei der Eingabe der Produktionsaufträge zulässt, müssen diese
zusammengefasst werden. Somit geht auch die Reihenfolge der Abarbeitung der Aufträge
verloren.
Der Datenaustausch, der in jeder Periode und für jede teilnehmende Gruppe einmal von
Semiramis nach SCSim und einmal in umgekehrter Richtung stattfindet, erfordert einige manuelle
Schritte. Im Folgenden werden alle Schritte, die für eine Gruppe in einer Periode durchgeführt
werden müssen, noch einmal zusammenfassend dargestellt.
Zuerst müssen Vertriebsaufträge, Beschaffungsaufträge, Produktionsaufträge, Ressourcen und
Zeitmodelle mit den passenden Filtern exportiert werden. Anschließend muss man auf den
Knowledge Store zugreifen und die fünf Exporte lokal in einen Ordner speichern. In denselben
muss auch das XSL Dokument „transSEM-SCS“ gespeichert werden. Im XSL-Dokument muss von
Hand die Gruppennummer und die Nummer der aktuellen Periode angegeben werden.
Anschließend wird die Transformation gestartet, welche allerdings keine Zeit in Anspruch nimmt.
Die dadurch generierte Datei wird auf der Homepage http://www.iwi.hs-karlsruhe.de/scs/start unter
der Anwendung „Simulieren (XML-Datei)“ hochgeladen. Nach der Simulation muss die
„Ergebnisliste (XML)“ wiederum in einen lokalen Ordner gespeichert werden in dem sich auch das
XSL-Dokument „transSCS-SEM“ befindet. Das Programm Kernow 1.6.1b3 transformiert die Daten
abermals und speichert sie lokal ab. Den letzten Schritt bildet der Datenimport nach Semiramis,
der wiederum über den Knowledge Store verläuft.
Die aufgezählten Schritte müssen für jede Gruppe in jeder Periode durchgeführt werden. Der
gesamte Prozess könnte in Zukunft gänzlich automatisiert werden. Dabei würde sich die
Verwendung von Webservices anbieten. Webservices erlauben Programme, die auf
unterschiedlichen Netzwerkrechnern laufen, über das Internet miteinander zu verknüpfen.
6 Zusammenfassung und Ausblick

Die Verwendung von Planspielen in der Lehre wird als sehr effiziente Lernform angesehen, und
von den Studierenden als angenehm empfunden. Ebenso verhält es sich mit der Lehre von ERP-
Systemen in der betriebswirtschaftlichen Ausbildung. Im besten Fall sollen Studierende direkten
Kontakt zu einem solchen System haben um durch Experimente und Erfahrungen ihr Wissen und
Verständnis für betriebsinterne Prozesse zu vertiefen. Die Verwendung dieses Planspiels
kombiniert die beiden positiven Merkmale von Planspielen und ERP-Systemen: Der Umgang mit
einem ERP-System wird spielerisch im Rahmen eines IT-basierten Planspiels vermittelt.
79
Ein weiterer bedeutender Vorteil dieses Planspiels ist Folgender: Es bietet die Möglichkeit,
Studierenden die „Blackbox“ Produktion in ERP-Systemen aufzubrechen. Durch die relativ
einfache Darstellung des Produktionsprozesses im Planspiel und der Herausforderung an die
Teilnehmenden einen möglichst effizienten Produktionsmix zu erstellen, werden ihnen alle
relevanten Komponenten und ihre Wechselwirkungen nahe gebracht. Umso intensiver sie sich mit
dem Produktionsprozess beschäftigt haben, umso leichter wird es anschließend fallen, ihnen die
Anwendungen bezüglich der Produktion im ERP-System verständlich zu machen.
Neben der Verbesserung des Datenaustausch zwischen beiden Systemen wäre es interessant zu
überprüfen, wie exakt die Planung in Semiramis mit den tatsächlichen Ergebnissen in SCSim
übereinstimmt. Auch wenn es kleine Unterschiede und Ungenauigkeiten in der Abstimmung der
Systeme gibt, die es zu berücksichtigen gilt, ist es wissenswert, wie gut die Planungsergebnisse,
die die Materialbedarfsplanung in Semiramis liefert, sind. Dabei können verschiedene Paramter
wie Durchlaufzeiten oder Leerzeiten von Interesse sein. Zu diesem Zweck sollte eine empirische
Studie durchgeführt werden, die in verschiedenen Versuchen Antworten auf die gestellten Fragen
bringen soll.
80
II. Abbildungsverzeichnis
Abbildung 1: Der Integrationsgedanke bei ERP-Systemen ............................................................. 10
Abbildung 2: Die vier Phasen des erfahrungsbasierten Lernens ..................................................... 18
Abbildung 3: Systemarchitektur von Semiramis............................................................................... 26
Abbildung 4: Elemente des Fertigungsbetriebs ............................................................................... 28
Abbildung 5: Fertigungsdurchlauf..................................................................................................... 29
Abbildung 6: Lieferzeit ...................................................................................................................... 33
Abbildung 7: Kapazitäten ................................................................................................................. 35
Abbildung 8: Planspielverlauf ........................................................................................................... 37
Abbildung 9: Zuordnung der Wochenzeitmodelle zu Ressourcen ................................................... 43
Abbildung 10: Zusammensetzung eines Produktionsplans ............................................................. 44
Abbildung 11:Einbettung der Materialbedarfsplanung innerhalb des Produktionsprozesses .......... 47
Abbildung 12: Vertriebswunsch & Direktverkauf .............................................................................. 49
Abbildung 13: Verlauf des Transfers der Vertriebsdaten ................................................................. 50
Abbildung 14: Bestellungen.............................................................................................................. 51
Abbildung 15: Verlauf des Transfers der Beschaffungsdaten .......................................................... 52
Abbildung 16: Arbeitsaufträge .......................................................................................................... 53
Abbildung 17: Verlauf des Transfers der Produktionsdaten ............................................................ 54
Abbildung 18: Arbeitszeiten.............................................................................................................. 54
Abbildung 19: Verlauf der Transformation der Ressourcendaten .................................................... 56
Abbildung 20: Datentransfer von Semiramis nach SCSim .............................................................. 60
Abbildung 21: Ablauf des Planspiels ................................................................................................ 73
Abbildung 22: Prozessablauf Produktionsaufträge .......................................................................... 75
Abbildung 23: Prozessablauf Beschaffungsaufträge ....................................................................... 76
III. Tabellenverzeichnis
Tabelle 1: Liefertreue in Periode 3 ................................................................................................... 31
Tabelle 2: Liefertreue in Periode 4 ................................................................................................... 31
Tabelle 3: Teilestammdaten ............................................................................................................. 42
Tabelle 4: Ressourcenkapazitäten ................................................................................................... 65
81
IV. Literaturverzeichnis
Bücher:
Arndt, Holger: Supply Chain Management, Optimierung logistischer Prozesse; Gabler; Wiesbaden,
2004.
Bach, Mike: XSL und Xpath – verständlich und praxisnah; Transformation und Ausgabe von XML-
Dokumenten mit XSL; Addison-Wesley Verlag, München, 2000
Frick, Detlev, Andreas Gadatsch, und Ute G. Schäffer-Külz: Grundkurs SAP ERP,
Geschäftsprozessorientierte Einführung mit durchgehendem Fallbeispiel. Vieweg & Sohn Verlag;
Wiesbaden, 2008.
Gadatsch, Andreas: Grundkurs Geschäftsprozess-Management. Methoden und Werkzeuge für die

IT-Praxis: Eine Einführung für Studenten und Praktiker. Vieweg& Sohn Verlag; Wiesbaden, 2008.
Hansen, Hans Robert, Gustaf Neumann: Wirtschaftsinformatik 1, Grundlagen und Anwendungen;

Lucius & Lucius; Stuttart, 2005.
Harramach, Niki: Das Management Plan Spiel Buch, Signum- Verlag, Wien, 1992.
Manteufel, Andreas: Systeme spielen, Selbstorganisation und Kompetenzentwicklung in sozialen
Systemen; Vandenhoeck & Ruprecht, Göttingen, 1998.
Koch, Daniel: XSLT – schnell und kompakt; entwickler.press; Frankfurt, 2007.
Mertens, Peter et al: Grundzüge der Wirtschaftsinformatik; Springer Verlag; Heidelberg; Berlin,
2005.
Mertens, Peter: Integrierte Informationsverarbeitung , Operative Systeme in der Industrie. Gabler;

Wiesbaden, 2007.
Orth, Christian: Unternehmensplanspiele in der betriebswirtschaftlkichen Aus- und Weiterbildung;

Josef Eul Verlag; Lohmar, 1999.
Promberger, Kurt, Christoph Jünger, Markus Traxl, und Peter Wanka: Implementierung von ERP-
Sytemen an Universitäten. Wien - Graz: Neuer wissenschaftlicher Verlag, 2006.
Promberger, Kurt, Norbert Schlager-Weidinger, und Markus Traxl: Verwaltungsmodernisierung

durch Enterprise Resource Planning Systeme. Wien - Graz: Neuer wissenschaftlicher Verlag,
2003.
82
Rautenstrauch, C.; Schulze, T.: Informatik für Wirtschaftswissenschaftler und
Wirtschaftsinformatiker, Springer Verlag; Berlin, 2003.
Rebmann Karin: Planspiel und Planspieleinsatz, Theoretische und empirische Explorationen zu

einer konstruktivistischen Planspieldidaktik, Verlag Dr. Kovac, Hamburg, 2001.
Reichmayr, Christian: Collaboration und WebServices; Architekturen, Portale, Techniken und

Beispiele, Springer; Berlin, 2003.
Ritter, Bernhard: Enterprise Resource Planning (ERP); Pflichtenhefterstellung und Evaluation.

überarbeitete Auflage ed. Vol. 3. Heidelberg, 2005.
Sumner Mary: Enterprise Resource Planning. Pearson - Prentice Hall; New Jersey, 2005.
Wannenwetsch, H. H.; Nicolai, S: E-Supply-Chain-Management, 2. Auflage, Gabler; Wiesbaden,

2004.
Wannenwetsch, Helmut, Sascha Nicolai: E-Supply-Chain-Management, Grundlagen – Strategien –

Praxisanwendungen; Gabler; Wiesbaden, 2004.
Wannenwetsch, Helmut: Integrierte Materialwirtschaft und Logistik, Eine Einführung; Springer

Verlag; Berlin-Heidelberg, 2002.
Zeitschriften:
Davenport, T. H. (1998): Putting the Enterprise into the Enterprise System, In: Harvard Business
Review, Juli-August 1998, S. 119-121
Friedl, Gunther/Hilz, Christian/Pedell, Burkhard (2002): Integriertes Controlling mit SAP-Software.

In: Kostenrechnungspraxis 2002. 46(3). S. 161-169.)
Hawking, Paul/McCarthy, Brendan/Stein, Andrew (2005): Integrating ERP‘s Second Wave into
Higher Education Curriculum. URL: http://www.pacis-net.org/file/2005/178.pdf, (2005),
(07.01.2009)
Heinz Lothar Grob,Wilhelm Grießhaber (1995): Computergestützte Lehre an der Universität

PDF: http://miami.uni-muenster.de/servlets/DerivateServlet/Derivate-204/CALCAT1.pdf
83
Noguera, Jose/Watson, Edward (2004): Effectiveness of using an enterprise system to teach
process-centred concepts in business education. In: Journal of Enterprise Information Management
2004. 17/1. S. 56 – 74
o.A. (2003): Java-ERP Semiramis startet durch. In: Computerwoche, Nr 11, März 2003;
Watson, E. E.; Schneider, H.(1999): Using ERP Systems in Education. In: CAIS – Communications
of the AIS 1 (1999) Feb. 1999, S. Article 9.
Dissertationen:
Becker Oliver: Serielle Transformationen von XML; Probleme, Methoden, Lösungen, 2004;
Dissertation, Humbold Universität, Berlin
Schulungsunterlagen:
Dgp 2003 (2008): SCSim, SupplyChainSimulation, Version 20.08.2008
SorftM Semiramis GmbH&Co. KG(2007): Semiramis Hilfe „Vertriebsaufträge“. Ab Release 4.3,

Ausgabedatum 6/2007
SorftM Semiramis GmbH&Co. KG(2005): Semiramis Hilfe „Ressourcen“. Ab Release 4.3,

Ausgabedatum 11/2005
SorftM Semiramis GmbH&Co. KG(2005): Semiramis Hilfe „Wochenzeitmodelle“. Ab Release 4.1,

Ausgabedatum 10/2005
SorftM Semiramis GmbH&Co. KG(2006): Semiramis Hilfe „Produktionspläne“. Ab Release 4.3,

Ausgabedatum 9/2006
SorftM Semiramis GmbH&Co. KG(2005): Semiramis Hilfe „Einlastung“. Ab Release 4.1,

Ausgabedatum 9/2005
SorftM Semiramis GmbH&Co. KG(2006): Semiramis Hilfe „Materialbedarfsplanung“. Ab Release

4.3, Ausgabedatum 9/2006
SorftM Semiramis GmbH&Co. KG(2005): Semiramis Hilfe „Daten exportieren“. Ab Release 4.1,
Ausgabedatum 5/2005
SorftM Semiramis GmbH&Co. KG(2006): Semiramis Hilfe „Produktionsvorschläge“. Ab Release 4,

Ausgabedatum 9/2006
84
SorftM Semiramis GmbH&Co. KG(2007): Semiramis Hilfe „Beschaffungsvorschläge“. Ab Release
4.3, Ausgabedatum 2/2007
Internet:
Dr. Walter E. Rohn(2003): Zu Planspielen, Deutsche Planspiel Zentrale,

http://www.dpsz.de/zitate.htm (7.9.08)
Gümbel H. (2005): Semiramis – Native Business Software der nächsten Generation, White Paper –
Version 5.0. http://www.semiramis.com/semiramis/servlet/pages/de/19250;jsessionid=58AEB31
9655F173DEFF21E84a55DF795 (17.2.2009)
Heinz Lothar Grob,Wilhelm Grießhaber (1995): Computergestützte Lehre an der Universität

PDF: http://miami.uni-muenster.de/servlets/DerivateServlet/Derivate-204/CALCAT1.pdf
Hinterhuber H., Promberger K., Piazolo F. (2006): Usability Testing von ERP-Systemen: working
paper 29/2006, Universität Innsbruck. http://www.verwaltungsmanagement.at/602/uploads/
usability_testing_erp.pdf (17.2.2009)
o.A. (2008): TopSim learning business by doing business, Die Planspielmethode,

http://www.topsim.com/de/ueber_planspiele/methode/ (26.09.2008)
o.A. (2008): XSLT Tutorial; http://www.w3schools.com/Xsl/ (10.2.09)
o.A. (o.J.): Suisse Austrian German Simulation and Gaming Assosiation,

http://www.sagsaga.org/page10-400.html (1.10.2008)
o.A.(2008): Pressemitteilung von: SoftM Semiramis GmbH & Co. KG

http://www.openpr.de/pdf/187283/Semiramis-und-Partner-auf-der-CeBIT-2008-Halle-5-C16-
Semiramis-4-4-und-Branchenloesungen.pdf; (17.1.2009)
Ralph Schöpfer (2006): mySAP ERP 2005; http://www.sap.com/germany/media/50070634.pdf

(9.1.2009)
Ulrich Bennemann M.A(o.J): Geschichte der CoSims, http://www.ghs-kosim.de/bodycosimtext.htm

7.9.08
Weiss, Manfred. "ERP II setzt Anbietermarkt unter Druck." CIO online. 24 Apr. 2006.
http://www.cio.de/_misc/article/printoverview/index.cfm?pid=183&pk=821328&op=lst. (18.1.2009)
85
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Diplomarbeit selbstständig angefertigt
habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche
kenntlich gemacht.
Die Arbeit wurde bisher weder in gleicher noch in ähnlicher Form einer anderen Prüfungsbehörde
vorgelegt und auch noch nicht veröffentlicht.
Innsbruck, Februar 2009
86

Diplomarbeit2 7

Hochgeladen von

Copyright:

Verfügbare Formate

Diplomarbeit2 7

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diplomarbeit2 7

Hochgeladen von

Copyright:

Verfügbare Formate

Einsatz von Simulationsprogrammen zur Vermittlung komplexer

zur Erlangung des akademischen Grades

Eingereicht bei Herrn

Von Lukas PAA

Innsbruck, Februar 2009

1.1 PROBLEMSTELLUNG ................................................................................................................. 6

2.1 ENTWICKLUNG ......................................................................................................................... 8

3.1 GESCHICHTE DER PLANSPIELE ............................................................................................... 14

4 AUSWAHL PLANSPIEL UND ERP SYSTEM ........................................................................ 24

4.1 AUSWAHL ERP...................................................................................................................... 25

5 SEMIRAMIS UND SCSIM ALS PLANSPIEL.......................................................................... 36

5.1 SZENARIO ............................................................................................................................. 36

6 ZUSAMMENFASSUNG UND AUSBLICK .............................................................................. 79

1.2 Darlegung des Themas

Da die abgebildeten Prozesse in den Frameworks/Modulen der Produktion die unternehmerische

1.4 Abgrenzung der Arbeit

1.5 Wissenschaftliche Bearbeitung des Themas

Bildet eine betriebswirtschaftliche Software alle Geschäftsprozess eines Unternehmens in

Typischerweise sind ERP-Lösungen in Module oder Komponenten wie Finanzwesen und

2.4 ERP in der Lehre

3.1 Geschichte der Planspiele

3.2 Was sind Planspiele

Da diese Arbeit als Diplomarbeit eines Betriebswirtschaftslehre-Studiums verfasst wird, wird im

Ein betriebswirtschaftliches Planspiel bzw. Unternehmensplanspiel ist eine modellhafte Abbildung

3.3 Phasen eines Planspiels

3.6 Vorteile der Verwendung von Planspielen

- Planspiele unterstützen eine selbstorganisierte und praxisorientierte Lernkultur. Diese

3.7 Arten von Planspielen

3.7.1 Unterscheidungsmerkmale ökonomischer Planspiele

3.7.1.1 Betrieblicher Umfang

Unternehmensplanspiele lassen sich nach dem Umfang der abgebildeten Unternehmensbereiche

3.7.1.3 Interaktion zwischen Teilnehmergruppen

3.7.1.4 Determiniertheit des Modells

3.7.1.6 Zusammensetzung der Spielgruppen

3.7.1.7 Nutzung rechnerischer Hilfsmittel

3.7.1.8 Komplexität des Modells

4 Auswahl Planspiel und ERP System

4.1 Auswahl ERP

4.2 Auswahl Planspiel

4.2.3 Planung und Disposition im Modellbetrieb

Um möglichst effizient zu wirtschaften müssen die Teilnehmenden versuchen, ihre Lagerbestände

4.2.3.3 Dispositive Entscheidungen

4.2.3.3.2 Disposition (Eigenfertigungsprodukte)

5 Semiramis und SCSim als Planspiel

Das ausgewählte und umgesetzte Szenario sieht wie folgt aus:

5.2 Vorgehensweise bei der Entwicklung

5.2.1 Grundlegende Stammdaten

Teil- Bezeichnung Ver- Teile- Dis- Wieder- Abwei- Lager- Bestell-

K21 Kette K 5,00 300 1,8 0,4 300 50,00

Zur Definition der theoretischen Kapazitäten der zeitabhängigen Ressourcen werden

Die Materialbedarfsplanung in Semiramis liefert Informationen darüber, welche Artikel in welcher

Die Materialbedarfsplanung bietet die folgenden Vorteile:

5.3.1 Datentransfer von Semiramis nach SCSim

Folgende Abbildung verdeutlicht den Datenaustausch bezüglich der Vertriebsdaten. Aus

• Daten: Artikel, Menge

Abbildung 13:: Verlauf des Transfers der Vertriebsdaten

Folgende Abbildung veranschaulicht den Transfer der Beschaffungsdaten.

• Daten: Artikel, Menge, Referenz

Abbildung 15:: Verlauf des Transfers der Beschaffungsdaten