grundkurs geschäftsprozess-management || prozessmanagement...

5Prozessmanagementmit betriebswirtschaftlicher Standardsoftware

5.1 Motivation und Grundlagen

Nachdem im vierten Kapitel die anwendungsneutrale Prozessunterstützung durch Work-flow-Management-Systeme vorgestellt wurde, behandelt das fünfte Kapitel die anwen-dungsspezifische, d. h. auf einzelne betriebliche Tätigkeitsbereiche ausgerichtete Unter-stützung von Geschäftsprozessen durch betriebswirtschaftliche Standardsoftware. JüngereUntersuchungen bestätigen, dass der Erfolg von Prozessmanagement auch von der Gestal-tung der betriebswirtschaftlichen Software (Business Software) abhängt (vgl. z. B. Schubertund Koch 2011).

Workflow-Management-Systeme unterstützen die Prozessplanung und -steuerung,nicht aber die Prozessausführung. Betriebswirtschaftliche Einzelfunktionen (z. B. Anlegeneines Auftrages, Prüfen der Gehaltsgruppe eines Mitarbeiters, Erfassen der Reisedateneines Seminarteilnehmers) werden durch spezielle Softwaresysteme – ggf. unter der Kon-trolle der Workflow-Management-Systeme – bereitgestellt. So wird beispielsweise derWorkflow „Reisekostenabrechnung“ für verschiedene Workflow-Schritte auf ein Personal-wirtschaftssystem (Übernahme der Personalstammdaten), Finanzsystem (Überweisungdes Abrechnungsbetrages), Buchungssystem (Beschaffung von Flugtickets) oder einE-Mail-System (Benachrichtigung des Hotels über eine Buchungsanfrage) zurückgreifen.Der Workflow „Auftragsbearbeitung“ bedarf der Unterstützung durch spezielle Softwa-resysteme (Kundeninformationssystem, Lagerverwaltung, Versandsteuerung), die vomWFMS zwar eingebunden werden, die spezifische Funktionalität stellen jedoch andereSysteme bereit.

Ausgangspunkt der Entwicklung betriebswirtschaftlicher Standardsoftware in den 70erJahren waren die damals sehr verbreiteten individuell entwickelten Insellösungen (vgl.Abb. 5.1). Hierunter sind Programmsysteme (Applikationen) zu verstehen, die ihre Datenindividuell verwalten und nur über Schnittstellenprogramme (Datentransferprogramme)mit anderen Applikationen kommunizieren (vgl. Abb. 5.3). Eine zentrale Datenbasis, auf

255A. Gadatsch,Grundkurs Geschäftsprozess-Management, DOI 10.1007/978-3-8348-2428-8_5,© Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden 2012

256 5 Prozessmanagementmit betriebswirtschaftlicherStandardsoftware

Lager

Applikationen

Datenbanken

Lager

Applikationen

Datenbanken

Einkauf

Applikationen

Datenbanken

Einkauf

Applikationen

Datenbanken

Fertigung

Applikationen

Datenbanken

Fertigung

Applikationen

Datenbanken

Verkauf

Applikationen

Datenbanken

Verkauf

Applikationen

Datenbanken

Controlling

Applikationen

Datenbanken

Controlling

Applikationen

Datenbanken

Buchhaltung

Applikationen

Datenbanken

Buchhaltung

Applikationen

Datenbanken

Personal

Applikationen

Datenbanken

Personal

Applikationen

Datenbanken

Unternehmens-bereiche

Man. oder maschineller

Datenaustausch

Legende

Programme Unternehmens-bereiche

Man. oder maschineller

Datenaustausch

Legende

Programme

Abb. 5.1 Lose verbundene nicht integrierte Systeme (Insellösungen)

die alle Applikationen zugreifen können, ist nicht vorhanden. Ebenso fehlt eine übergrei-fende Prozesssteuerung.

Seit Einführung der lochkartengestützten Datenverarbeitung Anfang der 1960er Jah-re entwickelte sich die Computerunterstützung kontinuierlich weiter. Insbesondere ist derEinsatz von Standardsoftware angestiegen, sie stellt in vielen Unternehmen die dominie-rende Softwarekategorie dar (vgl. z. B. Gronau 2001b, S. 14). Betriebswirtschaftliche Stan-dardsoftware wird zur Lösung fachspezifischer Aufgaben im Controlling, der Abwicklungvon Korrespondenzu. a. eingesetzt. Sie besteht aus Applikationen, die entweder aus einzel-nen Softwarepaketen oder integrierten Komplettpaketen bestehen. Neuere Entwicklungensehen so genannte „Serviceorientierte Architekturen“ vor, bei denen die Standardsoftwarein eine Vielzahl kleinere und unabhängig voneinander einsetzbare Bausteine zerlegt wird.

Büro-Applikationen dienen der arbeitsplatzunabhängigen Bereitstellung von lokal be-nötigten Grundfunktionen, wie sie typischerweise für Büroarbeitsplätze notwendig sind(z. B. Textverarbeitung). Business-Applikationen dienen der klassischen funktionsorientier-ten Unterstützung spezifischer Arbeitsplatztypen (z. B. Applikation „Vertriebsabwicklung“für Sachbearbeiter im Vertrieb). Sie stellen die jeweilige Arbeitsplatzfunktionalität bereit,die wegen der speziellen Anforderungen eines Arbeitsplatzes notwendig sind. Der Be-reich der Business Applikationen wird üblicherweise auch unter dem Begriff ERP-Systemdiskutiert (ERP = Enterprise Resource Planning). Hierunter ist ein Softwaresystem zuverstehen, bei dem mehrere betriebswirtschaftliche Applikationen durch eine gemeinsa-me Datenbasis integriert sind (vgl. Abb. 5.2). Dies ist auch zugleich der Hauptvorteil einesERP-Systems, die Integration mehrerer Applikationen durch eine gemeinsameDatenbank.Typische Business-Applikationen für ERP-Systeme sind Finanzwesen und Controlling,Produktionsplanung- und Steuerung, Einkauf und Logistik, Vertrieb und Versand so-

5.1 Motivation und Grundlagen 257

(gemeinsame) Datenbank

LagerEinkauf Fertigung Verkauf

ControllingBuchhaltung Personal

•Stammdaten (Material, Kunden, …)•Bewegungsdaten (Bestellungen, …)•Bestandsdaten (Lagerbestand, Kontensaldo, …)

Unternehmens-bereiche

Zugriff auf Daten

Legende

Programme Unternehmens-bereiche

Zugriff auf Daten

Legende

Programme

(Gemeinsame) Applikationenfür Einkauf, Lager, Fertigung,

Verkauf, Buchhaltung, Controlling, Personal u.a.

Abb. 5.2 Konstruktionsprinzip eines ERP-Systems

Textverarbeitung

Tabellenkalkulation

Grafik/Präsentation

Individuelle Datenhaltung

...

Büro-Applikationen(Arbeitsplatzunabhängige

Unterstützung von Grundfunktionen)

Einkauf und Logistik

Produktionsplanung- und Steuerung

Vertrieb und Versand

Finanz- und Rechnungswesen

Personal

...

Business-Applikationen(Arbeitsplatzspezifische Unterstützung

einzelner betrieblicher Funktionsbereiche)

Handel

Versicherungen

Telekommunikation

Öffentliche Verwaltung

Luftfahrt

...

Branchen-Applikationen(Branchenspezifische Unterstützung

von Geschäftsprozessen)

E-Mail

Telefax

World Wide Web

Elektronischer Kalender

Elektronisches Archiv

...

Kommunikations-Applikationen(Arbeitsplatzverknüpfende

Kommunikationsunterstützung)

Betriebswirtschaftliche Applikationen

Textverarbeitung

Tabellenkalkulation

Grafik/Präsentation

Individuelle Datenhaltung

...

Büro-Applikationen(Arbeitsplatzunabhängige

Unterstützung von Grundfunktionen)

Einkauf und Logistik

Produktionsplanung- und Steuerung

Vertrieb und Versand

Finanz- und Rechnungswesen

Personal

...

Business-Applikationen(Arbeitsplatzspezifische Unterstützung

einzelner betrieblicher Funktionsbereiche)

Handel

Versicherungen

Telekommunikation

Öffentliche Verwaltung

Luftfahrt

...

Branchen-Applikationen(Branchenspezifische Unterstützung

von Geschäftsprozessen)

E-Mail

Telefax

World Wide Web

Elektronischer Kalender

Elektronisches Archiv

...

Kommunikations-Applikationen(Arbeitsplatzverknüpfende

Kommunikationsunterstützung)

Betriebswirtschaftliche Applikationen

Abb. 5.3 Betriebswirtschaftliche Standardsoftware

wie Personal. Im Vordergrund stehen hier die interne Prozessunterstützung, weniger dieUnterstützung zwischenbetrieblicher Geschäftsprozesse. Die individuelle Anpassung anunterschiedliche Bedürfnisse erfolgt durch Customizing, d. h. durch Parametrisierung derStandardsoftware ohne Programmierung. ERP-Systeme dienen oft dem branchenneutra-len Einsatz.

Kommunikations-Applikationen dienen der Unterstützung von arbeitsplatzübergreifen-den Tätigkeiten durch die Bereitstellung von Kommunikationsfunktionen (z. B. E-Mail).Branchen-Applikationen unterstützen die wesentlichen geschäftsspezifischen Prozesse aus-gewählter Branchen. Hinzu kommt die Unterstützung von Querschnittsprozessen wieFinanzen, Controlling und Personalwesen, die in allen Branchen relevant sind, ggf. un-terstützt durch spezifische Voreinstellungen (z. B. Branchen-Kontenpläne für Finanzen,Branchen-Tarifverträge).


5.2 Gesamtzusammengang der Prozessunterstützungmit Informationssystemen

Mertens (2009) hat ein Modell entwickelt, welches die horizontale und vertikale Integra-tion von Prozessen in einem Unternehmen darstellt (vgl. Abb. 5.4). Informationssystememüssen einerseits entlang der Wertschöpfungskette integriert werden. Andererseits müs-sen Führungsinformationen verdichtet für Querschnitts- und Führungsprozesse bereitge-stellt werden.

Ordnet man die gängigen betrieblichen Informationssysteme in das Konzept vonMertens aus Abb. 5.4 ein, so ergibt sich die in Abb. 5.5 dargestellte Situation. Workflow-Management-Systeme unterstützten Prozesse im gesamten Unternehmen, wenngleich der

Abb. 5.4 Integrationsmodell von Mertens (2009)

Abb. 5.5 IT-Unterstützung im Integrationsmodell von Mertens (2009)

5.3 Historische Entwicklung und Trends 259

Schwerpunkt meist im Leistungserstellungsbereich liegt, da dort repetitive Prozesse mitvielen Beteiligten in großer Zahl auftreten. ERP-Systeme unterstützen schwerpunktmäßiginterne Kern- und Querschnittsprozesse während Supply-Chain-Management-Systeme(SCM) und Customer-Relationship-Management-Systeme (SCM) die Integration vonLieferanten bzw. Kunden sicherstellen. Data Warehouse-Systeme sammeln und verdich-ten Informationen und stellen sie Zielgruppengerecht für Analysen und auch operativeProzesse zur Verfügung.

5.3 Historische Entwicklung und Trends

Während um 1990 vorwiegend Großunternehmen der Industrie das ERP-System R/2 ein-gesetzt haben, um den Standardisierungsprozess voranzutreiben, änderte sich später derMarkt in verschiedener Hinsicht. 1993 kamenGroßunternehmen anderer Branchen hinzu.Das SAP-Produkt R/2® musste zunehmend dem Nachfolgeprodukt R/3, das auf der mo-derneren Client-/Server-Basis entwickelt wurde, weichen. Neben den in der SAP® R/2-ÄradominierendenGroßrechnern (Mainframes)wurden nun zunehmendmehrUnix-Systemeeingesetzt.

Ab dem Jahr 1996 kamen erstmals ernst zu nehmende Konkurrenten zu der bis dahindominanten SAP AG auf den Markt für ERP-Systeme. Der gehobene Mittelstand setztezunehmend ERP-Software ein, was zuvor wegen der Großrechnertechnologie von SAP®R/2® zu teuer war. Großunternehmen wechselten in großer Zahl mit ihren R/2-Systemenin Richtung R/3® und führten auch weiterhin SAP ERP® in den bis dahin nicht durchERP-Systeme abgedeckten Bereichen ein. Erstmals wurden die ersten Y2K (Jahr2000) undEuro-Projekte gestartet. Diese durch technische Zwänge (Y2K) oder politische Vorgaben(EURO) initiierten Aufgabenwaren häufig der Anlass, selbst entwickelte Individualsoftwa-re oder veraltete Standardsoftware durch ERP-Systemewie SAPR/3® oder Baan® abzulösen,da diese Systeme die erforderliche Funktionalität zur Verfügung stellten.

Ab 1999 verstärkte sich der Trend zu Standardsoftware auch im Segment des unte-ren Mittelstandes. Dies ging einher mit einer nun wachsenden Anzahl von Software-Anbietern. Unterstützt wurde der Einsatz von betriebswirtschaftlicher Standardsoftwareim unteren Mittelstand, insb. SAP® R/3®, durch die gestiegene Leistungsfähigkeit vonSystem-Plattformen auf der Basis vonWindowsNT, die eine vergleichsweise preisgünstigeR/3-Implementierung ermöglichten.

Der Fokus der vor 2000 liegenden Jahre betraf imwesentlichen dieUnterstützung inner-betrieblicher Prozesse, während zwischenbetriebliche Geschäftsbeziehungen nur ansatz-weise betrachtet wurden. Die zunehmende Globalisierung der Unternehmensaktivitätenverlagert in Zukunft die Prozessketten in die vor- und nachgelagerten Stufen der betriebli-chen Leistungserstellung.

Wurde in früheren Jahren betriebswirtschaftliche Standardsoftware vorwiegend fürhoch standardisierte Unternehmensaufgaben wie Buchhaltung, Kostenrechnung, Con-trolling, Lagerhaltung oder Personalabrechnung eingesetzt, hat sich das Bild seit der


Jahrtausendwende deutlich gewandelt. Auch in weniger strukturierten Aufgabenfeldernwie Marketing, Unternehmensstrategie, Personalmanagement oder Produktentwicklungwird zunehmend Standardsoftware eingesetzt (vgl. auch Oehler 2005, S. 35).

BeispieleStellvertretend für diese Entwicklungstendenzen sind die Konzepte Supply ChainManagement auf der Beschaffungsseite sowie Customer-Relationship-Managementauf der Absatzseite. Die hieraus resultierenden Anforderungen (wie z. B. sich stän-dig verändernde und heterogene Marktpartner und damit auch unterschiedlicheInformationssysteme), aber auch die zunehmenden Möglichkeiten der elektroni-schen Geschäftsabwicklung, die unter dem Schlagwort Electronic-Commerce zu-sammengefasst werden, erfordern zukünftig eine Erweiterung der Funktionalitätbetriebswirtschaftlicher Standardsoftware zur Unterstützung zwischenbetrieblicherProzesse. Ein anderes Beispiel sind Klassifikationswerkzeuge, die teilweise wie z. B.eCla@ss kostenlos verfügbar sind (vgl. eCl@ss 2001 und Palme 2001).

Ein weiteres Konzept für die Integration zahlreicher Unternehmen an einemGesamtprozess sind Produktionsversorgungszentren, die im Fahrzeugbau als Folgeder Probleme bei der Just-in-Time-Belieferung durch Staus auf öffentlichen Stra-ßen entstehen. Mehrere Kraftfahrzeughersteller richten hierzu Lieferantenparks inunmittelbarerNähe ihrerMontagewerke ein, die von einemexternen Logistikdienst-leister betrieben werden. Das Konzept besteht darin, die sequentielle AnlieferungvonMontageteilen an das Band nicht dem einzelnen Lieferanten zu überlassen, son-dern durch einen eigenverantwortlichen Logistikdienstleister zu organisieren. DieLieferanten des Automobilunternehmens liefern z. B. etwa drei Tage vor Beginn dieabgerufenen Teile an. Zum Abrufzeitpunkt stellt der Logistikdienstleister innerhalbkürzester Zeit die Waren mehrerer Hersteller zu einem fahrzeugbezogenen Paketzusammen (z. B. Fußmatten, Radio, Spiegel, Sitze, Ersatzreifen . . . ), welches dannkomplett übernommen wird. Oft liegen nur 30 Minuten zwischen Abrufzeitpunktdurch den Fahrzeughersteller und der synchronen Anlieferung am Band.

Bis etwa 2005 verstärkten sich die Bemühungen der Softwarehersteller, Applikationen– die über den ERP-Bereich hinausgehen – anzubieten. Neben den bereits behandeltenAspekten des Supply-Chain- und Customer-Relationship-Managements ist das Einsatzge-biet Mobile-Commerce bzw. auch Mobile Business zu nennen, das eine Reihe interessan-ter Geschäftsmodelle hervorgebracht hat (vgl. hierzu ausführlich Clement 2002). Hier-unter ist die mobile elektronische Abwicklung von Geschäftsprozessen über das Internetzu verstehen. Betriebswirtschaftliche Standardsoftware wird zunehmend nicht mehr alsmonolithischer Block angesehen, sondern unter demSchlagwort „Componentware“ durcheine Ansammlung vonKomponenten realisiert, die durch einen Rahmen zusammengehal-ten werden.

5.4 Enterprise Resource Planning Systeme 261

Branchen wie Finanzdienstleistungen und Banken, die bisher im Kerngeschäftsbereichkaum Standardsoftware eingesetzt haben, können wegen des steigenden Angebotes ihreseit mehr als 30 Jahren eingesetzten veralteten Systeme ablösen (vgl. Vogel 2004a,b).

Bis Ende der ersten Dekade des 21. Jahrhunderts werden Themen rund um Internet-Portale und elektronische Marktplätze den Standardsoftware-Markt dominieren, weildie weltweite überbetriebliche Kommunikation und Prozessunterstützung im Vorder-grund stehen. Heute noch nicht existierende Firmen werden die Standardsoftware derZukunft produzieren. Die stille Durchführung von Geschäftsprozessen ohne aktive Be-teiligung von Menschen (Silent-Commerce) für Unternehmen aller Größenklassen undBranchenzugehörigkeiten gehört zum Tagesgeschäft des Informationsmanagements. Dieflexible Kopplung von unternehmensübergreifenden Geschäftsprozessen und der sie un-terstützenden Informationssysteme stellt eine der wesentlichen Herausforderungen dieserEpoche dar, da ausgehend von technischen Standardardisierungen auch organisatorischeStandards geschaffen werden müssen (vgl. z. B. Beier 2002, S. 315).

In diesem Zusammenhang werden seit einigen Jahren Web-Services als Werkzeugfür die Umsetzung unternehmensübergreifend verteilter Konzepte diskutiert. Hierun-ter sind standardisierte Schnittstellen auf Basis von Internet-Diensten zu verstehen, dievon dezentralen Informationssystemen verarbeitet werden können (vgl. Stiemerling 2002,S. 435).

5.4 Enterprise Resource Planning Systeme

5.4.1 Merkmale von ERP-Systemen

Unter einem ERP-System (ERP = Enterprise Resource Planning) ist ein Softwaresystemzu verstehen, bei dem mehrere betriebswirtschaftliche Standard Business-Applikationendurch eine gemeinsame Datenbasis integriert sind (vgl. S. 306). Dies stellt sicher, dass nurbetriebswirtschaftlich konsistente Transaktionen ausgeführt werden können (vgl. Friedlet al. 2002, S. 164.).

Typische Business-Applikationen für ERP-Systeme sind Finanzwesen und Control-ling, Produktionsplanung und Steuerung, Einkauf und Logistik, Vertrieb und Versandsowie Personal. Im Vordergrund stehen hier die interne Prozessunterstützung, wenigerdie Unterstützung zwischenbetrieblicher Geschäftsprozesse. Die individuelle Anpassungan unterschiedliche Bedürfnisse durch Customizing, d. h. ERP-Systeme unterstützen denbranchenneutralen Einsatz. Ein Beispiel für ein bekanntes ERP-System ist das SystemSAP® ERP.

ERP-Systeme zeichnen sich durch eine Reihe von Merkmalen wie Datenintegration,Prozessintegration, operative Funktionalität, einheitliches Entwicklungskonzept, Schich-tenarchitektur und Transaktionsorientierung aus (vgl. Tab. 5.1).


Tab. 5.1 Merkmale von ERP-Systemen

Merkmal Kurzbeschreibung Beispiele1. Daten-integration

Mehrere Softwaremodule nutzengemeinsame Daten

Ein Vertriebs- und Buchhaltungs-modul verwenden jeweils dieKundenstammdaten.

2. Prozess-integration

Abteilungsübergreifende Ge-schäftsprozessewerden durchmehrere beteiligte Softwaremodulegemeinsam unterstützt.

Die Kundenauftragsbearbeitung wirdvom Eingang der Kundenanfrage, überdie Fertigung bis hin zur Auslieferungund Bezahlung der Ware mit Hilfemehrerer Softwaremodule (Vertriebs-abwicklung, Produktionsplanung,Versand, Finanzen) unterstützt.

3. OperativeFunktionalität

Unterstützung operativer Auf-gaben eines Unternehmens zurAbwicklung von Geschäftsvorfäl-len.

Auftragsbearbeitung, Fertigungspla-nung, Kundenbuchhaltung, ErfassenEingangsrechnungen, Gehaltsabrech-nung.

4. Ein-heitlichesEntwicklungs-konzept

Softwaremodule nutzen gemeinsa-mes Repository und basieren aufeinheitlichen Entwicklungsstan-dards

Gleiches Bildschirmmaskenlayout,gleichartige Fehlermeldungen.

5. Schichten-architektur

Softwarearchitektur zur Unter-stützung einer über mehrereAbteilungen und Standorte, ggf.auch Länder, verteilten Verarbei-tung.

Client-/Server-Architektur zur Reali-sierung des dezentralen Zugriffs aufDaten und Funktionen

6. Transakti-onsorientie-rung

Onlineverarbeitung von Ge-schäftsvorfällen und Speicherungder Daten auf Datenbanken.

Anlegen eines Kundenauftrages, Bu-chen einer Eingangsrechnung.

1. ERP-Merkmal: DatenintegrationEinHauptmerkmal integrierter Standardsoftware ist die gemeinsameVerwendung vonDa-ten.

Beispiel: VertriebsdatenKundenstammsätze werden im Regelfall originär durch Mitarbeiter im Vertriebangelegt. Hier fallen Aufgaben wie Vergabe einer Kundennummer, Kundenname,Anschrift, Vertriebsdaten usw. an.

Der Debitorenbuchhalter kann diese im ERP-System verfügbaren Informatio-nen aufgreifen und um spezifische Informationen der Buchhaltung erweitern (z. B.Kreditlimit, Mitbuchkonto, Zahlungsmodalitäten). Beide Mitarbeiter greifen aufdieselben Datenbestände zu.


Die Datenintegration macht sich vor allem in der „Durchbuchung“ von Geschäftsvor-fällen in allen aktivierten Komponenten der Standardsoftware bemerkbar. Verwendet einUnternehmen beispielsweise ein integriertes Anwendungssystem mit den TeilfunktionenLogistik/Materialwirtschaft, Produktionsplanung und Buchhaltung, so bewirkt eine Wa-reneingangsbuchung eines für die Produktionssteuerung notwendigen Rohmaterials fol-gende Aktivitäten:

• Fortschreibung der mengenmäßigen Lagerbestände in der Logistik und Materialwirt-schaft

• Auslösung eines Produktionsauftrages, der auf dieses Material wartet,• Erhöhung der Lagerwerte in der Buchhaltung.

2. ERP-Merkmal: ProzessintegrationVon besonderer Bedeutung für das Geschäftsprozessmanagement ist die Frage der Durch-gängigkeit der Prozessunterstützung, d. h. der Verzicht auf Mitarbeiter-, Abteilungs- oderSoftwarewechsel. Nur eine durchgängige Verbindung mehrerer Anwendungsbausteine zueinem Geschäftsprozess erlaubt es, auf Schnittstellen weitgehend zu verzichten und Datennur einmal, am Entstehungsort, zu erfassen und in allen Komponenten weiterzuverar-beiten. Integrierte Datenbanken erfordern die Plausibilitätsprüfung aller Daten schon beider Eingabe in das System. So müssen auch bei einer mengenmäßigen Wareneingangsbu-chung die buchhaltungsrelevanten Datenfelder erfasst und geprüft werden. So muss z. B.festgestellt werden, ob eine mit dem Wareneingang zu belastende Kostenstelle überhauptexistiert. Ebenso müssen in einem solchen Anwendungsfall die Daten des Geschäfts-vorfalls in alle betroffenen Anwendungsbausteine weitergereicht, d. h. „durchgebucht“werden.

Erst die durchgängige schnittstellenfreie Verbindung der Einzelfunktionen,wie z. B. Lo-gistik, Rechnungswesen oder Vertrieb zu einem Gesamtsystem machen eine integrierteStandardsoftware aus. Alle Systemkomponenten greifen hierbei auf gemeinsam genutz-te Datenbanken zu. Eine „Integration“ verschiedener Bausteine über Batch-Schnittstellenstellt dagegen nur eine Datenversorgung der Einzelkomponenten dar und kann nicht alsIntegration bezeichnet werden. „Batch-Programme“ laufen ohne Benutzereingriffe ab. Einanderer, etwas veralteter, Begriff hierfür ist die „Stapelverarbeitung“. Dialogprogramme er-fordern imGegensatz zu Batchprogrammen Benutzerinteraktionen, wie z. B. die Erfassungvon Kundendaten am Bildschirm. Daten, die für nicht integrierte Programme für unter-schiedliche Zwecke erforderlich sind, werden über Schnittstellenprogramme ausgetauscht.Bei hohemDatenvolumen wird dies häufig in der Form von Batch-Programmen realisiert.Dies ist z. B. bei der Übertragung von Kundenstammsätzen aus einem Vertriebs-System inein Finanzbuchhaltungs-System der Fall.

Entscheidend ist es, ob Prozessketten über alle Bausteine der Standardsoftware hinwegabgebildet werden können. So muss die Auftragsabwicklung entsprechend dem realen Be-arbeitungsfluss durch die Vertriebs-, Logistik, Produktions- und Versandfunktionen imStandardsoftwaresystem implementiert und übergangslos ohne Medienbrüche ausgeführt


Sekundärprozess

Primärprozess

Sekundärprozess

Scheck-rücklaufZahlung

Kredi-toren

Hauptbuch

Haupt-buch

Rechnungs-eingang

Istvorl.Ist

Bestell-obligoBANF-ObligoControlling

Waren-eingang

Bestel-lungBANFLogistik

Finanzen

Modul Prozessketten

Abb. 5.6 Prozessintegration am Beispiel Einkaufslogistik

werden können. ImHintergrund müssen die administrativen Funktionen wie Rechnungs-wesen und Controlling mit den erforderlichen Informationen versorgt werden.

Fallbeispiel 1 zur Prozessintegration: Beschaffungslogistik mit Integrierter Standard-softwareDer Prozessüberblick des Primärprozesses Beschaffung in Abb. 5.6 zeigt, wie ausge-hend von Bestellanforderungen (BANF) der Logistik Obligodaten im Controlling(z. B. auf einem Auftrag oder einer Kostenstelle fortgeschrieben werden). Bestel-lanforderungen sind Anforderungen an den Einkauf, bestimmte Materialien oderDienstleistungen zu beschaffen. Sie können z. B. vom Bedarfsverursacher (z. B.Leiter der Kostenstelle) im Modul Materialwirtschaft angelegt werden. Unter ei-nem Obligo sind Verpflichtungen zu verstehen, die aufgrund von Verträgen oderDispositionen entstehen und noch nicht buchhalterisch erfasst sind. Ein Bestellob-ligo wird durch die Bestellung im Einkauf ausgelöst. Der Wareneingang führt inden Controlling-Berichten zu vorläufigen Istwerten, die durch den späteren Rech-nungseingang vom „tatsächlichen Ist“ abgelöst werden. Der Wareneingang schlägtsich auf Materialkonten des Hauptbuches im Sekundärprozess Finanzen nieder.Der Rechnungseingang wird über die Rechnungsprüfung des Moduls Materialwirt-schaft auch ins Kreditorennebenbuch und über die Mitbuchtechnik ins Hauptbuchgebucht.

Fallbeispiel 2 zur Prozessintegration: Vertriebslogistik mit betriebswirtschaftlicherStandardsoftwareDie Abb. 5.7 zeigt den Kernprozess Vertrieb, der als Datenlieferant für die invol-vierten Querschnittsprozesse auftritt. Der Auftragseingang im Vertriebsmodul löst


SekundärprozessZahlungMahnung

ErgebnisAuftrags-eingangForecast

Controlling

RechnungWaren-ausgang

Auftrags-eingangVertrieb

DebitorenHaupt-buch

Kredit-prüfung

Finanzen

Modul Prozessketten

Primärprozess

Sekundärprozess

Abb. 5.7 Prozessintegration am Beispiel Vertriebslogistik

die Kreditlimitprüfung in der Debitorenbuchhaltung aus. Gleichzeitig werden dierelevanten Controllingobjekte (z. B. Auftrag) fortgeschrieben und gehen in Forecast-Analysen des Vertriebs-Controllingmoduls ein. Die Buchung desWarenausgangs imVertrieb löst wiederum die Fakturierung aus. Bei integriertem Einsatz betriebswirt-schaftlicher Standardsoftware wird hierdurch die Buchung der Rechnung ausgelöst,die im Nebenbuch Debitoren und über die Mitbuchtechnik im Hauptbuch fort-geschrieben wird. Hiernach folgen je nach Kundenverhalten die Mahnung oderZahlungsabwicklung im Finanzwesen. In der Prozessübersicht wurde die Berück-sichtigung der zahlungsrelevanten Vorgänge im Rahmen der Finanzdisposition(Treasury) der Einfachheit halber vernachlässigt.

3. ERP-Merkmal: Operative FunktionalitätERP-Systeme unterstützen Funktionen, die zur operativen Bearbeitung der regelmäßig an-fallenden Geschäftsvorfälle eines Unternehmens notwendig sind. Beispiele sind die Er-fassung von Bestellungen, Aufträgen, Durchführung der Lohn- und Gehaltsabrechnungusw. Sie grenzen sich hierdurch vonManagementinformationssystemen ab, welche für dieUnterstützung der Analyse von Daten eingesetzt werden können, z. B. für Kundenumsatz-analysen.

4. ERP-Merkmal: Einheitliches EntwicklungskonzeptEinzelne, unabhängig voneinander konzipierte Teilfunktionen lassen sich nicht zu einemGesamtsystem integrieren, so dass es die obigen Anforderungen erfüllen kann. Integrier-te Standardsoftwaresysteme basieren daher auf einem einheitlichen Entwicklungskonzept.In Form eines Schichtenmodells wird auf einer unteren Ebene ein Basissystem mit über-greifenden, für alle Teil-Funktionen notwendigen „Services“ konzipiert. Daneben werden


Basiseinstellungen (z.B. Kalender)

Unter-nehmen

A

Unter-nehmen

B

Unter-nehmen

C

Unter-nehmen

D

Unter-nehmen

E

ERP-System

Abb. 5.8 Mandantenfähigkeit

bei integrierten Systemen einheitliche Standards eingesetzt, so z. B. ein einheitliches Bild-schirm und Druckoutput-Layout, verwendete Datenbanksysteme bzw. Datenbanksystem-schnittstellen und Verwendung offener Schnittstellen (z. B. TCP/IP).

5. ERP-Merkmal: SchichtenarchitekturERP-Systeme sind keine Einplatz-Systeme, wie z. B. ein Textverarbeitungsprogramm, dasauf einem einzelnen Arbeitsplatz vollständig installiert und genutzt wird. Sie unterstüt-zen betriebswirtschaftliche Funktionen, die in der Regel von mehreren Mitarbeitern inverschiedenen Abteilungen und auch an unterschiedlichen Standorten benötigt werden.Aus diesem Grund ist eine Schichtenarchitektur notwendig, die meist in Form des Client-/Server-Prinzips mit einer Trennung der Präsentation, Verarbeitung undDatenhaltung rea-lisiert wird.

6. ERP-Merkmal: TransaktionsorientierungDie Unterstützung operativer Geschäftsvorfälle erfordert die Veränderung von Datenmit Hilfe von Online-Transaktionen. ERP-Systeme arbeiten transaktionsorientiert, d. h.sie stellen eine Reihe von Transaktionen zur Unterstützung der Geschäftsprozesse zurVerfügung (z. B. Transaktion zum Anlegen eines Kundenauftrags, zur Erfassung einerBestellung, zum Ändern eines Mitarbeiterstammsatzes u. a.).

