Diplomarbeit2 7
Diplomarbeit2 7
betriebswirtschaftlicher Prozesse
DIPLOMARBEIT
Inhaltsverzeichnis 3
Abbildungsverzeichnis 81
Tabellenverzeichnis 81
Literaturverzeichnis 82
2
I. Inhaltsverzeichnis
1 EINFÜHRUNG ........................................................................................................................... 6
2 ERP-SYTEME ........................................................................................................................... 8
3 PLANSPIELE .......................................................................................................................... 14
4
5.3.4 Umsetzung der Datentransformation.......................................................................... 69
5.4 ABLAUF ................................................................................................................................. 72
5.5 KOMPROMISSE UND PROBLEME .............................................................................................. 78
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
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.
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.
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
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
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
Vgl. Gümbel (2005), S.6
20
Vgl. Gümbel (2005), S.7
21
Vgl. Gümbel (2005), S.7
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.
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.
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!“
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
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
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.
- 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
Vgl. Rebmann (2001); S.30
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.
- 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
Vgl. Rebmann (2001); S.30
45
Vgl. Rebmann (2001); S.30
46
Vgl. Rebmann (2001); S.30
47
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
48
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
49
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
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.
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
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
51
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
52
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
53
Vgl. http://www.sagsaga.org/page10-400.html (1.10.2008)
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.
Ö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.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.
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.
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.
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.
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.
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
64
Vgl. Grob H., Grießhaber W., (1995); S. 6
65
Vgl. Rebmann (2001); S.27
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.
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
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.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
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
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.
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
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.
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.
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.
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
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
88
Vgl. Semiramis Hilfe; Materialbedarfsplanung (2006); S.2
46
89
Abbildung 11:Einbettung der Materialbedarfsplanung innerhalb des Produktionsprozesses
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.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>
• Transformation
XSLT
• Daten: Artikel, Menge
XML • SCSim kompatibel
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>
<amount>3200</amount>
</totalQuantity>
<reference>5</reference>
<Item>
<number>K34</number>
</Item>
</Details>
<Details>
<totalQuantity>
<amount>500</amount>
95
Screenshot: SCSim
51
</totalQuantity>
<reference>4</reference>
<Item>
<number>K36</number>
</Item>
</Details>
• Transformation
XSLT
• Daten: Artikel, Menge, Modus
XML • SCSim kompatibel
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
• Daten: Artikel, Menge
XML • Export aus Semiramis: Produktionsaufträge
• Transformation
XSLT
• Daten: Artikel, Menge
XML • SCSim kompatibel
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>
<availableTime>14400000</availableTime>
</ModelMonday>
</Details>
</WeekTimeModel>
55
• Daten: Ressource, Wochenzeitmodell
XML • Export aus Semiramis: Ressource & Wochenzeitmodel
• Transformation
XSLT
98
Abbildung 19:: Verlauf der Transformation der Ressourcendaten
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.
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.
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.
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.
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.
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>
<xsl:apply-templates
select="document('03_ProductionOrder.xml')"/>
</productionlist>
<workingtimelist>
<xsl:apply-templates
select="document('04_Resource.xml')"/>
</workingtimelist>
</input>
</xsl:template>
<xsl:template match="n2:semiramis">
<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:template match="n3:semiramis">
<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:template match="n4:semiramis">
<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
200 2 Nicht relevant 0
251-265 2 <code>150</code> 240min
<availableTime>14400000</availableTime>
300 3 Nicht relevant 0
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.
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>
<amount>100</amount>
- <Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
- <storageArea>
<warehouse>100</warehouse>
</storageArea>
- <Item>
<number>P1</number>
</Item>
</Details>
</ReceiptOfGoods>
</semiramis>
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" />
<batch id="2" amount="10" cycletime="50" cost="1374,70" />
<batch id="3" amount="10" cycletime="50" cost="1374,70" />
<batch id="4" amount="10" cycletime="50" cost="1374,70" />
<batch id="5" amount="10" cycletime="50" cost="1374,70" />
<batch id="6" amount="10" cycletime="50" cost="1374,70" />
<batch id="7" amount="10" cycletime="50" cost="1374,70" />
<batch id="8" amount="10" cycletime="50" cost="1374,70" />
<batch id="9" amount="10" cycletime="50" cost="1374,70" />
<batch id="10" amount="10" cycletime="1010" cost="1374,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.
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:
<?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>0</deliverySlip>
<SupplierPartner>
<number>20010</number>
</SupplierPartner>
<InventoryOrganizationPartner>
<number>00000</number>
</InventoryOrganizationPartner>
<ReceiptOfGoodsType>
<code>100</code>
</ReceiptOfGoodsType>
<Details>
<deliverySlipDetailNumber>0</deliverySlipDetailNumber>
<totalQuantity>
<amount>3200</amount>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<storageArea>
<warehouse>100</warehouse>
</storageArea>
<Item>
<number>K34</number>
</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.
<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>
<xsl:apply-templates
select="inwardstockmovement|completedorders"/>
</semiramis>
</xsl:template>
<xsl:template match="inwardstockmovement">
<ReceiptOfGoods>
<deliverySlip>0</deliverySlip>
<SupplierPartner>
<number>20010</number>
</SupplierPartner>
<InventoryOrganizationPartner>
<number>00000</number>
</InventoryOrganizationPartner>
<ReceiptOfGoodsType>
<code>100</code>
</ReceiptOfGoodsType>
<xsl:for-each select="order">
<Details>
<deliverySlipDetailNumber>0</deliverySlipDetailNumber>
<totalQuantity>
<amount>
<xsl:value-of
select="@amount"/>
</amount>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<storageArea>
<warehouse>100</warehouse>
</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>
<xsl:when test="some $x in
(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>
<xsl:when test="some $x in
(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>
<deliverySlip>0</deliverySlip>
<SupplierPartner>
<number>20010</number>
</SupplierPartner>
<InventoryOrganizationPartner>
<number>00000</number>
</InventoryOrganizationPartner>
<ReceiptOfGoodsType>
<code>200</code>
</ReceiptOfGoodsType>
<xsl:for-each select="order">
<Details>
<deliverySlipDetailNumber>0</deliverySlipDetailNumber>
<totalQuantity>
<amount>
<xsl:value-of
select="@quantity"/>
</amount>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<storageArea>
<warehouse>100</warehouse>
</storageArea>
<Item>
<number>
<xsl:choose>
<xsl:when test="some $x in
(1,2,3) satisfies $x=@item">P<xsl:value-of select="@item"/></xsl:when>
<xsl:when test="some $x in
(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>
<xsl:when test="some $x in
(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:
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
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
113
Aus Semiramis Hilfe „Beschaffungsvorschläge“ (2007); S.4
76
<?xml version="1.0" encoding="UTF-8"?>
<input>
<user game="1" group="1" period="1" />
<qualitycontrol type="no" losequantity="0" delay="0" />
<sellwish>
<item article="1" quantity="200" />
<item article="2" quantity="200" />
<item article="3" quantity="160" />
</sellwish>
<selldirect>
<item article="1" quantity="0" price="0.0" penalty="0.0" />
<item article="2" quantity="0" price="0.0" penalty="0.0" />
<item article="3" 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" />
<production article="26" quantity="200" />
<production article="51" quantity="170" />
<production article="3" quantity="140" />
</productionlist>
<workingtimelist>
<workingtime station="1" shift="1" overtime="240" />
<workingtime station="2" shift="1" overtime="0" />
<workingtime station="3" shift="1" overtime="0" />
<workingtime station="4" shift="1" overtime="0" />
<workingtime station="6" shift="1" overtime="0" />
<workingtime station="7" shift="1" overtime="0" />
<workingtime station="8" shift="1" overtime="0" />
<workingtime station="9" shift="1" overtime="0" />
<workingtime station="10" shift="1" overtime="0" />
<workingtime station="11" shift="1" overtime="0" />
<workingtime station="12" shift="1" overtime="0" />
<workingtime station="13" shift="1" overtime="0" />
<workingtime station="14" shift="1" overtime="0" />
</workingtimelist>
</input>
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.
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.
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.
Mertens, Peter et al: Grundzüge der Wirtschaftsinformatik; Springer Verlag; Heidelberg; Berlin,
2005.
Promberger, Kurt, Christoph Jünger, Markus Traxl, und Peter Wanka: Implementierung von ERP-
Sytemen an Universitäten. Wien - Graz: Neuer wissenschaftlicher Verlag, 2006.
Sumner Mary: Enterprise Resource Planning. Pearson - Prentice Hall; New Jersey, 2005.
Zeitschriften:
Davenport, T. H. (1998): Putting the Enterprise into the Enterprise System, In: Harvard Business
Review, Juli-August 1998, S. 119-121
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)
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:
SorftM Semiramis GmbH&Co. KG(2005): Semiramis Hilfe „Daten exportieren“. Ab Release 4.1,
Ausgabedatum 5/2005
Internet:
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)
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)
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.
86