Leseprobe
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1 Einleitung
1.1 Hinführung zum Thema
1.2 Ausgangssituation
1.3 Zielsetzung und Aufbau der Arbeit
2 Die Entscheidung „Make or Buy“
2.1 0Geeignete Standardwarenwirtschaftssysteme
2.1.1 Festlegung der Kriterien für die Auswahl
2.1.2 Betrachtung der Marktanalyse bezüglich der Kriterien
2.1.3 Analyse
2.2 Standardsoftware versus Eigenentwicklung
2.2.1 Vor- und Nachteile des Erwerbs von Standardsoftware
2.2.2 Vor- und Nachteile der Eigenentwicklung
2.2.3 Zusammenfassung der Ergebnisse
3 Grundlagen zu Warenwirtschaftssystemen
3.1 Einleitung
3.2 Begriffsabgrenzungen
3.2.1 Der Begriff des Warenwirtschaftssystems
3.2.2 Der Begriff des Referenzmodells
3.3 Das Handels-H-Modell
3.4 Das Prinzip „Vereinfachung durch Vereinheitlichung“ nach Hertel
3.4.1 Die Grundidee
3.4.2 Das Konstrukt der operativen Einheiten
3.4.3 Offenheit des Systems durch strikte Orientierung an Normen
3.4.4 Das Zwei-Ebenen-Konzept
3.4.5 Das Baukastenkonzept
4 Modularisierung und Software-Architekturen
4.1 Begriffsabgrenzungen
4.1.1 Der Begriff Modul
4.1.2 Der Begriff Software-Architektur
4.2 Prinzipien der Modulbildung
4.2.1 Geheimnisprinzip (Information Hiding)
4.2.2 Balance zwischen Kopplung und Kohäsion
4.2.3 Beziehungen zwischen Modulen
4.3 Der Modul Guide
4.3.1 Der graphische Modul Guide
4.3.2 Der Modul Guide als Tabelle
5 Weitere Konzepte zur Vereinheitlichung
5.1 Einführende Überlegungen
5.2 Erweiterung des Konzeptes der operativen Einheiten nach Hertel um externe Marktpartner
5.2.1 Vor- und Nachteile der Erweiterung
5.2.2 Unterschiede zwischen internen und externen operativen Einheiten
5.2.3 Beziehungen operativer Einheiten zu Prozessen
5.2.4 Gemeinsamkeiten aller Arten operativer Einheiten
5.2.5 Das Konstrukt der operativen Einheiten im Überblick
5.3 Vergleich des Beschaffungsprozesses mit dem Distributionsprozess
5.3.1 Der Beschaffungsprozess
5.3.2 Der Distributionsprozess
5.3.3 Gemeinsamkeiten und Unterschiede bei Beschaffungs- und Distributionsprozess
5.3.4 Schlussfolgerung
5.4 Mandantenfähigkeit der Funktionsbereiche der operativen Einheiten
5.4.1 Der Begriff der Mandantenfähigkeit
5.4.2 Mandantenabwicklung in den Funktionsbereichen der operativen Einheiten
5.4.3 Mandantenfähige Prozesse
5.4.4 Bedeutung der Mandantenfähigkeit für die Datenhaltung
6 Auswahl der Vorgehensweise für den Entwurf
6.1 Abgrenzung des Vorgehensmodells von gängigen Vorgehensmodellen
6.2 Die Grundlage für den Entwurf
6.3 Modulare Entwurfsmethoden
6.3.1 Top-Down-Entwurf
6.3.2 Bottom-Up-Entwurf
6.3.3 Top-Down-Entwurf versus Bottom-Up-Entwurf
6.3.4 Die geeignete Entwurfsmethode für das Warenwirtschaftssystem
6.4 Mögliche Ansätze für das Vorgehensmodell
6.4.1 Einstieg über das Konzept „Das Konstrukt der operativen Einheiten“
6.4.2 Einstieg über das Konzept „Vergleich des Beschaffungsprozesses mit dem Distributionsprozess“
6.4.3 Bewertung der beiden Vorgehensweisen
7 Das Vorgehensmodell für den Entwurf des Warenwirtschaftssystems
7.1 Einleitung
7.2 Teil 1 – Erstellung der Teilentwürfe
7.2.1 Schritt 1: Anwendung des Konzeptes „Vergleich des Beschaffungsprozesses mit dem Distributionsprozess“
7.2.2 Schritt 2: Anwendung des Konzeptes „Das Konstrukt der operativen Einheiten“
7.2.3 Schritt 3: Anwendung des Konzeptes „Mandantenfähigkeit der Funktionsbereiche der operativen Einheiten“
7.2.4 Schritt 4: Anwendung des Konzeptes „Das Zwei-Ebenen-Konzept“
7.2.5 Schritt 5: Erstellung des graphischen Modul Guide zu beiden Teilsystemen
7.3 Teil 2 – Erstellung des Gesamtentwurfs
7.3.1 Schritt 1: Erstellung des tabellarischen Modul Guide für das Gesamtsystem
7.3.2 Schritt 2: Entwurf der anderen Geschäftsprozesse
7.3.3 Schritt 3: Bestimmung der Modulschnittstellen
7.3.4 Schritt 4: Ergänzung der Beziehungstypen im graphischen Modul Guide
7.3.5 Schritt 5: Erstellung der ER-Modelle
8 Anwendung des Vorgehensmodells
8.1 Einleitung
8.2 Teil 1: Erstellung der Teilentwürfe
8.2.1 Schritt 1: Anwendung des Konzeptes „Vergleich des Beschaffungsprozesses mit dem Distributionsprozess“
8.2.2 Schritt 2: Anwendung des Konzeptes „Das Konstrukt der operativen Einheiten“
8.2.3 Schritt 3: Anwendung des Konzeptes „Mandantenfähigkeit der Funktionsbereiche der operativen Einheiten“
8.2.4 Schritt 4: Anwendung des Konzeptes „Das Zwei-Ebenen-Konzept“
8.2.5 Schritt 5: Erstellung des graphischen Modul Guide zu beiden Teilsystemen
8.3 Teil 2: Erstellung des Gesamtentwurfs
8.3.1 Schritt 1: Erstellung des tabellarischen Modul Guide für das Gesamtsystem
8.3.2 Schritt 2: Entwurf der anderen Geschäftsprozesse
8.3.3 Schritt 3: Bestimmung der Modulschnittstellen
8.3.4 Schritt 4: Ergänzung der Beziehungstypen im graphischen Modul Guide
8.3.5 Schritt 5: Erstellung der ER-Modelle
9 Zusammenfassung der Ergebnisse
9.1 Die Ergebnisse des Vorgehensmodells
9.1.1 Umsetzung der vorgestellten Konzepte
9.1.2 Erreichung höherer Flexibilität und geringerer Komplexität durch das Vorgehensmodell
9.1.3 Erfüllung allgemeiner Forderungen an Vorgehensmodelle
9.2 Gegenüberstellung der Eigenentwicklung nach dem Vorgehensmodell und dem Erwerb von Standardsoftware
9.2.1 Nachteile der Eigenentwicklung nach dem Vorgehensmodell gegenüber dem Erwerb von Standardsoftware
9.2.2 Vorteile der Eigenentwicklung nach dem Vorgehensmodell gegenüber dem Erwerb von Standardsoftware
9.2.3 Fazit
9.3 Kostenersparnis durch das Vorgehensmodell
10 Ausblick
Literaturverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abb. 2-1: Auszug aus einem Fragebogen der SAP AG
Abb. 3-1: Das Handels-H-Modell
Abb. 3-2: Verhältnis Warenwirtschaftssystem und Handelsinformationssystem
Abb. 3-3: Kontext-Diagramm eines Warenwirtschaftssystems
Abb. 3-4: SEDAS als Kommunikationsschnittstelle
Abb. 3-5: Das Zwei-Ebenen-Konzept
Abb. 4-1: Einordnung der Software-Architektur in den Software-Entwicklungsprozess
Abb. 4-2: Balance zwischen Kopplung und Kohäsion
Abb. 4-3: Komponentendiagramm
Abb. 4-4: Komponentendiagramm – Beziehungstypen
Abb. 4-5: Komponentendiagramm – dynamische Bindung
Abb. 5-1: ERM Arten operativer Einheiten
Abb. 5-2: ERM Hierarchie von Leistungseinheiten
Abb. 5-3: ERM Prozessberechtigung operativer Einheiten
Abb. 5-4: ERM Rolle einer operativen Einheit bei einem Prozess
Abb. 5-5: ERM Adressen operativer Einheiten
Abb. 5-6: ERM Bedingung für operative Einheiten bei einem Prozess
Abb. 5-7: ERM Überblick Konstrukt der operativen Einheiten
Abb. 5-8: Objekthierarchie der beschaffungsprozessprägenden Objekte
Abb. 5-9: Objekthierarchie der distributionsprozessprägenden Objekte
Abb. 5-10: Zusammenhang Beschaffungs- und Distributionsprozess
Abb. 5-11: Zuordnung der Daten zu Mandanten
Abb. 8-1: Funktionsbäume Einkauf - Marketing
Abb. 8-2: Funktionsbäume Wareneingang und Warenausgang
Abb. 8-3: Funktionsbäume Kreditorenbuchhaltung und Debitorenbuchhaltung
Abb. 8-4: Prozessmodell Lieferantenstammpflege
Abb. 8-5: Prozessmodell Abnehmerstammpflege
Abb. 8-6: Erstellung graphischer Modul Guide
Abb. 8-7: Prozessmodell Aktionsabwicklung
Abb. 8-8: Beziehungstypen im graphischen Modul Guide
Abb. 8-9: Aufteilung Artikelstammdaten
Abb. 8-10: ERM Artikelsichten
Abb. 8-11: ERM Artikelsicht Logistik
Abb. 8-12: ERM Artikelsicht Beschaffung
Abb. 8-13: ERM Artikelsicht Distribution
Abb. 8-14: ERM Artikelsicht Beschaffung und Distribution vereinheitlicht
Tabellenverzeichnis
Tabelle 2-1: Marktanalyse Standardsoftware Teil 1
Tabelle 2-2: Marktanalyse Standardsoftware Teil 2
Tabelle 2-3: Erste Auswahl nach dem Kriterium der Handelsstufe
Tabelle 2-4: Zweite Auswahl nach dem Kriterium des Branchenfokus
Tabelle 2-5: Exemplarische Aufstellung der Gesamtkosten des ERP-Einsatzes nach Kostenarten
Tabelle 2-6: Zusammenfassung der Vor- und Nachteile von Standardsoftware und Eigenentwicklung im Überblick
Tabelle 4-1: Modul Guide als Tabelle
Tabelle 4-2: Tabelle Einbindung eines Moduls in Prozesse
Tabelle 6-1: Bewertung der Vorgehensweisen zur Modularisierung des Warenwirtschaftssystems im Überblick
Tabelle 8-1: Tabellarischer Modul Guide Gemeinsamkeiten Prozesse Lieferantenstammpflege / Abnehmerstammpflege
Tabelle 8-2: Modultabelle OE_Sicht
Tabelle 8-3: Modultabelle OE_SichtAllgm
Tabelle 8-4: Bearbeitende operative Einheiten des Moduls Auswahl einer operativen Einheit
Tabelle 8-5: beteiligte operative Einheiten des Moduls Bestellübermittlung
Tabelle 8-6: Modultabelle Artikelsicht Beschaffung
Tabelle 8-7: Modultabelle Artikelsicht Beschaffung – Datenbeschaffung
Tabelle 8-8: Modultabelle Artikelsicht Beschaffung – Datenprüfung
Tabelle 8-9: Modultabelle Artikelsicht Beschaffung – Datenverarbeitung
Tabelle 8-10: Modultabelle Artikelsicht Beschaffung – Datenbeschaffung mit aufrufendem Modul
Tabelle 8-11: Modultabelle Artikelsicht Beschaffung – Datenprüfung mit aufrufendem Modul
Tabelle 8-12: Modultabelle Artikelsicht Beschaffung – Datenverarbeitung mit aufrufendem Modul
Tabelle 8-13: Modultabelle WE_PosBuch
Tabelle 8-14: Modultabelle Warenbewegung eines Artikels
Tabelle 8-15: Modultabelle Abrechnung eines Artikels
Tabelle 8-16: Modultabelle Artikelneuanlage
Tabelle 8-17: Modultabelle Anzeige und Pflege der Grunddaten eines Artikels
Tabelle 8-18: Modultabelle Artikelstammdatenpflege
Tabelle 8-19: Modultabelle Prozesssteuerung Stammdatenpflege
Tabelle 8-20: Modultabelle Artikelstammdatenpflege mit Prozess und aufrufendem Modul
Tabelle 8-21: Modultabelle Prozesssteuerung Stammdatenpflege mit Prozess und aufrufenden Modul
Tabelle 8-22: Modul OE_Select – Modultabelle
Tabelle 8-23: Modul OE_Select – Bearbeitende operative Einheiten
Tabelle 8-24: Modul OE_Select – Beteiligte operative Einheiten
Tabelle 8-25: Tabellarischer Module Guide mit Input- und Output-Schnittstelle
1 Einleitung
1.1 Hinführung zum Thema
Dem Warenwirtschaftssystem (WWS) kommt als zentralem Softwaresystem im Handel eine entscheidende Rolle bei der Informationsbeschaffung und dem Datenaustausch zu. Das Warenwirtschaftssystem ist ein System zur Steuerung und Optimierung sämtlicher dispositiven, warenbezogenen und abrechnungsbezogenen Prozesse eines Handelsunternehmens. Dieses System wurde in vielen Unternehmen nicht an einem Stück, sondern sukzessive im Laufe vieler Jahre entwickelt. Oft ist dadurch ein kaum überschaubar großes Softwaresystem von mehreren tausend Programmen entstanden, das nur noch sehr schwer zu warten ist. Damit stellt die Neukonzeption die beste Möglichkeit dar, neue Anforderungen zu integrieren. Daher wird in dieser Arbeit ein Ansatz erarbeitet, auf dessen Basis ein Konzept für ein neues Warenwirtschaftssystem mit deutlich verringerter Komplexität erstellt werden kann.
Umgesetzt und erprobt wird dieser Ansatz im Rahmen der Neugestaltung des Warenwirtschaftssystems eines Handelsunternehmens mit Filialen in mehreren Branchen, das sowohl im Großhandel, als auch im Einzelhandel tätig ist.
Der für das Unternehmen erwartete Nutzen besteht in einer Verkürzung der Entwicklungszeiten, der Reduzierung der Wartungs- und Entwicklungskosten sowie einer Verbesserung der Qualität der Software.
1.2 Ausgangssituation
Das Problem bei vielen heutigen Warenwirtschaftssystemen liegt darin, dass sie aufgrund ihrer Komplexität nur noch mit sehr hohem Aufwand wartbar und anpassbar sind.
Für diese Situation lassen sich nach Hertel folgende fünf Gründe anführen, die miteinander in engem Zusammenhang stehen[1]:
- Zu lange Entwicklungsdauer
In der Regel wurde das System nicht an einem Stück konzipiert, sondern über einen langen Zeitraum in mehreren Teilprojekten. So wurden nacheinander gemäß aktueller Anforderungen einzelne Teilsysteme realisiert, die an die bis dahin vorhandenen Systeme angehängt wurden oder parallel dazu laufen. Häufig beobachtet man in Unternehmen, dass das Gesamtsystem mit dem Unternehmen historisch gewachsen ist und im Laufe der Zeit für verschiedene Branchen oder Vertriebszweige völlig unterschiedliche Softwarelösungen entstanden sind.
- Fehlendes Gesamtkonzept
Das ist die Konsequenz einer zu langen und in mehrere Teilprojekte zerstückelten Entwicklungsphase. Durch die sukzessive Entwicklung des Warenwirtschaftssystems gibt es kein Gesamtkonzept. Stattdessen gibt es jeweils Konzepte für die einzelnen Teilsysteme, die oftmals durch Weiterentwicklung dieser Systeme im Laufe der Zeit auch durchbrochen wurden.
- Fehlende Abstraktion vom Einzelfall
Dieser Fehler entsteht durch eine vorschnelle Umsetzung der aktuellen Anforderungen in Software, ohne im System bereits realisierte Vorgänge auf Gemeinsamkeiten zu untersuchen. Er steht also im engen Zusammenhang mit den ersten beiden Gründen. So ist es dann auch erklärbar, dass es beispielsweise unterschiedliche Programme für die Bestellerfassung gibt, die auf die Besonderheiten bestimmter Artikelgruppen zugeschnitten sind, obwohl der eigentliche Vorgang der Bestellung bei allen Artikelgruppen derselbe ist.
- Fehlende Datenmodellierung
Den einzelnen Teilsystemen liegen oft völlig unterschiedliche Stammdaten zugrunde, sodass es kein einheitliches Datenmodell gibt. Auch innerhalb eines Teilsystems wurde oftmals keine Modellierung der Daten vorgenommen. Das erkennt man beispielsweise daran, dass es jeweils für den Artikelstamm nur eine Datei gibt, in der alle zugehörigen Attribute gespeichert sind. Das gleiche lässt sich auch auf andere Stammdaten wie beispielsweise den Lieferantenstamm übertragen.
- Fehlende Integration der einzelnen Subsysteme
Dieses Problem ergibt sich aus den bereits oben geschilderten Gründen. Die einzelnen Teilsysteme lassen sich nicht mehr in das Gesamtsystem integrieren, weil sie unabhängig voneinander weiterentwickelt wurden. Die Programme und Daten weichen so stark voneinander ab, dass eine Integration automatisch einer Neukonzeption des gesamten Systems gleich käme.
Ergänzend zu diesen fünf Gründen ist zu erwähnen, dass in vielen Unternehmen mit der Entwicklung dieser Systeme zu einer Zeit begonnen wurde, in der es keinesfalls selbstverständlich war, dass die Daten elektronisch gespeichert und die Geschäftsprozesse durch Software abgebildet oder gar automatisiert wurden. Aufgrund dessen gab es auch wenige Erfahrungen bezüglich des Aufbaus eines Warenwirtschaftssystems. Erst während der Entwicklung wurden diese Erfahrungen gesammelt und bei der Realisierung neuer Teilsysteme umgesetzt. Die bis dahin vorhandene Software wurde meist nicht entsprechend geändert, weil dem damit verbundenen Kostenaufwand kein für das Unternehmen direkt ersichtlicher Nutzen gegenüber stand.
Hinzu kommt der enorme technische Fortschritt während dieser Zeit. Viele neue Konzepte waren in der Vergangenheit technisch gar nicht umsetzbar.
Genau diese Situation mit den oben aufgeführten Ursachen trifft auch auf das Warenwirtschaftssystem des eingangs vorgestellten Unternehmens zu. Da die Qualität des Warenwirtschaftssystems den Unternehmenserfolg entscheidend beeinflusst, ist es erforderlich, das System zu erneuern, damit es an aktuelle und auch zukünftige Anforderungen wieder leichter angepasst werden kann.
1.3 Zielsetzung und Aufbau der Arbeit
Im Rahmen der vorliegenden Arbeit wird ein Vorgehensmodell für die Konzeption eines neuen Warenwirtschaftssystems mit modularem Aufbau erarbeitet. Grundprinzip dieses Modells ist Vereinfachung durch Vereinheitlichung.
Nachdem in der Einführung das Problem der heutigen Warenwirtschaftssysteme mit den dazuführenden Ursachen geschildert wurde, wird in Kapitel 2 die zentrale Entscheidung „Make or Buy“ diskutiert.
In Kapitel 3 werden die für das Verständnis der Arbeit notwendigen Begriffsabgrenzungen vorgenommen, das in dieser Arbeit verwendete Referenzmodell und Konzepte zur Vereinheitlichung vorgestellt, die einen wesentlichen Beitrag zur Vereinfachung des Systems leisten.
Kapitel 4 geht allgemein auf den Entwurf einer modularen Software-Architektur ein. Als Erstes werden die Begriffe Modul und Software-Architektur abgegrenzt. Danach werden wichtige Prinzipien der Modulbildung und der Modul Guide als Hilfsmittel bei Entwurf und Dokumentation vorgestellt
In Kapitel 5 werden einzelne Konzepte aus Kapitel 3 überarbeitet und neue Konzepte hinzugefügt mit dem Ziel, das Warenwirtschaftssystem weiter zu vereinfachen.
Die Vorgehensweise bei der Modularisierung wird in Kapitel 6 erarbeitet. Dazu wird die Grundlage für den Entwurf bestimmt und modulare Entwurfsmethoden und mögliche Ansätze für das Vorgehensmodell diskutiert.
Basierend auf den Ergebnissen aus Kapitel 6 wird in Kapitel 7 das Vorgehensmodell zur Modularisierung des Warenwirtschaftssystems entwickelt.
Zum besseren Verständnis werden in Kapitel 8 Beispiele für die einzelnen Schritte des Vorgehensmodells gezeigt, wobei insbesondere auf Knackpunkte bei der Vorgehensweise eingegangen wird.
Kapitel 9 fasst die Ergebnisse der Arbeit zusammen und Kapitel 10 gibt einen Ausblick auf die weitere Vorgehensweise.
2 Die Entscheidung „Make or Buy“
Wenn ein neues Softwaresystem entwickelt werden soll, stellt sich als erstes die Frage, ob das System in Eigenentwicklung erstellt oder entsprechende Standardsoftware gekauft werden soll. Beide Alternativen haben Vor- und Nachteile. Um eine Entscheidung treffen zu können, ist eine umfassende Marktanalyse im Bezug auf geeignete Standardsoftwarelösungen notwendig. In Abschnitt 2.1 werden solche Standardsysteme auf Eignung untersucht. Aufgrund der gefundenen Auswahl werden in Abschnitt 2.2 die Vor- und Nachteile von Standardsoftware und Eigenentwicklung diskutiert, die zur Entscheidung führen.
2.1 0Geeignete Standardwarenwirtschaftssysteme
Am Markt sind zahlreiche Standardwarenwirtschaftssysteme vertreten, die sich für das eingangs vorgestellte Unternehmen mehr oder weniger eignen. Schütte/Vering (2004) haben eine umfassende Marktanalyse durchgeführt, auf die in diesem Abschnitt Bezug genommen wird. Diese Analyse klassifiziert Standardsoftwaresysteme nach verschiedenen Systemmerkmalen.
2.1.1 Festlegung der Kriterien für die Auswahl
Als erstes Systemmerkmal führen die Autoren die Systemart und den Funktionsumfang an. Darunter sind insbesondere folgende Kriterien zu verstehen:
- Handelsstufe,
- Branchenfokus und
- Abdeckung weiterer Funktionsbereiche[2]
Da für die von Schütte/Vering angeführten weiteren abgedeckten Funktionsbereiche, wie z.B. Finanzbuchhaltung, Personalwirtschaft, Personaleinsatzplanung und Zeiterfassung, im eingangs vorgestellten Unternehmen bereits Softwaresysteme im Einsatz sind, die nicht abgelöst werden sollen, wird auf den Aspekt „Abgedeckte weitere Funktionsbereiche“[3] nicht weiter eingegangen. Somit findet die erste Auswahl nach den Kriterien Handelsstufe und Branchenfokus statt.
Das vorgestellte Unternehmen ist im Großhandel und im Einzelhandel tätig. Da in beiden Bereichen teilweise dieselben Sortimente geführt werden, ist es nicht sinnvoll, für Groß- und Einzelhandel getrennte Warenwirtschaftssysteme zu erwerben. Das Warenwirtschaftssystem muss demzufolge diese beiden Handelsstufen abdecken.
Darüber hinaus benötigt das Unternehmen eine Softwarelösung, die den Branchenfokus auf folgende Branchen hat:
- Lebensmittel / Frische
- Baumärkte
- Baustoffe / Fliesen
- Elektro
- Sanitär / Heizung
- Unterhaltungselektronik
- Holz
- KFZ-Teile
- Lacke & Farben
- Reifen
2.1.2 Betrachtung der Marktanalyse bezüglich der Kriterien
Aufgrund dieser Kriterien lässt sich nach Tabelle 2-1 und Tabelle 2-2 eine erste Auswahl treffen.
Tabelle 2-1: Marktanalyse Standardsoftware Teil 1
Abbildung in dieser Leseprobe nicht enthaltenQuelle: Schütte/Vering 2004, S. 132
Tabelle 2-2: Marktanalyse Standardsoftware Teil 2
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Schütte/Vering 2004, S. 134
2.1.3 Analyse
Wenn für das gesamte Unternehmen eine Softwarelösung eingekauft werden soll, ist aufgrund der folgenden Betrachtung erkennbar, dass es sehr schwer sein wird, ein geeignetes Standardsystem zu finden.
Das Kriterium der Handelsstufe erfüllen von den untersuchten 64 folgende 47 Standardsysteme:
Tabelle 2-3: Erste Auswahl nach dem Kriterium der Handelsstufe
Abbildung in dieser Leseprobe nicht enthalten
Nach Berücksichtigung des Branchenfokus bleiben von diesen 47 Systemen noch folgende 2 Systeme übrig:
Tabelle 2-4: Zweite Auswahl nach dem Kriterium des Branchenfokus
Abbildung in dieser Leseprobe nicht enthalten
Wird bezüglich der Auswahlkriterien ein Kompromiss eingegangen, hat dies zur Folge, dass die gekaufte Software an die Anforderungen des Unternehmens angepasst werden muss. Diese Anpassung wird „Customizing“ genannt und erhöht die Anschaffungs- und Wartungskosten in der Regel enorm. Deshalb werden in den meisten Unternehmen bei den Anpassungen auch wieder Kompromisse eingegangen, um die Kosten nicht zu sehr in die Höhe zu treiben.
Bei den beiden Systemen aus Tabelle 2-4 und auch einigen durch die Auswahlkriterien ausgeschiedenen Systemen – wie beispielsweise SAP Business One oder SAP mySAP Retail – handelt es sich um universelle Standardsoftware (ERP-Systeme) mit Handelsspezifika, also keine reinen Branchenlösungen.[4] ERP-Systeme erheben den Anspruch, durch Customizing branchenübergreifend einsetzbar zu sein, und beinhalten außer dem reinen Warenwirtschaftssystem insbesondere Personalwirtschafts- und Rechnungswesensysteme. ERP-Systeme bilden vor allem aus technologischer Sicht den State-of-the-Art moderner Warenwirtschaftssysteme.[5] Allerdings haben sie den Nachteil, dass unter Umständen Systeme mitgekauft werden müssen, die nicht benötigt werden, und durch das Customizing erhöhte Anschaffungs- und Wartungskosten entstehen. Für Unternehmen mit mehreren Handelsstufen und branchenübergreifender Tätigkeit, wie das eingangs vorgestellte Unternehmen, stellen sie aber meist die einzige Möglichkeit für den Einsatz von Standardsoftware dar.
Während die Anschaffungskosten für ein reines Warenwirtschaftssystem als Standardsoftware meist in einstelliger Millionenhöhe bleiben, sind die Anschaffungskosten für ein ERP-System in der Regel zweistellige Millionenbeträge. Schütte/Vering plädieren für die Anschaffung von Standardsoftware. Dennoch räumen die Autoren ein: „Die Kosten, die mit dem ERP-Einsatz verbunden sind, sollten vor der Projektdurchführung keinesfalls unterschätzt werden. Diverse Projekte haben gezeigt, dass eine Reihe von Entscheidungsträgern enorme Einsparpotentiale im IT-Investitionsbudget vermuten. Diese Erwartungen erweisen sich allerdings häufig als Trugschluss.“[6] Um dies zu belegen, fügen die Autoren eine exemplarische Aufstellung der mit dem ERP-Einsatz verbundenen Kosten hinzu (Tabelle 2-5).
Tabelle 2-5: Exemplarische Aufstellung der Gesamtkosten des ERP-Einsatzes nach Kostenarten
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Schütte/Vering 2004, S. 30
Aus dieser Aufstellung geht hervor, dass die Softwarelizenzen nur einen geringen Kostenfaktor darstellen. Außerdem sind aus der Tabelle die Kosten ersichtlich, die durch Anpassungen eines Standardsystems an unternehmens- und branchenspezifische Besonderheiten verursacht werden.
Diese Anpassungen können durch das bereits erwähnte Customizing vorgenommen werden. Hierbei werden Parametereinstellungen vorgenommen, mit denen aus den Konfigurationsalternativen, die das ERP-System vorsieht, die für das Unternehmen am besten geeignete ausgewählt wird. Der Prozess der Parametereinstellung ist sehr umfangreich. Deshalb versuchen die ERP-Hersteller mittlerweile diesen Prozess mithilfe von Fragebogenkatalogen zu unterstützen.[7] Diese Kataloge bestehen in der Regel aus Fragebögen zu allen Komponenten der Software. Die einzelnen Fragebogen beinhalten in der Regel sehr detaillierte Fragen, aufgrund deren Beantwortung die entsprechende Systemkomponente konfiguriert wird. Dabei ist von einem Mittelwert von 100 oder mehr Fragen pro Fragebogen auszugehen.
Nicht alle Fragen können standardisiert werden. Gerade bei mittelständigen Unternehmen können Organisationsformen und Abläufe von Unternehmen zu Unternehmen sehr stark variieren. Deshalb bildet ein Standard-Fragebogenkatalog meist nur den Einstieg in eine ganze Reihe sehr ausführlicher Interviews mit den Abteilungen und den Entscheidern. Viele Fragen ergeben sich erst aus diesen Interviews. Eine Ist-Analyse bestehend aus diesen Interviews und der Dokumentation nimmt bei mittelständigen Unternehmen etwa 10 – 20 Tage über einen Zeitraum von 4 – 8 Wochen in Anspruch.
Das zeigt, dass es sich beim Customizing keineswegs um einen trivialen Vorgang handelt, wie oftmals von Softwareanbietern dargestellt.
Abb. 2-1 zeigt beispielhaft einen Auszug aus einem Fragebogen der SAP AG zur Konfiguration des Prozesses der Kundenauftragsbearbeitung eines Produktionsplanungs- und -steuerungssystems.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-1: Auszug aus einem Fragebogen der SAP AG
Quelle: Keller/Lietschulte/Curran 1999
Erst nachdem alle Fragen geklärt sind, können die Parametereinstellungen – das eigentliche Customizing – vorgenommen werden. Zumindest in der Einführungsphase müssen die Parametereinstellungen von Mitarbeitern des Software-Anbieters vorgenommen bzw. unterstützt werden. Die weitere Pflege dieser Einstellungen kann nur von Mitarbeitern des eigenen Unternehmens vorgenommen werden, die hinsichtlich des Softwaresystems gut geschult sind und darüber hinaus über fundierte IT-Kenntnisse verfügen. Alleine mit dieser Tatsache kann die Behauptung von Softwareanbietern, der Einsatz von Standardsoftware würde eine enorme Einsparung von Personalkosten bewirken, widerlegt werden.
Dennoch stellt die Anpassung eines ERP-Systems durch Customizing an unternehmensspezifische Besonderheiten den Idealfall dar. Weitere Anpassungstechniken sind Add-on-Programmierung an definierten Schnittstellen, Modifikation und Modularisierung.[8]
Unter Add-on-Programmierung wird die Erstellung eigener Programme, die für individuelle Abläufe benötigt werden, an definierten Schnittstellen – so genannten User-Exits – verstanden.[9] Diese Programme werden in der Regel von Entwicklern des eigenen Unternehmens vorgenommen. D.h., es werden hierfür weiterhin Entwickler im Unternehmen benötigt.
Unter Modifikation werden funktionale und strukturelle Anpassungen verstanden. Hierbei werden fehlende oder nicht den Anforderungen gerecht werdende Funktionen hinzugefügt oder angepasst.[10]
Die Modularisierung ist in der Regel die ungünstigste Anpassungstechnik. Unter Modularisierung wird in diesem Zusammenhang der Austausch ganzer Bausteine der Standardsoftware oder das Hinzufügen neuer Bausteine verstanden. Sie liegt vor, wenn komplette Programmbausteine im ERP-System fehlen oder ersetzt werden müssen. Von dieser Anpassungsart wird als letzte Möglichkeit Gebrauch gemacht, wenn der Standardsoftware Bausteine fehlen oder die installierten Programmbausteine nicht mit kleineren Modifikationen an die Bedürfnisse des Unternehmens angepasst werden können.[11]
Die erforderlichen Anpassungstechniken sollten eine entscheidende Rolle bei der Auswahl eines ERP-Systems einnehmen. Die Releasefähigkeit wird nur durch Anpassung mittels Customizing und Add-on-Programmierungen erhalten. Bei Modifikationen und besonders bei Modularisierung ist mit erheblichen Folgekosten bei Releasewechseln zu rechnen.[12]
2.2 Standardsoftware versus Eigenentwicklung
Auf Basis der Ergebnisse aus Abschnitt 2.1 gibt es zwei Alternativen: den Kauf eines ERP-Systems und die Eigenentwicklung. Beide Möglichkeiten werden im Weiteren auf ihre Vor- und Nachteile untersucht.
2.2.1 Vor- und Nachteile des Erwerbs von Standardsoftware
In der Literatur ist eine eindeutige Tendenz zu Standardsoftware nicht zuletzt deshalb zu erkennen, weil die Literatur häufig von Softwareanbietern verfasst wurde. Als Begründung werden vor allem die hohe Zukunftssicherheit, die hohe Flexibilität durch umfassende Customizing-Möglichkeiten, die weitgehende Hardware-, Datenbank- und Betriebssystemunabhängigkeit und nicht zuletzt die kostengünstigere Lösung im Vergleich zu langwieriger Eigenentwicklung hervorgehoben.[13] Als weiterer Vorteil einer Standardlösung ist die schnelle Einsetzbarkeit zu vermerken, wenn man von notwendigen Anpassungen des Systems an unternehmensspezifische Gegebenheiten einmal absieht. Je nachdem, wie hoch der Leidensdruck in einem Unternehmen ist, wird der Kauf eines ERP-Systems aus diesem Grund oft vorgezogen.
Die zugeschriebene hohe Zukunftssicherheit resultiert aus dem technologischen State-of-the-Art dieser Systeme und der meist sehr guten Marktposition des Anbieters.[14] Allerdings ist die Durchführung jedes Releasewechsels des Systems notwendig, um den technologischen Vorteil auf Dauer zu gewährleisten. Da die Softwareanbieter bei älteren Releaseständen meist nur noch begrenzte oder überhaupt keine Unterstützung anbieten, ist ein Unternehmen in der Regel zudem gezwungen, jeden Releasewechsel durchzuführen. Der Erwerb eines neuen Release stellt neben den Anschaffungskosten nicht zu unterschätzende Zusatzkosten dar. Darüber hinaus müssen innerhalb des Unternehmens Mitarbeiter – i.d.R. IT-Spezialisten – geschult werden, die das System betreuen. Mit jedem Releasewechsel des Systems entsteht erneuter Schulungsbedarf. Die Schulungen sind meist sehr teuer, was auch erklärt, warum SAP-Berater auf dem Arbeitsmarkt so händeringend gesucht werden.
Der Kauf von Standardsoftware zieht weitere Kosten nach sich, die von Unternehmen häufig nicht direkt erkannt werden. Viele Unternehmen bedenken bei der Kostenanalyse nur die Anschaffungs- und Wartungskosten. Die Hotline-Kosten werden meist unterschätzt. Gerade diese Kosten stellen sich oftmals im Nachhinein als sehr hoch heraus, da die IT-Spezialisten im Unternehmen trotz der teuren Schulungen, die meist nur die Handhabung des Systems im Regelfall beinhalten, nur noch begrenzt in der Lage sind, in Fehlersituationen einzugreifen.
Ein weiterer häufig auftretender Fehler seitens der Unternehmen beim Kauf von Standardsoftware ist, dass die branchen- und unternehmensspezifischen Besonderheiten zu Beginn unvollständig oder gar nicht beschrieben werden, weil entweder davon ausgegangen wird, dass das System diese ohnehin abdeckt, oder sie zu dem Zeitpunkt noch nicht überblickt werden und erst bei Einführung oder sogar erst nach Einsatz des Systems gemerkt wird, dass sie nicht berücksichtigt sind. Dadurch werden im Nachhinein zum Teil gravierende Anpassungen des Systems notwendig. Nachdem ein System gekauft ist, ist ein Unternehmen vom Softwareanbieter abhängig. Das versetzt diesen in die Lage, sehr viel höhere Preise für diverse Anpassungen zu verlangen als direkt beim Kauf der Software.
Das gleiche gilt für die Datenübernahme aus den Altsystemen. Der Softwareanbieter ist auf genaue Angaben von seinen Kunden angewiesen, um die Daten übernehmen zu können. Oftmals werden diese Angaben aber fehlerhaft, unvollständig oder gar nicht gemacht. Auch das verursacht im Nachhinein hohe Kosten. Auf der anderen Seite muss die Datenübernahme häufig von Mitarbeitern des eigenen Unternehmens durchgeführt werden, da sie vom Softwareanbieter nicht angeboten wird. Daraus resultierende Probleme treten in der Regel auch erst nach Vertragsunterschrift auf.
Ein weiterer Aspekt ist, dass mit dem Kauf von Standardsoftware häufig deutlich höhere Hardwarekosten verbunden sind, als es bei Eigenentwicklung der Fall ist. Der Hauptgrund dafür ist die Komplexität der Standardsoftwaresysteme. Ein Softwareunternehmen muss mit seinem Softwaresystem die Ansprüche vieler Unternehmen und Branchen abdecken können, um auf dem Markt bestehen zu können. Dadurch sind diese Systeme in der Regel umfangreicher als Individualsoftware, die lediglich die Belange eines Unternehmens und der Branchen, in denen es tätig ist, abdecken muss.
Die obigen Ausführungen führen nur einige der Probleme und der versteckten Kosten beim Kauf von Standardsoftware auf. Sie sollen aber genügen, um das Problem zu verdeutlichen. Weitere Aspekte, wie beispielsweise hohe Kosten durch mangelnde oder unzureichende Abdeckung der Prozesse des Unternehmens, wurden bereits in Fachzeitschriften diskutiert.[15]
2.2.2 Vor- und Nachteile der Eigenentwicklung
Bei der Eigenentwicklung muss ein detailliertes Konzept für das Warenwirtschaftssystem erstellt werden. Das erfordert einen hohen Zeitaufwand, der noch vor der eigentlichen Entwicklung anfällt. Außerdem fehlt in vielen Unternehmen das Know-How, um ein solches Konzept zu erstellen. Das resultiert daraus, dass Unternehmen häufig an der Schulung ihrer Mitarbeiter sparen. Die Schulungskosten der Mitarbeiter eines Softwareanbieters gehen in den Preis des Softwaresystems ein. Die Unternehmen, die Standardsoftware erwerben, tragen somit die Schulungskosten der Mitarbeiter des Softwareanbieters. Zusätzlich müssen – wie bereits erwähnt – eigene Mitarbeiter für die Handhabung und Betreuung der gekauften Software geschult werden. Die Argumentation von Unternehmen, durch den Erwerb von Standardsoftware automatisch Personalkosten einzusparen, stellt sich im Nachhinein oft als Trugschluss heraus. Eine allgemeine Aussage darüber, welche Alternative die kostengünstigere ist, kann nicht gemacht werden.
Verfügt ein Unternehmen über gut ausgebildete Mitarbeiter, so stellt die Eigenentwicklung in vielen Fällen die bessere Alternative dar. Sie hat den Vorteil, dass branchen- und unternehmensspezifische Besonderheiten direkt bei Konzepterstellung und somit von Vorneherein bei der Entwicklung des Softwaresystems berücksichtigt werden können. Das ist damit zu begründen, dass eine hausinterne EDV-Abteilung in der Regel besser mit branchen- und vor allem unternehmensspezifischen Besonderheiten vertraut ist als ein externer Softwareanbieter. Eigene Mitarbeiter erstellen das System speziell für das Unternehmen. Ein Softwareanbieter muss zusätzlich die Besonderheiten anderer Unternehmen berücksichtigen. Aus diesem Grunde verläuft bei der Eigenentwicklung in der Regel auch die Übernahme der Daten aus dem Altsystem problemloser als bei der Einführung von Standardsoftware. In den meisten Fällen sind die Entwickler sowohl mit dem alten als auch mit dem neuen System vertraut.
Bezüglich der Betreuung und Wartung des Warenwirtschaftssystems sei zusätzlich erwähnt, dass externe Softwareanbieter in der Regel viele Kunden zu betreuen haben, deren Anforderungen nacheinander bearbeitet werden. Eigene Mitarbeiter hingegen sind nur für das eigene Unternehmen tätig und können dadurch Anforderungen schneller in Software umsetzen und im Fehlerfall schneller reagieren. Das optimiert die Abläufe und die Benutzerbedienung für das Massengeschäft im Unternehmen.
Als letztes ist noch das Risiko zu erwähnen, das mit dem Kauf von Standardsoftware verbunden ist. Selbst Softwareanbieter mit sehr guter Marktposition sind nicht vor Unternehmenskrisen gefeit. Wenn eine solche Krise zum Konkurs oder zum Verkauf des Softwareunternehmens führt, so wird die Software in der Regel nicht weiter entwickelt und betreut. Die Kunden dieses Softwareanbieters sind dann gezwungen, sich erneut nach einer geeigneten Softwarelösung umzusehen. Nicht selten führen die dadurch entstehenden Kosten auch auf der Seite des Kunden zu einer Krise. Wird das System von eigenen Mitarbeitern entwickelt, so ist dieses Risiko auszuschließen.
2.2.3 Zusammenfassung der Ergebnisse
Die obigen Ausführungen verdeutlichen, dass die Vorteile der einen Alternative die Nachteile der anderen sind und umgekehrt. Zur besseren Übersicht werden die Ergebnisse noch einmal in einer Tabelle zusammengefasst.
Tabelle 2-6: Zusammenfassung der Vor- und Nachteile von Standardsoftware und Eigenentwicklung im Überblick
Abbildung in dieser Leseprobe nicht enthalten
Aufgrund dieser Ergebnisse wird in der vorliegenden Arbeit die Eigenentwicklung dem Einkauf einer Standardsoftware vorgezogen.
3 Grundlagen zu Warenwirtschaftssystemen
3.1 Einleitung
Bevor es an die Entwicklung einer Methode zur Vereinfachung des Warenwirtschaftssystems geht, ist es erforderlich, dieser Arbeit zugrunde liegende Konzepte vorzustellen. In Abschnitt 3.2 werden die Begriffe Warenwirtschaftssystem und Referenzmodell abgegrenzt. Das in dieser Arbeit verwendete Referenzmodell wird in Abschnitt 3.3 vorgestellt. Abschnitt 3.4 geht auf Konzepte zur Vereinheitlichung nach Hertel ein.
3.2 Begriffsabgrenzungen
3.2.1 Der Begriff des Warenwirtschaftssystems
Hertel versteht ein Warenwirtschaftssystem mit Fokus auf mehrstufige Warenwirtschaftssysteme als „ein System zur Steuerung und Optimierung der Sortimente, der Dispositions-, der Waren- und der Zahlungsströme über alle Unternehmenseinheiten, also über Großhandels- und Einzelhandelsstufe und zur Kommunikation und Integration der externen Marktpartner wie Lieferanten, Kunden, Banken oder Marktforschungsinstitute“[16]. Nach Tietz hat ein Warenwirtschaftssystem die Aufgabe, Sortimente, Lagerbestände und alle damit in Verbindung stehenden Waren- und Zahlungsdispositionen zu optimieren[17]. Becker/Schütte grenzen den Begriff wie folgt ein: „Ein Warenwirtschaftssystem repräsentiert die warenorientierten dispositiven, logistischen und abrechnungsbezogenen Prozesse für die Durchführung der Geschäftsprozesse eines Handelsunternehmens.“[18] Hinsichtlich der Abgrenzung, welche Informationssysteme eines Handelsunternehmens zum Warenwirtschaftssystem gehören, gehen die Meinungen auseinander. Auf diesen Sachverhalt und das hier verwendete Verständnis wird in Abschnitt 3.3 bei der Vorstellung des hier verwendeten Referenzmodells eingegangen.
3.2.2 Der Begriff des Referenzmodells
Für den Begriff des Referenzmodells ist in der Literatur kein einheitliches Verständnis auszumachen. Luxem definiert ein Referenzmodell als „ein von unternehmensspezifischen Besonderheiten abstrahierendes Abbild eines Realweltausschnitts […]“.[19] Becker /Schütte verstehen als wesentliche Charakteristika eines Referenzmodells „Bezug des Referenzmodells zu den einzelnen betrieblichen Systemen und Empfehlungscharakter eines solchen Modells“[20].
Nach Maicher sollte ein Referenzmodell folgende Eigenschaften aufweisen:
- „allgemeingültig,
- hinsichtlich individueller Bedürfnisse und Erfordernisse anpassbar,
- als spezifisches Modell einsetzbar,
- Erfahrungswissen repräsentierend.“[21]
Scheer versteht ein Referenzmodell als ein „Modell, das als Ausgangspunkt für die Entwicklung auf konkrete Aufgabenstellungen bezogene Problemlösungen dienen kann“[22].
Referenzmodelle sind in der Regel das Ergebnis weitreichender Erfahrungen des Modellerstellers und damit mehrfach validiert. Wird ein Referenzmodell als Basis für die eigene Entwicklung verwendet, hat man die Gewähr, dass es sich um mehrfach erprobte Lösungen handelt. Das mit der eigenen Modellerstellung verbundene Risiko der fehlerhaften Abbildung der bestehenden und gewünschten realen Begebenheiten wird durch die Existenz einer Ausgangslösung, von der zumindest Kernbestandteile übernommen werden können, reduziert.
Zusammenfassend ist ein Referenzmodell als allgemeingültige, modellhafte Darstellung eines Realitätsausschnittes zu verstehen, die als Basis für die eigene Entwicklung dienen sollte.
3.3 Das Handels-H-Modell
Das Handels-H-Modell ist ein Referenzmodell, das in Anlehnung an die Architektur integrierter Informationssysteme (ARIS) für Unternehmen mit Handelsfunktionen entwickelt wurde.[23] Es ist ein umfassendes Modell, das aus über 100 Einzelmodellen besteht. Die Autoren betrachten nicht nur die eigentliche Warenwirtschaft, sondern sämtliche Informationssysteme im Handel. Alle Bereiche des Handels-H-Modells werden aus funktions-, daten- und prozessorientierter Sicht betrachtet. Zur Modellrepräsentation dieser Sichten verwenden die Autoren Funktionsbäume, Entity-Relationship-Modelle (ERM) und Ereignisgesteuerte Prozessketten (EPK).[24]
Aufgrund ihrer optischen Darstellungsform wird die Architektur als Handels-H-Modell bezeichnet.[25].
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-1: Das Handels-H-Modell
Quelle: Becker/Schütte 2004, S. 43
Die warenwirtschaftlichen Anwendungsbereiche sind in drei große Teilbereiche eingeteilt. Im linken Schenkel ist der Beschaffungsbereich dargestellt, der aus den Teilsystemen Einkauf, Disposition, Wareneingang, Rechnungsprüfung und Kreditorenbuchhaltung besteht. Im rechten Schenkel sieht man den Vertriebsbereich, zu dem die Teilsysteme Marketing, Verkauf, Warenausgang, Fakturierung und Debitorenbuchhaltung gehören. Das Verbindungsstück dieser beiden großen Bereiche bildet das Lager mit seiner Überbrückungsfunktion zwischen Beschaffung und Distribution.[26] Diese Anwendungsbereiche gehören nach Becker/Schütte zum Umfang des Warenwirtschaftssystem.
Die im Fuß des Modells aufgeführten betriebswirtschaftlich-administrativen Aufgaben und die Analysesysteme, die das Dach bilden, werden von Becker / Schütte nicht als Bestandteil des eigentlichen Warenwirtschaftssystem verstanden. Die Autoren fassen diese Aufgaben und das Warenwirtschaftssystem unter dem Oberbegriff Handelsinformationssystem zusammen.[27] Diese Abgrenzung ist in Abb. 3-2 dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-2: Verhältnis Warenwirtschaftssystem und Handelsinformationssystem
Quelle: Becker/Schütte 2004, S. 46
Hertel fasst im Gegensatz dazu alle Informationssysteme eines Handelsunternehmens unter dem Begriff des Warenwirtschaftssystem zusammen.[28]
In dieser Arbeit werden wie bei Becker/Schütte nur die warenwirtschaftlichen Anwendungsbereiche als Bestandteil des Warenwirtschaftssystems verstanden.
3.4 Das Prinzip „Vereinfachung durch Vereinheitlichung“ nach Hertel
3.4.1 Die Grundidee
„Vereinfachung ist das Ziel; nicht für jeden Vorgang ein Programm zu schreiben, sondern in den vielen zunächst unterschiedlichen Vorgängen das Gemeinsame finden und entsprechend organisatorisch einheitlich umzusetzen, muss die Grundkonzeption für ein neues Warenwirtschaftssystem sein.“[29]
Zur Erreichung dieses Ziels nennt Hertel vier Konzepte[30], die im Weiteren erläutert werden.
3.4.2 Das Konstrukt der operativen Einheiten
Die Grundfunktion eines Handelsunternehmens ist, Ware bei Lieferanten einzukaufen und an Kunden weiterzuverkaufen. Die äußere Umgebung oder der Kontext, in dem ein Handelsunternehmen und damit das eingesetzte Warenwirtschaftssystem steht, lässt sich gut in einem Kontextdiagramm darstellen, das in der strukturierten Analyse (SA) angewandt wird.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-3: Kontext-Diagramm eines Warenwirtschaftssystems
Quelle: Hertel 1999, S. 178
In diesem Kontext gibt es zwei Vorgänge, die Bestellung beim Anbieter und den Auftrag des Abnehmers. Jeder dieser Vorgänge hat drei Ströme:
- einen Informationsfluss (Bestellung / Auftrag)
- einen Warenfluss (Wareneingang / Warenausgang)
- und einen Zahlungsfluss (Auszahlung / Einzahlung).[31]
Hertel geht bei diesen Beschreibungen von dem Warenwirtschaftssystem eines Zentrallagers aus. Die Anbieter sind die Lieferanten des Unternehmens und die Abnehmer die Filialen. Das Warenwirtschaftssystem einer Filiale steht in demselben Kontext, wobei hier sowohl Streckenlieferanten als auch das Zentrallager Anbieter sind. Die Abnehmer sind die Kunden des Unternehmens. Die Vorgänge, die in einer Filiale ablaufen, sind dieselben wie in der Zentrale. Beide lösen Bestellungen bei Lieferanten aus und erhalten Ware von diesen Lieferanten, beide erhalten Aufträge von den Abnehmern und liefern Ware an diese aus. Der einzige Unterschied sind die agierenden Parteien.[32]
Um diese Prozesse vereinheitlichen zu können, abstrahiert Hertel von der Art der unternehmensinternen Einheiten und nennt diese allgemein operative Einheiten. Er führt folgende Typen von operativen Einheiten auf:
- Filialen
- Zentral-/ Regionallager
- Niederlassungen /Zentralen[33]
Durch dieses Konzept lassen sich alle gleichartigen Prozesse zwischen diesen internen Einheiten einheitlich lösen. Außerdem wird dadurch die starre Hierarchie von Unternehmen für das Warenwirtschaftssystem aufgelöst, die von Unternehmen zu Unternehmen stark variieren kann und die heutigen Softwarelösungen stark beeinflusst. Ein Unternehmen wird somit als Netzwerk gleichberechtigter operativer Einheiten dargestellt. So können organisatorische Umstrukturierungen innerhalb eines Unternehmens durch das Warenwirtschaftssystem ohne hohen Änderungsaufwand realisiert werden.
Das Gesamtwarenwirtschaftssystem wird durch dieses Konzept in ein Netzwerk von Warenwirtschaftssystemen für jede operative Einheit ersetzt.
3.4.3 Offenheit des Systems durch strikte Orientierung an Normen
Innerhalb des Netzwerks der Warenwirtschaftssysteme der operativen Einheiten und auch nach außen mit externen Marktpartnern wie den Anbietern und im Großhandel auch den Abnehmern findet Datenaustausch statt. Für den Austausch mit externen Marktpartnern gibt es standardisierte genormte Schnittstellen. Diese Schnittstellen lassen sich auch im unternehmensinternen Datenverkehr verwenden.
[...]
[1] vgl. Hertel 1999, S. 13 - 16
[2] vgl. Schütte/Vering 2004, S. 131-133
[3] vgl. Schütte/Vering 2004, S. 133
[4] vgl. Schütte/Vering 2004, S. 133
[5] vgl. Schütte/Vering 2004, S. 27
[6] vgl. Schütte/Vering 2004, S. 29
[7] vgl. Schütte/Vering 2004, S. 30
[8] vgl. Schütte/Vering 2004, S. 30
[9] vgl. Schütte/Vering 2004, S. 30
[10] vgl. Schütte/Vering 2004, S. 31
[11] vgl. Schütte/Vering 2004, S. 31
[12] vgl. Schütte/Vering 2004, S. 31
[13] vgl. Schütte/Vering 2004, S. 27
[14] vgl. Schütte/Vering 2004, S. 27
[15] vgl. Eckel 2001, S. 24 – 25
[16] vgl. Hertel 1999, S. 11
[17] vgl. Tietz 1993, S. 1079f
[18] vgl. Becker/Schütte 2004, S. 46
[19] vgl. Luxem 2001, S. 37
[20] vgl. Becker/Schütte 2004, S. 76
[21] vgl. Maicher 1999, S. 168
[22] vgl. Scheer 1999, S. 6
[23] vgl. Becker/Schütte 2004, S. 42
[24] vgl. Fettke/Loos 2004, S. 17f
[25] vgl. Becker/Schütte 2004, S. 43f
[26] vgl. Becker/Schütte 2004, S. 42
[27] vgl. Becker/Schütte 2004, S. 46
[28] vgl. Hertel 1999, S. 11
[29] vgl. Hertel 1999, S. 175
[30] vgl. Hertel 1999, S. 175 – 205
[31] vgl. Hertel 1999, S. 178
[32] vgl. Hertel 1999, S. 179
[33] vgl. Hertel 1999, S. 180 – 183
- Arbeit zitieren
- Gaby Trinker (Autor:in), 2005, Konzept für den modularen Aufbau eines Warenwirtschaftssystems für ein Handelsunternehmen mit Filialen, München, GRIN Verlag, https://www.grin.com/document/67987
Kostenlos Autor werden
Kommentare