MandantenfähigkeitErgänzend kommt bei vielen Standard-ERP-Systemen die Mandantenfähigkeit hinzu.Hierunter ist die Möglichkeit zu verstehen, mehrere Unternehmen aus betriebswirtschaft-licher Sicht völlig unabhängig voneinander in einer technischen Installation abzurechnen(vgl. Abb. 5.8). Für alle Unternehmen geltende Basiseinstellungen beschränken sich aufwenige allgemeingültige Aspekte (z. B. Kalendereinträge). Darüber hinaus kann jedesUnternehmen individuell konfiguriert und auf der Installation abgerechnet werden.

5.5 Supply Chain Management Systeme 267

5.4.2 Verbreitung von ERP-Systemen

In den meisten Unternehmen werden ERP-Systeme eingesetzt. Dies zeigen zahlreiche Un-tersuchungen und Umfragen. So ergab z. B. eine Umfrage der META Group (vgl. o. V.2003), dass über 66% der befragten Unternehmen (N = 278 Unternehmen) ein ERP imEinsatz haben. Bei Großunternehmen kann bereits von einer Sättigung des Marktes ge-sprochen werden, da dort meist ERP-Systeme im Einsatz sind. Der Fokus liegt eher auf derEinführung weiterer Module oder Komponenten der jeweiligen Software. Nach einer Un-tersuchung des IT-Medienunternehmens IDC kann die SAP AG die Marktführerschaft imERP-Markt für sich beanspruchen (o. V. 2004).

5.5 Supply ChainManagement Systeme

5.5.1 Begriff und Abgrenzung zur Logistik

Die Logistik ist einer der zentralen Geschäftsprozesse eines Unternehmens. Hierunter istdie Planung und Steuerung vonMaterial- und den zugehörigen Informationsflüssen einesUnternehmens zu verstehen. Hierzu gehören insbesondere die physische Materialbereit-stellung, die innerbetriebliche Logistik, d. h. Zwischenlagerung und Verteilung der Mate-rialien sowie die sich anschließende physische Distribution der Waren an die Empfänger(vgl. z. B. Tempelmeier 1992, S. 4).

Der Fokus der klassischen Logistik liegt auf der Planung, Steuerung und Optimierungdes Materialdurchlaufs innerhalb eines Unternehmens. Dies hat dazu geführt, dass diebereits vorgestellten ERP-Systeme schwerpunktmäßig die innerbetriebliche Logistikunter-stützung sicherstellen, während die zwischenbetrieblichen Aspekte keine oder nur geringeUnterstützung erfahren.

Unternehmen sehen sich seit Jahren stark wachsenden Anforderungen hinsichtlicheiner erhöhten kurzfristigen und stabilen Lieferfähigkeit, steigenden Qualitätsanforde-rungen und einem sinkendem Preisniveau gegenübergestellt. Dies führte zu einem Abbaunicht zwingend notwendiger Funktionen und einer so genannten „Konzentration auf dieKernkompetenzen“ eines Unternehmens, d. h. der eigentlichen Stärken z. B. in der Her-stellung bestimmter Produkte oder Bereitstellung von Leistungen. Da die Arbeitsteiligkeitin der Güterproduktion und die damit verbundene Spezialisierung stark zugenommenhat, wurde es auch erforderlich, sich verstärkt mit der überbetrieblichen Frage der Opti-mierung der gesamten logistischen Kette vom Lieferanten und dessen Vorlieferanten biszum Kunden und wiederum seinem Endabnehmer zu beschäftigen.

Die Betrachtung dieser gesamten logistischen Kette vom ersten Lieferanten bis zumEndverbraucher wird als „Supply-Chain (SC)“ bezeichnet und stellt den überbetrieblichenCharakter des Ansatzes heraus. Supply Chain Management (SCM) geht daher weit überdie innerbetrieblichen Aspekte der Logistik hinaus und betrachtet die gesamte zwischen-


Lieferant Fertigungs-Stufe 1

Fertigungs-Stufe 2 Handel End-

verbraucherLieferant Fertigungs-Stufe 1

Fertigungs-Stufe 2 Handel End-

verbraucherMaterialfluss Materialfluss Warenfluss WarenflussMaterialfluss Materialfluss Warenfluss Warenfluss

Finanzfluss

Informationsfluss

Finanzfluss

Informationsfluss

Finanzfluss

Informationsfluss

Finanzfluss

Informationsfluss

Finanzfluss

Informationsfluss

Finanzfluss

Informationsfluss

Finanzfluss

Informationsfluss

Finanzfluss

Informationsfluss

InformationsflussInformationsfluss

Supply-Chain(SC)Supply-Chain(SC)

Logistische Kette (Material-, Informations- und Finanzfluss) vom erstenLieferanten über alle Fertigungsstufen hinweg bis zum EndverbraucherLogistische Kette (Material-, Informations- und Finanzfluss) vom erstenLieferanten über alle Fertigungsstufen hinweg bis zum Endverbraucher

Supply-Chain(SC)Supply-Chain(SC)

Logistische Kette (Material-, Informations- und Finanzfluss) vom erstenLieferanten über alle Fertigungsstufen hinweg bis zum EndverbraucherLogistische Kette (Material-, Informations- und Finanzfluss) vom erstenLieferanten über alle Fertigungsstufen hinweg bis zum Endverbraucher

Abb. 5.9 Supply-Chain in Anlehnung an Knolmayer et al. (2000, S. 2)

betriebliche Kette. SCM strebt eine verstärkte Zusammenarbeit aller an einer Supply-Chainbeteiligten Unternehmen an, um alle Material-, Informations- und letztlich auch die Fi-nanzflüsse insgesamt zum gemeinsamen Nutzen zu optimieren. Die Darstellung in derAbb. 5.9 verdeutlicht diesen Zusammenhang.

Das Konzept des Supply ChainManagements umfasst die integrierte Planung, Optimie-rung, Steuerung und Kontrolle der Material-, Informations- und Finanzflüsse vom erstenLieferanten über alle Fertigungsstufen hinweg bis hin zum letzten Endverbraucher.

Hiervon abzugrenzen ist das SRM (Supplier-Relationship-Management), dass sich aufdie Pflege der Beziehungen zu den Lieferanten beschränkt (vgl. Große-Wilde 2004, S. 61).SRM ist das Gegenstück zumCRM (Customer RelationshipManagement), das sichmit derKundenbeziehungspflege beschäftigt. TypischeAufgaben des SRMsind die Lieferantenaus-wahl, die Einführung spezieller Informationssysteme zur Realisierung der elektronischenBeschaffung, E-Payment, der Aufbau von Lieferantenportalen unddasMonitoring der Lie-feranten hinsichtlich Qualität und Konditionen. CRM dagegen beschäftigt sich mit denWaren, Finanz- und Informationsströmen vom ersten Lieferanten bis hin zum Endabneh-mer.

Die SCM-Aktivitäten finden auf der strategischen Ebene (z. B. Auswahl geeigneter Lie-feranten und Gestaltung der Leistungs- und Informationsströme) und auf der operativenEbene durch detaillierte Planung und Überwachung der Material-, Informations- und Fi-nanzflüsse (z. B. Veränderung der Logistikplanung auf Grund eines Maschinenausfalls)statt.

Die möglichen Nutzenpotentiale des SCM sind für alle an der Supply Chain Beteiligtenvon hoher Bedeutung (vgl. Knolmayer et al. 2000, S. 18):

• Erhöhung der Prognosegenauigkeit,• Reduktion der Materialbestände,


• Senkung der Prozesskosten,• Erhöhung der Liefertreue,• Verbesserung der Kapazitätsauslastung und• Steigerung der Produktivität.

Beispiel AutomobilindustrieDer Produktionsprozess zur Herstellung von Automobilen kann als klassischer Pro-zess für die Notwendigkeit von Supply Chain Management herangezogen werden.Typischerweise sind bei den hierbei auftretenden vielfältigen Produktions- undMontageprozessen mehr als 100.000 Teile in der erforderlichen Qualität und Men-ge an weltweit auftretenden Standorten genau dann zu liefern, wenn sie gebrauchtwerden. Die hierbei einzuhaltenden Zeitpunkte für die Anlieferung sind teilwei-se im Minutenbereich angesiedelt. Verzögerungen treffen häufig den vollständigenProduktions- und Montageprozess und erfordern eine sofortige Neuplanung dergesamten Supply-Chain, um die Konsequenzen zu berücksichtigen. Die beteiligtenZulieferer und Dienstleistungsunternehmen sind in einem gemeinsamen Material-,Informations-, und Finanzkreislauf eingebunden, der nur durch geeignete Compu-terunterstützung gesteuert werden kann.

Beispiel ComputerindustrieDurch die Nutzung von SAP-Komponenten wurden bei der Compaq ComputerCorporation zur Unterstützung der weltweiten Logistikkette u. a. folgendemessbareVerbesserungen erreicht (vgl. Thomas 2002):

• Reduktion der Zyklusdauer für Nachfrageprognosen vonmehrerenMonaten aufeine Woche und weniger,

• Verkürzung der Bearbeitungszeit für das Anlegen eines Kundenauftrages von 2–3 Tagen auf 1 Tag nach Entgegennahme des Auftrages,

• Verkleinerung der Materialbestände um 10–15%,• Verbesserung der Auftragserfüllung von 85% auf mindestens 95%Nachfrageab-

deckung.

5.5.2 Ziele des Supply ChainManagements

Die Hauptziele des Supply ChainManagements sind die Erfüllung der Kundenanforderun-gen und die Erhöhung der Wirtschaftlichkeit unternehmensübergreifender Wertschöp-fungsprozesse. Hieraus resultieren mehrere Einzelziele wie (vgl. Weber 2001, S. 4).


• Erhöhung des Kundenservice (z. B. Termin- und Liefertreue)• Verkürzung der Zeiten für Produktentwicklung und Auftragsdurchlauf,• Bestandsreduzierung einer Lieferkette,• größere Flexibilität durch Integration in der Lieferkette,• Nutzung von Synergieeffekten und neue Geschäftschancen.

Eng verbundenmit den Zielen des SCM ist die Reduzierung des Bullwhip-Effektes (vgl.Keller und Krol 2003). Hierunter sind Nachfrageschwankungen in Lieferketten zu verste-hen, die umso stärker ansteigen, je weiter eine Unternehmung in einer Lieferkette vomEndverbraucher entfernt ist. Unternehmen reagieren hierauf z. B.mit einer ausgleichendenLagerhaltung, die zu steigenden Logistikkosten führt. Die Ursachen für den Bullwhip-Effekt sind noch nicht vollständig erforscht. Schönsleben et al. (2003, S. S42–43) nennenu. a. folgende Ursachen:

• Lange Durchlaufzeiten: Je länger die Durchlaufzeit eines Kunden- bzw. Fertigungsauf-trages ist, desto größer ist der Bullwhip-Effekt.

• Absatzplanungen der Produzenten auf der Basis von Bestellungen des jeweiligen Vor-gängers anstelle der Endnachfrage in der Lieferkette verstärken den Effekt.

• Losbildung:Werden Bedarfe zu Losen zusammengefasst, umRüstkosten und bestellfixeKosten zu senken, wird die Nachfrage in den nachgelagerten Stufen verzerrt.

• Schwankende Preise gegenüber Endkunden führen zu atypischem Vorziehen und Ver-zögern von Bedarfen, was den Bullwhip-Effekt der nachgelagerten Stufen verstärkt.

• Fehlende oder verzögerte Informationen über Bedarfsveränderungen verzerren denBe-darf in nachgelagerten Stufen: z. B. Reifenproduzent erfährt erst mit Verzögerung vonNachfragesteigerung nach bestimmen Reifentypen.

Durch eine verbesserte Planungsgenauigkeit und schnellere Informationsweitergabe inder gesamten Supply-Chain wird eine Reduzierung dieses Effektes mit den vorgenanntenZielen angestrebt. Die Einhaltung der Ziele wird im Rahmen der Prozessführungmit Hilfespezifischer Kennzahlen des Controllings sichergestellt (vgl. Tab. 5.2).

5.5.3 Organisation des Supply ChainManagements

Supply Chain Management kann unterschiedlich organisiert werden. Die Zusammenar-beit kann auf mehreren organisatorischen Ebenen stattfinden (vgl. Knolmayer et al. 2000,S. 15 f.):

• zwischen mehreren Konzern-Unternehmen,• zwischen zwei Unternehmen in der Supply-Chain und• zwischen mehr als zwei Unternehmen in der Supply-Chain.


Tab. 5.2 SCM-Kennzahlen (Weber 2001, S. 4)

Kennzahlentyp BeispieleLogistik-Kennzahlen Lieferzuverlässigkeit

FehlmengenLieferfähigkeitLieferbereitschaftLieferzeit und Lieferflexibilität der KetteBestandsreichweite und Umschlagshäufigkeit

Kosten-Kennzahlen Kosten der gesamten KetteLagerkostenBestandskostenHandlingkostenTransportkostenSystem- und Steuerungskosten

Produktivitäts-Kennzahlen AnlagennutzungGrad der KapazitätsausnutzungTransportauslastung

Finanz-Kennzahlen Zykluszeit Zahlung der Kunden –Zahlung der Lieferanten (cash to cash cycle-time)

Supply Chain Management findet häufig bereits auf überbetrieblicher Ebene innerhalbeines Konzernunternehmens statt, wenn die beteiligten rechtlich selbständigen Konzern-unternehmen entlang einer logistischen Kette positioniert sind. Beispiele finden sich invielen Branchen, z. B. der Automobil-, Telekommunikations- oder auch der Computer-industrie. Initiiert werden entsprechende Maßnahmen in diesen Fällen häufig von denKonzernzentralen, die eine gemeinsame Strategie und eine aus Konzernsicht durchgeführ-te Optimierung von Durchlaufzeiten und Materialbeständen fordern.

Beispiel: KonzerndatenmanagementSo hat z. B. ein großer deutscher Konzern in einem Projekt zum gemeinsamenDatenmanagement den Grundstein für ein konzernweites SCM gelegt, in demgemeinsamgenutzteKunden- oder Produktdaten definiert, strukturiert und auf zen-tralen Datenservern bereitgestellt werden (vgl. Fleisch et al. 1998).

SCM-Konzepte können bereits auf bilateralen Vereinbarungen zwischen zwei in derSupply-Chain benachbarten Unternehmen beruhen (vgl. Knolmayer et al. 2000, S. 16).Bereits seit mehreren Jahren finden diese Vereinbarungen unter Nutzung von Technolo-giestandards wie EDI (Electronic Data Interchange) statt, die zum Austausch von Auf-tragsdaten (Bestellung, Lieferung, . . . ) geeignet sind. Hierbei werden die IV-Systeme derbeiden beteiligten Unternehmen mit Hilfe von Vereinbarungen über den Datenaustausch


(sog. Protokolle) so aufeinander abgestimmt, dass die computerunterstützten Prozesse zueinem Gesamtprozess verschmelzen. Derartige Konzepte optimieren lediglich den Da-tenaustausch zwischen den beiden beteiligten Unternehmen, ein „echtes“ SCM im Sinneeiner Optimierung der gesamten logistischen Kette liegt daher streng genommen nichtvor.

Ein sinnvoller Weg zur Ausschöpfung der Nutzenaspekte des Supply Chain Manage-ments erfordert die Beteiligung mehrerer Unternehmen, die an einer Supply-Chain betei-ligt sind. Im Gegensatz zur Initiierung der SCM-Maßnahmen durch eine Konzernzentraleerfolgt der Anstoß meist durch ein besonders interessiertes Unternehmen. Erforderlich istes, über ein gemeinsam genutztes Informationssystem die Datenbasis für die gemeinsameLogistikunterstützung zu schaffen. Knolmayer et al. schlagen hier ein gemeinsames Lo-gistik Data Warehouse vor (vgl. Knolmayer et al. 2000, S. 17). Die Informationssystemeder beteiligten Unternehmen greifen auf das Data Warehouse zu, um ihren jeweiligen In-formationsbedarf zu befriedigen. Da die Unternehmen im Gegensatz zum „Konzernfall“rechtlich und wirtschaftlich unabhängig sind, treten eine Reihe von zusätzlichen Fragenauf, die gelöst werden müssen. Einige Beispiele sind (vgl. auch Buxmann und König 2000,S. 54):

• Wer übernimmt die Führungsrolle für Außenkontakte?• Wie werden die auftretenden Geschäftsrisiken, z. B. auf Grund von Störungen, verteilt?• Wie werden die gemeinsam erwirtschafteten Deckungsbeiträge verteilt?• Wer entscheidet über Optimierungsalternativen, die zu unterschiedlichen Kapazitäts-

auslastungen führen können?

Beispiel SmartEin bekanntes Beispiel für ein in der Praxis erfolgreiches Konzept des Supply ChainManagements ist die Produktion des Kleinwagens Smart, das durch ein Konsortiummehrerer rechtlich und wirtschaftlich selbständiger Unternehmen getragen wird.Mercedes-Benz nimmt die Führungsrolle in dieser Supply-Chain wahr. Die gesamteLogistik wird vonmehreren unabhängigen Partnern gemeinsam getragen (vgl. Bux-mann und König 2000, S. 55).

Das Supply Chain Council ist eine 1997 gegründete gemeinnützige Vereinigung von In-dustrieunternehmen.DieMitglieder arbeiten zusammen, umdas SupplyChainOperationsReference Modell (SCOR) weiter zu entwickeln, den Einsatz zu unterstützen und die wei-tere Verbreitung zu fördern. Es ist das derzeit einzige Referenzmodell für Logistikketten.Es enthält Standardprozessdefinitionen, Terminologien und auch Kennzahlen. Mitgliederdes Supply Chain Council können gemeinsame Supply Chains bilden, da sie die gleicheMethode verwenden.


Beschaffung Produktion AbsatzBeschaffung Produktion AbsatzBeschaffung Produktion AbsatzBeschaffung Produktion Absatz Beschaffung Produktion AbsatzBeschaffung Produktion Absatz BeschaffungAbsatz

Betrachtetes UnternehmenLieferant(intern/extern)

Kunde(intern/extern)

Lieferant des

Lieferanten

Kunde des

Kunden

Supply-Chain

Zwischenbetriebliche Planung der gesamten

„Supply-Chain“

Zwischenbetriebliche Planung der gesamten

„Supply-Chain“

Planungsobjekte•Produkte •Absatzmengen•Liefertermine•Kapazitäten•Fertigungspläne•Transportrouten•........

Planungsziel: Produziert wird im Idealfall nur das, was der Endverbraucher auch abnimmt

Abb. 5.10 Supply Chain des Supply Chain Councils (SCOR)

Die Abb. 5.10 zeigt die Darstellung der Supply-Chain nach dem Konzept des SupplyChain Council (vgl. SCOR 2001). Zu erkennen ist die betriebsübergreifende Betrachtungder logistischen Kernprozess-Schritte „Beschaffung“, „Herstellung“, „Lieferung“, die sichauf jeder Wertschöpfungsstufe wiederholen. Die ganzheitliche Betrachtung bezieht alleWertschöpfungsstufen vom „Lieferanten des Lieferanten“ bis hin zum „Kunden des Kun-den“ ein.

Das SCOR-Modell der Supply Chain umfasst vier Kernprozesse (vgl. Kuhn et al. 1998,S. 9):

• Planung: Strategische Make-or-Buy-Entscheidungen und Ressourcenplanung, ope-rative Anforderungsanalyse und Bedarfsaggregation sowie Auftragsplanung und -verteilung,

• Beschaffung: Strategische Aktivitäten wie Bildung von Partnerschaften und Abschlussvon Kontrakten sowie Beurteilung der Lieferanten, operative Arbeiten wie Lieferung,Lagerung, Prüfung und Bereitstellung von Material,

• Produktion: Strategische Konzeption der Fertigungsinfrastruktur, d. h. von Produkti-onseinrichtungen, operativen Aktivitäten wie Materialanforderung, Fertigung, Monta-ge und Verpackung,

• Absatz: Nachfrageerfassung, Auftragsabwicklung, Distribution, Lagerhaltung, Trans-port und Auslieferung.

Die Optimierung von Logistikprozessenwar auch bereits ein Ziel des sog. Just-in-Time-Konzeptes. Es besagt, dass Materialien erst dann für die Produktion bereitgestellt werdensollen, wenn sie tatsächlich benötigt werden, d. h. auf eine Zwischenlagerung wird weitge-


Tab. 5.3 Just-in-Time vs. SCM (Krüger und Steven 2000, S. 506)

Just in Time Supply Chain ManagementGrundannahme Distanz zwischen Lieferant und

Abnehmer ist kurzDistanz zwischen Lieferant undAbnehmer ist groß

Qualität der Informa-tionen

Sehr hoch, da kurzfristige Pro-gnosen

Eher gering, da langfristige Pro-gnosen

Unsicherheit bei derAnlieferung

Sehr gering In Abhängigkeit von Transport-mitteln eher hoch

Anzahl der Anliefe-rungen

Hoch Eher gering

Bedeutung von Be-ständen

Keine/wenig Bestände Bestände sind notwendig, umUnsicherheiten abzufangen

hend verzichtet. Auch hier lassen sich Beispiele in der gesamtenAutomobilindustrie finden.Das Konzept der Just-in-Time-Belieferung ist durchaus verträglich mit dem Ansatz desSupply Chain Management und kann als dessen Teilmenge betrachtet werden, da es ähn-liche Ziele verfolgt.

Die wesentlichen Merkmale beider Konzepte werden in der Tab. 5.3 verglichen, um dieUnterschiede und Gemeinsamkeiten aufzuzeigen (vgl. Krüger und Steven 2000, S. 506).

5.5.4 Computerunterstützung des Supply ChainManagements

Schon lange bevor der Begriff des Supply ChainManagements bekannt wurde, gab es Soft-ware zur Unterstützung betrieblicher Planungsprobleme der Produktion und Logistik.

Eines der ersten Konzepte zur Unterstützung bei betrieblichen Planungsproblemenwarder MRP-Ansatz (Manufacturing Resource Planning). Hierunter ist ein Programm zurAuflösung von Stücklisten und Bedarfsermittlung zu verstehen, das für die zu beschaf-fenden bzw. fertigenden Materialen Planaufträge mit Angaben über Mengen und Termineerstellte.

Da dieser Ansatz nicht ausreichend war, um betriebliche Planungsprobleme zufriedenstellend zu lösen (z. B. wurden kein Ressourcenabgleich durchgeführt), wurde das KonzeptMRP II entwickelt. MRP II-Systeme waren in der Lage, die für die Fertigung erforder-lichen Ressourcen zu berücksichtigen und den Planaufträgen zuzuordnen. Neben Kun-denaufträgenmit Sekundärbedarfen wurden auch anonymePlanaufträge zur Deckung vonPrimärbedarfen an Materialien erzeugt und für mehrere Werke und Standorte eines Un-ternehmens ermittelt. Auch dieses Konzept reichte nicht für alle Praxisprobleme aus. Sowar die Planungsdauer durch eine sequentielle Vorgehensweise zu lang, was dazu führte,dassmeist nurmonatlich geplant wurde und dies wiederum zu veralteten Planungsständenführte.


Supply-Chain-Management-Systeme

(Planung)

Supply-Chain-Management-Systeme

(Planung)

Enterprise Ressource Planning-Systeme

(Ausführung)

Enterprise Ressource Planning-Systeme

(Ausführung)

Data-Warehouse-Systeme(Analyse)

Data-Warehouse-Systeme(Analyse)

Ist-DatenIst-Daten

Plan-Daten

Plan-DatenAnalyse-Daten

Analyse-Daten

Stammdaten undPlanungstypenStammdaten undPlanungstypen

Abb. 5.11 Supply-Chain-Cycle (in Anlehnung an Bartsch und Teufel 2000)

Aus den MRP II-Systemen wurden in den 1980–1990er Jahren die ERP-Systeme ent-wickelt. Da sie umfassende Funktionen zur Unterstützung der Beschaffung, Logistik undProduktion bereitstellen, liegt die Vermutung nahe, dass sie auch geeignete Funktionalitä-ten für das Supply Chain Management bereithalten.

WiemehrereUntersuchungen gezeigt haben, reichten die Funktionen der ERP-Systeme,die sich vorwiegend auf innerbetriebliche Aspekte fokussierten, nicht aus, um die umfas-senden Anforderungen an das überbetriebliche Supply Chain Management abzudecken(vgl. z. B. Knolmayer et al. 2000, S. 20).

Stattdessen traten Mitte der 1990er Jahre verstärkt Supply Chain Management Systemeauf den Softwaremarkt, welche die ERP-Systeme ergänzten undmit ihnen über Schnittstel-len verbunden wurden. Üblicherweise wird hierbei noch in die Kategorien Supply-Chain-Planning und Supply-Chain-Execution unterschieden.

Supply-Chain-Planning-Systeme stellen Funktionen bereit, die der inner- und überbe-trieblichen Planung dienen. Typische Funktionen sind die Bedarfs- und Absatzplanung,Standort- und Tourenplanung sowie Produktions- und Feinplanung.

Supply-Chain-Execution-Systeme stellen Funktionen für die Datenverwaltung undKommunikationsunterstützung bereit.

Im Gegensatz zu den ERP-Systemen, die ihre Vorgängersysteme (MRP II) ersetzt undverdrängt haben, arbeiten SCM-Systememit ERP-Systemen inVerbindungmit DataWare-house Systemen eng zusammen.

Supply Chain Management-Systeme unterstützen die Schritte Planung, Ausführungund Controlling. Jeder dieser Schritte wird durch spezialisierte Informationssysteme ab-gedeckt.

Dieser Supply-Chain-Cycle ist in Abb. 5.11 dargestellt (in Anlehnung an Bartsch undTeufel 2000, S. 19).

Vor Beginn der Planung werden die im ERP-System vorgehaltenen Stammdaten sowiedie Transaktionsarten, d. h. die anfallenden Planungstypen in das SCM-Systemübertragen.


Dort werden komplexe Planungsvorgänge durchgeführt, deren Ergebnisse ins ERP-Systemübertragen unddort operativ ausgeführtwerden.Die anfallenden Ist-Datenwerden zwecksdetaillierter Analyse in ein Data Warehouse (DW) übertragen und dort ausgewertet. Re-levante Analysedaten (z. B. Durchlaufzeiten von Aufträgen, Planüberschreitungen) findenfür die erneute Planung im Supply Chain Management-System im nächsten Planungszy-klus Verwendung.

Die Trennung in Planungsfunktionen (SCM-System), Ausführungsfunktion (ERP-System) und Analysefunktion (DW) hat den Vorteil, dass im realen Betrieb keine last-abhängigen Probleme auftreten. ERP-Systeme sind transaktionsorientiert konzipiertund optimieren den Durchsatz zu bearbeitender Aufträge. Sie sind für die Verwen-dung möglichst vieler gleichzeitig arbeitender Anwender ausgelegt. SCM-Systeme dienender Durchführung von komplexen und rechenzeitintensiven Planungsarbeiten. SCM-Systeme halten meist sehr umfangreiche Daten und Modelle im Hauptspeicher, währendERP-Systeme vorwiegend geringe Einzel-Datenmengen pro Anwender bearbeiten. DaSCM-Systeme zum Teil auf Stammdaten und weitere Daten des ERP-Systems zugreifenmüssen, wäre eine Integration beider Funktionen in einem Softwaresystem mit Belastun-gen für eine der beiden Benutzergruppen (Planer oder Endanwender) verbunden. Dasgleiche gilt auch für Data Warehouse Systeme, die vorwiegend für die rechenzeitinten-sive Analyse konzipiert sind und auch Historiendaten über mehrere Monate oder Jahrespeichern, während ERP-Systeme in der Regel nur aktuelle Daten vorhalten.

5.6 Customer Relationship Management Systeme

5.6.1 Begriff

Die Notwendigkeit, den Kunden verstärkt in den Mittelpunkt der unternehmerischen Ak-tivitäten zu stellen, hat gegen Ende der 1990er Jahre auch Auswirkungen auf die Unter-stützung durch betriebswirtschaftliche Standardsoftware gehabt. Eine tendenziell sinkendeKundenbindung in vielen Branchen und zugleich erhöhte Anforderungen der Kunden anihre Lieferanten (z. B. kürzere Bearbeitungs- und Auskunftszeiten) führten zu umfangrei-chenAktivitäten der Standardsoftware-Hersteller, neue Softwarelösungen (Customer Rela-tionship Management-Systeme) zu entwickeln, um diesen Anforderungen gerecht zu wer-den.

Customer Relationship-Management (CRM) ist ein primär betriebswirtschaftlichesThema, das zunächst fachlich definiert werden muss. CRM richtet die Unternehmenspro-zesse und Kundenstrategien so aufeinander aus, dass die Kundentreue gestärkt und dieRendite langfristig gesteigert wird (vgl. Rigby et al. 2002, S. 56). CRM benötigt zur Realisie-rung dieses Ansatzes je nach Situation des Unternehmens spezielle Softwareanwendungenzur systematischen Unterstützung der Kundenbeziehungen. Auf der Basis einer speziellenDatenbank, in der sich Kundeninformationen befinden (z. B. persönliche Daten, Vorlie-

5.6 Customer RelationshipManagement Systeme 277

Marke-ting

Marke-ting

Fulfill-ment

Fulfill-ment

ServiceService VertriebVertriebKunden-daten

oder

Kunden-austritt

Kunden-eintritt

Abb. 5.12 CRM-Life-Cycle-Modell (Giesen 2001)

ben, Umsätze) wird ein individueller Kontakt zum Kunden unterstützt (vgl. Hansen undNeumann 2001, S. 140). Die Technikunterstützung darf nicht im Vordergrund der Überle-gungen stehen. CRM ist in erster Linie als eine Unternehmensphilosophie zu betrachten,bei der alle Entscheidungen über die Wünsche des Kunden im Mittelpunkt stehen und indie Unternehmensstrategie zu implementieren sind.

Stark überspitzt formuliert, ist CRMder Versuch, das Prinzip des „Tante Emma Ladens“auf moderne IT-Lösungen zu übertragen, um große Kundenmengen trotz des Datenum-fangs individuell anzusprechen. CRMkann auch als Gruppierung der Unternehmensfunk-tionen um den Kunden herum betrachtet werden, so dass seine Anforderungen möglichstoptimal erfüllt werden (vgl. Abb. 5.12, Giesen 2001).

Marketing und Vertrieb ziehen in diesem CRM-Life-Cycle-Modell den Kunden in denKreislauf hinein. Das Fulfillment sorgt fürUmsetzung der Kundenerwartungen in Leistun-gen. Der Service im Bereich After-Sales betreut den Kunden nach dem Verkauf.

Vergleicht man CRM mit dem klassischen, in vielen praktischen Fällen noch vorherr-schenden Massenmarketing, so fallen mehrere Unterschiede auf, die spezifische Compu-terunterstützung erfordern (vgl. Abb. 5.13).

CRM wird in drei Kategorien unterteilt (vgl. z. B. Hippner und Wilde 2004, S. 16 f.):operatives CRM (oCRM), analytisches CRM (aCRM) und kommunikatives bzw. collabo-ratives CRM (oCRM).

Das operative CRM dient der Unterstützung des Tagesgeschäfts imMarketing, Vertriebund Service (z. B. Kontaktverwaltung, Kundeninfo). Das analytische CRM unterstützt aufder Grundlage eines Kunden-Data Warehouses die systematische Auswertung von Kun-denkontakten und deren Reaktionen aufMaßnahmen (z. B. eineWerbekampagne) des Un-ternehmens. Das kommunikative CRM dient der Steuerung, Unterstützung und Synchro-nisation aller kundenorientierten Kommunikationskanäle (sog. (Customer Touch Points)wie z. B. den Außendienst eines Unternehmens.


Tab. 5.4 Massenmarketing versus CRM

Merkmal Massenmarketing CRMKundenfokus Alle Kunden einer Kategorie

werden gleich behandeltKunden werden individuell ent-sprechend ihrem „Kundenwert“betrachtet

Kundensegmentierung Große homogene Segmente Kleine, individuelle SegmenteKommunikationsfre-quenz

Regelmäßig je Kundenkatego-rie

Individuell je Kunde

Grundstrategie Möglichst viele Waren an denGesamtmarkt verkaufen

Möglichst viele Waren an eineneinzelnen Kunden verkaufen

5.6.2 Architektur

Während die klassischen ERP-Systeme imProzessbereich „Vertrieb undMarketing“ imwe-sentlichen klassische Funktionen zur Abwicklung von Anfragen, Angeboten, Aufträgensowie der Auslieferung und Fakturierung bereitstellten, fragten viele Unternehmen nacheiner ganzheitlichen Computerunterstützung aller mit dem Kunden verbundenen Prozes-se.

Notwendig sind vor allem Systeme, um Front-Office-Prozesse, d. h. Geschäftsprozessemit direktem und interaktivem Kundenkontakt, zu verbessern. Dies sind Softwaresyste-me zur Unterstützung von Marketing, Vertriebs- und Service-Prozessen, wie Sie z. B. inCall-Centern stattfinden. Hierunter sind organisatorische und meist auch räumliche Kon-zentrationen von Mitarbeitern mit kundenorientierten Geschäftsprozessen einschließlichder Beratung zu verstehen. Weiterhin sind hier auch Softwaresysteme zur operativen Un-terstützung der Außendiensttätigkeit vonMitarbeitern zu verstehen, die auch teilweise mitdem Begriff Sales Force Automation (SFA) umschrieben werden.

Aus technischer Sicht sind CRM-SystemeWeiterentwicklungen von sog. Computer Ai-ded Selling Systemen oder auch der Vertriebskomponenten vonERP-Systemen, welche nurauf reine Verkaufsprozesse ausgerichtet sind. CRM-Systeme unterstützen dagegen den ge-samten Marketing, Beratungs- Verkaufs- und Serviceprozess (vgl. auch Schulze et al. 2000,S. 148).

CRM-Systeme werden in der Regel als eigenständige Softwaresysteme konzipiert undlassen sichmit verschiedenen ERP-Systemen koppeln.Der Grund für die Entkopplung vonvorhandenenERP-Systemen liegt darin, dass im Bereich derMarketing-, Service- undVer-triebsprozesse schnellere Innovationszyklen erforderlich sind, als dies bei den inhaltlichmeist ausgereiften ERP-Systemen der Fall ist. Eine bedienerfreundliche und einfach zu be-nutzende Arbeitsoberfläche, auch für aushilfsweise beschäftigtes Personal führt zu völligneuen Anforderungen an die Standardsoftware.

CRM-Systeme unterstützten Marketing-, Verkaufs- und Serviceprozesse und stellenunterstützende Funktionen bereit (vgl. Schulze 2000, S. 33 f. und Abb. 5.13).

5.6 Customer RelationshipManagement Systeme 279

Funktionen von CRM-Systemen

Marketing-prozess

Verkaufs-prozess

Service-prozess

Unter-stützung

Kampagnen-management

Kunden-selektion

Marketing Enzyklopädie

Marketing-Analysen

Account-Management

Contact-Management

Opportunity-Management

Problemlösungs-management

Activity-Management

Informationen zu Verkaufsvorgängen

Informationen zu Wettbewerbernund Produkten

Produkt-konfigurator Angebotserstellung,

Preisfindung und AuftragserfassungVertriebs-

planungVertriebsanalyse und ForecastingMobile Sales

Call-Center-Management

Serviceanalysen

Management-Serviceverträge

Internet Self Service

Aussendienst-service

Gruppenkalenderund Synchronisation

E-Mail und Anbindung anandere E-Mail-Systeme

Reporting

Workflow-Management

Dokumentenmanagement und Suchmaschinen

Führungsfunktionund Frühwarnfunktion

Synchronisations-funktionen

Funktionen von CRM-Systemen

Marketing-prozess

Verkaufs-prozess

Service-prozess

Unter-stützung

Kampagnen-management

Kunden-selektion

Marketing Enzyklopädie

Marketing-Analysen

Account-Management

Contact-Management

Opportunity-Management

Problemlösungs-management

Activity-Management

Informationen zu Verkaufsvorgängen

Informationen zu Wettbewerbernund Produkten

Produkt-konfigurator Angebotserstellung,

Preisfindung und AuftragserfassungVertriebs-

planungVertriebsanalyse und ForecastingMobile Sales

Call-Center-Management

Serviceanalysen

Management-Serviceverträge

Internet Self Service

Aussendienst-service

Gruppenkalenderund Synchronisation

E-Mail und Anbindung anandere E-Mail-Systeme

Reporting

Workflow-Management

Dokumentenmanagement und Suchmaschinen

Führungsfunktionund Frühwarnfunktion

Synchronisations-funktionen

Abb. 5.13 CRM-Funktionen (Schulze 2000, S. 32 f.)

Das Kampagnenmanagement dient nach Schulze (2000) der Planung, Steuerung undAnalyse von Maßnahmen im Marketingprozess. Kundenselektionen dienen hierbei derAuswahl von Kunden für die geplanten Maßnahmen. Die Marketing-Enzyklopädie ent-spricht einer umfassenden Marketing-Datenbank mit Produkt- und Wettbewerberinfor-mationen, Werbebroschüren u. a. Der Verkaufsprozess wird durch vielfältige Funktionenunterstützt. Im Account-Management werden detaillierte Kunden- und Ansprechpart-nerdaten verwaltet, um eine individualisierte Kundenansprache zu ermöglichen. DasOpportunity-Management dient der gezielten Erfassung von Informationen, die im Rah-men einer Verkaufschance bis hin zum möglichen Vertragsabschluss entstehen. DerProduktkonfigurator unterstützt den Vertrieb bei der Gestaltung der Produktmerkmaleauf der Grundlage der Kundenanforderungen. Der Serviceprozess ist dem Verkauf nach-gelagert. Er nimmt Kundenanfragen, Beschwerden und Reklamationen auf und versuchtdiese in Kundenerhaltende Maßnahmen zu überführen. Daneben stellen CRM-Systemeunterstützende Funktionen bereit, die die Zusammenarbeit und Kommunikation sowiedie Informationsbeschaffung generell fördern.

DieGrobarchitektur vonCRM-Systemen ist inAbb. 5.14 dargestellt. DerArchitekturan-satz ähnelt der Vorgehensweise bei DataWarehouses. Aus internen und externen Datenbe-ständenwird eine CRM-Datenbank aufgebaut. Diese wirdmit hierfür spezifisch geschaffe-nen Analysewerkzeugen für Kunden- und Produktuntersuchungen sowie für Kampagneneingesetzt.

Nachteilig ist die notwendigerweise anfallende Redundanz von Kunden- und Produkt-daten, da diese zumindest in großen Teilen sowohl im ERP-System, als auch im CRM-


CRM-Daten-Bank

CRM-Daten-Bank

Operative(interne)Daten

(z. B. ausERP-

Operative(interne)Daten

(z. B. ausERP-Systemen)

ExterneDaten

ExterneDaten

Kunde

Analysen undAnalysen undKampagnen

Abb. 5.14 Grobarchitektur von CRM-Systemen

System gespeichert werden müssen. Die Folge ist, dass Datensynchronisationen erforder-lich werden und damit einige Vorteile von integrierten ERP-Systemen (gemeinsame Da-tenbasis, Prozessintegration in einem System) verloren gehen.

5.6.3 Einsatzbereiche

Die Anforderungen der CRM-Prozesse sind vielfältig, da komplexe Prozess-Strukturenabzudecken sind. Ein Beispiel für einen typischen CRM-Prozess, der als Aufgabenketten-diagramm dargestellt ist, findet sich in Schulze et al. 2000, S. 153 (vgl. Abb. 5.15). Es zeigteinen Prozess der Kundenberatung und mobilen Auftragserfassung vor Ort, der durch einCRM-System unterstützt werden kann.

Beispiel Call-CenterIn Call-Centern werden häufig Personen für begrenzte Zeit ohne spezifischeProduktkenntnisse mit komplexen Kundenbetreuungsaufgaben wie Telebanking-Services betraut. Die eingesetzten Softwaresysteme müssen dies in der Benut-zerinteraktion entsprechend berücksichtigen. Ein CRM-System für den Einsatz imCall-Center muss z. B. in der Lage sein, eine Studentische Aushilfskraft nach kur-zer Ausbildung so zu führen, dass eine aus Kundensicht qualifizierte Beratungund Betreuung möglich ist. Derartige Anforderungen gehen weit über die An-forderungen an die Benutzerführung von ERP-Systemen hinaus, die überwiegendvon permanent beschäftigten und langfristig ausgebildeten Mitarbeitern bedientwerden. Andererseits müssen CRM-Systeme in der Lage sein, auch qualifizierteVertriebsaußendienst-Mitarbeiter kundenorientiert zu unterstützen. Die gesamteKundenhistorie, abgeschlossene und offene Verträge, Umsätze, Kaufprofile und

5.7 Data Warehouse Systeme 281

UnternehmenKunde Contact-

CenterVerkäufer-

AußendienstVerkäufer-

InnendienstAuftrags-

verwaltungProzesseVerkauf

Kunden-prozesse

Backoffice-prozess

Beratungdurchführen

Angebot mobiländern

Angebotändern

Auftragerfassen

Auftragändern

Auftragabwickeln

Informationeneinholen

Bedarfspezifizieren

Angebot prüfen/ändern

Lieferantenauswählen

Auftragerteilen

Auftragändern

Angebot mobilerstellen

Auftrag mobilerfassen

Auftrag mobiländern

UnternehmenKunde Contact-

CenterVerkäufer-

AußendienstVerkäufer-

InnendienstAuftrags-

verwaltungProzesseVerkauf

Kunden-prozesse

Backoffice-prozess

Beratungdurchführen

Angebot mobiländern

Angebotändern

Auftragerfassen

Auftragändern

Auftragabwickeln

Informationeneinholen

Bedarfspezifizieren

Angebot prüfen/ändern

Lieferantenauswählen

Auftragerteilen

Auftragändern

Angebot mobilerstellen

Auftrag mobilerfassen

Auftrag mobiländern

Abb. 5.15 Aufgabenkettendiagramm (Schulze et al. 2000)

mehr muss für Verkaufsgespräche bereitgestellt werden. Daneben sind administra-tive Funktionen für den Verkaufsabwicklungsprozess (Auftragsprüfung, Produkt-konfigurierung, Kreditwürdigkeitsprüfung) erforderlich.

Ein weiteres Einsatzbeispiel für CRM-Software ist die Kundenselektion mit Suchbäu-men. Sie dient der Identifikation von profitablen Kunden, der Ermittlung von Kaufwahr-scheinlichkeiten und auch des optimalen Kanals, über den der Kunde anzusprechen ist(vgl. Oesterer 2002a). Die Abb. 5.16 zeigt die Anwendung des Suchbaumverfahrens zurKundenselektion mit Software der Firma SAS (vgl. Oesterer 2002b).

5.7 DataWarehouse Systeme

5.7.1 Begriff des DataWarehouse

In vielen Unternehmen besteht das Problem, aus der Vielzahl der gespeicherten Daten diegeeigneten Informationen konsistent und aktuell bereitzustellen. Seit einigen Jahren wird


Abb. 5.16 Kundenselektion mit Suchbäumen (SAS)

daher der Aufbau einesDataWarehouse als Ansatz zur Lösung dieses Problems vorgeschla-gen.

Ein DataWarehouse ist ein Datenbestand, der aus unterschiedlichen unternehmensin-ternen und externen Quellen gespeist wird. Die Daten werden zuvor formal bereinigt,inhaltlich überprüft und gefiltert und technisch verdichtet, so dass sie als konsistente Aus-gangsbasis für weitere Analysen durch dedizierte Analysewerkzeuge zurVerfügung stehen.Der gesamte Prozess zum Aufbau eines Data Warehouses wird als Data Warehousing be-zeichnet. Das Hauptziel eines Data Warehouse ist es, aus den operativen Daten des Unter-nehmens (Fertigung, Vertrieb, Marketing, Personal u. a.), ggf. angereichert durch externeDaten (z. B. Börsenkurse undWirtschaftskennzahlen), diejenigen Informationen zu extra-hieren und in geeigneter Form bereitzustellen, die für eine individuelle Entscheidungs-findung erforderlich sind. D. h. das Ziel des Einsatzes eines Data Warehouses ist es, dieInformationsversorgung im Unternehmen zu verbessern.

Ein Data Warehouse lässt sich mit einem Warenlager vergleichen, nur dass hier voneinem „Datenlager“ gesprochen werden muss (vgl. Abb. 5.17). Die Analogie macht deut-lich, dass nicht nur die Art, Qualität undMenge derWaren (d. h. Daten), sondern auch dieLagerorganisation (d. h. Daten- und Zugriffsmöglichkeiten) für die Schnelligkeit des Wa-rentransportes (d. h. Such- und physikalische Zugriffszeit) zumEmpfänger von erheblicherBedeutung sind. Ebenso wichtig, wie die termingerechte Belieferung eines gewöhnlichenLagers ist, so wichtig ist für ein Data Warehouse die regelmäßige zeitnahe Aktualisierungdes Datenbestandes mit entscheidungsrelevanten Informationen.


WarenlagerPhysikalische Lagerung von WarenNach Art, Qualität und Menge gelagerte Waren

Kurze Auslagerungszeitfür den Warenempfänger

Funktion

Inhalt

Ziel der La-gerorgani-sation

Data WarehouseDigitale Lagerung von InformationenNach Art, Struktur und Umfang gespeicherte Informationen

Kurze Zugriffszeit auf Informationen durch den Benutzer

Regelmäßige Belieferungmit Waren

Aktualität Regelmäßige Aktualisierungder Informationen

Abb. 5.17 Analogie Data Warehouse undWarenlager

Tab. 5.5 Beispiele für Dimensionen

Dimension BeispieleRegion Frankreich, Deutschland, USA, . . .Zeitraum 2009, 2010, 2011, 2012, 2013, . . .Produkt Gemüse, Getränke, Obst, Zeitschriften

5.7.2 DataWarehouse Architekturen

Daten können in einem Data Warehouse nach beliebigen Dimensionen dauerhaft gespei-chert werden. Dimensionen sindMerkmale zur Beschreibung von Datensätzen. Hierunterfallen beliebige Attribute, z. B.: Region, Produkt, Zeit. Anhand der Ausprägungen der Di-mensionen lassen sich Daten analysieren und interpretieren (vgl. Tab. 5.5).

Die Daten werden für Auswertungszwecke in multidimensionalen Würfeln (Cubes) ge-halten (vgl. Abb. 5.18, die gezielt nach sehr unterschiedlichenKriterien ausgewertet werdenkönnen.

Ein Vorteil eines DataWarehouses ist es, dass nutzerspezifische Sichten auf den gleichenDatenbestand erzeugt werden können (vgl. Abb. 5.19).

Der Produktmanager analysiert die Umsätze seines Produktes über alle Länder hinwegfür den gesamten Zeitraum. Der Leiter der Landesgesellschaft in Großbritannien dagegeninteressiert sich für die Umsätze zweier Jahre aller Produkte in seiner Landesgesellschaft.Der Marketingleiter führt eine ad hoc Abfrage der Daten eines bestimmten Produktes in-nerhalb einer Landesgesellschaft für ein einzelnes Jahr durch.

Aus technischer und organisatorischer Sicht gibt es unterschiedliche Ansätze, ein Da-ta Warehouse zu konzipieren. Folgende Konzepte lassen sich unterscheiden (vgl. z. B. vgl.Schinzer und Bange 2000, S. 50 f.): Virtuelles Data Warehouse, zentrales Data Warehouseund verteiltes Data Warehouse.


Abb. 5.18 Auswertungsmöglichkeiten über Cubes

Abb. 5.19 Nutzerspezifische Sichten auf die gleichen Daten

Bei einem virtuellen Data Warehouse greifen die Anwender mit ihren Abfragetoolsnicht auf eine spezielle Datenbank, sondern direkt auf die operativen Daten zu. Wegen derhohenBelastung der operativen Anwendungssysteme (Beeinträchtigung der Performance)und der schlechten Datenqualität (Datenredundanz, geringe Historie der Datenbestände)ist dieser Ansatz wenig Erfolg versprechend (vgl. Abb. 5.20).

Ein zentrales Data Warehouse besteht aus einer Datenbank, die mit Transformations-tools aus verschiedenen Datenquellen versorgt wird. Die Anwender greifen mit Abfrage-tools auf diese spezifische Datenbank zu. Dieser Ansatz wird im Folgenden noch näherbeschrieben (vgl. Abb. 5.21).

Ein verteiltes Data Warehouse besteht aus mehreren „Themen Data Warehouses“, diean verschiedenen Standorten auf unterschiedlichenDatenhaltungssystemen implementiert


Opera-tive

Daten

Opera-tive

DatenExtern

Opera-tive

Daten

Opera-tive

DatenVertrieb

Opera-tive

Daten

Opera-tive

DatenLogistik Wissen

Analyse

Tools

DataWare-house

Extraktion und Aufbereitung

Operative Informationssysteme Data Warehouse Analyse-Tools

Abb. 5.20 Virtuelles Data Warehouse

Opera-tive

Daten

Opera-tive

DatenExtern

Opera-tive

Daten

Opera-tive

DatenVertrieb

Opera-tive

Daten

Opera-tive


Analyse

Tools

Infor-mati-onen

Infor-mati-onen

DataWare-house



Abb. 5.21 Zentrales Data Warehouse

Opera-tive

Daten

Opera-tive

DatenExtern

Opera-tive

Daten

Opera-tive

DatenVertrieb

Opera-tive

Daten

Opera-tive


Analyse

Tools


Infor-mati-onen

Infor-mati-onen

Kunden-Data Ware-house


Infor-mati-onen

Infor-mati-onen

Produkt-Data Ware-house

Abb. 5.22 Verteiltes Data Warehouse

sein können. Anwendungsbeispiele sind z. B. ein Vertriebs-, Marketing, Controlling- oderPersonal-DataWarehouse. Ein anderer Begriff hierfür ist „Data Mart“. Einsatzmöglichkei-ten sind nur bei großen Unternehmen oder bei speziellen Sicherheitsanforderungen (z. B.Personaldaten Warehouse) gegeben (vgl. Abb. 5.22).

Die Übersicht in Tab. 5.6 stellt die wichtigsten Merkmale eines DataWarehouse imVer-gleich zu ERP-Systemen gegenüber.


Tab. 5.6 Vergleich ERP-System und Data Warehouse

ERP-System Data WarehouseZielsetzung operative Durchführung von

Geschäftsprozessen (z. B. Ver-triebsabwicklung)

Bereitstellung entscheidungsrelevan-ter Informationen aus verschiedenenDatenquellen

Informations-gehalt

Detailinformationen der Ge-schäftsvorfälle für relativ kurzeZeiträume

DetaildatenVerdichtete Informationen für längereZeiträume

Datenstruktur Prozess- und/oder funktionsori-entiert

nachThemen gegliedert

Abfragen Strukturierte Standardabfragen Strukturierte StandardberichteAd hoc Abfragen

Performancebei Analysen

Schlecht, da auf operative Datenzugegriffen wird

Gut, da auf dedizierte Datenbankzugegriffen wird

Historie derDaten

Nein, allenfalls kurzfristig verfüg-bar

Ja, wird fortlaufend aktualisiert undergänzt

Benutzer SachbearbeiterEntscheidungsvorbereiter

Top-Management und ControllingMittleres ManagementEntscheidungsvorbereiter

5.7.3 DataWarehousing und Prozessmanagement

Die Integration der Planung, Steuerung und Analyse von Prozessen in Echtzeit ist eineder wichtigsten Herausforderungen für das Prozessmanagement in der Praxis. Unter demStichwort „Process Warehouse (PWH)“ ist ein Data Warehouse zur Unterstützung derEchtzeitanalyse von Geschäftsprozessen zu verstehen.

Die zentralen Funktionen eines PWH sind (vgl. Becker und Chamoni 2006, S. 24, mo-difiziert):

• Sammlung und Aufbereitung von aktuellen Basisdaten zu vorab definierten Prozess-kennzahlen aus vorgelagerten Informationssystemen (z. B. ERP-Systeme),

• Transformation, Berechnung undVerdichtung der Prozesskennzahlen (z. B. Durchlauf-zeiten, Bearbeitungszeiten, Störungen, Schwellwertüberschreitungen),

• Unterstützung der multidimensionalen Analyse und Navigation in den Ergebnisdaten,• Aufbereitung und Verteilung der Analysen an Entscheidungsträger und Analysten im

Unternehmen.

5.7.4 DataWarehousing undWissensmanagement

Ein interessanter Aspekt moderner betriebswirtschaftlicher Standardsoftware bietet sichunter dem Aspekt der Nutzung eines DataWarehouses zurWissensgewinnung. Unter dem


Daten

Informationen

Wissen

Verständnisgrad

Komplexität

Umsatzlisten

AufbereiteteUmsatzlisten

(z. B. ABC-Analyse

Erkennen der Zusam-menhängezwischen ver-

schiedenenProduktgruppen(z. B. Pampers+Bier)

Daten =Daten =

Informationen =Informationen =

Wissen = Wissen =

Umsatzlisten

AufbereiteteUmsatzlisten

Erkennen der Zusam-menhänge zwischen ver-

schiedenen Produktgruppen(z. B. Pampers+Bier)

Daten =Daten =

Informationen =Informationen =

Wissen = Wissen =

Daten =Daten =Zeichen+Syntax

Informationen =Informationen =Daten+Bedeutung

Wissen = Wissen =Informationen+Fähigkeit, diese zu nutzen

Abb. 5.23 Daten, Informationen undWissen (in Anlehnung an Grothe und Gentsch 2000, S. 18)

Begriff Wissensmanagement werden derzeit viele Aspekte sowohl in der Management-Literatur, als auch in der Literatur zur angewandten Informatik diskutiert. Im Folgendenwird unter Wissensmanagement der planmäßige computerunterstützte Umgang mit derRessourceWissen zur Erreichung der Unternehmensziele verstanden. Im Zusammenhangmit demEinsatz eines DataWarehouses lassen sich einige interessante Einsatzbeispiele auf-zeigen.

Unter Daten kann man Zeichen verstehen, die in Verbindung mit einer Syntax ver-wendet werden. Von Informationen spricht man, wenn Daten eine Bedeutung für denEmpfänger haben. Wissen sind internalisierte Informationen, d. h. der Empfänger ver-fügt über die Fähigkeit diese für Entscheidungen zu nutzen (vgl. Wille 2000, S. 357). DieAbb. 5.23 verdeutlicht in Verbindung mit dem darauf folgenden Beispiel den Zusammen-hang zwischen Daten, Informationen und Wissen (in Anlehnung an Grothe und Gentsch2000, S. 18).

Beispiel Daten, Informationen, WissenBetrachtet man den Geschäftsführer eines Supermarktes, der eine detaillierte Listemit den Einzelumsätzen seiner Kunden vorliegen hat, so stellt man fest, dass er dieseListe zunächst als Datensammlung wahrnimmt. Für ihn hat diese Datensammlungnoch keinen Wert, er ist nicht in der Lage, hieraus Entscheidungen für Handlungenabzuleiten. Daten sind Zeichen, die mit einer Syntax versehen sind.

Später erhält er von seinem Assistenten eine ABC-Analyse der Umsatzliste, sodass er nun in der Lage ist, diese als Informationen wahrzunehmen. In diesem Fallkann man von Informationen sprechen, da die Daten nun eine Bedeutung für den


Empfänger haben. Der Geschäftsführer kann nun eine Trennung der wichtigen Pro-duktgruppen von den weniger Wichtigen vornehmen.

Nach weiterer sorgfältiger Analyse werden Zusammenhänge zwischen der Um-satzhöhe und bestimmten Produktgruppen festgestellt, z. B. steigt der Bierverkaufmit demVerkauf vonKinderwindeln, wenn der Verkauf samstags vormittags erfolgt.In diesem Fall liegen Informationen vor, die gezielt für Marketing-Maßnahmen ge-nutzt werden können, d. h. es liegt „Wissen“ über das Kaufverhalten der Kunden vor.

Der Prozess desWissensmanagement umfasst drei Schritte: DieWissensgewinnung, dieWissenslogistik und die sich anschließende Wissensnutzung. Bei der Wissensgewinnunggeht es um die Identifikation und die Bereitstellung von relevantemWissen. Beispielweisewerden Kundendaten in einem Customer DataWarehouse abgelegt und anschließend miteinem speziellenWerkzeug analysiert. DieWissenslogistik verteilt das in DataWarehousesgespeicherte Wissen zielgruppenspezifisch an die Nutzer. So können die Kundendaten desCustomer-Data Warehouse mit einem Enterprise-Portal bereitgestellt werden.

Die Suche nach versteckten Informationen in den umfangreichenDatenbanken derUn-ternehmen hat zu enormenAnstrengungen geführt, um leistungsfähige Analysewerkzeugezu entwickeln (vgl. Schinzer und Bange 2000, S. 64). Grundsätzlich gibt es zwei Möglich-keiten, die inDataWarehouses enthaltenen Informationen zu analysieren: OLAP-Analysenund Data-Mining.

Die im Zusammenhang mit dem Begriff Data Warehouse oft verwendete Abkürzung„OLAP“ steht für Online Analytical Processing. Der Begriff wurde 1993 von Edgar F.Codd, dem Erfinder der relationalen Datenbank, geprägt. Die OLAP-Technologie erlaubtes, im Onlinebetrieb ad hoc aus Datenbanken entscheidungsunterstützende Informatio-nen für Analysezwecke zu gewinnen und aufzubereiten. Im Gegensatz zu OLTP-Systemen(Online-Transaction-Processing-Systeme), die operative Daten enthalten, werdenmit demOLAP-Ansatz hierfür geschaffene Data Warehouses analysiert.

Allerdings ist die OLAP-Suche top-down orientiert, d. h. der Mensch gibt vor, wonacher sucht. Er muss schon eine relativ genaue Vorstellung haben von dem, was er sucht. Erkennt nur das Ergebnis noch nicht. Die OLAP-Analyse stieß schnell an ihre Grenzen, dasie nicht selbstständig nach unbekannten Zusammenhängen suchen kann.

Beispiel Fragestellungen für OLAP-AnalysenMit welchen Kunden machen wir den größten Umsatz?In welchen deutschen Niederlassungen verlieren wir die meisten Kunden?

Beim Data Mining (Maschinelle Datenmuster-Erkennung) werden die Datenbeständeautomatisch mit Hilfe von Algorithmen nach unbekannten Zusammenhängen durchsucht.


•Datengesteuerte Analyse•Suche der Dimensionen !•Datengesteuerte Analyse•Suche der Dimensionen !

•Auf welche Kunden sollen wir uns beim Vertrieb von

„Schmuck-PC“ konzentrieren?•Welche Verbundbeziehungen treten bei unseren Produktenauf ? (z. B. Kauf von Pampers und Bier am Samstag)



Bottom UpBottom Up






Bottom UpBottom Up






Bottom UpBottom Up

Data MiningData MiningMethodeMethode

MerkmaleMerkmale

BeispieleBeispiele

RichtungRichtung

•Anwendergesteuerte Datenanalyse•Dimensionen sind bekannt


•Mit welchen Kunden machen wir den größten Umsatz?•In welchen deutschen Niederlassungen verlieren wir die meisten Kunden?


Top DownTop Down





Top DownTop Down





Top DownTop Down

Klassische-AnalyseKlassische-Analyse

Der Analytiker weiß wonach

er sucht

Der Analytiker weiß noch nichtwonach er sucht!

Der Analytiker weiß wonach

er sucht

Der Analytiker weiß noch nichtwonach er sucht!

Abb. 5.24 Methoden zur Analyse von Data Warehouses

Der Suchprozess ist bottom-up, d. h. datengetrieben (vgl. Abb. 5.24). Hierbei treten z. B.die folgenden Fragen auf:

Beispiel Fragestellungen für Data-Mining-AnalysenAuf welche Kunden sollen wir uns beim Vertrieb von neuen Produkten (z. B. ein„Schmuck-PC)“ konzentrieren? Welche Verbundbeziehungen treten bei unserenProdukten auf? (z. B. Kauf von Kinderwindeln und Bier am Samstagvormittag)

Data Mining steht als Oberbegriff für eine Vielzahl vonMethoden, die für die Auswer-tung eines DataWarehouse zur Verfügung stehen. ImGegensatz zu den klassischen, durchden Anwender gesteuerten Analysen, wird beim DataMining datengetrieben ohne aktivenEingriff des Benutzers nach interessanten Datenmustern gesucht (vgl. Grothe undGentsch2000, S. 177).

Das aus Gentsch (1999) entnommene Fallbeispiel soll den Einsatz vonDataWarehousesanhand eines konkreten Praxisfalles skizzieren.

Beispiel LufthansaDie Deutsche Lufthansa hatte neben seiner klassischen Vertriebslinie, dem Flug-scheinverkauf per Reisebüro, einen zweiten – wesentlich kostengünstigeren Weg –über ein Internetportal eröffnet. Das Ziel des Unternehmens bestand darin, aus demvorhandenenKundenbestand diejenigen zu identifizieren, die für denDirektvertriebper Internet besonders zugänglich erschienen, um für sie gezielte Marketingmaß-


nahmen durchzuführen. Eine Erhöhung des Direktvertriebs auf 25%war wegen derKostenvorteile des Direktvertriebes mit einer Einsparung in 3-stelliger Millionenhö-he verbunden.

Der Lösungsansatz der Lufthansa bestand darin, zunächst aus den weit ver-zweigten operativen Datenbeständen der eingesetzten Informationssysteme (Ticke-tabrechnung, Flugrabatt-Programm, Flugdaten) ein konsolidiertes Kunden-DataWarehouse aufzubauen. Mit Hilfe eines Data Mining Werkzeuges wurde dannin einem zweiten Schritt ein Analyse-Datenbestand bestehend aus identifiziertenOnline-Kunden und Normalkunden untersucht.

Das Ergebnis war ein präzises Profil eines typischen Online-Kunden (männlich,30–39 Jahre alt, hoher Anteil Inlandsflüge, selten Interkontinentalflüge und hoheFlugaktivität in 3 von 4 Quartalen). Mit diesem „Wissen“ über den Kunden warman in der Lage, gezielte Marketing-Maßnahmen einzuleiten und die potentiellenOnline-Kunden direkt ohne Streuverluste anzusprechen.

5.8 Standardsoftware versus Individualsoftware

5.8.1 Handlungsraum

Eine klassische Frage der Wirtschaftsinformatik ist die Frage nach der Beschaffung der fürdie Unterstützung der Geschäftsprozesse erforderlichen Anwendungssoftware. Auch wennsich der strategische Ansatz in der Praxis verschoben hat, sind in den meisten Unterneh-men Fragen der Individualentwicklung oder des Einsatzes von Standardsoftware zu klären.

Grundsätzlich sind vier Handlungsalternativen zu betrachten (vgl. Abb. 5.25), die in derPraxis allerdings in zahlreichen Mischformen zu finden sind.

Die klassische Eigenentwicklung von Software mit eigenen Mitarbeitern, die ggf. durchspezialisierte Berater unterstützt werden, ist zunehmend seltener anzutreffen. Sie domi-niert in einigen Branchen (Versicherungen, Banken), bei denen das Angebot an Standard-software noch vergleichsweise gering ausgeprägt ist. So beträgt in der deutschen Versiche-rungswirtschaft der Anteil der COBOL-Programmierer an den IT-Mitarbeitern im Groß-rechnerumfeld noch 46% (Stand 31.12.2003, vgl. GDV 2005).

Der klassische Kauf von Standardsoftware mit nachgelagerter Implementierung durcheigene Mitarbeiter und Berater nimmt seit Jahren in Bereichen mit hohem Softwareange-bot (z. B. Fertigungsindustrie,Maschinenbau,Handel) zu.Die klassischeEigenentwicklungdurch ein beauftragtes externes Softwarehaus (Drittentwicklung) ist typischerweise imMit-telstand anzutreffen, der übermeist nur geringeEntwicklungsressourcen verfügt, aber auchin größeren Unternehmen für spezielle Anwendungen. Da Standardsoftware vergleichs-weise hohe Investitionen in Mitarbeiter, Hardware und weitere Ressourcen erfordert, hat

5.8 Standardsoftware versus Individualsoftware 291

Make(Individualsoftware)

Make(Individualsoftware)

Buy(Standardsoftware)

Buy(Standardsoftware)

•Eigenentwicklung SoftwareSoftwareentwicklung wirdvon eigenen Mitarbeitern,ggf. unterstützt durch Berater, durchgeführt

InterneLösungInterneLösung

ExterneLösungExterneLösung

•Kauf StandardsoftwareStandardsoftware wird gekauftund von eigenen Mitarbeiternmit Unterstützung externerBerater implementiert

•Fremdentwicklung SoftwareExternes Softwarehaus führt imAuftrag die Entwicklung einerIndividualsoftware, ggf. unter-stützt durch eigene Mitarbeiter, durch

•Miete StandardsoftwareStandardsoftware wird durch ext.Unternehmen (Provider) beschafft und betrieben. Bedarfsabhängige Nutzung (Miete)der Software als Mandant.

Abb. 5.25 Basis-Alternativen der Softwarebeschaffung

in den vergangenen Jahren dasMietmodell für Standardsoftware eine spürbareVerbreitunggefunden. Hier entfällt der Kauf der Standardsoftware, da dies von einem hierauf spezia-lisierten Provider durchgeführt wird. Der Provider verfügt über das Know-how für dieEinführungs- und Implementierungsunterstützung, der Anwender zahlt für die Software-nutzung.

Die Meinungen zum Einsatz von Individual- bzw. Standardsoftware gehen seit Jahr-zehnten weit auseinander, wie das folgende Fallbeispiel zeigt.

Fallbeispiel: VersicherungsbrancheIn der Versicherungsbranche ist der Anteil der selbst entwickelten Software im Ver-gleich zum Einsatz von Standardsoftware sehr groß. Auf einer Podiumsdiskussionmit IT-Managern vertritt der Inhaber eines Softwarehauses, das überwiegend Indi-vidualsoftware erstellt, folgende Meinung: „Einer unserer Kunden aus dem Bereichder privaten Krankenversicherung hat eine Softwarelösung zur Prüfung des Scha-densrisikos selber entwickelt. Input für diese Software sind die Vorerkrankungen desAntragsstellers sowie weitere Daten wie Wohnort, Beruf, usw. Als Ergebnis liefertdas Programm eine Schadenswahrscheinlichkeit und einen eventuell notwendigen Ri-sikozuschlag bzw. im Extremfall eine Ablehnungsempfehlung. In dieses System sindjahrzehntelange Erfahrungen hinein geflossen, die sehr spezifisch an das Unternehmenangepasst sind. Wir können es uns nicht vorstellen, dass auf absehbare Zeit derartigeAufgaben durch Standardsoftware lösbar sind.“

Der gleichfalls anwesende Vertreter eines großen Standardsoftwareanbieters warhiermit nicht einverstanden. Seine Entgegnung lautete: „Die industrielle Nutzung


Maßgeschneiderte Lösung

Keine Anpassung der Organisation erforderlich

Unabhängigkeit von Softwarelieferanten

Ggf. Strategische Vorteile

Maßgeschneiderte Lösung

Keine Anpassung der Organisation erforderlich

Unabhängigkeit von Softwarelieferanten

Ggf. Strategische Vorteile

Hohe Entwicklungskosten

Wartung teuer, oft gar nicht mehr möglich

Teilweise unzureichendeDokumentation

Abhängigkeit von Entwicklern

Hohe Entwicklungskosten

Wartung teuer, oft gar nicht mehr möglich

Teilweise unzureichendeDokumentation

Abhängigkeit von Entwicklern

Abb. 5.26 Pro und Contra Individualsoftware

von Standardsoftware ist nicht nur auf die Buchhaltung und Lagerwirtschaft begrenzt.Vor etwa 25–30 Jahren wurde von Anhängern der Individualentwicklung die Meinungvertreten, dass das Kerngeschäft eines Industrieunternehmens so speziell sei, dass eskaum möglich sein wird, Produktionsplanungs- und Steuerungssoftware für den Mas-senmarkt herzustellen. Heute finden Sie in so gut wie jedem Unternehmen im BereichFertigung und Produktion Software des Marktführers oder eines Wettbewerbers. Ichdenke, die Dienstleistungsbranche bzw. in diesem Fall die Versicherer können hiervonprofitieren. Auch für den geschilderten Versicherungsfall kann ich mir vorstellen, dassStandardsoftwareanbieter für das Kerngeschäft von Versicherungsunternehmen Soft-warelösungen im Sinne eines Frameworks anbieten, die für spezielle Anforderungenum eigene Bausteine ergänzt werden können. Ein solcher Baustein kann z. B. die Tari-fierung oder die Risikoprüfung sein.“

Ähnliche Vorbilder gibt es übrigens auch in der bereits angesprochenen Ferti-gungsindustrie im Bereich der Schnittmengenoptimierung. Anbieter von Standard-software bieten ihren Kunden dieMöglichkeit, an definierten Schnittpunkten eigeneModule zur Schnittmengenoptimierung einzubinden.

5.8.2 Entwicklung von Individualsoftware

In der Abb. 5.26 sind eine Reihe von Argumenten zum oder gegen den Einsatz von In-dividualsoftware aufgeführt, die nachfolgend diskutiert werden. Zu beachten ist, dass dieaufgeführten Argumente immer im Kontext der jeweiligen Entscheidungssituation zu be-trachten sind, und nicht generell zutreffend sind.


Bei der Individualentwicklung werden vom Anwender die gewünschten Anforderun-gen formuliert und in Form einer IV-Lösung umgesetzt. Eine Anpassung der Organisationist nicht erforderlich, da auf die Wünsche eingegangen wird. Dies kann, je nach Situationdes Unternehmens, als Vorteil angesehen werden.

Problematisch ist allerdings, dass der „Einbau“ von Individualentwicklungen zu kom-plexen Anwendungsarchitekturen führen kann. Alte und jüngere Generationen von Soft-waresystemen werden miteinander vernetzt, mit der Folge, dass die Wartungsmöglichkei-ten für zukünftige Entwicklungen erschwert werden.

Kritisch ist in diesem Zusammenhang auch anzumerken, dass gerade durch den Ein-satz von Standardsoftware auch längst überfällige organisatorische Veränderungen „er-zwungen“ werden können oder zumindest induziert werden. Überfällige organisatorischeVeränderungen lassen sich daher durch den Einsatz von Individualsoftware leichter her-auszögern, als durch den Einsatz von Standardsoftware.

Die Eigenentwicklung von Software hat den Vorteil, dass kein Abhängigkeitsverhält-nis zu einem Softwarelieferanten aufgebaut wird, das in der Regel über mehrere Jahre, oftJahrzehnte hinweg bestehen bleibt.

Diese Bindung ist wesentlich stärker, als z. B. die Bindung an einen Hersteller für Com-puterhardware, da der Austausch von Software wesentlich mehr Aufwand verursacht, alsder Austausch von Hardware.

Unternehmen benötigen strategische Alleinstellungsmerkmale, um im Wettbewerblangfristig bestehen zu können und die Kundenbindung sicherzustellen. Sie möchten sichnach außen individuell darstellen, um sich von Wettbewerbern abzugrenzen. Eine homo-gene Unterstützung der Geschäftsprozesse durch den Einsatz von Standardsoftware ist fürviele Unternehmen ein Grund, Individualsoftware zu entwickeln. Mit diesem Instrumenthaben sie die Möglichkeit, gezielt Wettbewerbsvorteile in ausgewählten Prozessbereichenzu schaffen.

In Frage kommen hier produkt- oder marktnahe Prozessfelder mit innovativem Cha-rakter (z. B. Produktentwicklung) oder nach außen sichtbaren Systemen wie z. B. Vertrieboder Systeme zur Gestaltung des Internet-Auftrittes.

In den klassischen betriebswirtschaftlichen Bereichen, die vorwiegend nach innen ge-richtete Geschäftsprozesse abdecken, wie z. B. Finanzbuchhaltung, Kostenrechnung, Con-trolling, Personalwesen, aber auch Logistik und Materialwirtschaft, ist der Umfang derFunktionalität und die Qualität verfügbarer Standardsoftwarepakete derart hoch, dass eineIndividualentwicklung kaum noch in Betracht kommt.

Die Entwicklung von Individualsoftware erfordert einen hohen finanziellen Aufwandund ist meist sehr risikoreich, weil der angestrebte Funktionsumfang nicht erreicht wirdoder die geplanten Projektbudgets überschritten werden. Immer wieder ist in Praxispro-jekten festzustellen, dass trotz moderner Entwicklungsmethoden – häufig aus Zeitgründen– die Dokumentation der abgelieferten Programme nicht ausreichend oder in Einzelfällennicht verfügbar ist.

Die Unabhängigkeit von Softwarelieferanten wird bei der Individualentwicklung ein-getauscht gegen eine Abhängigkeit von Schlüsselmitarbeitern in der Softwareentwicklung.


Durch den Einsatz vonmodernenMethoden des Software-Engineering und der Qualitäts-sicherung kann dieser Nachteil zunehmend reduziert, aber nicht ausgeschlossen werden.Letztlich ist die Abhängigkeit zu einzelnen DV-Mitarbeitern gerade für kleinere Unterneh-men ein riskantes Problem bei Individualentwicklungen.

Beispiel Jahr-2000-UmstellungEin Beispiel für die Problematik der Abhängigkeit von Softwareentwicklern lie-ferte kürzlich die Jahr-2000-Problematik, die zum Teil dadurch verschärft wurde,dass nur noch wenige Mitarbeiter die Fachkenntnisse hatten, die vor Jahren ent-wickelten Programme zu verändern. Im Wesentlichen handelte es sich hierbei umKenntnisse der Programmiersprache COBOL, mit der über Jahrzehnte hinweg An-wendungssysteme entwickelt wurden. Teilweise wurden Fälle bekannt, in denenbereits pensionierte Mitarbeiter befristet eingestellt wurden, um die aktiven Ent-wickler zu unterstützen.

5.8.3 Einsatz von Standardsoftware

Für viele Unternehmen ist der Einsatz von Standardanwendungssoftware (kurz: Standard-software) die einzige Alternative, da sie nur so ihre Arbeitsabläufe effektiv unterstützenkönnen. Sie kaufen mit der Standardsoftware nicht nur Software, sondern auch generi-sche Prozesse ein, die an die Belange ihres Unternehmens angepasst werden müssen bzw.für deren Einsetzbarkeit die Aufbau- undAblauforganisation des Unternehmens verändertwerden muss. Einige Vor- und Nachteile, die häufig zum Einsatz von Standardsoftware ge-nannt werden, sind in Abb. 5.27 zusammengefasst:

Die Anschaffungskosten sind im Vergleich zu den Kosten für eine Individualentwick-lung geringer, da die Entwicklungskosten des Herstellers auf eine größere Kundenzahlverteilt werden.

Zu bedenken ist, dass die reinen Anschaffungskosten nicht den dominanten Kosten-faktor für eine Einführung von Standardsoftware darstellen. Mit der Einführung von Stan-dardsoftware fallen häufig auch Kosten für die Umstellung von Hardware an. Teilweise istauch die Beschaffung weiterer Software, z. B. ein bestimmtes Datenbankverwaltungssys-tem, notwendig.

Der Wettbewerb unter den Herstellern von Standardsoftware führt dazu, dass die Pro-dukte ständig verbessertwerden und in der Regel das aktuelle betriebswirtschaftliche Fach-wissen in Form von Programmen repräsentieren.

Die Kunden der Standardsoftware-Anbieter profitieren daher von der permanentenWeiterentwicklung der Software und können in der Regel auch aktuelle Standards desSoftwaremarktes nutzen. Ein Beispiel aus der jüngeren Vergangenheit ist die Weiterent-wicklung betriebswirtschaftlicher Standardsoftware um Internet-Funktionalitäten.


Geringer Anschaffungspreis

Know-how-Transfer durchden Hersteller

permanente Weiterentwick-lung an Marktstandards

hohe Funktionalität

Branchenneutralität und In-dividualität durch Customizing

Strategischer Nutzen

Geringer Anschaffungspreis

Know-how-Transfer durchden Hersteller

permanente Weiterentwick-lung an Marktstandards

hohe Funktionalität

Branchenneutralität und In-dividualität durch Customizing

Strategischer Nutzen

Herstellerabhängigkeit

Teures Spezialpersonal

Geringer Einfluss auf Weiter-entwicklung der Funktionalität

Hoher Einführungsaufwand(Schulung, Beratung)

Anpassung aufwendig odernicht möglich

Herstellerabhängigkeit

Teures Spezialpersonal

Geringer Einfluss auf Weiter-entwicklung der Funktionalität

Hoher Einführungsaufwand(Schulung, Beratung)

Anpassung aufwendig odernicht möglich

Abb. 5.27 Pro und Contra Standardsoftware

Betriebswirtschaftliche Standardsoftware verfügt heute im Gegensatz zu früheren Jah-ren über eine sehr umfangreiche Funktionalität, die im Regelfall die üblichen Anforderun-gen eines Funktionsbereiches (z. B. Finanzen) vollständig abdeckt.

Nicht selten werden manche Funktionen beim Ersteinsatz wegen der Fülle an Funk-tionen noch nicht eingesetzt, zu späteren Zeitpunkten aber genutzt. Häufig wird Standard-software international eingesetzt. Moderne Softwarepakete sind für alle gängigen Sprachender Welt einschließlich japanischer, chinesischer, arabischer und russischer Schriftzeicheneinsetzbar. Hierdurch besteht die Möglichkeit, weltweite Teamsmit der gleichen Standard-software – auf den gleichen Datenbeständen – arbeiten zu lassen. Jeder Mitarbeiter kanndas System in seiner individuellen Sprache bedienen.

Betriebswirtschaftliche Standardsoftware steht Hard- und Softwareunabhängig für ver-schiedene Branchen zur Verfügung. Frühe Generationen von Standardsoftware boten nurgeringe oder keineMöglichkeiten der Individualisierung durch denKunden. Aktuelle Soft-wareprodukte können über so genanntes Customizing im Rahmen der angebotenen Funk-tionalität an die Wünsche der Anwender angepasst werden.

Die Anzahl der „Stellschrauben“, d. h. der möglichen Parametrisierungen sind derartkomplex, dass keine generellen Aussagenmöglich sind. Grundsätzlich besteht dieMöglich-keit, derartige Standardsoftwareprodukte weitgehend an die Anforderungen im jeweiligenUnternehmen anzupassen, obgleich trotzdem mit Anpassungen der Organisation und derGeschäftsprozesse zu rechnen ist.

Häufig wird der Einsatz von Standardsoftware mit strategischen Aspekten begründet.Die Entscheidung für den Einsatz von Standardsoftware, häufig auch für einen bestimmtenHersteller, wird in der Regel auf der obersten Management-Ebene getroffen.

Dies kann bei einer geeigneten Motivation durchaus sinnvoll sein, z. B. dann, wenn esgewünscht ist, mit Hilfe des Softwareeinführungsprojektes notwendige organisatorischeÄnderungen zu begründen und durchzusetzen. Diese Situation ist in der Praxis häufig an-


zutreffen, denn bei der Individualsoftwareentwicklung werden gerne die aktuelle Aufbau-organisation und die aktuellen Geschäftsprozesse als Basis für Sollkonzepte verwendet. Indiesem Fall kann der Einsatz von Standardsoftware zu durchaus gewünschter „Nachdenk-lichkeit“ zur Vorteilhaftigkeit der derzeitigen Aufbauorganisation und der Geschäftspro-zesse führen.

Derartige Projekte haben dann den Charakter von Business Reengineering-Projekten,und der Einsatz der Standardsoftware dient hier als Werkzeug, d. h. als Enabler für dieÜberarbeitung derGeschäftsprozesse. Zudemwerden die verantwortlichenMitarbeiter derFachbereiche vergleichsweise früh in die Projektverantwortung mit einbezogen, da bereitsein funktionsfähiges Softwaresystem vorliegt und die Anpassung an die betrieblichen Er-fordernisse eine schwerpunktmäßige betriebswirtschaftliche Aufgabe darstellt. Hierdurchwird erreicht, dass die zukünftige Softwarelösung eher den Anforderungen entspricht, alsdies bei Eigenentwicklungen häufig der Fall ist, woMitarbeiter der Fachabteilung währendder Entwicklungsarbeiten wenig involviert sind.

Der wesentliche strategische Vorteil des Einsatzes von Standardsoftware liegt im ge-ringeren Folgeaufwand bei Erweiterungen des installierten Systems. Die Erweiterung derFunktionalität von selbst erstellten Applikationen übersteigt nicht selten den Aufwanddes ursprünglichen Einführungsprojektes, führt aber häufig zu vollständigen (Wartungs-)Projekten. Beim Einsatz von Standardsoftware sind funktionale Erweiterung durch Ak-tivierung der erforderlichen Funktionen und deren Parametrisierung (Customizing)jederzeit möglich. Allerdings gilt dies nur solange sich die funktionalen Erweiterungen imStandardleistungsumfang der Software bewegen. Sind Anforderungen zu realisieren, diehierüber hinausgehen, sind Zusatzentwicklungen (sog. Add Ons) oder sogar ÄnderungenimQuellcode (sog.Modifikationen) erforderlich, die den Charakter von Eigenentwicklun-gen haben.

Dennoch sind die strategischen Aspekte nicht immer ausschlaggebend bzw. zutreffend.Weniger kritisch ist der Einsatz betriebswirtschaftlicher Standardsoftware im Bereichinterner administrativer Geschäftsprozesse, die einen Querschnittscharakter haben, wiez. B. Rechnungswesen und Personal. Sorgfältiger muss die Auswahl dagegen bei Kern-geschäftsprozessen sein, die wesentliche Wertbeiträge für das Unternehmen liefern. Hierkönnen teilweise keine wettbewerbsdifferenzierenden Merkmale mit Standardsoftwarerealisiert werden.

Die Entscheidung für einen Hersteller und sein Produkt führt zwangsläufig zu einer ge-wissen, z. T. auch hohen,Abhängigkeit, da in der Regel nur ein geringer Einfluss,meist auchnur mittelbar über User-Groups etc. auf die Produktpolitik und Weiterentwicklung mög-lich ist. Die Abhängigkeit wiegt umso schwerer, wenn in für das Unternehmen strategischrelevanten Prozessfeldern Standardsoftware eingesetzt wird.

Weniger kritisch sind dagegen Prozessfelder mit hohem Standardisierungsgrad, wiez. B. Finanzwesen oder Bürokommunikation (Textverarbeitung, E-Mail usw.). Die infrüheren Softwaregenerationen übliche Praxis der Modifikation (Änderung des Source-Codes) ist häufig technisch nicht möglich (keine Auslieferung des Source-Codes durchden Hersteller) oder langfristig zu aufwändig. Letzteres ist zunehmend mehr der Fall, da


Änderungen des Source-Codes bei mehrmaligen Releasewechseln pro Jahr nicht mehrmitvertretbarem Aufwand realisierbar sind.

Die Einführung und der Betrieb von Standardsoftware erfordert einmalig im Rahmender erstmaligen Einführung, aber auch permanent während des Betriebes einen hohenSchulungs- und meist auch Beratungsaufwand durch den Hersteller oder hierauf speziali-sierte Beratungsunternehmen.

Das erforderliche Spezialpersonal ist in der Regel teuer und nur schwer zu beschaffen.Durch frühzeitige Einbindung und Qualifizierung von Mitarbeitern, die später als Coachim Unternehmen fungieren, kann dieser Nachteil bei adäquatem Projektmanagement ge-mildert werden.

Weiterhin ist zu berücksichtigen, dass bei Einsatz von Standardsoftware in der Praxismittel- bis langfristig Veränderungen in der Personalstruktur der IT-Abteilung auftreten,die einen Wechsel von Standardsoftware zurück zur Individualentwicklung erschweren.Der Grund hierfür sind deutliche Reduktionen der Personalkapazitäten für die Anwen-dungsentwicklung, da diese nur noch für die Entwicklung undAnpassung vonErweiterun-gen (sog. Add Ons) erforderlich sind. Aufgebaut werden stattdessen Personalressourcenmit betriebswirtschaftlich-organisatorischen Fähigkeiten, d. h. die Einführung von Stan-dardsoftware ist mit einem Wandel der IT-Abteilung von der Entwicklung hin zu unter-nehmensinternen Beratung verbunden.

Häufig werden auch Wartungsverträge mit externen Partnern abgeschlossen, so dassdie Entwicklungsressourcen weitgehend abgebaut werden (sog. Outsourcing).

5.8.4 Wirtschaftlichkeit von Standardsoftware

Häufig sind mit der Einführung von Standardsoftware wirtschaftliche Erwartungen ver-bunden, welche die Wettbewerbsfähigkeit des Unternehmens erhalten und sichern sollen.Neben den reinen Anschaffungskosten für die Standardsoftware fallen andere Kostenar-ten bei der Einführung von Standardsoftware wesentlich stärker ins Gewicht (vgl. z. B. dasPraxisbeispiel einer problembehafteten ERP-Einführung im Mittelstand in Schmitz 2003).Am Beispiel von SAP ERP® soll dies aufgezeigt werden. Die wesentlichen Kostenkategori-en einer SAP®-Einführung sind in untenstehender Aufzählung aufgeführt (vgl. Buxmannund König 1996).

Wegen des hohen Bedarfes an produktspezifischem Know-how ist eine Einführungvon SAP®-Systemen in der Regel mit dem Einsatz externer Berater verbunden. Beraterkommen üblicherweise in allen Projektphasen zum Einsatz, insbesondere bei der oft mitder R/3-Einführung verbundenen Reorganisation der Geschäftsprozesse (Business Reen-gineering), vor allem aber beimCustomizing des R/3-Systems, der Anwenderschulung, derRealisierung von Erweiterungen (insbesondere Eigenentwicklungen mit der von der SAPAG entwickelten Programmiersprache ABAP/4®) und sehr häufig über längere Zeiträumehinweg bei der Einführungsunterstützung des produktiven Systems (häufig noch 2–3 Jahrenach Produktivstart). Demzufolge stehen Beraterkosten, wie die obige empirische Unter-


suchung zeigt, an erster Stelle der Kostenarten, die mit der Einführung von SAP®-Systemenverbunden sind.

Kostenkategorien des SAP®-Einsatzes:

• Kosten für externe Berater,• Kosten zur Anschaffung oder Erweiterung der Hardware- und Systemsoftware,• Kosten für die Abstellung eigener Mitarbeiter für das Einführungsprojekt,• Anschaffungs- und Wartungskosten für die SAP-Standardsoftware,• Kosten für Schulungsmaßnahmen.

Da die Einführung von Client-/Server-Systemen bei einemWechsel von Großrechner-systemenmitHardwareerweiterungen (Server, Endgeräte,Netzwerk) verbunden ist, erklärtdies die an zweiter Stelle genannte Kostenart für Erweiterungen der IT-Infrastruktur. Un-ternehmen, denen bereits eine geeignete IT-Infrastruktur zur Verfügung steht, könnenmitgeringeren Kosten rechnen. Durchschnittliche Laufzeiten von bis zu einem Jahr bei kleine-ren und mittleren Projekten und von mehr als einem Jahr bei Großprojekten verursachenhohe Personalkosten für die Abstellung eigener Mitarbeiter der betroffenen Fachbereiche(insbesondere Buchhaltung, Controlling, Materialwirtschaft, Vertrieb) und der Informati-onsverarbeitung. Gerade von den Fachabteilungen wird die Bereitstellung von „Schlüssel-Personal“ für das Einführungsprojekt gefordert, um die Abläufe und Strukturen des Un-ternehmens im SAP®-System abzubilden, was den Ablauf des normalen Tagesgeschäftesungünstig beeinflusst. Von eher untergeordneter Bedeutung sind die Anschaffungs- undLizenzkosten für die Standardsoftware sowie Kosten für reine Endanwenderschulungen,auch wenn diese Kostenarten noch in beachtlicher Höhe anfallen.

Trotz der enormen Kosten zeigt der Erfolg des SAP®-Systems, dass dem Aufwanderhebliche Nutzenpotentiale gegenüberstehen, die einen Einsatz rechtfertigen können.Die wesentlichen Nutzenkategorien einer R/3-Einführung sind in untenstehender Auf-listung aufgeführt (vgl. Buxmann und König 1996). Während in der Vergangenheit mitder Einführung von Standardsoftware vor allem die IT-gestützte Abdeckung wichtigerUnternehmensfunktionen im Vordergrund des Unternehmensinteresses stand, wird beider SAP®-Einführung vor allem eine Verbesserung der Unterstützung der betrieblichenGeschäftsprozesse gesehen.

Nutzenkategorien des SAP®-Einsatzes:

• Bessere Planung, Steuerung und Kontrolle der betrieblichen Geschäftsprozesse,• Einheitliche und konsistente Datenbasis,• Verbesserte Flexibilität im Hinblick auf eine Anpassung der Informationssysteme und

Geschäftsprozesse an geänderte Anforderungen,• Verkürzung von Durchlaufzeiten der betrieblichen Geschäftsprozesse,• Qualitative Verbesserung betrieblicher Geschäftsprozesse.

Martin et al. (2002) unterscheiden in einer neueren Untersuchung vier Nutzenkatego-rien des Einsatzes von ERP-Systemen:


• Prozesseffizienz (Geschäftsprozesse),• Markteffizienz (Kunden- und Marktorientierung),• Ressourceneffizienz (Produktivität und Wirtschaftlichkeit) und• Delegationseffizienz (Effizienz der Informationsgewinnung).

Unter der Prozesseffizienz verstehen sie die Fähigkeit eines Unternehmens, Geschäfts-prozesse in den Kategorien Kosten, Qualität und Zeit zu verbessern. Beispiele sind dieReduzierung der Durchlaufzeiten von Aufträgen oder eine Erhöhung der Liefertermin-treue.

Unter Markteffizienz ist die verbesserte Nutzung von Chancen auf den Absatz- und Be-schaffungsmärkten durch koordiniertes Auftreten gegenüber Kunden bzw. Lieferanten zuverstehen. Dies kann z. B. auf der Beschaffungsseite durch eine Nachfragebündelung oderauf der Absatzseite durch verbesserte Produkte und Dienstleistungen erfolgen.

Ressourceneffizienz ist die Verbesserung der Produktivität undWirtschaftlichkeit, d. h.die optimierte Nutzung von Ressourcen in Form von Personen, Anlagen, Maschinen undKapital. Beispiele hierfür sind verbesserte Kapazitätsauslastung, Reduzierung der Lagerbe-stände oder Reduzierung der benötigten Mitarbeiteranzahl.

Die Delegationseffizienz misst die Steigerung der Nutzung des Problemlösungspotenzi-als hierarchisch übergeordneter Einheiten. Als Beispiele können eine höhereGeschwindig-keit und Qualität der Informationsverarbeitung durch IT-gestützte Reports und Analysengenannt werden. Durch den Zugriff auf eine und dieselbe Datenbank sind häufig weltweiteAnalysen für einen gesamten Konzern ohne Zusammenführen und Verdichtung verschie-dener Datenbestände möglich.

Der Abdeckungsgrad der Benutzeranforderungen durch Standardsoftware hat mittler-weile einen hohen Grad erreicht. Untersuchungen haben ergeben, dass der Abdeckungs-grad der Anforderungen durch das ERP-System SAP® R/3® in allen Modulen sehr hoch ist(vgl. Mauterer et al. 2003).

Auch nach der Einführung einer betriebswirtschaftlichen Standardsoftware ist einewei-tere Nutzensteigerung in allen unterstützten Unternehmensbereichen möglich, in dem ge-zielt im Rahmen von Prozessoptimerungsprojekten Verbesserungspotenziale identifiziertund durch geeignete Maßnahmen umgesetzt werden.

5.8.5 Portfolio als Entscheidungshilfe

Oftmals wurde in den vergangenen Jahren die Entscheidung für Eigenentwicklung oderKauf von Softwareanwendungen in jedem Projekt neu entschieden (Make or Buy). So wa-ren z. T. einzelne Funktionen mit Standardsoftware (z. B. Personal, Finanzen), andere da-gegen durch Eigenentwicklungen abgedeckt. Ursache war die oft fehlende Funktionalitätder Standardsoftwareanbieter oder mangelnde Möglichkeiten des Customizing.

Meist steht einem Unternehmen eine ausreichende Funktionalität zur Abdeckung derGrundfunktionen durch Standardsoftware zur Verfügung. Standardanwendungen vieler


Buy, Customize and Integrate!Make or Buy?

Individual-software

Standard-software

StandardA

StandardD

StandardC

StandardB

ErweiterungE

Abb. 5.28 Strategien bei der Softwareauswahl

Strategische BedeutungStrategische Bedeutung

Verfügbarkeitstandardisierter

Lösungen

Verfügbarkeitstandardisierter

Lösungen

geringgering

geringgering

hochhoch

hochhoch

Buy and CustomizeBuy and Customize Buy and Customizeand Integrate

Buy and Customizeand Integrate

Make or Buy and Customize

Make or Buy and Customize Make!Make!

•Kauf und Customizing von SSW•Vollständige Anpassung der

Organisation an die SSW •Organisation follows IT

(BPR mit Standardsoftware!)

•Entwicklung einfacher und kosten-günstiger Individualsoftware

•Ergänzender Einsatz von SSW(soweit am Markt verfügbar)

•Entwicklung aufwendiger und funktional maßgeschneiderterIndividualsoftware

•IT follows Organisation

•Kauf und Customizing von SSW•Ergänzung um Add Ons, dort wo die Organisation nicht angepasst werden kann bzw. soll

•IT meets Organisation

Abb. 5.29 Eigenentwicklung versus Standardsoftware

Hersteller für Finanzen, Controlling oder Personal decken die wichtigsten Funktionen ab.Auch Funktionen der Materialwirtschaft und Logistik und Vertrieb können durch Ein-satz von Standardsoftware gut abgedeckt werden. Dort wo Funktionen fehlen oder durchindividuelle Abläufe Vorteile erzielt werden sollen, versucht man durch Customizing derStandardsoftware (Buy, Customize and Integrate) die individuellenWünsche zu realisieren.Individuallösungen (Complete) ergänzen die Standardsoftware (vgl. Abb. 5.28).

Die Abb. 5.29 zeigt ein Portfolio zur Unterstützung der Auswahl einer passendenHand-lungsalternative.

5.9 Architekturen betriebswirtschaftlicher Standardsoftware 301

Bei geringer strategischer Bedeutung der Prozessunterstützung für das Unternehmen(z. B. Finanz- und Rechnungswesen) und gleichzeitig einer hohen Verfügbarkeit an Stan-dardsoftware (z. B. SAP® ERP) ist es sinnvoll, die Organisation an die ausgewählte Softwareanzupassen, d. h. Business Process Reengineering-Maßnahmen einzuleiten.

Steht dagegen bei hohem Marktangebot an Standardsoftware eine hohe strategischeBedeutung der Prozesse im Vordergrund, wie dies häufig im Vertrieb und Customer Re-lationship Management der Fall ist, so sollte zwar Standardsoftware angeschafft werden.Allerdings sollte dort, wo aus strategischer Sicht eine Anpassung der Organisation nichtwünschenswert oder sinnvoll erscheint, eine Erweiterung um Eigenentwicklungen vor-genommen werden. Modifikationen der Standardsoftware sollten wegen der Folgekostenvermieden werden.

Bei hoher strategischer Bedeutung der Prozessunterstützung für das Unternehmen undgeringer Marktverfügbarkeit von Standardsoftware (z. B. Leistungserbringungsprozesse inBanken, Versicherungen undTelekommunikation) sind sorgfältige und aufwändige Eigen-entwicklungsprojekte durchzuführen unter Verwendung moderner Projektmanagement-und Entwicklungsmethoden.

Ist dagegen eine geringe strategische Bedeutung und ein geringes oder nur partiellesAngebot von Standardsoftware verfügbar (z. B. Internes Bildungswesen, Aktienoptions-Programme), lässt sich der Eigenentwicklungsaufwand durch kostengünstige Individual-lösungen minimieren (z. B. Einsatz von Standard-Werkzeugen wie MS Access, MS Excel).

Praxisbeispiel „DLR“Ein Beispiel für eine Strategie in diesem Sinne ist das Vorgehen des DeutschenZentrums für Luft- und Raumfahrt (DLR) im Rahmen der betriebswirtschaftlichenSysteme. Für Standardprozesse wie z. B. Finanzbuchhaltung wird Standardsoftwareeingesetzt. Für unternehmensspezifische Prozesse, die Wettbewerbsvorteile darstel-len, ist die Entwicklung von Individualsoftware möglich (vgl. Schuster und Senden2007).

5.9 Architekturen betriebswirtschaftlicher Standardsoftware

5.9.1 Ziele undMerkmale

Ausgehend von der Geschäftsarchitektur eines Unternehmens ist eine Informationssyste-marchitektur zu entwickeln, in die die vom Unternehmen benötigten IT-Anwendungeneingebunden werden können.

Die Geschäftsarchitektur besteht aus der Geschäftsstrategie, die sie unterstützenden Ge-schäftsprozesse und die beteiligten bzw. ausführenden Akteure, also Personen oder IT-


Anwendungen. Sie ist prinzipiell unabhängig von den IT-Systemen (vgl. Hess et al. 2006,S. 396).

Die Informationssystem-Architektur beschreibt das Zusammenspiel aller IT-Anwen-dungen. Sie legt fest, in welchem Anwendungssystem Daten erzeugt, aktualisiert und ggf.wieder gelöscht werden. Sie beschreibt, welche Geschäftsprozesse bzw. Teilprozesse durchdie Anwendungssysteme primär unterstützt werden und welche Daten zu transferierensind.

Die Bedeutung von Informationssystem-Architekturen (auch als General-Bebauungs-plan oder IT-Anwendungslandschaft bezeichnet) wurde schon relativ früh erkannt (vgl.z. B. den Beitrag von Krcmar 1990). Eine leistungsfähige Computerunterstützung istmittlerweile als Schlüsselfaktor für den Erfolg eines Unternehmens anerkannt. Übli-cherweise setzen mittlere und große Unternehmen Hard- und Softwarekomponentenunterschiedlicher Hersteller ein und kombinieren auch selbst entwickelte Software mitfremdbeschaffter Standardsoftware (z. B. ERP-Systeme). Vielfach werden Stammdaten(z. B. Kunden, Lieferanten, Artikel) in verschiedenen Informationssystemen unter unter-schiedlichen Schlüsselbegriffen geführt. Sobald systemübergreifende Geschäftsprozessenotwendig werden, treten Probleme auf, da die Zuordnung der Daten nicht möglich ist.Ein hierfür typisches, in vielen Unternehmen anzutreffendes Beispiel ist die Problematikdes Nahrungsmittelkonzerns Nestlé.

Praxisbeispiel „Nestlé“„So arbeiten in den 21 Werken der deutschen Nestlé-Tochter knapp 11.000 Mitar-beiter mit unterschiedlichen SAP-Lösungen. Das führt dazu, dass beispielsweise derfür die Produktion eines Schokoriegels benötigte Zucker mit über 20 verschiede-nenNummern hinterlegt sein kann. Um die Stammdaten weltweit zu harmonisierenund die Arbeitsprozesse zu vereinheitlichen, hat der Nahrungsmittel- und Geträn-kehersteller konzernweit das so genannte Globe-Projekt gestartet. Es strebt eineeinheitliche Datenbank mit den Materialdaten für sämtliche Rohstoffe, Halbfabri-kate und Fertigprodukte an, und soll bis 2006 mit der weltweiten Einführung vonmySAP.com abgeschlossen sein.“ (vgl. Kloss 2003a).

Diese Vorgehensweise erfordert eine sinnvolle und ab einer bestimmten Unterneh-mensgröße auch computerunterstützte Planung einer Gesamtarchitektur, damit die Bau-steine zu einem sinnvollen Gebilde zusammengefasst werden können. Andernfalls drohenbei der Integration von Applikationen unterschiedlicher Hersteller Interaktionsproblemeder beteiligten Softwarekomponenten, da die zu unterstützenden Geschäftsprozesse sichnicht an Softwaregrenzen halten und durchgängig unterstützt werdenmüssen.WesentlicheAufgaben, die in diesem Zusammenhang zu lösen sind, seien hier kurz skizziert:


• Entwicklung einer unternehmensweiten Informationssystem-Architektur (Sollarchi-tektur), die Auskunft über vorhandene und geplante Applikationen und deren Schnitt-stellen eines Unternehmens gibt.

• Entwicklung und Umsetzung eines General-Bebauungsplanes im Sinne eines Master-planes undLeitfaden für die Entwicklungs- und Standardsoftware-Einführungsprojekte.

• Steuerung der Entwicklungs- und Standardsoftwareeinführungsprojekte im Hinblickauf die Einhaltung der Sollarchitektur.

Die Anforderungen an eine Unternehmensarchitektur betreffen die Flexibilität imHin-blick auf die Einbindung beliebiger Komponenten, den Einsatz von Hard- und Software-sowie organisatorischen Standards, um Softwarebausteine unterschiedlicher Hersteller zukombinieren, Hardwarebausteine verschiedener Anbieter zu koppeln und das reibungsloseorganisatorische Zusammenspiel aller Beteiligten sicherzustellen und die operative Tool-unterstützung zumManagement der eingebundenen Applikationen.

5.9.2 Ausgewählte Konzepte

Kreiselmodell der ganzheitlichen Informationssystem-ArchitekturSchon relativ früh hatKrcmar seinKreiselmodell einer ganzheitlichen Informationssystem-Architektur in die Diskussion eingebracht, das aber aufgrund seines allgemeinen Ansatzesauch heute noch Gültigkeit hat (vgl. Abb. 5.30, Krcmar 1990). Seine Analogie eines Krei-sels betont, dass alle Komponenten für ein dauerhaftes Gleichgewicht benötigt werdenund keine davon entfernt werden kann. Unter einem Informationssystem versteht erein Mensch-Maschine-System, das Informationen für die Durchführungs-, Führungs-,Analyse- und Entscheidungsfunktionen im Unternehmen einschließlich der Datenbasisund Funktionen bereitstellt (vgl. Krcmar 1990, S. 396).

Die erste Schicht des Kreiselmodells enthält die Unternehmensstrategie, die denAusgangspunkt für die Informationssystem-Architektur darstellt. Die darunter liegen-de Schicht enthält auf der einen Seite die Prozessarchitektur und auf der anderen Seite dieAufbauorganisationsarchitektur. Sie beschreibt die Ziele und Inhalte der Geschäftspro-zesse sowie der hierfür erforderlichen Aufbauorganisation. Darunter liegt eine Schichtmit Anwendungs-, Daten- und Kommunikationsarchitektur. Die Anwendungsarchitekturbeschreibt Funktionen zur Unterstützung der darüber liegenden Prozesse. Anwendungenkönnen selbst entwickelte Softwaresysteme oder Fremdbeschaffte Standardanwendungs-systeme sein. Die Datenarchitektur beschreibt den statischen Zusammenhang zwischenDaten, die für das gesamte Unternehmen von Interesse sind in Form von Datenmodel-len. Kommunikationsarchitekturen beschreiben Informationsflüsse. Die unterste, vierteSchicht beschreibt die Infrastruktur, die auch als Technologie-Architektur beschriebenwird. Hier wird festgelegt, welche Informations- und Kommunikationstechnologien imUnternehmen eingesetzt werden (z. B. technische Standards für Betriebssysteme, Compi-ler, Datenbankverwaltungssysteme, Standardsoftware).


Infra- struktur

Strategie

Prozess-architektur

Aufbau-Organisations-architektur

Anwendungs-architektur

Daten- architekturKommuni-kations-architektur

Abb. 5.30 Kreiselmodell der IS-Architektur (Krcmar 1990)

Applikationsarchitektur des InformationszeitaltersEin Beispiel für eine herstellerneutrale und generell einsetzbareGeschäftsarchitektur habenHuber et al. (1999) vorgestellt. Sie gehen hierbei von einemParadigmenwechsel von der In-dustriegesellschaft hin zur Informationsgesellschaft aus, der sich auch in veränderten An-forderungen an eine derartige Architektur niederschlägt. WesentlicheMerkmale der Infor-mationsgesellschaft sind z. B. flache und vernetzte Organisationsstrukturen, bereichsüber-greifende Ablaufoptimierungen und parallel ablaufende Prozesse sowie eine ganzheitliche,d. h. mit möglichst wenigen Bearbeiterwechseln auskommende Sachbearbeitung. Das Ar-chitekturkonzept (vgl. Huber et al. 1999, S. 46) ist in Abb. 5.31 in abgewandelter Formdargestellt.

Aufbauend auf Standards, die vom Unternehmen für Geschäftsprozesse und Daten zuerarbeiten und vorzugeben sind, werden Architekturkomponenten zur Prozessunterstüt-zung definiert. Die Architekturkomponenten decken durch unterschiedliche Applikatio-nen verschiedene Funktionsbereiche des Unternehmens ab. Sie sind in Abb. 5.32 dargestellt(vgl. Huber et al. 1999, S. 47).

ERP-Systeme bilden den Kern der Architektur, da sie für die wesentlichen innerbe-trieblichen Geschäftsprozesse eines Unternehmens unterstützend eingesetzt werden kön-nen. Data Warehouse-Applikationen dienen der Bereitstellung konsistenter Informationenfür das Management, die aus unterschiedlichen Applikationen stammen. Advanced Plan-ning- and Scheduling-Applikationen dienen der Planung von Produktionsprozessen undder Bereitstellung der erforderlichen Materialien über die gesamte Beschaffungskette hin-weg. Electronic Business Applikationen unterstützen die Geschäftsprozesse mit Geschäfts-partnern über das Medium Internet und bieten neue Formen der Interaktion mit dem


EIS Executive Information SystemEIS Executive Information System

KM KnowledgeManagementKM Knowledge Management

APS (SCM)Advanced Planning

Systems (SupplyChainManagement)



ElectronicCommerceElectronicCommerce

SFASales Force Automation





Systems (Supply ChainManagement)

ElectronicCommerceElectronicCommerce



DW Data WarehouseDW Data Warehouse

ERP Enterprise Ressource PlanningERP Enterprise Ressource Planning

Master Data ManagementMaster Data Management

Unternehmens-Standards

Abb. 5.31 Applikationsarchitektur Informationszeitalter (Huber et al. 1999)

Kunden (z. B. Internet-Shops, elektronische Marktplätze). Sales Force Automation Appli-kationen werden auch als Customer Relationship Management Applikationen bezeichnet.Sie unterstützen das ganzheitliche computerunterstützte Management der Kundenbezie-hungen. Hierunter fallen insbesondere Softwaresysteme für die Marketing und Verkaufs-unterstützung.

Applikationen für dasKnowledge-Management dienen zielgruppenorientiert derGewin-nung, Speicherung und Verteilung von Wissen. Hierzu zählen im weitesten Sinne auchWorkflow-Management-Systeme, da sie Information über Prozesswissen (als Workflow-Modelle) enthalten und für die Ausführung sowie über Analysekomponenten für detail-lierte Einzelanalysen bereitstellen.Executive Information Systemedienen derUnterstützungder Planungs- und Kontrollprozesse des Managements. Sie bauen auf DataWarehouseAp-plikationen auf und nutzen deren Datenbasis für Analysen. DasMaster Data Managementdient der Standardisierung vonDaten imUnternehmen. Beispiele für zu standardisierendeDaten sind insbesondere Stammdaten wie Kunden- oder Produktdaten, da diese im Re-gelfall in mehreren Applikationen erfasst, geändert oder für Informationszwecke benötigtwerden. Aufgabe der Standardisierung ist es, die unternehmensweit bedeutsamenDaten zudefinieren, für einzelne Sichten (z. B. Vertriebssicht der Kundendaten, Buchhaltungssichtder Kundendaten) die jeweils verantwortlichen Organisationseinheiten zu identifizierenund ihnen die Kompetenz und Werkzeuge für die Verwaltung der Strukturen und In-


Applikationsbereiche Mas

ter D

ata

Man

agem

ent

ER

P-S

yste

me

Dat

a W

areh

ouse

Sys

tem

e

Pla

nnin

g/S

ched

ulin

g A

pplik

atio

nen

E-C

omm

erce

App

likat

ione

n

Sal

es F

orce

Aut

omat

ion

Kno

wle

dge

Man

agem

ent

EIS

-Exe

cutiv

e In

form

atio

n S

yste

ms

EntwicklungForschungNachfrageplanungBedarfsplanungProduktionsplanungBeschaffungsmanagementLagerhaltungProduktion Distribution/TransportServiceHuman RessourcesLohnbuchhaltungKreditorenbuchhaltungDebitorenbuchhaltungInterne/Externe FIBUDesktop PurchasingVerkaufFührungsinformationenGroupWareDokumentenmanagementDaten StandardisierungDatensammlungen

Applikationen

Abb. 5.32 Applikationen der Funktionsbereiche (Huber et al. 1999)

halte zu übertragen. Ohne ein unternehmensweites Master Data Management entstehenungewollte Redundanzen, d. h. identische Daten werden mehrfach gespeichert, oder aberinkonsistente, d. h. sich inhaltlich widersprechende Datenbestände.

Beispiele für unternehmensspezifische GeschäftsarchitekturenEin Beispiel für eine unternehmensspezifische Geschäftsarchitektur ist die Informations-systemarchitektur der Deutschen Telekom (vgl. Fleisch et al. 1998). Ausgehend von derGeschäftsstrategie des Unternehmens wurde mit Hilfe der Methode Promet eBN für dieDeutsche Telekom eine Geschäftsarchitektur entwickelt. Inhalte des Ansatzes, der als Eck-pfeilerkonzept bezeichnet wird, sind mehrere Bausteine, die unterschiedliche Aspekte derTelekom-Architektur beschreiben und insbesondere die Anforderungen der bei der Tele-kom eingesetzten SAP-Software berücksichtigen (vgl. Fleisch et al. 1998, S. 97 f):

• SAP-Organisationsmodell (regelt zentrale Einstellungen im SAP-Organisationsmodell,die von allen Projekten beim Customizing berücksichtigt werden müssen)


• SAP-Konzernkern (Pre-Customizing, d. h. zentral vorgenommene Voreinstellungendes Customizing für alle Konzerneinheiten, die über das Organisationsmodell hinaus-gehen)

• Migrationsplanung (SAP-Masterplan des Konzerns, regelt z. B. die übergreifendeRelease-Strategie für Upgrades)

• Datenmanagement (Kerninformationsobjekte, d. h. Datenobjekte mit konzernweiterRelevanz)

Ohne auf diese Aspekte detailliert einzugehen, werden aber einige wichtige Fragen auf-geführt, die durch die Beschreibung der Aspekte beantwortet werden.

• Wie werden generelle und konzernweit relevante organisatorische Anforderungen indas Customizing der SAP-Software umgesetzt, so dass diese abgedeckt werden (z. B.überschneidungsfreie Abbildung der Tochtergesellschaften in sog. Systemorganisati-onseinheiten des SAP-Systems wie Buchungskreise, Geschäftsbereiche, Kostenrech-nungskreise)?

• Wie können gemeinsame Einstellungen in den SAP-Systemen des Konzerns identifi-ziert, überschneidungsfrei dezentral entwickelt und fortgeschrieben werden?

• Wie kann eine langfristige Migrationsplanung der Ist-Architektur in Richtung der Soll-Architektur gemäß Geschäftsarchitektur erfolgen?

• Wo ist bei der detailliertenAusprägung vonCustomizing-EinstellungenKoordinations-bedarf zwischen Projektteams, wo sind Freiräume, die ausgefüllt werden können?

Einweiteres Beispiel findet sich inGräff (1999).Dortwird dieUnternehmensarchitekturder Neckermann Versand AG vorgestellt. Die Neckermann-Unternehmensarchitektur be-schreibt in 3 Ebenen ausgehend von derUnternehmensstrategie über dieGeschäftsprozesseauf der untersten Detaillierungsebene die Aufbauorganisation sowie die im Unternehmeneingesetzten Anwendungs- und Kommunikationssysteme (vgl. Abb. 5.33). Auf jeder Ebe-ne kommen aufgabenspezifische Beschreibungsmethoden zum Einsatz. So werden auf der3. Ebene Anwendungs- und Kommunikationssysteme in den aus dem ARIS-Konzept (vgl.S. 141 ff.) bekannten Schritten Fachkonzept, DV-Konzept und Implementierung hinsicht-lich verschiedener Aspekte (Daten, Funktionen, Schnittstellen u. a.) detailliert beschrieben.

Die Unternehmensarchitektur wird u. a. dazu eingesetzt, den Ist-Zustand zu beschrei-ben und in einen ebenfalls hiermit beschriebenen Soll-Zustand zu überführen (vgl. Gräff1999, S. 175). Als Beispiel wird eine Neugestaltung der Geschäftsprozesse für die Auftrags-abwicklung genannt.

5.9.3 Referenzarchitektur für betriebliche Informationssysteme

Aufbauend auf den vorgestellten Applikationskategorien wird in Abb. 5.34 eine Referenz-architektur für betriebliche Informationssysteme vorgestellt, welche die genannten Appli-kationsbereiche unterstützt.


Abb. 5.33 Neckermann Un-ternehmensarchitektur

Unternehmens-strategie

Geschäfts-prozesse

Aufbau-organisation

Anwendungs-u. Kommuni-

kationssysteme

1. Ebene

2. Ebene

3. Ebene

Data - Warehouse und Analyse - Tools

Supply -Chain-Management

Workflow-Management

Enterprise ResourcePlanning

Customer RelationshipManagement

Textverarbeitung

Tabellenkalkulation

Präsentation

Indiv. Datenhaltung

Grafik

...

E-Mail

Telefax

Kalender

Archiv

WWW

...

Elektronische Marktplätze (Marketplaces)

Portale

Elek

tron

isch

e B

esch

affu

ng(E

-Pro

cure

men

t)

Elektronischer Vertrieb (E- Shops)

Electronic- Commerce- Applikationen

Business -Applikationen

Büro -Applikationen Kommunikations - Applikationen

Abb. 5.34 Referenzarchitektur für betriebliche Informationssysteme

Den Kern der Architektur bilden die Business-Applikationen mit den betriebswirt-schaftlichen Komponenten für das Enterprise-Resource-Planning, Supply Chain Manage-ment, Customer-Relationship-Management sowie das funktionsübergreifende Workflow-Management. Hinzu kommt eine Komponente für das Data-Warehousing, welche dieBereitstellung von Informationen zur Aufgabe hat. Diese Komponenten stellen betriebs-

5.10 BetriebswirtschaftlicheStandardsoftware im Mittelstand 309

wirtschaftliche Grundfunktionen für die inner- und zwischenbetriebliche Prozessunter-stützung und die Datenanalyse bereit. ERP, SCM und CRM-Systeme unterstützen jeweilsspezifische Prozessfelder, während dasWorkflow-Management komponentenübergreifen-de Prozesse unterstützt.

Business-Applikationen werden ergänzt durch Komponenten für arbeitsplatzneutra-le Büro-Applikationen sowie Kommunikations-Applikationen zur Sicherstellung der ar-beitsplatzübergreifenden Kommunikation. Sämtliche bisher vorgestellten Architektur-komponenten werden eingerahmt durch eine Electronic-Commerce-Komponente, dieApplikationen für den Elektronischen Handel (Marktplätze), elektronische Beschaffung(E-Procurement) und Vertrieb (E-Shops) sowie Portale zur Informationsverteilung. DieElectronic-Commerce-Komponente stellt die Integration der übrigen Komponenten mitdem Internet sicher.

5.10 Betriebswirtschaftliche Standardsoftware imMittelstand

Der Begriff des Mittelstandes, also kleinerer undmittlerer Unternehmen (KMU), wird un-terschiedlich definiert. An dieser Stelle wird auf die häufig verwendete KMU-Definitionder Europäischen Kommission zurückgegriffen. Demnach hat ein KMU

• weniger als 250 Mitarbeiter,• max. 40 Mio. EUR Jahresumsatz oder max. 27 Mio. EUR Bilanzsumme/Jahr und• befindet sich zu weniger als 25% im Besitz von „Nicht-KMU“ (vgl. z. B. Bundesminis-

terium für Wirtschaft und Arbeit 2003).

Gronauhat neunMerkmale von kleineren undmittleren Unternehmen identifiziert, dieim Hinblick auf den Einsatz von ERP-Systemen von hoher Bedeutung sind (vgl. Gronau2007, S. 16):

• Bündelung von Routineaufgaben beim Inhaber,• Inhaber entscheidet allein,• Wenig formalisierte Investitionsentscheidungen,• Defizite in der Methodik strategischer Planung,• Zeitengpässe bei Planungsaufgaben,• Geringe Anwendung betriebswirtschaftlicher Verfahren,• Kleine Organisationseinheiten,• Hohe Anpassungsfähigkeit,• Geringere finanzielle Risikobereitschaft.

Kleinere undmittlere Unternehmen sind demnachmeist inhabergeführt. Hierdurch isteine starkeKonzentration vonRoutineaufgaben zu Lasten strategisch/planender Aufgabenauf die Person des Inhabers festzustellen. Auf Grund der persönlichen Haftung des Inha-bers ist die Risikobereitschaft bei Investitionen deutlich geringer als bei Großunternehmen.


KleineOrganisationseinheitenmit breiterVerantwortung und eine hoheAnpassungsfähig-keit und schnelle Umsetzung von Entscheidungen begünstigen grundsätzlich den Einsatzneuer Technologien, wenn der Nutzen transparent ist. Entscheidungen werden ohne auf-wändigen Investitionsprozess vom Inhaber selbst getroffen und verantwortet.

Hohe Anforderungen an IT auch imMittelstandMittelständische Unternehmen sind vergleichbaren Anforderungen hinsichtlich der An-wendung vonMethoden undWerkzeugen ausgesetzt wie Großunternehmen. Beispiele fürsolche Herausforderungen sind die Jahr2000 und Euro-Umstellung. Andernfalls drohenihnen Integrationsprobleme bei der zwischenbetrieblichen Kooperation mit anderen Ge-schäftspartnern, z. B. als Zulieferunternehmen von Großkonzernen.

KMUKleine und mittlere Unternehmen (KMU) müssen daher bezüglich der Leistungsfähig-keit ihrer Geschäftsprozessorganisationund Informationsverarbeitungmit Großunterneh-men konkurrieren. Durch den Einsatz von Standardsoftware profitieren sie vom aktuellenbetriebswirtschaftlichen und technischen Standard, den moderne Standardsoftware heu-te enthält. Aktuelle IT-Technologien werden auch von den IT-Abteilungen kleinerer Ge-schäftspartner im Mittelstand erwartet.

Für die Softwarehersteller hat sich der Markt mittlerweile in Richtung Mittelstand ver-schoben, da Großunternehmen meist nur noch Ersatzbeschaffungen und Aktualisierun-gen vornehmen. Wie verschiedene Untersuchungen und Marktstudien zeigen, sind vorallem kleinere Unternehmen im ERP-Umfeld noch mit Eigenentwicklungen ausgestattetoder setzen gar keine ERP-Lösungen ein (vgl. z. B. die Marktuntersuchung der Konradin-Verlagsgruppe in o. V. 2002b). Nicht selten finden sich die Realität widerspiegelnde Zitatewie diese (vgl. Seidel 2003): „. . . Rund 50 Prozent der mittelständischen Unternehmen inDeutschland haben noch keine Software, die die wichtigsten Kernprozesse durchgängigunterstützt und gleichzeitig anpassungsfähig ist . . . “

Die Situation ist jedoch nicht neu. Zum gleichen Ergebnis kam bereits eine Untersu-chung aus dem Jahr 2000, die zugleich den Reifegrad der eingesetzten Software betrachtet.Während der Einsatz von betriebswirtschaftlicher Standardsoftware in Großunternehmenbereits weit fortgeschritten ist, sind im Mittelstand noch nicht alle Möglichkeiten des Ein-satzes ausgeschöpft. Der Einsatz von Standardsoftware ist unter den speziellen Rahmenbe-dingungen des Mittelstandes zu betrachten:

• KMU verfügen über vergleichsweise flache Strukturen,• eine geringer ausgeprägte Arbeitsteilung und• eine starke Vernetzung von vor- und nachgelagerten Prozess-Schritten.

5.10 BetriebswirtschaftlicheStandardsoftware im Mittelstand 311

Beispiele für die Vernetzung vor- und nachgelagerter Prozess-SchritteVernetzung von produktionsnahen Funktionen wie Produkt- und Verfahrensent-wicklung, Arbeitsvorbereitung und Fertigungssteuerung.Zusammenfassung von klassischen kaufmännischen Funktionen wie Finanzen,Controlling und Einkauf.Einheitliches Management der IT-Planung, IT-Entwicklung und IT-Betrieb.

Hieraus ergeben sich Vorteile für die Einführung und Nutzung von Standardsoftware,wie die geringe Anzahl von „Entscheidern“ und eine geringere Anzahl von „Bearbeiter-wechseln“ bei derAusführung vonGeschäftsprozessen.DieseRahmenbedingungenwirkensich positiv auf die Dauer der Einführung von Standardsoftware aus, da weniger Personeneinzubinden sind.Die imVergleich zuGroßunternehmen andere Situation imHinblick aufdie Aufbau- und Prozessorganisation führt zu veränderten Anforderungen an betrieblicheStandardsoftware:

• Breite Prozessunterstützung: KMU benötigen Informationssysteme, welche die breitereQualifikation und umfangreichere Verantwortung der Mitarbeiter bei der Ausführungvon Geschäftsprozessen unterstützen.

• Schnelle Einführung/hohe Stabilität: KMU benötigen wegen der weniger stark ausge-prägten Spezialisierung der Mitarbeiter und der geringeren Personalausstattung Stan-dardsoftware, die schnell und mit wenig Drittunterstützung einzuführen ist und beigeringem Pflegeaufwand stabil läuft.

• Vollständige Funktionsabdeckung: Die notwendige Standardsoftware muss vielfach diegleichen funktionalen Anforderungen abdecken, die auch bei Großunternehmen an-fallen. Besondere Anforderungen des Unternehmens müssen abbildbar sein, ohne dassProgrammieraufwand anfällt.

Die Marktanteile der Softwareanbieter hängen stark von der Größenklasse der betrach-teten Unternehmen ab. Eine Analyse der deutschen Marktanteile im Jahr 2001 (vgl. Seidel2003) zeigte, dass im Segment „bis 100 Mitarbeiter“ noch mehrere Anbieter mit Markt-anteilen zwischen 10 und 20% auftreten. Im Segment zwischen 100 und 500 Mitarbeiterndominiert dagegen ein einziger Hersteller mit einem Marktanteil von 40%.

Die Auswahl von Standardsoftware ist imMittelstand wegen des höheren Angebotes anunterschiedlichen Produkten bzw. der größeren Herstelleranzahl ein Prozess, der sich übermehrere Wochen und Monate hinziehen kann. Da kleinere und mittlere Unternehmen inder Regel über weniger Erfahrung in Auswahlprozessen verfügen, sind Checklisten zurUnterstützung dieser Aufgabe von hoher Bedeutung. Lüder (2000, S. 245) stellt eine inVerbindung mit der Universität Hannover entwickelte Checkliste zur Verfügung, die fürdie Auswahl von Finanzbuchhaltungssoftware imMittelstand zumEinsatz kommen kann.


5.11 Einführung betriebswirtschaftlicher Standardsoftware

5.11.1 Grundstrategien

Die Einführung einer betriebswirtschaftlichen Standardsoftware stellt häufig nicht gekann-te Anforderungen an die Mitarbeiter in den betroffenen Unternehmen. Neben fachlich-betriebswirtschaftlichen Fragestellungen werden auch völlig neue Anforderungen an dieZusammenarbeit der Mitarbeiter innerhalb und zwischen den betroffenen Bereichen desUnternehmens gestellt, da integrierte Softwaresysteme keine Abteilungsgrenzen kennen.Die Einführung einer betriebswirtschaftlichen Standardsoftware, insbesondere von klassi-schen ERP-Systemen, stellt einen massiven Eingriff in ein Ordnungssystem dar, der ohneKonflikte nicht zu bewältigen ist (vgl. Maucher 2001, S. 23). Aus diesemGrund ist dieWahlder geeigneten Grundstrategie eine besonders sensible und für den weiteren Projektverlaufwichtige Aufgabe, die nur mit Unterstützung der Unternehmensführung erfolgen kann.

Zur Einführung einer betriebswirtschaftlichen Standardsoftware wie z. B. SAP ERP®gibt es prinzipiell zwei Grundstrategien: Die „Big-Bang-Strategie“, d. h. den stichtagsbezo-genen Austauschdes Systems in einemZug, oder die „Sukzessiv-Strategie“, d. h. die schritt-weise Verlagerung von Prozessen in ein neues System. Mauterer (2002, S. 23) spricht hierauch von Small Bangs.

Beim Big-Bang besteht die Möglichkeit, diesen für das Gesamtunternehmen oder, imFalle einer dezentralen Organisationsform, sukzessive nach der Festlegung eines Master-systems, für dezentrale Einheiten (z. B. Länder oder regionale Niederlassungen) als so ge-nannten Roll-Out durchzuführen.

Bei der Sukzessiv-Strategie sind Kriterien für die Definition der Schrittfolge zu defi-nieren, üblicherweise unterscheidet man die abteilungsbezogene bzw. funktionsorientierteUmstellung und die marktorientierte bzw. prozessbezogene Umstellung des Systems. InAbb. 5.35 sind die Grundstrategien einschließlich weiterer Differenzierungen dargestellt.

Unter einem Big-Bang ist in diesem Zusammenhang die vollständige Ablösung einesAltsystems durch ein neues Standardsoftwaresystem zum Stichtag zu verstehen.

Mit der Aktivierung des neuen Systems wird die „Alt-Welt“ vollständig abgeschaltet.Die Vorgehensweise der Big-Bang-Strategie ist in Abb. 5.36 dargestellt.

Die Big-Bang-Strategie ist eine theoretisch optimale Lösung, da keinerlei Schnittstel-lenprobleme auftreten und von Beginn an eine integrierte Softwarelösung zur Verfügungsteht. Es fallen auch keine Übergangsproblememit Doppelarbeiten imAlt- undNeusysteman, und es besteht auch keine Gefahr von Dateninkonsistenzen, da strikt nach alten Datenvor dem Stichtag und neuen Daten nach dem Stichtag unterschieden werden kann.

Der schwerwiegendste Nachteil dieses Vorgehens ist das extrem hohe Projektrisiko, dasbei Totalausfall des neuen Systems die Unternehmung in ihrer Existenz gefährden kann.Beispiele aus der Praxis zeigen, dass dies auftreten kann. Um die Projektrisiken auf einMinimum zu reduzieren, sind umfangreiche Tests und Rückfall-Szenarien notwendig (vgl.Abb. 5.37).

5.11 Einführung betriebswirtschaftlicher Standardsoftware 313

Big-BangBig-Bang Roll Out(lokaler Big-Bang)

Roll Out(lokaler Big-Bang)

Schrittweise funktions-orientierte Einführung


Schrittweise prozess-orientierte EinführungSchrittweise prozess-orientierte Einführung

•Vollständige Ablösung des Altsystems zum Stichtag

•funktions- oder abteilungsweise Ablösung des Altsystems.•Beispiel: Ablösung der Material-wirtschaft durch SAP-R/3).

•Sukzessive Ablösung durch Umstel-lung vollständiger Prozessketten

•Beispiel: Erst Ablösung des Ersatz-geschäftes, dann Neugeschäft für Geschäfts- bzw. Privatkunden

•Unternehmen mit dezentraler Organisation entwickeln zunächst ein zentrales Mastersystem.•Anschließend erfolgt ein Roll-Outsukzessiv als lokaler Big-Bang.

Big-Bang-StrategienBig-Bang-Strategien

Sukzessiv-StrategienSukzessiv-Strategien

Big-BangBig-Bang Roll Out(lokaler Big-Bang)

Roll Out(lokaler Big-Bang)



Schrittweise prozess-orientierte EinführungSchrittweise prozess-orientierte Einführung











Big-Bang-StrategienBig-Bang-Strategien

Sukzessiv-StrategienSukzessiv-Strategien

Abb. 5.35 Einführungsstrategien für Standardsoftware

VertriebPPSLogistikEinkauf

PersonalFiBu

AusgangssituationAusgangssituation MigrationsergebnisMigrationsergebnis

Alts

yste

mER

P


PersonalFiBu


PersonalFiBu

AusgangssituationAusgangssituation MigrationsergebnisMigrationsergebnis


PersonalFiBu

Abb. 5.36 Big-Bang Vorgehensweise

Ein Big-Bang stellt sehr hohe Anforderungen an das Projektmanagement und forderteinen konzentrierten Einsatz der Personalressourcen (Fach- und IT-Abteilung und meistauch der externen Berater) innerhalb eines sehr eng definierten Zeitrahmens.

Beispiel: Erfolgreiche Big-Bang-EinführungEin Beispiel für eine erfolgreiche Big Bang-Einführung ist in Frank et al. (1997)zu finden, welche die Einführung von SAP ERP® im Geschäftsgebiet „Automatisie-rungstechnik“ der Siemens AG beschreiben. Die Gründe für die vomUnternehmenals riskante unternehmerische Entscheidung erachtete Big-Bang-Einführung lagenim zu hohen Zeitbedarf für die Alternative einer funktionsorientierten Einführung


Vorteile•Theoretisch optimale Lösung•Keine Schnittstellenproblematik•Keine Gefahr von Inkonsistenzen(klare Trennung: alte Daten/ neue Daten)

•Keine Doppelarbeiten, da keine Übergangsphase•Integriertes System bei Systemstart verfügbar

Vorteile•Theoretisch optimale Lösung•Keine Schnittstellenproblematik•Keine Gefahr von Inkonsistenzen(klare Trennung: alte Daten/ neue Daten)

•Keine Doppelarbeiten, da keine Übergangsphase•Integriertes System bei Systemstart verfügbar

Nachteile•Extrem hohes Projektrisiko durch hohe Projekt-komplexität (Gefahr des Totalausfalls)

•Sehr hohe Anforderungen an das Projektmanagement•Erfordert umfangreiche Tests und Rückfallstrategien•Maximale Ressourcenbelastung durch gleichzeitigeEinbindung aller Bereiche (FA und IT)

Nachteile•Extrem hohes Projektrisiko durch hohe Projekt-komplexität (Gefahr des Totalausfalls)

•Sehr hohe Anforderungen an das Projektmanagement•Erfordert umfangreiche Tests und Rückfallstrategien•Maximale Ressourcenbelastung durch gleichzeitigeEinbindung aller Bereiche (FA und IT)

Abb. 5.37 Big-Bang Vor- und Nachteile

(Zeitbedarf 4 Jahre anstelle von 14Monaten). Ein weiterer Aspekt war die damit ver-bundene schnellereVerfügbarkeit des gebundenen Personals. Daman sich in diesemPraxisbeispiel der bevorstehenden Risiken sehr bewusst war, wurden umfangreicheSicherungsmaßnahmen zur Risikoreduzierung eingeleitet (z. B. Lasttests).

Beispiel: Komplexe Big-Bang-EinführungEin Beispiel für eine problematischere Big Bang-Einführung wurde im Heft 46der Computerwoche vom 16.11.2001 (vgl. CW 2001) gemeldet. Demnach standbeim Energieversorger GEW AG die Ablösung der bisher genutzten Host-Verbrauchsabrechnung durch Einführung der SAP-Branchenlösung Industrial-Solution Utilities/Customer Care and Services (IS-U/CCS) an. Gleichzeitig sollteeine neue Abrechnungssystematik eingeführt werden, bei der die Kunden nicht al-le gleichzeitig eine Jahresabrechnung erhalten, sondern nach einem rollierendenVerfahren abgerechnet werden. Ziel dieser Reengineering Maßnahmen war es, ei-ne gleichmäßigere Belastung zu erreichen. Zusätzlich sollte mit der SAP-Einführungnoch ein integriertes Rechnungswesen aufgebaut und dieUmstellung auf den EUROrealisiert werden.

Die offenbar zu komplexe Aufgabe wurde vom Projektmanagement nicht be-wältigt. Die Konsequenzen waren erheblich. Nach der Produktivbetriebsaufnahmezum 01.09.2001 konnten in einigen finanzorientierten Teilbereichen des Systemskeine Zahlungenmehr abgewickelt werden. „Monatelang konnten keine Abschlags-zahlungen von Privatkunden mehr verbucht werden“ (vgl. CW 2001). Von AnfangSeptember 2001 bis Ende Oktober 2001 war man nicht in der Lage, Abbuchungsauf-träge durchzuführen.

Um die Nachteile einer Big-Bang-Lösung zumindest abzumildern, besteht bei Un-ternehmen mit dezentraler Organisation (z. B. regionalen Niederlassungen, Standorte inmehreren Ländern) die Möglichkeit, zunächst zentral ein Mastersystem zu definieren(vgl. Abb. 5.38) und es dann sukzessive auszurollen, d. h. auf die regionalen Einhei-



PersonalFiBu


PersonalFiBu

AusgangssituationAusgangssituation MastersystemMastersystem

Alts

yste

mER

P

MM

NLNL

NLNLNLNL

NLNL

NLNLNLNL

NLNLNLNL

NLNL

NLNL NLNL

NLNLNLNL

NLNL

NLNLNLNL

NLNLNLNL

NLNL

NLNL

Abb. 5.38 Roll-Out (Schritt 1)

1. Roll-Out1. Roll-Out 2. Roll-Out2. Roll-Out

NLNLNLNLNLNL

NLNL NLNL

MM

NLNLNLNLNLNL

NLNL NLNL

MM

NLNLNLNLNLNL

NLNL NLNL

MM

NLNLNLNLNLNL

NLNL NLNL

MM

NLNL

NLNLNLNL

NLNL

NLNL NLNL

NLNLNLNL

NLNL

NLNL

Abb. 5.39 Roll-Out (Schritt 2)

ten zu verteilen, dort ggf. noch anzupassen und es dann produktiv einzusetzen (vgl.Abb. 5.39).

Meistens wird an den lokalen Standorten dann ein lokaler Big-Bang durchgeführt.Die Verfolgung einer Roll-Out-Strategie führt deutlich geringere Projektrisiken nach

sich, da die Erfahrungen der ersten Projekte für Folgeprojekte genutzt werden können undbei Problemen nur Teile des Unternehmens (z. B. eine Niederlassung) betroffen sind. DerRessourceneinsatz kann zudem zeitlich deutlich entzerrt werden (vgl. Abb. 5.40).

Nachteilig sind zunächst die erforderlichen Voraussetzungen, die diesen Lösungsansatznicht in jedem Anwendungsfall erlauben. Notwendig ist eine dezentrale Organisation miteinem überschaubaren Komplexitätsgrad. Sind die lokalen Organisationen so groß, dassauch hier kein lokaler Big-Bang durchgeführt werden kann, so muss auf die Sukzessiv-Strategie ausgewichen werden. Weitere Nachteile sind darin zu sehen, dass erst nach Ab-schluss des gesamten Roll-Outs, der sich je nach Größe des Unternehmens über Jahrehinziehen kann, ein integriertes System zur Verfügung steht.


Vorteile•Geringeres Projektrisiko als beim globalen Big-Bang•Erfahrungen der Pilotprojekte können genutzt werden•Zeitlich entzerrter Ressourceneinsatz•Mastersystem gute Ausgangsbasis für Folgeprojekte

Vorteile•Geringeres Projektrisiko als beim globalen Big-Bang•Erfahrungen der Pilotprojekte können genutzt werden•Zeitlich entzerrter Ressourceneinsatz•Mastersystem gute Ausgangsbasis für Folgeprojekte

Nachteile•Nur bei dezentraler Organisation möglich!•Erfordert umfangreiche Koordination•Integriertes System erst nach Abschluss Roll-Out•Verdichtungen für zentrale Auswertungen notwendig•Erfordert hohe MA-Mobilität (Roll-Out-Teams)

Nachteile•Nur bei dezentraler Organisation möglich!•Erfordert umfangreiche Koordination•Integriertes System erst nach Abschluss Roll-Out•Verdichtungen für zentrale Auswertungen notwendig•Erfordert hohe MA-Mobilität (Roll-Out-Teams)

Abb. 5.40 Roll-Out Vor- und Nachteile

Beispiel: Roll-Out von SAP-Software bei WellaEinBeispiel für eine typischeRoll-Out-Strategiewird in einemArtikel über dieWellaAG im CIO-Magazin beschrieben (vgl. o. V. 2002). Die Wella AG ist ein Unterneh-men mit zahlreichen weltweiten Aktivitäten, d. h. einer Produktion in 17 Ländern,einem Vertrieb in 104 Ländern, 48 Tochtergesellschaften und einem Umsatzanteilvon 80% im Ausland.

Zahlreiche IT-Projekte sind parallelmitweltweitemFokus zu bearbeiten. Aus denErfahrungen der Vergangenheit mit zahlreichen unterschiedlichen ERP-Systemenheraus wurde ein Vorstandsbeschluss „Wenn ERP-Systeme, dann SAP-Software“ ge-troffen. Diese Standardisierung bringt es mit sich, dass Geschäftsprozesse weltweitzu standardisieren und die eingesetzten SAP-Systeme einheitlich zu konfigurierensind.

Deshalb verfolgt das Unternehmen einen Template-Ansatz mit einem Master-system, der beispielsweise im Roll-Out-Projekt SWAP (SAP Wella in Asia Pacific)zum Tragen kommt. Im Rahmen dieses Projektes führen mehrere asiatische Lan-desgesellschaften gemeinsam einen SAP-Prototyp auf Basis der Templates des Mas-tersystems aus Deutschland ein, der den Prozessbereich „Sales and Distribution“abdeckt. Das System wird von einem zentralen RZ-Betreiber in Singapur betrieben,die Verknüpfung der Gesellschaften erfolgt über ein gemeinsames sicheres VPN-Netz (VPN = Virtual Private Network).

Ein weiteres Beispiel wird von Frieters (2008) beschrieben, der die Entwicklung unddas Rollout eines globalen SAP®-Templates bei der Mars Inc. analysiert und u. a. mit denvergleichbaren Projekten der Wettbewerber vergleicht.

Aus derHistorie herauswird oft die Schrittfolge nach funktionalen oder abteilungsbezo-genen Kriterien vollzogen. Begriffe wie „Buchhaltungssystem“, „Lagerverwaltungssystem“oder „Vertriebssystem“ dürften vielen Mitarbeitern aus eigener Praxis bekannt sein. DieBegriffe stammen aus der funktionalen Arbeitsteilung und dokumentieren die dahinterstehende Idee von funktionsunterstützenden IV-Systemen. Zudem bieten noch viele Her-steller von ERP-Systemen funktionsorientierte Lizenzen an, d. h. die Kosten steigen bei


VertriebPPSLogistik Einkauf

PersonalFiBu

LogistikEinkauf

PersonalFiBu

VertriebLogistik Einkauf

PersonalFiBu

PPS VertriebPPS

AusgangssituationAusgangssituation 1. Migrationsschritt1. Migrationsschritt 2. Migrationsschritt2. Migrationsschritt

Alts

yste

mER

P

temporäre Schnittstelletemporäre Schnittstelle

Abb. 5.41 Schrittweise funktionsorientierte Einführung

Vorteile•Geringes Projektrisiko•Überschaubare und „managebare“ Einzelprojekte•Ressourceneinsatz zeitlich entzerrt gemäß Projektplan•Kontinuierliche Belastung der Mitarbeiter (FA + IT)•Erfahrungen der Teilprojekte können genutzt werden

Vorteile•Geringes Projektrisiko•Überschaubare und „managebare“ Einzelprojekte•Ressourceneinsatz zeitlich entzerrt gemäß Projektplan•Kontinuierliche Belastung der Mitarbeiter (FA + IT)•Erfahrungen der Teilprojekte können genutzt werden

Nachteile•Erheblicher Aufwand für temporäre Schnittstellen•Manueller Aufwand wo keine Schnittstellen vorhanden•Doppelarbeiten durch MA in der Übergangsphase•Gefahr von Inkonsistenzen durch Daten-Redundanzen•Kein integriertes System während der Übergangsphase

Nachteile•Erheblicher Aufwand für temporäre Schnittstellen•Manueller Aufwand wo keine Schnittstellen vorhanden•Doppelarbeiten durch MA in der Übergangsphase•Gefahr von Inkonsistenzen durch Daten-Redundanzen•Kein integriertes System während der Übergangsphase

Abb. 5.42 Schrittweise funktionsorientierte Einführung

Inanspruchnahme von funktionalen Bestandteilen der Produkte. Nicht genutzte Funktio-nen führen zu keinen Kosten.

Die Funktionsorientierte schrittweise Vorgehensweise löst sukzessive einzelne Funkti-onsblöcke aus dem Altsystem durch die neue ERP-Software ab und verbindet die beiden„Welten“ übergangsweise durch Schnittstellen (vgl. Abb. 5.41).

Vorteilhaft gegenüber Big-Bang-Strategien ist die kürzere Einzelprojektlaufzeit, da dasGesamtprojekt in mehrere unabhängige Teilprojekte zerlegt werden kann. Die Einzelpro-jekte sind einfacher zu handhaben, damit sinkt das Gesamtprojektrisiko (vgl. Abb. 5.42).

Auf der anderen Seite der Bilanz stehen im wesentlichen Nachteile, die durch dasSchnittstellenproblem induziert werden. Der Aufwand für die Implementierung derSchnittstellen ist enorm. Für die Übergangszeit, die durchausmehrere Jahre betragen kann,steht kein integriertes Gesamtsystem zur Verfügung. Dort, wo keine Schnittstellen imple-mentiert werden (können), entsteht ein hoher manueller Aufwand durch die betroffenenMitarbeiter. Zudem besteht die Gefahr von Inkonsistenzen durch Daten-Redundanzen, dadie „Alt-Welt“ und das neue ERP-Systemmit Daten versorgt werden müssen.

Die Prozessorientierung hat sich seit den 1990er Jahren als Paradigma der Unterneh-mensgestaltung durchgesetzt und in vielen Unternehmen etabliert.

Alternativ zur traditionellen funktionalen Vorgehensweise zur Einführung von Stan-dardsoftware bietet sich daher eine diesem Paradigma folgende Strategie an. Die einzel-nen Schritte der Migration werden hierbei nach marktorientierten Gesichtspunkten vor-genommen. D. h. es werden einzelne Prozessketten vollständig aus dem Altsystem her-ausgelöst und sofort durchgängig durch das neue ERP-System unterstützt. Meist stellt man


VertriebPPSLogistikEinkaufPersonalFiBu


AusgangssituationAusgangssituation 1. Migrationsschritt1. Migrationsschritt 2. Migrationsschritt2. Migrationsschritt

Alts

yste

mER

P

temporäre Schnittstelletemporäre Schnittstelle





Geschäftsprozess 1(z.B. Geschäftskunden)

Geschäftsprozess 2(z.B. Privatkunden)

Geschäftsprozess 3(z.B. Versandhandel)

VertriebPPSLogistik EinkaufPersonalFiBu


















Abb. 5.43 Schrittweise prozessorientierte Einführung

Vorteile•Wie funktionsorientierte Einführung, zusätzlich:•Geringeres Projektrisiko da Teilprozesse autark sind•Zunächst können unkritische Prozesse durchgängig umgestellt werden (z.B. erst Ersatz-, dann Neu-geschäft)

•Geringerer Aufwand für Schnittstellen, da i. d. R. nur Querschnittsprozesse und Stammdaten betroffen

Vorteile•Wie funktionsorientierte Einführung, zusätzlich:•Geringeres Projektrisiko da Teilprozesse autark sind•Zunächst können unkritische Prozesse durchgängig umgestellt werden (z.B. erst Ersatz-, dann Neu-geschäft)

•Geringerer Aufwand für Schnittstellen, da i. d. R. nur Querschnittsprozesse und Stammdaten betroffen

Nachteile•Wie funktionsorientierte Einführung•Ggf. Redundanzen in der Stammdatenhaltung

Nachteile•Wie funktionsorientierte Einführung•Ggf. Redundanzen in der Stammdatenhaltung

Abb. 5.44 Schrittweise prozessorientierte Einführung

zunächst die Primärprozesse sukzessiv umund plant die Querschnittprozesse (Rechnungs-wesen/Personal) en bloc am Anfang oder Ende des Projektes.

Voraussetzung für eine derartige Vorgehensweise ist, dass sich die Einzelprozesse auchorganisatorisch herauslösen lassen müssen und getrennt betrieben werden können.

Grundsätzlich gelten bei dieser Vorgehensweise die gleichen Vorteile, wie bei der Funk-tionsorientierte Einführung von Standardsoftware. Allerdings ist das Projektrisiko wesent-lich geringer, da die Teilprozesse autark sind und die Reihenfolge der Einzelprojekte nachdem Risiko für das Unternehmen gesteuert werden können. So können z. B. zunächst we-niger kritische Prozesse umgestellt werden. Später können, wenn Erfahrungen vorliegenund die Projektmannschaft „fit“ ist, andere Prozesse nachgezogen werden. So bietet es sichim Regelfall an, erst das Ersatzgeschäft und danach das Neugeschäft umzustellen. Hier-durch ist gewährleistet, dass Erfahrung nicht mit dem Kerngeschäft, dem Verkauf neuerProdukte, sondern mit dem nachgelagerten Ersatzteilgeschäft gesammelt werden können.

Auch der Aufwand für die Projektdurchführung ist geringer, da wegen der durchgän-gigen Prozessunterstützung weniger Schnittstellen zu versorgen sind. Im Regelfall tauchennoch Schnittstellen zu Querschnittsprozessen wie Rechnungswesen und Personal und evtl.gemeinsam genutzte Stammdaten (z. B. Materialstamm, Kundenstamm) auf. Zudem sinddie Schnittstellen für die Dauer der Systemumstellung konstanter als bei der funktionsori-entierten Umstellung.

Grundsätzlich gelten die Nachteile der funktionsorientierten Umstellung. Darüber hin-aus sind keine weiteren negativen Aspekte zu verzeichnen, allenfalls sind gewisse Redun-danzen bei der Stammdatenhaltung hinzunehmen.


(Schnittstellen-)Aufwand(Schnittstellen-)Aufwand

ProjektrisikoProjektrisiko

geringgering

geringgering

hochhoch

hochhoch

Big-Bang

Schrittw.prozess-orientiert

Schrittw.funktions-orientiert

Roll-out

Abb. 5.45 Gesamtbewertung (Strategisches Portfolio)

GesamtbewertungDas strategischePortfolio inAbb. 5.45 ordnet die vorgestelltenHandlungsalternativen nachden besonders wichtigen Entscheidungskriterien „Projektrisiko“ und „Aufwand“ in einePortfolio-Darstellung ein. Hierbei wird der Aufwand für die Realisierung und Demontageder Schnittstellen in den Vordergrund gestellt, da er das wesentlichste Unterscheidungs-merkmal darstellt.

Werden die wesentlichen Aspekte gegenüberstellt, so sprechen für das sukzessive Pro-zessorientierte Vorgehen viele Vorteile, aber kaum für die Existenz des Unternehmensnennenswerte Nachteile. Grundsätzlich ist eine fallbezogene Prüfung der Entscheidungs-grundlage erforderlich, da die vielfältigen Voraussetzungen zu erfüllen sind und auchexogene Entscheidungsparameter, wie z. B. Zeitdruck, unternehmenspolitische Vorgabenu. a. m. zu berücksichtigen sind.

5.11.2 Life-Cycle-Modell

Phasenmodelle bzw. Life-Cycle-Modelle werden bereits seit längerem für die Steuerungkomplexer Entwicklungsvorhaben eingesetzt. Auch die Einführung von betriebswirt-schaftlicher Standardsoftware lässt sich als Life-Cycle-Modell darstellen (vgl. Abb. 5.46).Die drei Teilzyklen Fachkonzept, Realisierung sowie Einführung und Betrieb bilden einenmehrfach vernetzten Kreislauf, der ausgehend von einem Abgleich der Geschäftsprozes-se mit der Unternehmensstrategie bis hin zur operativen Nutzung des Softwaresystemsführt. Nach einem kurzen Überblick über den Standardsoftware-Life-Cycle erfolgt einedetaillierte Behandlung der einzelnen Teilzyklen.

Der erste Zyklus (Fachkonzept) umfasst den Abgleich der Ist-Geschäftsprozesse mitden Vorgaben aus der Geschäftsstrategie. Eine Entscheidung für den Einsatz von Stan-


Geschäftsprozess-analyse

Referenzprozess-modellbasierteSollkonzeption

Customizingder Sollprozesse

Integrationstest

Betrieb undWartung

Einzeltest

Geschäfts-strategie-

entwicklung

1. Fachkonzept

2. Realisierung

3. Einführungund Betrieb

Geschäftsprozess-modellierung

Entwicklung von Schnittstellenund Add Ons

AbnahmeSchulung

Abb. 5.46 Life-Cycle-Modell für Standardsoftware

dardsoftware erfordert im Regelfall eine Ausrichtung der Unternehmensstrategie an denMöglichkeiten der zum Einsatz kommenden Standardsoftware. Erhebliche Wechselwir-kungen bestehen zwischen derUnternehmensstrategie undden fachlich-technischenMög-lichkeiten der zum Einsatz kommenden Standardsoftware. Die Auswahlentscheidung derStandardsoftware ist daher diesem Life-Cycle-Modell vorgelagert und im Rahmen einerEinsatzuntersuchung durchzuführen.

Die Sollkonzeption der zukünftigen Geschäftsprozesse erfolgt auf der Basis von Refe-renzprozessmodellen, die in der Regel durch die Standardsoftwarehersteller bereitgestelltwerden. Auf dieser Grundlage werden die Sollgeschäftsprozesse modelliert und anschlie-ßend nochmals mit den Vorgaben der Unternehmensstrategie verglichen. Die Firma SAPstellt beispielsweise ihre Referenzprozesse in Form von eEPK (erweiterte Ereignisgesteuer-ten Prozessketten) zur Verfügung.

Das Ergebnis des ersten Teilzyklus sind Sollprozesse, die auf den Möglichkeiten derStandardsoftwareaufbauen und ggf. fachliche Vorgaben für die nachgelagerte Entwicklungvon Add Ons. Hierunter ist zusätzliche Software zur Realisierung von Zusatzanforderun-gen, Altdatenübernahme und Schnittstellen zu bereits eingesetzten weiteren Informations-systemen zu verstehen.

Im zweiten Teilzyklus, der Realisierung erfolgt zunächst ein umfassendes „Customi-zing“ der Standardsoftware. Dies bedeutet, dass die zuvor modellierten Soll-Geschäftspro-zesse über Einstellungen in Form von Tabelleneinträgen in der Standardsoftware verankertwerden. Da meist zwischen denMöglichkeiten der Geschäftsprozessgestaltung, welche dieStandardsoftware bietet und den Vorgaben der Sollprozessmodellierung noch Lücken ver-bleiben, sind zusätzliche Softwarekomponenten, so genannte Add Ons, auf Basis der Soll-


Zusammenhang zwischen Unternehmensanforderungen, Funktionsumfang der Standardanwendungssoftware und Zusatzanforderungen (Add Ons)

Umfang derUnternehmenes-anforderungen




Funktionsumfangder Standard-anwendungs-software




Anforderungen,die durch

Customizing mit der

SSW abbildbar sind Nicht benötigter


Nicht benötigter Funktionsumfangder Standard-anwendungs-software

Umfang der Zusatz-anforderungen(Realisierung durch Add Ons)

Umfang der Zusatz-anforderungen(Realisierung durch Add Ons) Anforderungen,

die durchCustomizing

mit der SSW abbildbar

sind Nicht benötigter Funktionsumfangder Standard-anwendungs-software

Nicht benötigter Funktionsumfangder Standard-anwendungs-software



Abb. 5.47 Anforderungsabgleich mit Standardsoftware

Prozesse zu realisieren. Diese Entwicklungsprojekte können grundsätzlich wie Individual-entwicklungsprojekte behandelt werden. Hinzu kommt die Realisierung von Schnittstellenzwischen den sonstigen datenliefernden oder -empfangenden Informationssystemen desUnternehmens. Den Abschluss des zweiten Teilzyklus bilden die zahlreichen Einzeltestsder durch Customizing realisierten Standard-Funktionen, der selbst entwickelten AddOnssowie der Schnittstellenprogramme. Ggf. leiten sich aus den Tests noch Überarbeitungender Customizing-Einstellungen bzw. selbst entwickelten Programme ab.

Abbildung 5.47 zeigt den Zusammenhang zwischen demvomUnternehmen gewünsch-ten Funktionsumfang (linke Kreisfläche) und den von der Standardsoftware bereitge-stellten Funktionen (rechte Kreisfläche, gestrichelt), die durch das Referenzmodell desHerstellers beschrieben werden. Die mittlere Schnittmenge zeigt den Umfang der Anfor-derungen, die vom Unternehmen im Rahmen der „Standardlösung“, d. h. durch geeigneteCustomizing-Einstellungen mit der Standardsoftware realisiert werden können. Die linkeSichel repräsentiert den durch Zusatzprogramme (sog. Add Ons) zu realisierenden, dierechte Sichel den nicht vomUnternehmen benötigten Funktionsumfang der Standardsoft-ware.

Im dritten Teilzyklus erfolgt zunächst ein Integrationstest der bereitgestellten Kom-ponenten. Insbesondere sind hier bereichsübergreifende Geschäftsprozesse zu überprü-fen. Nach der Abnahme des Systems sind ggf. noch (Teil-)Korrekturen der Customizing-Einstellungen bzw. Eigenentwicklungen vorzunehmen oder Schulungen durchzuführen.Die Schulung erfolgt auf der Grundlage der Soll-Prozesse, d. h. aus dem meist vom Her-steller bereitgestellten Standardschulungsmaterialien sind unternehmensspezifische Schu-lungsdokumente zu erstellen. Nach erfolgter Schulung und Aktivierung des Systems kannder produktive Betrieb des Systems aufgenommen werden.


Im Betrieb auftretende Störungen, Erweiterungswünsche der Anwender und vomHer-steller angebotene aktualisierte Softwareversionen führen zur Wartung des Systems, d. h.zu einem erneuten Durchlauf des gesamten Zyklus.

Vorgehensmodelle betrachten die Wartungsphase meist nicht sehr ausführlich, sie darfinhaltlich nicht unterschätzt werden, da der hier anfallende Aufwand zum Teil dem vonSoftwareeinführungsprojekten gleichkommt.

Ein wesentliches Erfolgskriterium für den Einsatz von Standardsoftware, insb. von ERP-Systemen, ist die Anpassbarkeit an die Anforderungen des Unternehmens. Die Herstellerbieten unterschiedliche Möglichkeiten zur Lösung des Problems an. In der Praxis habensich u. a. folgendeMöglichkeiten etabliert, die in der Regel von den Softwareanbietern kom-biniert werden (vgl. hierzu Schuh 2006, S. 369 ff.):

• Parametrisierung (Customizing),• Modularisierung (Zerlegung der Standardsoftware in kleine Komponenten zur Unter-

stützung einzelner Prozessschritte),• Listengenerator (Erzeugung von Standardlisten ohne Programmierung),• Maskengenerator (Erzeugung oder Änderung von Bildschirmmasken ohne Program-

mierung),• Programmgenerator (Erzeugung von Standardprogrammen ohne Programmierarbei-

ten),• Referenzprozessmodelle.

Die Einführung und Weiterentwicklung von Standardsoftware beinhaltet immer wie-derkehrende Fragestellungen und Tätigkeiten, die in verschiedenen Unternehmen in glei-cher oder sehr ähnlicher Form anzutreffen sind. Einige dieser Fragen seien hier exempla-risch aufgeführt:

• Welche Geschäftsprozesse unterstützt die ausgewählte Standardsoftware?• Welche vom Unternehmen gewünschten Aufgaben werden durch die Software abge-

deckt?• Wie kann die Standardsoftware konfiguriert werden, um die Anforderungen des Un-

ternehmens zu erfüllen?

Neben dem Vorgehensmodell im Sinne einer „Arbeitsanleitung“ und Schrittfolge derdurchzuführenden Tätigkeiten sind auch inhaltliche Angaben über den Funktionsum-fang der Standardsoftware erforderlich. Referenzmodelle beschreiben Erfahrungswissen,welches im Rahmen der Sollkonzeption eines Informationssystems als Grundlage für dasReengineering der Geschäftsprozesse dienen kann. Sie können aus der Praxis aus bereitsdurchgeführten Einführungsprojekten (sog. Best Practice Cases) oder auch aus theoreti-schen Überlegungen heraus erstellt werden (vgl. Scheer 1998b, S. 61).

Hersteller betrieblicher Standardsoftware stellen z. T. Referenzmodelle für ihre Produk-te bereit. Allerdings wird der Einsatz von Referenzmodellen und der damit verbundene


Tooleinsatz in der Praxis auch kritisch gesehen, weil damit auch ein erheblicher Zusatzauf-wand verbunden ist (vgl. z. B. die kritischen Äußerungen eines Praktikers zum Einsatz vonModellierungstools in ERP-Projekten in Weißbach 2006, S. 50–52). Die Projektmitarbei-ter müssen sich in Modellierungsmethodik und Werkzeugnutzung einarbeiten, was eineerhebliche Mehrbelastung darstellen kann.

Referenzmodelle beinhalten zumindest Geschäftsprozessmodelle und zum Teil auchFunktions-, Daten und Organisationsmodelle. Funktionsmodelle beschreiben in Formvon Funktionsbäumen die durch das Standardanwendungssystem abgedeckte Funk-tionshierarchie. Datenmodelle zeigen die für die Ausführung von Geschäftsprozessenerforderlichen Informationen und Daten und deren Abhängigkeiten meist in Form vonEntity-Relationship-Modellen. Organisationsmodelle beschreiben mögliche Ausgestal-tungsformen der für die Ausführung der Geschäftsprozesse aufzubauenden Unterneh-mensorganisation in Form von Organigrammen. Die Zielsetzung der Referenzmodellebesteht in der Abbildung der betrieblichen Realität in einer standardisierten und für Drittenachvollziehbaren konsistenten Form (vgl. Aichele et al. 1994, S. 253).

Auf der Grundlage der Referenzmodelle, die als Ausgangsbasis für die Sollkonzeptiondienen, werden unter Beachtung der unternehmensspezifischenBelange die fallbezogenenSollgeschäftsprozesse modelliert. Sie müssen anschließend mit den Zielen der Unterneh-mensstrategie verglichen werden, bevor eine Umsetzung erfolgen kann.

Beispiel SAP-ReferenzmodelleDie Firma SAPAG stellt ihre Referenzprozesse ihren Kunden in Form von erweiter-ten Ereignisgesteuerten Prozessketten zur Verfügung.

Beispiel IT-ReferenzmodellFür ein fiktives IT-Unternehmen beschreibt Karer (2007) ein umfassendes Refe-renzprozessmodell mit Hilfe der EPK-Methode. Sein Modell beschreibt alle Ge-schäftsprozesse eines fiktiven IT-Unternehmens.

Die Abb. 5.48 zeigt die Verwendung von Referenzprozessmodellen im Rahmen desCustomizing einer Standardsoftware. Durch die Deaktivierung nicht benötigter Prozess-schritte oder die Ergänzung zusätzlich erforderlicher Schritte wird das Referenzmodell zueinem unternehmensspezifischen Prozess umgestaltet.

Der Einsatz von Referenzprozessmodellen im Rahmen der Auswahl und Implementie-rung von Standardsoftware ist in der Praxis bereits etabliert (vgl. Tab. 5.7).

Im Rahmen der dem Life-Cycle vorgelagerten Softwareauswahl können die von denHerstellern bereitgestellten Referenzmodelle im Sinne ausführlicher fachlicher Produktbe-schreibungen verwendet werden um die unterschiedlichen Softwarelösungenmiteinander


Referenz-Prozessmodell

Referenz-Prozessmodell

Unternehmens-spezifischer

Prozess

Unternehmens-spezifischer

Prozess

Prinzip-darstellung

Prinzip-darstellung

Customizing

Abb. 5.48 Einsatz von Referenzprozessmodellen

Tab. 5.7 Einsatzfelder für Referenzmodelle

Life-Cycle-Phase Einsatzbereich NutzenVorstudie Software-auswahl

Strukturierter Hersteller- undProduktvergleich

Einheitliche Vergleichsbasis

Fachkonzept Ausgangslösung für die Soll-konzeption

Zeitersparnis im Rahmen der Soll-konzeption und Nutzung vonBest-Practice-Lösungen

Realisierung Fachliche Grundlage für dieSystemkonfiguration (Custo-mizing)

Durchgängiger Methodeneinsatzohne Reibungsverluste zwischen denProjektphasen

Einführung undBetrieb

Anwenderschulun-gen/Schulungsunterlagen

Zeitersparnis und gemeinsame „Pro-zessbeschreibungssprache“

zu vergleichen. Während der Fachkonzeption dienen die Referenzmodelle als Ausgangs-basis für die Erstellung der Sollprozesse. Während der Realisierung des geplanten Systemskönnen die Referenzmodelle in Verbindung mit den Sollprozessen als Grundlage für dasCustomizing der Standardsoftware eingesetzt werden. Die Einführung und der Betrieb derSoftware werden dadurch unterstützt, dass Schulungsunterlagen und Benutzerdokumen-tationen durch Referenzmodelle ergänzt werden können. Durch die gemeinsame Prozess-beschreibungssprache wird die Kommunikation zwischen den Projektmitarbeitern undEndbenutzern verbessert.


Nicht in allen Branchen haben Referenzprozesse bisher Verwendung gefunden. Vorrei-ter waren klassische Industriezweige wie Maschinen- und Anlagenbau, aber auch Handelund ausgewählte Dienstleistungsbereiche. Bedingt durch den Kostendruck finden standar-disierte Geschäftsprozesse zunehmend auch in bisher vernachlässigten Branchen Verwen-dung. Als Beispiel seien hier das Gesundheitswesen und der Krankenhausbereich ange-führt.

Referenzprozesse in KrankenhäusernDie bisherige auf Tagespauschalen orientierte Vergütung wurde abgelöst und durchein neues System basierend auf DRG-Fallpauschalen (DRG = Diagnosis RelatedGroups) (vgl. hierzu ausführlich den Beitrag von Vera 2004). Das neue Vergü-tungsmodell orientiert sich am Befund, nicht an der Verweildauer des Patienten imKrankenhaus. Die Folge hiervon ist ein verstärkter Kostendruck auf die Kranken-häuser.

Als Konsequenz finden verstärkt betriebswirtschaftliche Denkweisen und Me-thoden Eingang in das Gesundheitswesen, wie z. B. die hier bedeutsame Beschrei-bung von „klinischen Behandlungspfaden“ (Clinical Path-Way). Hierunter sindstandardisierte Abläufe der notwendigenmedizinischen Prozeduren mit klarenVor-gaben für die amBehandlungsprozess Beteiligten zu verstehen.Mit anderenWorten:Referenzprozesse für die Krankenhausorganisation.

Kritisch ist bei der referenzmodellbasierten Vorgehensweise anzumerken, dass dasUnternehmen die Restrukturierung der Geschäftsprozesse an denMöglichkeiten der Stan-dardsoftware ausrichtet und das Business Reengineering geringere Freiheitsgrade umfasst,als dies bei Einführung von Individualsoftware der Fall wäre. Die Qualität der Sollge-schäftsprozesse hängt sehr stark von der Qualität der zugrunde gelegten Referenzmodelleab.

5.11.3 Projektmanagement bei der ERP-Einführung

Die Auswahl und Einführung von Standardsoftware wird üblicherweise in Projektformdurchgeführt (vgl. z. B. Gronau 2001a, S. 33). Die für die Einführung einer Standardsoftwa-re erforderliche Projektorganisation unterscheidet sich in einigen Punkten von den bei In-dividualentwicklungsprojekten üblichen Schemata. Sie ist zumindest bei größeren Unter-nehmen mit mehreren in IT-Fragen unabhängigen Geschäftsbereichen, Niederlassungenoder Standorten in zwei grundlegende Teilaufgaben zu zergliedern, dem unternehmens-weiten Management der Standardsoftwareeinführung (Programm-Management) und demManagement von Einzelprojekten.


Unter Programm-Management ist generell dieAuswahl und koordinierte Planung einesProjektportfolios, d. h. eines Bündels von Projekten, zu verstehen, das die Unternehmens-ziele unterstützt. Hier ist insbesondere die konzernweite Steuerung der Einführung undWeiterentwicklung der Standardsoftware im Ganzen zu verstehen.

Beispiel Weltweite ERP-EinführungEin Beispiel für Programm-Management ist die weltweite Einführung einer be-triebswirtschaftlichen Standardsoftware für die Prozessbereiche Beschaffung, Logis-tik, Vertrieb und Versand sowie Rechnungswesen und Controlling eines internatio-nalen Lebensmittelkonzerns.

Das Einzelprojekt-Management ist die Steuerung eines oder mehrerer zusammenge-höriger Einzelprojekte zur Einführung von Standardsoftware oder deren Erweiterung ineinem abgegrenzten organisatorischen, zeitlichen und sachlichen Umfang.

Beispiel Einführung FinanzbuchhaltungEin Beispiel für ein Einzelprojekt ist die Einführung einer betriebswirtschaftlichenStandardsoftware für das interne und externeRechnungswesen für die deutscheNie-derlassung eines internationalen Lebensmittelkonzerns.

In kleineren Unternehmen fallen die Aufgaben des Programm-Management und desEinzelprojekt-Managementwegen der geringerenKomplexität in der Regel zusammen undbedürfen keiner organisatorischenTrennung, wenngleich sie sinngemäß dennochwahrge-nommen werden.

Das Programm-Management richtet sich an den Unternehmenszielen aus. Das bedeu-tet, dass das Ziel des Programm-Managements darin besteht, die Ausrichtung der Zieleund Vorgehensweise der Einzelprojekte an den Unternehmenszielen sicherzustellen. Dadie Ziele der Einzelprojekte durchaus nicht immer korrelieren und insbesondere Konkur-renzsituationen bei Ressourcenknappheit auftreten kann, handelt es sich um eine Aufgabeder Unternehmenssteuerung.

Die Aufgaben des Programm-Managements bestehen in der strategischen Koordina-tion der Einzelprojekte, der Durchsetzung der Unternehmensziele, der Erarbeitung undFestlegung vonUnternehmens- bzw. Konzern-Standards und insbesondere auch der Bera-tung der Unternehmensleitung bei Interessenskonflikten der Einzelprojekte und der Her-beiführung einer Lösung.

Das Programm-Management setzt zahlreiche IT-Management-Werkzeuge zur Lö-sung der Aufgaben ein, u. a. eine Programmplanung für die Projekte, ein integrierendesBerichts- und Risikomanagement (vgl. Seidel 2007, S. 104 f.).


Programm-ManagementProgramm-Management

Projekt-Lenkungsausschuss 1


Projekt 1

z. B. Einführung SAP R/3im Personalwesen

Projekt 1

z. B. Einführung SAP R/3im Personalwesen



Projekt 2

z. B. Einführung SAP R/3

im Finanzwesen

Projekt 2

z. B. Einführung SAP R/3

im Finanzwesen

Projekt-Lenkungsausschuss n

Projekt-Lenkungsausschuss n

Projekt n

z. B. Entwicklung

von Unternehmens-Standards

Zentraler Materialstamm, Customizing-Templates, ...

Projekt n

z. B. Entwicklung

von Unternehmens-Standards

Zentraler Materialstamm, Customizing-Templates, ...

...

...Ei

nzel

proj

ekte

Unt

erne

hmen

Abb. 5.49 Programm-Management

Neben den Einzelprojekten zur Einführung oderWeiterentwicklung unternehmensspe-zifischer Aufgaben (z. B. Einführung eines ERP-Systems im Personalwesen) ist es erforder-lich, zentrale für alle Teilprojekte relevante Aufgaben, wie die Bereitstellung von unter-nehmensweiten Customizing-Einstellungen (Templates) oder zentralen weltweit gültigenMaterialstammdaten (z. B. einheitliche Materialnummern und -Klassifikationen) als Ein-zelprojekt unter der Kontrolle des einzelprojektübergreifenden Programm-Managementszusammenzufassen (vgl. zur Konzeption des Programm-Managements ausführlichDobiéyet al. 2004).

Wegen der strategisch relevanten Ziele und Aufgaben ist es erforderlich, dass dasProgramm-Management der Unternehmensleitung unterstellt wird. Die Steuerungsor-gane der Einzelprojekte sind die Projektlenkungsausschüsse. Sie sind üblicherweise imProgramm-Management vertreten. In der Praxis sind unterschiedliche Organisationsfor-men üblich. Die Gestaltungsspielräume reichen von der Einzelperson bis hin zu einemhoch besetzten Gremium aus den betroffenen Einheiten des Unternehmens.

Der Qualifikation eines Programm-Managers kommt eine erhebliche Bedeutung zu.Bei der Auswahl der Programm-Manager ist es daher notwendig, strategisch ausgerichteteManagementpersönlichkeiten zu finden, die fachlichesWissenmit IT-Wissen kombinierenkönnen.

Die Planung und Steuerung einzelner Projekte ist die Aufgabe des Einzelprojekt-Management (vgl. Abb. 5.50). In der Regel wird dieVertretung imProgramm-Managementdurch den Leiter des Projektlenkungsausschusses (PLA) wahrgenommen, der als Auftrag-geber des Projektes den PLA leitet. Daneben sind im PLA der oder die Projektleiter desEinführungsprojektes vertreten. Meist werden mehrere Projektleiter als Vertreter für denPLA bestimmt, die der Fachseite und der eigenen Datenverarbeitungsabteilung entstam-men. Eine „Doppelspitze“ in der Projektleitung hat den Vorteil, dass die Interessen beiderBereiche (Fachseite und Informationstechnik) gleichrangig vertreten werden. Einseitige


PLA Einführung ERP-System im FinanzwesenPLA Einführung ERP-System im Finanzwesen

TPL TechnikTPL

Technik

•ITSystemaufbauBerechtigungenInstallation

•ITSystemaufbauBerechtigungenInstallation

TPL FiBu

TPL FiBu

TPLControlling

TPLControlling

ManagementAuftraggeber

ManagementAuftraggeber

PL(Fachseite)

PL(Fachseite)

PL(eigene IT)

PL(eigene IT)

PLBerater

PLBerater

ManagementBerater

ManagementBerater

•ITSAP-Berater •ITSAP-Berater

Ker

ntea

mEr

w. T

eam

Man

agem

ent

•Fachseite (Prozess-gestaltung, Custom.)•IT (IT-Konzept,Customizing, Schnitt-stellen, Reports)

•Berater

•Fachseite (Prozess-gestaltung, Custom.)

•IT (IT-Konzept,Customizing, Schnitt-stellen, Reports)

•Berater

•Fachseite (Prozess-Details)

•IT (z. B. Abap)•Berater (Spezial-fragen, Schulung)



...

...•Fachseite (Prozess-gestaltung, Custom.)•IT (IT-Konzept,Customizing, Schnitt-stellen, Reports)

•Berater

•Fachseite (Prozess-gestaltung, Custom.)•IT (IT-Konzept,Customizing, Schnitt-stellen, Reports)

•Berater





Abb. 5.50 Einzelprojekt-Management

Besetzungen haben den in der Praxis anzutreffenden Nachteil, dass u. U. das Projekt vonder nicht paritätisch beteiligten Seite boykottiert werden kann.

Da bei der Einführung von Standardsoftware in Praxisprojekten sehr häufig externe Be-ratungsunternehmen mit spezifischem Fachwissen zur Unterstützung eingesetzt werdenund diese meist maßgeblich die inhaltlichen Arbeiten bestimmen, ist es sinnvoll den vomBeratungsunternehmen benannten Projektleiter ebenfalls in den PLA mit aufzunehmen.Da im Rahmen der Einführung von betriebswirtschaftlicher Standardsoftware häufig mitinternen Widerständen zu rechnen ist, gehört zu den Aufgaben der externen Berater auchder Abbau von nicht fachlich motivierten Vorbehalten durch Unterstützung der unterneh-menseigenen Projektmitarbeiter und Überzeugung kritischer Mitarbeiter der Fachabtei-lungen (vgl. Gabriel und Lohnert 2000, S. 179), so dass eine Integration in das Projektteamauch aus diesen Gründen sinnvoll ist.

Häufig etablieren Großunternehmen konzernzugehörige Beratungshäuser, die wie ex-terne Berater auftreten. Auch für diese gelten die Aussagen gleichermaßen. GelegentlichaufkommendeDiskussionenhinsichtlich der Vertraulichkeit der in den Entscheidungsgre-mien zu behandelnden Informationen führen meist dazu, dass die Beratungsunternehmenin das Führungsgremium aufgenommen werden, weil deren Wissensvorsprung es erfor-dert und eine vertrauensvolle Zusammenarbeit ohnehin erforderlich ist.

Im Regelfall wird es erforderlich sein, ein Einführungsprojekt in mehrere Teilprojek-te zu gliedern. Häufig wird in der Praxis ein Gesamtprojekt gebildet, in dem das ERP-Einführungsprojekt eine wesentliche Teilaufgabe darstellt und nicht softwarespezifischeOrganisationsfragen (z. B. Einbindung der Berater, Organisationsumbau) hiervon getrenntwerden (vgl. Schlick 1999, S. 17).


Im Rahmen des ERP-Projektes wird vielfach eine Untergliederung nach den einzufüh-renden Softwaremodulen (Finanzen, Controlling, Logistik etc.) gewählt. Es finden sichaber auch Beispiele für prozessorientierte Gliederungen (z. B. Ersatzteilgeschäft, Erstaus-rüstung) oder Kombinationen hieraus (z. B. Bildung mehrerer Logistik-Teilprojekte nachProzessen und je ein Querschnittsprojekt für Rechnungswesen und Personalwesen).

Die Aufgaben der Teilprojekte umfassen sowohl fachliche als auch technische Aufga-ben, die grundsätzlich in gemischten Teams aus Mitgliedern der Fachseite, der Informati-onsverarbeitung und ggf. externer Berater wahrzunehmen sind, umReibungsverluste (z. B.durch Missverständnisse) zu verhindern. Die eher fachlichen Aufgaben der Teilprojekteumfassen die Geschäftsprozessanalyse und deren Redesign, d. h. der Neugestaltung un-ter Berücksichtigung der Möglichkeiten der Standardsoftware. Daneben ist vor allem dasCustomizing, d. h. die Konfigurierung der Standardsoftware an die Belange und Anforde-rungen des Unternehmens zu verstehen.

Die eher technischen Aufgaben umfassen die Konzeption der Systemlandschaft,dem Customizing informationstechnischer Systemfunktionen (z. B. Schnittstellendatei-beschreibungen) und der Konzeption und Implementierung von Zusatzprogrammen undAuswertungen.

Teilprojekte bestehen aus einem kleinen Kernteam, das von der täglichen Arbeit be-freit und ausschließlich für die Projektarbeit abgestellt ist. Eine temporäre Mitarbeit ist ausnahezu allen betroffenen Unternehmensbereichen erforderlich. In die Projektorganisati-on sind zumindest diejenigen Mitarbeiter einzuordnen, die einen gewissen Anteil ihrerArbeitszeit für das Projekt einsetzen. Dies sind Mitarbeiter der Anwendungsentwicklung,die für die Erstellung von Zusatzprogrammen benötigt werden. Außerdem arbeiten Mitar-beiter der Fachabteilungen im Rahmen der Anforderungsanalyse und Sollkonzeption imRahmen ihrer Spezialaufgaben mit.

Daneben werden auch häufig Berater für vielfältige Spezialaufgaben (z. B. zur Klärungvon Fragen zu selten genutzten Funktionen der Standardsoftware oder technischen Fra-gen zum Einsatz von Datenbanken und Programmierwerkzeugen) oder aber für interneSchulungen temporär benötigt.

Daneben ist grundsätzlich ein Querschnittsteilprojekt für die technischen Belange er-forderlich. Die Aufgabe dieses Projektes ist der technische Aufbau des Systems, die Instal-lation der Standardsoftware und deren regelmäßige Aktualisierung mit neuen Programm-versionen durch den Hersteller. Meist enthalten die Standardsoftwarepakete umfangreicheWerkzeuge zur Benutzeradministration und Verwaltung von Berechtigungen. Auch dieseAufgaben müssen zentral für alle Teilprojekte an dieser Stelle wahrgenommen werden.

Zum Teil werden in größeren Einführungsprojekten auch Teilprojekte für die Metho-denunterstützung gebildet, die sich z. B. um die methodische Unterstützung der Prozess-analyse und Modellierung mit Hilfe spezieller Modellierungswerkzeuge kümmern.

Tabelle 5.8 stellt die wesentlichen Merkmale des Programm- und Einzelprojektmana-gement abschließend gegenüber.


Tab. 5.8 Programm- vs. Einzelprojekt-Management

Merkmal Programm-Management Einzelprojekt-ManagementZielsetzung Erreichung der Unternehmensziele Erreichung der ProjektzieleZeithorizont Langfristig

3–5 JahreMittelfristig1–2 Jahre

Aufgabe Management des Bündels der Ein-zelprojekte

Management eines Einzelprojektes

5.11.4 Erfolgsfaktoren der Standardsoftwareeinführung

In der Vergangenheit ist eine Vielzahl von Projekten zur Einführung einer Standardsoft-ware gescheitert oder wenigstens hinter den Erwartungen zurückgeblieben. Wie Untersu-chungen zeigen, werden hinter vorgehaltener Hand viele Einführungsprojekte als Misser-folg betrachtet, obgleich verantwortliche Führungskräfte die Projekte als Erfolge einstufen(vgl. z. B. Verbeck und Mancke 2001, S. 33).

Bei näherer Betrachtung lassen sich einige Erfolgsfaktoren festhalten, die zwar eineerfolgreiche, d. h. zeitlich, inhaltlich und ökonomisch zufriedenstellende, Softwareeinfüh-rung fördern, aber nicht garantieren können.

Erfolgsfaktoren Einführung von Standardsoftware:

• Realisierung einer durchgängigen Prozessunterstützung• Entwurf und Durchsetzung einer Gesamtarchitektur• Programm-Management zur konzernweiten Koordination• Modifikationsfreier Einsatz der Standardsoftware• Zentrale Releaseplanung• Einheitliche Entwicklungsstandards• Motivation der Mitarbeiter

Kaufmännisch-administrative Geschäftsprozesse (z. B. Einkauf, Logistik, Produktion,Vertrieb, Finanzen, Controlling und Personalwesen) sind grundsätzlich durchgängig miteiner Standardsoftware abzudecken. Hierzu gehört, dass Altsysteme konsequent durchdie betriebswirtschaftliche Standardsoftware abgelöst werden (vgl. auch Mauterer 2002,S. 183). Wird gegen diesen Grundsatz verstoßen, läuft das Unternehmen Gefahr, durchSchnittstellenprogramme zur Verbindung der Standardsoftware mit weiteren Softwa-rekomponenten die Vorteile integrierter betriebswirtschaftlicher Standardsoftware zuverlieren, da nicht mehr sämtliche Geschäftsprozessdaten in der Standardsoftware verfüg-bar sind. ImRahmender regelmäßig anzustrebendenVerbesserung der Geschäftsprozesse,der Einführung neuer Systeme sowie der Ablösung oder Weiterentwicklung alter Systemeist daher die Möglichkeit eines intensiveren Einsatzes der eingesetzten Standardsoftware(z. B. durch Aktivierung weiterer Module und Komponenten) sowohl aus fachlicher Sicht


als auch im Hinblick auf Schnittstellenminimierung und konsistente Datenbestände zuüberprüfen.

Der integrative Ansatz betriebswirtschaftlicher Standardsoftware kann nur über eineunternehmensweite Rahmenarchitektur realisiert werden. Hierfür sind zentrale Vorgabenfür Systemeinstellungen im Rahmen des Customizing notwendig. Weiterhin sind einheit-liche Stammdaten wie z. B. Materialstamm, Kundenstamm, die durch mehrere Informati-onssysteme benötigt werden, zu ermitteln und bereitzustellen.

Der Einsatz von der Standardsoftware wird unternehmensweit über ein an die Unter-nehmensleitung berichtendes Programm-Management abgestimmt und koordiniert.Wirdgegen diesen Grundsatz verstoßen, besteht die Gefahr, mehrere Standardsoftware-Inselnim Unternehmen zu erhalten, die von unterschiedlichen Auftraggebern weiterentwickeltwerden.

Standardsoftware ist grundsätzlich modifikationsfrei einzusetzen; Abweichungen sindüber ein vom Programm-Management vorzugebendes Verfahren unter Abwägung allerwirtschaftlichen und technischen Folgen abzustimmen. Wird dies nicht eingehalten, dro-hen dem Unternehmen nicht kalkulierbare Folgekosten bei zukünftigen Releasewechseln,da die Modifikationen manuell geprüft und in die neuen Softwareversionen übernommenwerden müssen. Da vielfach mit externen Beratern gearbeitet wird, stehen die Personen,die die Modifikationen implementiert haben, häufig nicht mehr zur Verfügung.

Eine Methode zur Messung der Standardnähe von betrieblicher Standardsoftwarewur-de von Sekatzek und Krcmar (2009) in Zusammenarbeit mit der BMW Group am Bei-spiel der SAP®-Software entwickelt. Die Autoren ermitteln Kennzahlen zur Häufigkeit derVerwendung von Standardsoftware-Modulen.Hieraus lassen sich Aussagen über den Nut-zungsgrad der Standardsoftware und Empfehlungen über mögliche Verbesserungen ablei-ten.

Praxisbeispiel: Modifikation ERP-SystemEin süddeutsches mittelständisches Anlagenbauunternehmen hatte 1988 das ERP-System Abas eingeführt und stark modifiziert, um individuelle Anforderungenabzudecken.Nach einigen Jahren stellte es fest, dass für einige der selbst entwickeltenZusatzprogramme (z. B. Dispositionssteuerung) nicht genutzte Funktionalitäten imStandardfunktionsumfang des Abas-Systems zur Verfügung standen. Das Zusam-menspiel zwischen Eigenentwicklungen und Standardprogrammen wurde deutlicherschwert. Einzelne Geschäftsprozessekonnten nur teilweise automatisiert ablaufen,da manuelle Eingriffe im Bereich der Individualentwicklungen erforderlich waren.Ende der 1990er Jahre war das System nur noch mit hohem Aufwand zu warten.Im Jahr 2004 entschied man sich für eine erneute Einführung der Abas-Software.Allerdings verzichtete das Unternehmen diesmal auf Modifikationen und nutzteausschließlich Standardfunktionen (vgl. hierzu ausführlich Stotz 2005, S. 23).


Alle Projekte zur Einführung der Standardsoftware im Unternehmen sowie die laufen-denWeiterentwicklungen unterliegen einer zentralenReleaseplanung durch das Programm-Management. Wird dies nicht sichergestellt, ist der Datenaustausch zwischen verschiede-nen Systemen, z. B. für Niederlassungen an unterschiedlichen Standorten, nicht sicherzu-stellen.

Alle Standardsoftware-Projekte unterliegen einheitlichen Vorgaben für den Entwick-lungsprozess, z. B. Regelungen für die Vergabe von Berechtigungen, Namenskonventionenfür kundeneigene Tabellen und Programme, Maskenlayouts.

Die frühzeitige und nachhaltige Motivation der Mitarbeiter ist eine der Schlüsselfakto-ren der Standardsoftwareeinführung, da der Nutzen integrierter betriebswirtschaftlicherSysteme schwerpunktmäßig auf der Prozessebene entsteht und zahlreiche Mitarbeiter oftkeinen Nutzen gegenüber der vorherigen Situation an ihrem Arbeitsplatz verspüren. VieleMitarbeiter müssen sogar nach der Einführung des Systems einen Zusatzaufwand für dieDatenerfassung durch neue Transaktionen oder ungewohnte und zum Teil auch umständ-liche Bildschirmdialoge bewältigen.

Die Erfolgsfaktoren für ERP-Einführungen sind nicht in allen Ländern identisch, dakulturelle Unterschiede zum Tragen kommen. Motwani et al. 2007 haben untersucht, wiesich erfolgreiche ERP-Einführungen in USA bzw. Indien unterscheiden. Hierbei konnteneinige kulturelleUnterschiede identifiziert werden. Sowird in indischenUnternehmen z. B.eine Setzung vonMeilensteinen und deren genaue Überwachung aufgrund der kulturellenGegebenheiten von den Mitarbeitern als Bestandteil einer guten Unternehmensführungerwartet. Ein kooperativer Führungsstil, wie der in den USA und meist auch in Europapraktiziertwird, wäre hier das völlig falsche Instrument.Dagegenwerden einseitig getroffe-ne Entscheidungen in den USA weniger akzeptiert als in indischen Unternehmen. ExterneExperten (Berater) werden in Indien eher angenommen, da die Gesellschaft kollektivisti-scher ausgeprägt ist (vgl. Motwani et al. 2007, S. 110–112).

5.11.5 Fallstudie

AusgangssituationDie Fallstudie betrachtet ein Unternehmen des Anlagenbaus mit etwa 1400 Mitarbeitern.Davon arbeiten etwa 75%amHauptsitz inDeutschland.Die restlichenMitarbeiter arbeitenweltweit in den Regionallägern, Vertriebsbüros und Niederlassungen. Der Jahresumsatzbeträgt 640 Mio. Euro.

Der ZentralbereichOrganisation und IT verantwortet dieOrganisation und IT-Planung,das Rechenzentrum und die Anwendungsentwicklung sowie den PC-Benutzerservice undberichtet an den kaufmännischen Vorstand. Der PC-Benutzerservice wird von einem ex-ternenDienstleister wahrgenommen. Für die Realisierung des derzeit größten IT-Projektes„Einführung einer betriebswirtschaftlichen Standardsoftware“ wurde ein großes Softwa-rehaus mit entsprechender Erfahrung in derartigen Projekten beauftragt.


Situationsbeschreibung

EinführungDas Unternehmen führt eine komplexe betriebswirtschaftliche Standardsoftware ein. DasProjektbudget beträgt ohne Kosten für neu anzuschaffende Hardware etwa 2 Mio. EUR.Bisher wurde eine weitgehend selbst entwickelte Software genutzt, die den gewachsenenAnforderungen des Unternehmens nicht mehr Rechnung trägt. Das Altsystem wurde inden vergangenen Jahren aus Kostengründen kaum weiterentwickelt. Ziel des Projektes istdie vollständige Ablösung des Altsystems und möglichst umfassende Nutzung der Stan-dardsoftware.

Mit der Durchführung des Einführungsprojektes wurde ein Softwarehaus beauftragt,da im eigenen Unternehmen kein spezifisches Know-how zur Verfügung steht. Im Rah-men des Projektes sollen die eigenen Mitarbeiter so ausgebildet werden, dass sie diespätere Betreuung und Weiterentwicklung der Standardsoftware selbständig übernehmenkönnen.

Das Projekt wurde in fünf funktional zugeschnittene Teilprojekte gegliedert und damitan die organisatorischen Zuständigkeiten im Hause angepasst: Rechnungswesen, Perso-nalwesen, Logistik und Produktion, Vertrieb sowie als Querschnittssteilprojekt Technik.Leiter des Projektes ist einMitarbeiter der IT-Abteilung, der über eine betriebswirtschaftli-che Ausbildung und langjährige Erfahrung verfügt. Er berichtet an den Leiter Organisationund IT, der zugleich den Lenkungsausschuss führt. Im Lenkungsausschuss sind die Leiterder Organisationseinheiten Rechnungswesen, Personalwesen usw. vertreten.

Den zuständigen kaufmännischen Vorstand erreichen bereits nach wenigen Monatenernst zu nehmendeHinweise seiner Mitarbeiter über den Projektfortschritt, die in den fol-genden Abschnitten kurz skizziert sind.

Stand der ArbeitenDie Fachkonzepte der TeilprojekteRechnungs- undPersonalwesenwurdenweitgehend fer-tig erstellt, da sich die verantwortlichen Führungskräfte auf die weitgehende Nutzung derStandardfunktionen der Software einigen konnten.

Durch die starke Integration der Standardsoftwaremodule sind noch mehrere abtei-lungsübergreifende Aufgaben mit Bezug zum Teilprojekt Logistik und Produktion sowiedem Teilprojekt Vertrieb zu regeln. So durchläuft der Beschaffungsprozess beispielsweisenacheinander die Abteilungen Einkauf, Wareneingang, Rechnungsprüfung, Kreditoren-buchhaltung und Hauptbuchhaltung. Da der Gesamtprozess abgestimmt werden muss,sind Regelungen in mehreren Fachkonzepten zu treffen.

Die Fachkonzepte für die Teilprojekte Logistik und Produktion sowie Vertrieb sind un-vollständig. Wesentliche Geschäftsprozesse sind noch in der Diskussion. Der Grund liegtdarin, dass die derzeitigen Arbeitsabläufe in diesen Aufgabenbereichen sehr weit von denReferenzprozessen der Standardsoftware entfernt sind und noch keine Einigung über eineProzessrestrukturierung erzielt werden konnte. Die Leiter der Fachabteilungen bestehenin der Diskussion mit den Beratern des Softwarehauses auf der Übertragung von histo-


risch gewachsenen Arbeitsabläufen in die Standardsoftware und insbesondere auf Beibe-haltung der bisherigen organisatorischenZuständigkeiten. Die Software-Berater argumen-tieren, dass die Abläufe des Unternehmens bei einer stärkeren Bereitschaft zum Business-Reengineering innerhalb derMöglichkeiten der Standardsoftwarezu lösen sind. Allerdingskönnen sie sich in derDiskussionmit den verantwortlichenMitarbeitern der Fachabteilun-gen nicht immer durchsetzen.

Das Teilprojekt Technik umfasst technische Aufgaben im engeren Sinne (Aufbau undInbetriebnahmederHardware, Vernetzung usw.) sowie die Erstellung eines Berechtigungs-konzeptes. Hierunter ist die organisatorisch-fachliche Regelung der Verantwortlichkeitenfür Prozesse (z. B. Wer darf den Kreditorenzahllauf durchführen?; Wer darf Lieferanten-und Kundenstammsätze anlegen und ändern?) und Objekte (Zugriff auf einzelne Kos-tenstellen, Materialien, Personaldaten usw.) und deren technische Hinterlegung in Sys-temtabellen zu verstehen. Bedingt durch die noch unvollständige Beschreibung der fach-lichen Konzepte konnten bisher nicht alle Berechtigungen festgelegt und implementiertwerden.

ProjektorganisationDie Mitglieder des Projektteams sind an mehreren Standorten verteilt untergebracht. Pro-jektmeetings finden wöchentlich in verschiedenen einzeln anzumietenden Besprechungs-räumen statt. Ein zentrales Projektbüro steht nicht zur Verfügung. Kurzfristige Meetingsmit mehr als vier Personen sind oft mangels geeigneter Besprechungsräume nicht organi-sierbar.

Zahlreiche Mitarbeiter der Fachabteilungen sind nicht von ihrer regulären Tätigkeitfreigestellt. Dies führte in der Vergangenheit mehrfach zu Terminkollisionen mit der Kon-sequenz, dass das Tagesgeschäft mehrfach Vorrang vor den Projekttätigkeiten hatte.

EinzelneBerater des Softwareunternehmens sind inweiteren Projekten andererKundentätig. Insbesondere im Teilprojekt Logistik und Produktion häufen sich Beschwerden derFachabteilungsmitarbeiter über die Nichtverfügbarkeit einzelner Berater.

Einige Teilprojektleiter der Fachabteilungen dürfen für das Projekt keine verbindlichenEntscheidungen treffen, da sich ihre jeweiligen Führungskräfte wichtige Entscheidungenvorbehalten haben. Dies führt bei schwierigen Fragen, z. B. wenn Geschäftsprozesse undorganisatorische Regelungen zu verändern sind, regelmäßig zu Verzögerungen in der Pro-jektarbeit, da die Softwareberater mehrereMitarbeiter des Fachbereiches überzeugen müs-sen.

AufgabenstellungDer kaufmännische Vorstand möchte sich ein unabhängiges Bild über die Situation desProjektes verschaffen und beauftragt einen unabhängigen externen Berater damit, Lö-sungsvorschläge zur Verbesserung der Situation zu erarbeiten.

5.12 Elektronische Geschäftsprozessunterstützung 335

LösungsvorschlägeEin Grundproblem des Projektes ist die Missachtung des Zusammenhangs zwischen Busi-ness Reengineering und dem Einsatz der Informationstechnik. Die Einführung von Stan-dardsoftware führt im Regelfall nur dann zum Erfolg, wenn sich das Unternehmen hin-sichtlich seiner Prozesse an die vorgesehenenMöglichkeiten der Standardsoftware anpasst.Das Beharren auf traditionellen Lösungen erhöht die Einführungskosten und den späterenWartungsaufwand (z. B. bei Releasewechseln).

1. EmpfehlungModerne betriebswirtschaftliche Standardsoftware setzt meist eine Prozessorganisationvoraus, die im vorliegenden Fall offensichtlich nicht vorliegt. Der Vorstand sollte dasProjekt stoppen und eine Restrukturierungsphase einlegen, in der zunächst über eineangemessene, an den Referenzprozessen der ausgewählten Standardsoftware orientierteReorganisation nachgedacht wird. Sollte die Standardsoftware die betriebswirtschaftli-chen Ziele im Kernbereich des Unternehmens (Produktion, Logistik und Vertrieb) nichtabdecken, muss ggf. auch die Auswahlentscheidung überdacht werden.

Der funktionale Zuschnitt des Projektes begünstigt Abteilungsdenken und Bereichse-goismen. Dies wirkt auch auf die gewählte Projektorganisation, welche ein Spiegelbild derAufbauorganisation darstellt.

2. EmpfehlungNach Vorliegen eines Konzeptes für die Prozessorganisation (s. o.) sollte die Projektorga-nisation nicht nach funktionalen Aufgaben, sondern nach möglichst umfassenden Pro-zessketten (z. B. Teilprojekte für Auftragsbearbeitungsprozess, Ersatzteilgeschäft usw.) ge-gliedert werden. Die Projektmitglieder müssen von den verantwortlichen Führungskräf-ten (Prozessverantwortliche) die Kompetenz für Entscheidungen übertragen bekommen.Für die Dauer des Projektes muss das Kernteam ein zentrales Projektbüro mit Konferenz-und Arbeitsräumen erhalten. Die Berater des beauftragten Softwarehauses müssen für dieProjektlaufzeit durchgängig zur Verfügung gestellt werden. Der Projektleiter sollte an denGesamtvorstand berichten, da es sich um ein unternehmenskritisches Projekt handelt. DerLenkungsausschuss ist neu zu besetzen, abhängig von der zukünftigen Prozessorganisati-on.

5.12 Elektronische Geschäftsprozessunterstützung

5.12.1 Electronic Business

Der elektronische Verkauf vonWaren und Dienstleistungen über das Internet ist in vielenBranchen etabliert und verdrängt zunehmend die traditionellen Absatzkonzepte. Nicht nurGroßunternehmen, sondern auch kleine undmittlere Unternehmen müssen sich den Her-ausforderungen dieser Entwicklung stellen, da die traditionellen nationalen Märkte mit


ElectronicCommerce

Mobile Commerce

ElektronischeGeschäftsabwicklung

InternetCommerce

Silent Commerce

ElektronischeMarktplätze

Portale OnlineStoresElectronic BusinessElectronic Business

Abb. 5.51 Begriffe des Electronic Business

geringem Aufwand zu globalen Märkten werden. Einen Überblick über die Begriffsvielfaltgibt die Abb. 5.51.

Einer der ersten Ansätze, die zum Electronic Business gezählt werden können, ist dasElectronic Banking, das sich in Deutschland bereits seit mehreren Jahren etabliert hat. Mitdem raschen Erfolg des Internets im kommerziellen Umfeld wurde die Idee des ElectronicBusiness auf Basis globaler World Wide Web-Technologien etabliert.

▸ Electronic Business Unter Electronic Business ist die Anbahnung, die Vereinbarungund die Abwicklung von zwischenbetrieblichen Geschäftsprozessen auf Basis integrierterdigitaler multimedialer Informationsverarbeitungs-Technologien insbesondere dem Inter-net zu verstehen.

Der wesentliche wirtschaftliche Effekt von Electronic Business liegt in der verändertenAbwicklung der Geschäftsprozessemit dem Geschäftspartner. Die elektronische Kommu-nikation erlaubt es, eine Reihe von Prozess-Schritten aus der Prozesskette zu entfernen,andere dafür zu integrieren. Hierdurch wird der Prozess stark beschleunigt und kann kos-tengünstiger gestaltet werden. Electronic Business ist nicht nur auf den Kauf und VerkaufvonWaren undDienstleistungen ausgerichtet, sondern auf die durchgängige Prozessunter-stützung. Electronic Business umfasst alle Kommunikations- und Verarbeitungsprozesseeinschließlich der dahinter liegenden Transport-Logistik (z. B. Warenauslieferung, Zah-lung).

Das primäre Ziel von Electronic Business ist eine Optimierung der Geschäftsprozessezwischen Geschäftspartnern und eine Senkung der Transaktionskosten. Damit wird einedeutliche Steigerung des Ertrages bewirkt. Die Kostensenkungspotentiale sind hierbei vonenormer Größe und von daher für die Unternehmensleitung von besonderer Bedeutung.


-Interne zesse mit Mitarbeitern (Job-Börse, Reise-kostenabrechnung)

Geschäftsprozesse mit potentiellen Mitarbeitern (Jobbörse, DiplomArbeitsbörsen)

B2E(Business-to-Employee)

Geschäftsprozesse mit Endkunden mit hoher Kooperation (Online-Rechnung)

-Zwischenbetriebliche Geschäftsprozesse mit Endkunden (Markt-plätze, Auktionen)

B2C(Business-to-Consumer

Zwischenbetriebliche Geschäftsprozesse mit hoher Kooperation Be-schaffungsprozesse)

Interne Geschäftsprozesse (Fuhrparksteuerung, Interne Logistik)

Zwischenbetriebliche Geschäftsprozesse mit Geschäftskunden (z. B. Marktplätze, Börsen)

B2B(Business-to-Business)

Extranet(Geschlossene Benutzergruppe)

Intranet(Firmeninterner

Markt)

Internet(Weltweiter

Markt)

-Interne Geschäftspro-

tern -

B2E

-B2C

B2B

IntranetInternet

Markt -Dimension

Mar

ktpa

rtne

r

Abb. 5.52 Grundformen des Electronic-Business

Mittlerweile haben sich konkrete Ausgestaltungsformen des Electronic Business in Ab-hängigkeit von der Dimension der beteiligten Märkte und den beteiligten Marktpartnernentwickelt, die in Abb. 5.52 zusammengestellt sind.

Business-to-Business Aktivitäten (B2B) bezeichnen zwischenbetriebliche Geschäftspro-zesse, die unter Geschäftskunden, z. B. zwischen Herstellern, Händlern usw. durchgeführtwerden.

Business-to-Consumer Aktivitäten (B2C) sind Geschäftsbeziehungen, die zwischen Un-ternehmen und ihren Endkunden durchgeführt werden.

Business-to-Employee Aktivitäten (B2E) sindGeschäftsprozesse zwischenUnternehmenund ihren Mitarbeitern oder potentiellen Mitarbeitern. Die Grundidee von B2E bestehtdarin, Mitarbeiter wie Kunden zu betrachten und analog dem B2C-Konzept mit Informa-tionen zu versorgen (vgl. Hansen und Deimler 2002, S. 108).

Transaktionen, die über das gesamte Internet abgewickelt werden, stellen einen welt-weiten elektronischen Markt dar, der für Transaktionen mit Geschäftspartnern, Endver-brauchern oder aber (potentiellen) Mitarbeitern genutzt werden kann. Typische Anwen-dungen sind Online-Shops. Transaktionen, die über ein firmeninternes Netzwerk auf Ba-sis der Internet-Technologie (Intranet) abgewickelt werden, dienen der Unterstützung in-terner Geschäftsprozesse und Services. Extranets sind Netzwerke, die nur geschlossenenBenutzergruppen auf Basis des weltweiten Internets zur Verfügung stehen. Hier werdenvorwiegend kooperationsintensive Geschäftsprozesse zwischen den Marktpartnern abge-wickelt. Typische Beispiele sind wertschöpfungsstufenübergreifende Beschaffungsprozessezwischen bekannten Unternehmen (z. B. Just-in-Time Lieferung in der Automobilindus-trie).

Der wesentliche Effekt von Electronic Business liegt in der veränderten Abwicklung derGeschäftsprozessemit demKunden. Die digitale Kommunikation mit demKunden erlaubt


es, einige Prozessschritte aus der Kette zu eliminieren bzw. zu revolutionieren. Hieraus re-sultiert eine drastische Beschleunigung der Prozessabwicklung.

5.12.2 Einfluss auf dieMärkte

Weltweiter Wettbewerb und eine drastische Reduktion der Markteintrittsbarrieren beigleichzeitig sinkender Kundenbindung sind die wesentlichen marktorientierten Auswir-kungen von Electronic Business.

Produzenten können bei Einsatz von Electronic Business ihren Standort weltweit freiwählen, da sie über das Internet global erreichbar sind, sofern es rechtlich und faktischmöglich ist. Hieraus ist die enorme Gefahr für Unternehmen zu erkennen, die sich diesenneuen Ansätzen verschließen. Grundsätzlich steht im elektronischen Markt jedem Un-ternehmen weltweit jeder nationale Markt zur Verfügung. Eine Einschränkung erfolgt le-diglich auf die Zahl der Kunden mit Internet-Anschluss, die permanent drastisch wächst.Damit werden die Markteintrittsbarrieren für die weltweite globale Markterschließung aufnahezu Null reduziert. Allerdings hat der mögliche schnelle Marktzugang für die Unter-nehmen auch eineKehrseite. DieKundenbindung istwegen derwesentlich höherenMarkt-transparenz grundsätzlich wesentlich geringer, so dass neue Konzepte für die Kundenge-winnung, Kundenbindung und die Produktgestaltung entworfen werden müssen. KundenimelektronischenMarkt sind gewöhnlichwesentlich experimentierfreudiger und erwartenvon den Anbietern stets aktuelle Distributionskonzepte und sind jederzeit bereit, kurzfris-tig neue Anbieter auszuprobieren.

Das Konzept des Electronic Business ist durchaus auch auf andere Produkte übertrag-bar, so z. B. auf leicht verderbliche Lebensmittel. Beispiele hierfür gibt es bereits in derPraxis (z. B. Internet Pizza-Bringdienste). Gerade die unmittelbare Einbindung des Kun-den in die unternehmensinternen Geschäftsprozesse machen den besonderen Vorteil vonElectronic Business aus, da Prozesskosten eingespart werden können, die durch den Kun-den wahrgenommen werden.

Unternehmen, die in elektronischenMärkten agieren möchten, müssen zuvor eine Rei-he von organisatorischen Anpassungen vornehmen. Die Gründe liegen in den geänder-ten Geschäftsprozessen und den daraus resultierenden Anforderungen. Der elektronischeMarkt erfordert neue Geschäftskonzepte und neue Geschäftsprozesse um erfolgreich agie-ren zu können. Kunden im digitalen Markt haben wesentlich höhere Erwartungen hin-sichtlich der Verfügbarkeit der Produkte, der Sortimentstiefe und -breite und den zur Ver-fügung gestellten Produktinformationen. Sie erwarten geringe Transaktionskosten sowiekürzeste Lieferzeiten.


5.12.3 Mobile Commerce

Seit demAufkommen des Electronic-Commerce tauchen in diesem Begriffsumfeld immermehr Varianten und Weiterentwicklungen auf, die zum Teil interessante technologischeAspekte beschreiben. Der Begriff des Mobile Commerce gehört zu den aktuell diskutiertenZukunftstechnologien.

▸ Mobile Commerce Unter Mobile Commerce ist die elektronische Abwicklung vonOnline-Geschäftsprozessen unter Nutzung der drahtlosen Kommunikation auf Basis derMobilfunktechnologie zu verstehen.

Im Kern handelt es sich bei Mobile Commerce nur um eine technologische Variantedes Electronic-Commerce, die nicht über die „traditionellen“ stationären Zugangstechni-ken sondern über spezielle mobile Endgeräte abgewickelt wird. Hierbei werden im We-sentlichen WAP-fähige Mobiltelefone oder Palmtops bzw. PDAs (PDA = Personal DigitalAssistent) in Verbindung mit datenübertragungsfähigen Mobiltelefonen eingesetzt. DieWachstumschancen von Mobile Commerce werden insgesamt sehr hoch eingeschätzt, dadie derzeitigen technologischen Möglichkeiten noch relativ schwach sind. In der Zukunftdürften höhere Übertragungsbandbreiten zur Verfügung stehen. Allerdings gibt es auchkritische Stimmen bezüglich der Wirksamkeit dieses Konzeptes. Kritiker sehen Risiken inden immens hohen Kosten der erforderlichen Technologien.

Die Banken sind derzeit die Vorreiterbranche für Mobile Commerce. Simple Ge-schäftsprozesse wie Kontoabfragen per Handy, Aktientransaktionen und Überweisungensind bereits technische Realität. Die derzeit noch wirksamen Markteintrittsbarrieren wiehohe Gebühren für mobile Datenübertragung, geringe Datenübertragungsgeschwindig-keiten, nicht ausreichendes Produktangebot dürften aber in wenigen Jahren beseitigt sein,so dass Unternehmen, die in diesem Bereich frühzeitig agieren, deutliche Wettbewerbs-vorteile erzielen können.

Aus Sicht der Unternehmen bietet Mobile Commerce einen herausragenden Vorteil,der für neue Produkte genutzt werden kann. Wegen der Nutzung der Mobilfunkplattformist der Empfänger jederzeit und überall für Leistungen erreichbar. Der Nutzer ist weiter-hin in der Lage, von (fast) jedem Punkt der Erde zu jeder Zeit geschäftliche Transaktionenauszuführen. Dies ermöglicht Chancen für neue Produkte nicht nur im Bereich der Infor-mationsbereitstellung (Aktienkurse, Börsennachrichten u. a. m.). Mobile Commerce kannals Plattform für Handelsfunktionen (Aktienkauf, Musik) aber auch für gezielte verkaufs-förderndeMaßnahmen zum Einsatz kommen.

5.12.4 Portale

Der Begriff Portal ist nicht einheitlich definiert. Häufige Begriffe sind Informationsportal,Dokumentenportal, Intranetportal bzw. Internetportal, Office Portal oder Knowledgepor-


tal. Grundsätzlich lassen sich horizontale und vertikale Portale unterscheiden. Danebengibt es Branchen- und Unternehmensportale.

▸ Horizontale Portale Horizontale Portale informieren breit und richten sich an privateund geschäftliche Anwender. Sie versuchen allgemeine Informationsbedarfe abzudeckenund verfügen über zusätzliche Funktionen wie Suchmaschinen und News-Rubriken.

Typische Vertreter sind Yahoo.com oder web.de. Die Portalbetreiber beschäftigenOnline-Redakteure, deren Aufgabe darin besteht, Informationen im Internet zu sichten,zu klassifizieren und aufbereitet darzustellen.

▸ Vertikale Portale Vertikale Portale haben spezielle Zielgruppen im Fokus und bietenspezialisierte Informationen an, die auf die Zielgruppe zugeschnitten sind. Sie lassen sichggf. noch nach Branchen (Branchenportal) oder Unternehmensportal (Zielgruppe = Mit-arbeiter und Geschäftspartner eines Unternehmens) differenzieren.

Besonders Erfolg versprechende Projekte sindMitarbeiterportale, da hierdurch vielfachzufriedene Mitarbeiter erzielt werden können. Erfolgreiche Beispiele lieferten die Unter-nehmen Cisco Systems, Coca-Cola oder Delta Airlines, deren B2E-Konzepte sich an denB2C-Modellen orientierten und dieMitarbeiter als Kunden sahen (vgl. Hansen undDeim-ler 2002, S. 108).

So gibt es bei Cisco Systems für neu eingestellte Mitarbeiter die Möglichkeit, sich überdas Mitarbeiterportal die Bürogrundausstattung, ein Mobiltelefon zu bestellen und die ge-wünschten Sozialleistungen auszuwählen. Da dieser Prozess anstatt einer Woche nur nocheinen Tag beansprucht, ist der Mitarbeiter wesentlich früher produktiv für das Unterneh-men tätig.

Portale sind durch eine Reihe vonMerkmalen charakterisiert: Zugangsdienste zu Infor-mationen, Personalisierung und weitere Zusatzdienste.

Ein Portal verschafft dem Anwender Zugang zu allgemeinen oder speziellen Informa-tionen. Es stellt sozusagen das Tor bzw. den Einstiegspunkt zu Links in das Internet bzw.bei Unternehmensinternen Lösungen in das Intranet dar.

Ein wesentlicher Erfolgsfaktor für Portale ist die Frage der gezielten Ansprache einzel-ner Besucher. Dies lässt sich über die Technik der Personalisierung erreichen. Hier mussinsbesondere Anwendern, die häufiger mit dem Portal arbeiten (z. B. um Beschaffungs-vorgänge abzuwickeln), eine Möglichkeit geschaffen werden, die individuell benötigtenFunktionen zu benutzen und die erforderlichen Informationen bereitgestellt zu bekom-men.

Die wachsende Konkurrenz unter den Portalen führt zu vielfältigen Zusatzdiensten,die dazu dienen, die Anwender regelmäßig zum Besuch der Portalseite zu veranlassen.Beispiele hierfür sind Suchfunktionen, Free-E-Mail, Free-SMS, Free-Web-Space zumSpeichern von Daten, Office-Funktionen wie Kalender und Adressbuch, Telefon- undE-Mailverzeichnisse u. v. m.


MarktplatzElektronischer

MarktplatzStoreA

OnlineStore

AStore

B

OnlineStore

BStore

C

OnlineStore

C

AAnbieter

A CAnbieter

CAnbieter

BAnbieter

B AAnbieter

A CAnbieter

CBAnbieter

B

Nach-frager

1

Nach-frager

1

Nach-frager

2

Nach-frager

2

Nach-frager

3

Nach-frager

3

Nach-frager

4

Nach-frager

4

Nach-frager

5

Nach-frager

5

Nach-frager

1

Nach-frager

1

Nach-frager

2

Nach-frager

2

Nach-frager

3

Nach-frager

3

Nach-frager

4

Nach-frager

4

Nach-frager

5

Nach-frager

5

Abb. 5.53 Online Store und Marktplatz

5.12.5 ElektronischeMarktplätze

NeueTechnologien führen häufig zuneuen Produkten undMärkten.Nachdemder elektro-nische Handel zunächst über Online Stores unternehmensindividuell abgewickelt wurde,kamen erste Ideen auf, elektronischeMärkte für beliebige Anbieter und Nachfrager analogeiner elektronischen Wertpapierbörse aufzubauen. Der Nutzeffekt besteht im Wesentli-chen darin, dass Nachfrager die Angebote im Internet einfacher, d. h. ohne Kenntnis derAnbieter lokalisieren können und die Geschäftsanbahnung durch den Marktplatz direktunterstützt wird. Weiterhin werden die Transaktionskosten deutlich gesenkt. Das Grund-prinzip beider Konzepte wird in Abb. 5.53 gegenübergestellt.

Die Betreiber vonOnline-Stores (vgl. Abb. 5.53, links) sind in vielen Fällen die Anbieterbzw. Händler selbst, während elektronischeMarktplätze (vgl. Abb. 5.53, rechts) in der Regelnicht von denAnbietern, sondern von unabhängigenDritten betriebenwerden.DerVorteildes Marktplatz-Konzeptes für die Unternehmen besteht darin, dass sie als Anbieter keineneigenen Marktplatz betreiben müssen und dennoch weltweit im Internet präsent sind. DieNachfrager wiederum haben nur eine Anlaufstelle und müssen sich nicht über mehrereWeb-Sites hinweg ein Marktangebot zusammenstellen.

Die Einsparpotentiale von elektronischen Marktplätzen zur Unterstützung der zwi-schenbetrieblichen Geschäftsprozesse sind enorm und können bis zu 52% der Prozess-kosten des Beschaffungsprozesses ausmachen, da vor allem zeitaufwändige Tätigkeitenwie „Prüfung von Daten im Einkauf “, „Bestellung im Informationssystem anlegen“, „Be-stellung an Lieferant faxen“, „Manuelle Auftragsverfolgung“ wegfallen (vgl. Allweyer 2001,S. 45). Neben einer Vereinfachung der Geschäftsprozesse ist mit der erfolgreichen Imple-mentierung auch häufig eine erhebliche Verkürzung der Bearbeitungszeiten verbunden.So wurde auf der Grundlage der SAP-Software eine B2B-Plattform für europäische Au-


Tab. 5.9 Einsparpotentiale elektronischer Marktplätze (Quicken 2001)

Arbeitsschritt HerkömmlichesVerfahren

SupplyOnVerfahren

Bemerkung

Bedarfs- for-mulierung

30 Minuten bis3 Stunden

30 Minuten Standardisierte Eingabemasken erleich-tern die Spezifizierung des Bedarfsund weisen auf relevante Produktei-genschaften hin und erläutern diese.Unternehmensinterne Gesamtbedarfesind auf Knopfdruck verfügbar.

Lieferantensu-che

2–3 Tage 30 Minuten

Einholen vonAngeboten

3–4 Wochen 2–3 Tage Postlaufzeiten entfallen, Angebotsfor-mulare sind materialgruppenspezifisch

Angebotevergleichbarmachen

3–4 Stunden 20 Minuten

Verhandlungenmit günstigstenAnbietern

2–3 Tage Entfälltbzw.Online-Bidding

Weiter gehende Verhandlungen könnenentfallen, Aktionen sind aber möglich

Vertragsab-schluss

20 Minuten 20 Minuten Unverändert

Gesamt Ca. 6 Wochen Ca. 3 Tage

tomobilzulieferer und deren Lieferanten aufgebaut, welche die Eigenarten dieser Brancheberücksichtigt und zu erheblichen Effizienzsteigerungen beiträgt (vgl. Quicken 2001).Tabelle 5.9 zeigt die Bearbeitungszeiten verschiedener branchenspezifischer Geschäftspro-zessschritte vor und nach der Einführung des elektronischen Marktplatzes „SupplyOn“(Quicken 2001, S. 91).

5.13 Wiederholungsfragen zum 5. Kapitel

1. Skizzieren Sie betriebliche Standardsoftware.2. Beschreiben Sie Merkmale von ERP-Systemen.3. Erläutern Sie anhandder „Kundenstammdaten“ die Bedeutung undWirkungsweise der

Datenintegration eines integrierten ERP-Systems?4. Skizzieren Sie die Struktur einer Supply-Chain.5. Beschreiben Sie die Struktur der Supply-Chain nach dem Konzept des Supply-Chain-

Council.6. Welche Formen derComputerunterstützung erfordert das Supply-Chain-Management?7. Grenzen Sie das Massenmarketing vom Customer-Relationship-Management ab.

5.14 Übungen zum 5. Kapitel 343

8. Entwerfen Sie eine Grobarchitektur für CRM-Systeme.9. Vergleichen Sie ein Data Warehouse zur Veranschaulichung mit einemWarenlager.10. Vergleichen Sie ein Data Warehouse mit einem ERP-System hinsichtlich der Ziele, des

Informationsgehaltes und ggf. weiterer relevanter Unterscheidungskriterien.11.Worin unterscheiden sich die Begriffe Daten, Informationen und Wissen?12.Welche Kosten entstehen bei der Einführung von betriebswirtschaftlicher Standard-

software? Wo liegt der Nutzen?14.Welche Einsatzmöglichkeiten bieten Referenzmodelle im Zusammenhang mit Stan-

dardsoftware?15. Grenzen Sie das Programm- vom Einzelprojektmanagement ab.16. Definieren Sie den Begriff „Electronic Commerce“.17. Beschreiben Sie die wesentlichen Grundformen des Electronic Commerce18. Stellen Sie die Besonderheiten des Mobile Commerce als Sonderform des Electronic

Commerce heraus19.Was ist unter dem Begriff „Personalisierung“ zu verstehen?20. Beschreiben Sie den Unterschied zwischen einem Online Store und einem elektroni-

schen Marktplatz.21.Welche Einsparmöglichkeiten bietet die Beschaffung über einen elektronischenMarkt-

platz?

5.14 Übungen zum 5. Kapitel

Übung 12: Enterprise Resource PlanningAufgabenstellung: Erläutern Sie den Begriff des ERP-Systems. Wofür steht die Abkürzung?Nennen Sie einige Bereiche eines Unternehmens, die typischerweise durch ERP-Systemeunterstützt werden.

Lösungshinweise: Ein ERP-System (Enterprise Resource Planning-System) ist ein Soft-waresystem, bei dem mehrere betriebswirtschaftliche Anwendungen durch eine gemein-same Datenbasis integriert sind. Typische Einsatzbereiche sind Finanzwesen und Control-ling, Produktionsplanung- und Steuerung, Einkauf und Logistik, Vertrieb und Versandsowie Personalwesen.

Übung 13: Einführung von ERP-SystemenAufgabenstellung: Begründen Sie, weshalb die Einführung und der Einsatz von ERP-Systemen in einen Regelkreislauf (Life-Cycle) mündet.

Lösungshinweise: ERP-Systeme verfügen über eine sehr hohe Funktionalität. Diese kannim Rahmen der Ersteinführung in der Praxis nicht vollständig aktiviert und genutzt wer-den. Nach der erfolgreichen Einführung tauchen Fehler auf, die beseitigt werden müssen.

Weiterhin äußern die Anwender Wünsche nach einer verstärkten Nutzung der Funk-tionen, die durch die ERP-Systeme bereitgestellt werden, und für eine Nutzung durch


Customizing-Aktivitäten an die Anforderungen des Unternehmens angepasst werdenmüssen.

Meist sehen sich die Unternehmen auch gezwungen, regelmäßige Releasewechseldurchzuführen, um einen aktuellen Softwarestand zu erhalten.

Übung 14: Individualentwicklung versus StandardsoftwareAufgabenstellung: Nennen Sie einige wichtige Gründe, weshalb Unternehmen Eigenent-wicklungen oder veraltete Standardsoftware durch moderne ERP-Systeme ersetzen?

Lösungshinweise: Häufig sind die bisherigen Anwendungen nicht mehr bedarfsgerechtoder zu teuer. Meist steht auch der Wunsch nach organisatorischen Verbesserungen imVordergrund, dermit einer neuen Softwarelösung kombiniertwerden soll. Auch lassen sichbisherige Lösungen nicht mehr pflegen und warten oder mit neuen Produkten integrieren.

In konzerngebundenen Unternehmen sind häufig Standards, insb. im Hinblick auf be-stimmte Produktlösungen, einzuhalten.

Übung 15: ERP-System zur Analyse?Aufgabenstellung: Weshalb ist ein ERP-System für die Analyse entscheidungsrelevanter In-formationen weniger gut geeignet als ein Data Warehouse?

Lösungshinweise:Ein ERP-Systemdient der operativenUnterstützung vonGeschäftspro-zessen, z. B. Einkaufs, Produktions- und Vertriebsprozesse. Die Systemarchitektur ist aufhohen Datendurchsatz ausgelegt, d. h. die Datenbank-Tabellen enthalten in der Regel kei-ne Zwischensummen oder Summen (z. B. nach Kunden oder Produktgruppen) wie sietypischerweise für managementorientierte Analysen benötigt werden.

Ein Data Warehouse wird regelmäßig aus internen und externen operativen Datenbe-ständen, z. B. aus ERP-Systemen mit Daten versorgt. Die Daten werden beim Laden in dasDataWarehouse selektiert, formatiert und verdichtet und liegen in Form abrufbarer Infor-mationen vor. Sie entsprechen damit eher den Anforderungen an betriebswirtschaftlicheAnalysen als die „Rohdaten“ eines ERP-Systems, das auf operative Prozesse hin ausgerichtetist.

Übung 16: Abhängigheiten beim SoftwareeinsatzAufgabenstellung: Diskutieren Sie die Behauptung, dass beim Einsatz von Individualsoft-ware die Abhängigkeit vonHerstellern geringer ist, als beim Einsatz von Standardsoftware.

Lösungshinweise: Beim Einsatz von Standardsoftwarewird ein Abhängigkeitsverhältniszu einemSoftwarelieferanten aufgebaut, das in der Regel übermehrere Jahre, oft Jahrzehntehinweg bestehen bleibt.

Allerdings besteht auch beim Einsatz von Individualsoftware ein Abhängigkeitsverhält-nis. Das Unternehmen geht i. d. R. eine Abhängigkeit zu mehreren Herstellern von Ent-wicklungswerkzeugen, Datenbanken u. a. ein.

Ein Wechsel derartiger Werkzeuge verursacht häufig einen vergleichbar hohen Auf-wand wie der Wechsel zu einer anderen Standardsoftware.

5.14 Übungen zum 5. Kapitel 345

Übung 17: Kosten der Einführung von ERP-SystemenAufgabenstellung:DieEinführung von Standardsoftware ist neben den reinenAnschaffungs-und Lizenzkosten mit z. T. erheblichen, über diese Positionen hinausgehenden Kostenverbunden. Nennen Sie hierfür Gründe und erläutern Sie diese!

Lösungshinweise:Hauptsächlich fallen bei der Einführung von StandardsoftwareKostenfür externe Berater, Kosten zur Anschaffung oder Erweiterung der Hardware- und System-software sowie Kosten für die Abstellung eigener Mitarbeiter für das Einführungsprojektan. Die Anschaffungskosten (Kauf und Lizenzen für Wartung) machen nur einen kleinenTeil der Gesamtkosten aus.

Die Gründe sind vor allem in der komplexen Struktur der Standardsoftware, die füreinen großen Markt konzipiert wurde, zu sehen. Das für die Einführung erforderlicheFachwissen ist meist nicht in den Unternehmen im ausreichenden Maße vorhanden undauch in der Regel nicht durch kurzfristige Schulungsmaßnahmen aufzubauen. Daher sindbei der Einführung von Standardsoftwaremeist externe Berater notwendig, die bei der Pla-nung, Konzeption und Umsetzung der Projekte unterstützend tätig sind.

Je nach vorhandener Infrastruktur sind auch Investitionen erforderlich, um diese an diemeist hohen Anforderungen der Standardsoftware anzupassen.

Übung 18: Gründe für den Einsatz von StandardsoftwareAufgabenstellung:Aus welchen Gründen setzen viele Unternehmen verstärkt Standardsoft-ware ein?

Lösungshinweise: Gründe für den verstärkten Einsatz von Standardsoftware sind:

1. Stark angestiegenes und differenziertes Marktangebot im Bereich der Querschnittspro-zesse (Finanzen, Controlling, Personal) und der Primärprozesse (Vertrieb, Produktion,Beschaffung u. a. m.).

2. Zwang zum Reengineering der Geschäftsprozesse, dessen Umsetzung durch moderneStandardsoftware erleichtert wird.

3. Permanenter Know-how-Transfer durch denHersteller, da diese imWettbewerb stehenund ihre Software stets aktuell halten müssen.

4. Zunehmend komplexer werdende Anforderungen der Fachabteilungen, die unter wirt-schaftlichen Aspekten nicht realisierbar erscheinen.

5. Viele fehlgeschlagene Entwicklungsprojekte, die inhaltlich oder zeitlich ihre Ziele nichterreicht haben oder die Entwicklungsbudgets überschritten haben.

6. Geringer Folgeaufwand bei Weiterentwicklungen, da Anpassungen im Rahmen desStandardangebotes ohne Programmierung möglich sind.

Übung 19: Gründe für den Einsatz von IndividualsoftwareAufgabenstellung: Weshalb kann es sinnvoll sein, keine Standardsoftware, sondern Indivi-dualsoftware einzusetzen?


Lösungshinweise: Gründe für den verstärkten Einsatz von Individualsoftware sind:

1. Individualsoftware wird auf die Belange des Unternehmens zugeschnitten und erfor-dert daher keine Änderung der Aufbau- oder Ablauforganisation.

2. Es besteht keine Abhängigkeit zu einem Standardsoftwarelieferanten, auf dessen Pro-duktpolitik in der Regel kein oder nur wenig Einfluss ausgeübt werden kann.

3. Durch gezielte Konzentration der Entwicklungsressourcen auf strategisch relevanteProzessfelder sindWettbewerbsvorteile möglich.

Übung 20: Einsatz von ReferenzprozessmodellenAufgabenstellung:Begründen Sie die Notwendigkeit des Einsatzes von Referenzprozessmo-dellen im Rahmen des Life-Cycle-Modells für die Einführung von Standardsoftware.

Lösungshinweise:Die Einführung von Standardsoftwarebringt esmit sich, dass derHer-steller Standardgeschäftsprozesse unterstellt, die eine Vielzahl von Anwendungsfällen ab-decken. Allerdings ist im Rahmen der Einführung der Standardsoftware erforderlich, dieunternehmensindividuellen Anforderungen zu berücksichtigen.

Hierfür werden Beschreibungen der vorgesehenen Geschäftsprozesse benötigt. Diesewerden meist in Form von Referenzprozessmodellen hinterlegt und können als Ausgangs-basis für kundenindividuelle Geschäftsprozesse verwendet werden.

Übung 21: ERP versus CRMAufgabenstellung: ERP-Systeme decken bereits große Teile der betrieblichen Prozessketteab, u. a. auch den Verkauf. In den letzten Jahren kamen verstärkt CRM-Systeme auf denMarkt. Erläutern Sie, welche Aufgaben CRM-Systeme in Ergänzung zu den ERP-Systemenübernehmen und wo es Überlappungen gibt.

Lösungshinweise:ERP-Systemeunterstützen vor allemdie imUnternehmen anfallendenGeschäftsprozesse aus abwicklungstechnischer Sicht. Es geht also darum, Kundenaufträgezu erfassen, Fertigungspläne zu erstellen, Lagerbestände zu überwachen und die Ferti-gung/Montage und den Versand zu steuern, um abschließend die Geschäftsvorfälle buch-halterisch zu erfassen. CRM-Systeme dienen dagegen der kundenorientierten Planung vonMaßnahmen und deren Überwachung. Hierzu gehören z. B. die Kundenselektion fürWer-bemaßnahmen, Analysen und der Betrieb von Call-Centern. Überlappungen gibt es imBereich der Kundenstammdaten und Produktstammdaten sowie einiger Bewegungsdaten(z. B. Kundenaufträge, Anfragen).

5.15 Literaturempfehlungen zum 5. Kapitel

Appelrath und Ritter (2000) Gute Einstiegslektüre für Projektleiter. Grundsatzwerk zurEinführung von SAP®-Systemen.

5.15 Literaturempfehlungen zum 5. Kapitel 347

Dobiéy et al. (2004) Praxisorientierte Beschreibung des Programm-Managementsals Werkzeug zum zielorientierten Management von Projekt-bündeln.

Gronau (2001a) Vertiefende Behandlung der Projektorganisation bei derEinführung von Standardsoftware. Zwei didaktisch gut auf-bereitete Fallbeispiele zur Einführung von Standardsoftwareim Anhang des Buches bieten die Möglichkeit einer praxis-nahen Vertiefung der Auswahlproblematik.

Gronau (2010) Vertiefende Einführung in die Funktionalität und das Mana-gement von ERP-Systemen

Grothe und Gentsch (2000) Praxisnahe Einführung zum Einsatz von Data WarehouseSystemen mit gut nachvollziehbaren Fallbeispielen.

Jacob (2008) Aktuelles Buch zur Planung und Einführung von ERP-Systemen mit einem detaillierten Fokus auf Nutzenaspekten.Insbesondere für Praktiker geeignet. Studenten finden hiereinen Einblick in die Praxis.

Mauterer (2002) Praxisnahe Dissertation zum Nutzen von ERP-Systemen amBeispiel von SAP® R/3®, die auf einer umfangreichen Befra-gung zahlreicher Unternehmen beruht. Das Buch bietet in-teressante Ergebnisse, die vielen Beratern teilweise bekanntwaren, in dieser Form aber nicht wissenschaftlich fundiertnachgewiesen wurden.

Mertens (2000 und 2007) Fundierter Überblick über den Einsatz von betrieblichen In-formationssystemen in Theorie und Praxis. Zahlreiche Fall-beispiele.

Rickayzen et al. (2002) Umfassende praxisorientierte Einführung in die Funktionali-tät des Workflow-Management-Moduls der SAP AG. Enthältviele detaillierte Anwendungsbeispiele.

Scheer et al. (2003) Aufschlussreiche Untersuchung zum Stand des E-Govern-ment in Deutschland unter besonderer Berücksichtigungvon BundOnline2005. Von besonderem Interesse für Leseraus öffentlichen Unternehmen und Behörden.

Schmitz (2003) Gutes Praxisbeispiel zu Problemen bei der Einführung einesERP-Systems im Mittelstand.

Schütte und Vering (2004) Fundierte Einführung in den Auswahlprozess von Waren-wirtschaftssystemen und deren Möglichkeiten zur Prozess-unterstützung mit zahlreichen Beispielen und Produktüber-sichten. Empfehlenswert für IT- und Prozessverantwortlichein mittleren und größeren Handelsunternehmen.

Schulze (2002) Guter Überblick über den Stand des Customer RelationshipManagement.


Wilhelm (2007) Das Buch bietet eine Einführung in organisatorische Fra-gen des Prozessmanagements und zahlreiche Musterpro-zesse/Referenzprozesse für unterschiedliche betrieblicheAufgaben, die in Form von Ablaufdiagrammen bereitgestelltwerden.

grundkurs geschäftsprozess-management || prozessmanagement...

Documents