2 Evaluation und Auswahl von EMS

Transkript

1 2 Evaluation und Auswahl von EMS 2.1 Einleitung Für die Bezeichnung von betriebswirtschaftlich-administrativer Standardanwendungssoftware sind in der Literatur sehr unterschiedliche Begriffe 11 (z.b. ERP, EMS oder IBSIS) zu finden. 12 Im folgenden Kapitel werden die Eigenschaften solcher Systeme (Vor- und Nachteile) beschrieben und eine Begriffsabgrenzung vorgenommen. Der zweite Teil dieses Kapitels setzt sich mit Auswahlkriterien und Informationsbeschaffungsmöglichkeiten für die Evaluation von solchen Systemen auseinander. Dabei wird ein grober Überblick über die aktuell auf dem Markt befindlichen Systeme gegeben und mögliche Alternativen zum Einsatz von Enterprise-Management-Systemen (EMS) diskutiert. 2.2 Enterprise-Management-Systeme (EMS) Standardsoftware Der Begriff "Standardsoftware" (SSW) stammt aus dem Marketingumfeld und war während langer Zeit in den einschlägigen Begriffsnormen nicht zu finden. 13 Dessen unklare Bedeutung 14 wurde erst im Verlaufe der achtziger Jahre konkreter beschrieben. 15 Zwei Definitionen, welche das heutige Verständnis von Standardsoftware im betrieblichen Umfeld recht gut umschreiben, werden im folgenden wiedergegeben Vgl. z.b. Barbitsch (1996), S. 9; Vgl. Barbitsch (1996), S. 13. Vgl. Ludewig (1994), S. 4. Vgl. Horváth/Petsch/Weihe (1983), S. 6. Vgl. Heinrich/Roithmayr (1986), S. 383; Horváth/Petsch/Weihe (1983), S. 4f.; Mertens et al. (1990), S. 400 ff.; Österle (1990a), S. 15. Vgl. Ludewig (1994), S. 4 ff.; Stahlknecht (1995), S. 312 ff. 7

2 Ludewig definiert Standardsoftware als "komplexe Anwendungssoftware, die ein Hersteller für den Markt entwickelt und anbietet, ein Anbieter kauft, anpasst oder häufiger vom Hersteller anpassen lässt und einführt. Die Anpassung kann auf verschiedene Weise erfolgen; lassen sich kleine Software-Systeme schon durch Parametrisierung oder durch gezielte Eingriffe an definierten Schnittstellen adaptieren, so wird sie bei grösseren Systemen kaum ohne erhebliche Eingriffe in die Software zu erreichen sein. Der Anwender muss sich umgekehrt auch der Software anpassen. Anpassung und Wartung werden um so aufwendiger, je mehr "freie" Eingriffe in der Software nötig sind, also Änderungen an Stellen, die nicht speziell dafür gemacht waren. Der Einsatz einer Standard-Software macht den Anwender wegen des Wartungsbedarfs für lange Zeit sehr abhängig vom Hersteller." 17 Mertens versteht unter Standardsoftware "Computerprogramme ("Standardprogramme"), die eine definierte Funktion, d.h. eine genau beschriebene Problemlösung übernehmen, generell, d.h. für unterschiedliche Hardware bzw. Betriebssysteme sowie weitgehend branchenunabhängig einsetzbar sind, in der Regel zu einem Festpreis angeboten werden und sich mit geringem, zeitlich und finanziell fixierbarem Aufwand organisatorisch anpassen lassen." 18 Anhand der Definitionen wird deutlich, dass bei der Beschreibung des Begriffs "Standardsoftware" verschiedenste Dimensionen berücksichtigt werden müssen. Grundsätzlich wird Standardsoftware für einen anonymen Markt entwickelt und lässt sich weitgehend branchen- und plattformunabhängig einsetzen. Die Preise sind im voraus festgelegt und hängen meist von der Anzahl Nutzer und bei modularisierten Systemen in der Regel auch vom funktionalen Nutzungsgrad ab. Den unterschiedlichen Bedürfnissen der Anwender wird durch vielfältige Anpassungmöglichkeiten (Customizing) Rechnung Vgl. Ludewig (1994) S. 8. Vgl. Mertens (1990), S

3 getragen. Ferner wird davon ausgegangen, dass sich der Anwender ebenfalls in einem gewissen Grad an die durch die erworbenen Produkte vorgegebenen Abläufe anpasst. Unter Berücksichtigung dieser Aspekte wird der Begriff "Standardsoftware" in dieser Arbeit wie folgt definiert: Definition: Unter Standardsoftware sind komplexe Anwendungssysteme zu verstehen, die für den anonymen Markt entwickelt werden und sich weitgehend branchen- und plattformunabhängig verwenden lassen. Das Einsatzgebiet bezieht sich entweder auf einen oder mehrere Funktionsbereiche eines Unternehmens. Beim Erwerb solcher Systeme gilt in der Regel ein aufgrund der Benutzerzahl und des Nutzungsumfangs angesetzter Festpreis. Die Integration von Standardsoftware kann sowohl durch Abstimmung des Anwendungspaketes auf die Unternehmensprozesse (Customizing) als auch durch Anpassung der betrieblichen Organisation an das erworbene Produkt erfolgen. Die Einsatzgebiete von Standardsoftware lassen sich grundsätzlich in die Bereiche Systemsoftware mathematisch-technische Anwendungssoftware und betriebswirtschaftlich-administrative Anwendungssoftware unterteilen. 19 Zur Systemsoftware werden u.a. Betriebssysteme (z.b. Unix oder Windows NT) und Datenbanksysteme (z.b. Oracle) gezählt. Mathematisch-technische Anwendungssoftware umfassen vor allem auf mathematischen und statistischen Methoden basierende Softwarepakete des technisch-wissenschaftlichen Anwendungsbereichs (z.b. CAD-Systeme, Baustatik-Systeme oder Optimierungspakete). Das Einsatzgebiet der betriebswirtschaftlich-administrativen Anwendungssoftware bezieht sich auf die klassischen betrieblichen Funktionsbereiche wie z.b. Finanz- und Rechnungswesen, Personalwesen, Beschaffung, Produktion und Vertrieb. Im den folgenden Ausführungen ist der Begriff "Standardsoftware" immer unter dem Hintergrund von betriebswirtschaftlich-administrativer Anwendungssoftware zu verstehen. 19 Vgl. Mertens (1990), S

4 2.2.2 Merkmale von EMS Enterprise-Management-Systeme richten sich in ihrem Wesen grundsätzlich nach dem im vorangegangenen Unterkapitel für Standardsoftware im betriebswirtschaftlichadministrativen Umfeld dargestellten Begriffsverständnis. Darüber hinaus verfügen solche Systeme aber über zusätzliche gemeinsame Merkmale 20, welche vor einer eigentlichen Begriffsdefinition näher betrachtet werden sollen. Integration EMS decken die administrativen Funktionen (Finanz- und Rechnungswesen, Beschaffung, Produktion, Vertrieb und Personalwesen) eines Unternehmens breit ab und orientieren sich an durchgängigen Geschäftsprozessen. Alle Anwendungsbereiche verfügen über die gleiche Datenbasis. Dadurch kann eine redundante Datenhaltung weitgehend verhindert und die Datenkonsistenz in hohem Masse gewährleistet werden. Ferner erfolgt die Integration auch in vertikaler Richtung, indem sämtliche Führungsebenen (von der Unternehmensleitung bis zum Sachbearbeiter) bei der Informationsverarbeitung berücksichtigt werden. Auf der Ebene der Führung findet ebenfalls eine Integration statt. Die verschiedenen Aktivitäten während des Führungsprozesses auf strategischer und operativer Ebene (Planung, Durchführung und Kontrolle) werden durch EMS unterstützt. 21 Flexibilität Die Flexibilität eines EMS bezieht sich grundsätzlich auf die Anpassungsfähigkeit eines Systems in technischer und betriebswirtschaftlicher Sicht. In technischer Hinsicht lassen sich EMS meist auf mehreren Hardwarewareplattformen und Betriebssystemen einsetzen. Durch die generelle Orientierung an den Prinzipien von Client/Server-Architekturen und durch die Unterstützung offener Standards (z.b. CORBA, COM oder DCE) entstehen umfangreiche Skalierungsmöglichkeiten Vgl. Barbitsch (1996), S. 3 f.; Buck-Emden/Galimow (1995), S. 88; CDI (1996b), S. 21 ff. Vgl. Österle (1990a), S

5 Auf betriebswirtschaftlicher Ebene bieten EMS zur Abdeckung von Geschäftsprozessen meist verschiedene Alternativen an. Die Anpassung (Customizing) erfolgt dabei entweder durch Parametersetzung oder durch Eingriffe an definierten Schnittstellen. In Ausnahmefällen können sogar Veränderungen am Source Code vornehmen. Im letztgenannten Fall erhöht sich aber der Wartungsaufwand (Releasewechsel) in erheblichem Umfang. Internationalität Durch die Globalisierung der Märkte operieren viele grössere Unternehmen im internationalen Umfeld. Zur Abdeckung der damit verbundenen Bedürfnisse unterstützen EMS meist mehrere Sprachen und erfüllen die gesetzlichen Anforderungen der wichtigsten Industriestaaten. Verbunden mit der organisatorischen Flexibilität (Abbildung von komplexen Unternehmensstrukturen) eignen sich EMS für den Einsatz in international tätigen Konzernen. Die oben dargestellten Hauptmerkmale stellen zusammen mit den im vorangehenden Unterkapitel beschriebenen Grundeigenschaften von Standardsoftware die wesentlichen Kennzeichen von EMS dar. Daraus lässt sich folgende Definition für Enterprise- Management-Systeme ableiten: Definition: Enterprise-Management-Systeme (EMS) decken sämtliche betriebswirtschaftlichen Anwendungsbereiche eines Unternehmens (Finanzwesen, Logistik und Personalwesen) ab und verbinden diese durch eine gemeinsame Datenbasis. Durch die Ausrichtung auf die Grundprinzipien von Client/Server-Architekturen (Portabilität, Offenheit, Skalierbarkeit) lassen sich EMS in technischer Hinsicht beliebig an unternehmensspezifische Bedürfnisse anpassen. Auf betriebswirtschaftlicher Ebene findet eine Anpassung (Customizing) durch Parametrisierung und ggf. durch Eingriffe an definierten Schnittstellen statt. In der Regel erfolgt parallel zur Anpassung des Systems eine Annäherung der Unternehmensorganisation an die Prozessvorgaben des EMS (Business Process Reengineering). Durch das Vorhandensein verschiedener Landesversionen (Erfüllung der gesetzlichen Vorschriften des jeweiligen Landes) und die Unterstützung mehrerer Sprachen lassen sich EMS auch in international tätigen Unternehmen einsetzen. 11

6 Alternativ zum Begriff "Enterprise-Management-System" sind in der Literatur eine Vielzahl weiterer Begriffe für solche Systeme anzutreffen. 22 In Tab. 2-1 sind die am häufigsten verwendeten Bezeichnungen angegeben. Deutscher Sprachraum Integrierte betriebswirtschaftliche Standardsoftware Betriebswirtschaftliche Anwendungssoftware Betriebswirtschaftliches (Standard-)anwendungen/ Standardpakete/Lösungen Integrierte betriebliche Standardinformationssysteme (IBSIS) Betriebswirtschaftlich-administrative Anwendungssoftware Englischer Sprachraum Enterprise Resource Planning Systems (ERP) Enterprise Applications (EA) Packaged Applications Packaged Client/Server Applications Business Software Solutions Enterprise-Wide Client/Server Software Tab. 2-1: Alternative Begriffe für Enterprise-Management-Systeme. Einige Beispiele für Enterprise-Management-Systeme sind SAP R/3, Baan IV, Oracle Applications, SSA BPCS, Marcam Prism, JDEdwards OneWorld, Peoplesoft Solutions oder CA-PRMS. All diesen Systemen sind die oben genannten Merkmale in unterschiedlicher Ausprägung gemeinsam. In Kap wird eine Marktübersicht über solche Systeme gegeben Vor- und Nachteile von EMS Der Einsatz von Enterprise-Management-Systemen ist im Vergleich zur Entwicklung von Individualsoftware mit wesentlichen Vorteilen verbunden. Gleichzeitig sind aber auch Einschänkungen zu machen, welche bei der Evaluation von EMS berücksichtigt werden müssen. Tab. 2-2 gibt einen Überblick über die in der Literatur erwähnten Vor- und Nachteile von EMS Vgl. z.b. Barbitsch (1996), S. 9; Horváth/Petsch/Weihe (1983), S. 6; Keller (1995). Vgl. dazu Adler (1990), S. 163; Barbitsch (1996), S. 13 ff.; Blume (1997), S. 16 ff.; Buck-Emden/ Galimow (1995), S. 22 ff.; Engels/Gresch/Nottenkämpfer (1996), S. 22 ff.; Gronau (1996), S. 13 ff.; Horváth/Petsch/Weihe (1983), S. 7 f.; Keller/Teufel (1997), S. 68 ff.; Kirchmer (1996), S. 14 f.; Knolmayer (1995a); Ludewig (1994), S. 1 ff.; Österle (1990a), S. 21 ff.; Stahlknecht (1995), S f.; Scheer/Berkau/Kraemer (1990), S. 93 ff. 12

7 Vorteile von EMS EMS bieten eine Vielzahl von Prozessvarianten und ermöglichen dadurch die Abdeckung aktueller und künftiger Anforderungen (Höhere Flexibilität). Die von einem EMS unterstützten Prozesse können als "Best in Practice" bezeichnet werden, da bei der Entwicklung die Erfahrungen sehr vieler Anwender eingeflossen sind (Zukauf von org. Know-how). Horizontale und vertikale Integration ist weitgehend gewährleistet. Meist höhere Softwarequalität durch Praxiserprobung und höheres Know-how bei der Softwareentwicklung. Schnellere Verfügbarkeit und somit kürzere Einführungsdauer. In der Regel bestehen Kostenvorteile beim Einsatz von EMS und die Einführungskosten sind durch Festpreise besser kalkulierbar. Weiterentwicklung und Wartung sind weitgehend gewährleistet (Zukunftssicherheit). Schnittstellenproblematik ist durch hohen Integrationsgrad weniger gravierend. Erfahrungsaustausch mit andern Anwendern (User Groups) lässt das Risiko kalkulierbarer werden. Die Nutzung neuer Technologien ist durch die auf dem Markt für EMS herrschende Konkurrenz schneller gewährleistet (Innovationsdruck). Auf dem Markt sind erfahrene Experten zu finden (Diese müssen nicht zuerst ausgebildet werden). Grosses Schulungsangebot auf dem Markt (höhere Qualität der Schulung, Einsatz von CBT-Software). Unternehmensübergreifender Datenaustausch wird durch weitgehende Standardisierung (z.b. EDIFACT) vereinfacht. Bessere Softwareergonomie durch die Verwendung einheitlicher grafischer Benutzeroberflächen. Integration mit Produkten anderer Hersteller durch die Verwendung von standardisierten Schnittstellen besser gewährleistet (z.b. DCOM oder CORBA). SSW ist in der Regel besser dokumentiert und dadurch ist die Verständlichkeit besser gewährleistet. Auf dem Markt ist eine Vielzahl von Zusatzliteratur vorhanden. Datenschutz und Datensicherheit sind in hohem Masse gewährleistet Durch Fremdbezug werden Personalressourcen in den IV-Abteilungen freigesetzt (Verringerung des Anwendungsstaus, Konzentration auf Probleme, welche nicht mit EMS gelöst werden können) Nachteile von EMS Kritische Unternehmensprozesse (Core Processes) lassen sich unter Umständen nicht "optimal" in der SSW abbilden und müssen angepasst werden. Strategische Differenzierung gegenüber Wettbewerbern entfällt. Gefahr der Gleichmacherei bei Prozessen in verschiedenen Unternehmungen unter Vernachlässigung betriebsindividueller Besonderheiten durch mangelnde Übereinstimmung der vom EMS angebotenen Funktionalität mit den betrieblichen Gegebenheiten. Durch EMS erzwungene Änderungen der Geschäftsprozesse können erheblich sein und sind meist schwer absehbar (Chance + Gefahr). EMS hat viel überflüssige Funktionalität (Hindernis für schlanke Einführung). Akzeptanzprobleme in den IV-Abteilungen durch das Obsoletwerden bisheriger Kenntnisse (Verlust von internem IV-Know-how, Rollenänderung) Release-Politik des Softwareanbieters ist wenig transparent und vielfach muss mit Verzögerungen von angekündigten Versionen gerechnet werden. Die Nutzung neu verfügbar gewordener Funktionen kann mit dem Zwang zum Release-Wechsel des gesamten Systems verbunden sein. Starke Abhängigkeit vom Anbieter durch mangelnde Transparenz der Standardsoftware. Der Quellcode ist häufig nicht verfügbar. Verschwenderischer Umgang mit Hardwareressourcen durch eine Vielzahl von ungenutzten Funktionen (generell höherer Ressourcenbedarf). Schnittstellen zu veralteter Individual- oder Standardsoftware sind oftmals schwierig realisierbar. Tab. 2-2: Vor- und Nachteile von Enterprise-Management-Systemen. 13

8 Die dargestellten Merkmale können nicht in jedem Fall als allgemein gültig betrachtet werden. Die betriebsspezifische Situation muss bei der Auswahl und Gewichtung dieser Faktoren unbedingt mitberücksichtigt werden Der Markt für Enterprise-Management-Systeme Der Markt von Enterprise-Management-Systemen wurde 1995 auf rund 4 Mia. USD geschätzt. 24 Bei Betrachtung der Marktentwicklung lässt sich eine Wachstumsrate zwischen 30% und 40% feststellen. In einer Studie von AMR (Advanced Manufacturing Research) wurde geschätzt, dass das Marktvolumen im Jahr 2000 über 15 Mia USD betragen werde. 25 Diese Zahlen beziehen sich nur auf die verkauften Softwarelizenz- und Wartungsverträge. Darüber hinaus ist anzunehmen, dass die Nebenleistungen (Hardwareverkäufe, Schulung und Beratungsdienstleistungen) die Basis-Werte um ein Mehrfaches übersteigen werden. 26 Da die einzelnen Produkte teilweise sehr unterschiedliche Bedürfnisse abdecken, lässt sich der Markt für EMS nicht eindeutig abgrenzen. Einerseits sind die verschiedenen Hersteller generell bestrebt, ihre Produkte auf eine möglichst grosse potentielle Kundengruppe auszurichten. Andererseits kann ein EMS unmöglich alle branchenspezifischen Merkmale in einem internationalen Umfeld abdecken und gleichzeitig auch für KMUs geeignet sein. Daher muss der Markt für EMS differenziert betrachtet werden. Als Gliederungsmerkmale können u.a. Unternehmensgrösse, Branchenzugehörigkeit und der Grad der internationalen Ausrichtung herangezogen werden George (1996). Shepard (1996). Vgl. AFOS (1996), S. 36; vgl. dazu auch Kapitel

9 Wird beispielsweise der weltweite Markt von EMS im Industriesektor für das Jahr 1995 betrachtet, ist eine klare Dominanz von SAP festzustellen (vgl. Abb. 2-1). Wird dagegen z.b. nur die Automobilindustrie betrachtet, erscheint in diesem Kundensegment SSA mit BPCS als Marktführer. 27 Dieser Vergleich soll verdeutlichen, dass über die Marktanteile auf dem EMS-Markt je nach Sichtweise sehr unterschiedlich sind und die dargestellten Vergleiche in der Regel nur für sehr grosse, über mehrere Branchen vertretene und international tätige Unternehmen repräsentativ sind. Marktanteile von 27 EMS-Herstellern 1995 im Industriesektor (weltweit) Other 19% Peoplesoft 3% Oracle 5% SAP 34% JDE 5% Marcam 5% Baan 7% SSA 9% CA 13% Quelle: AMR 1996 Abb. 2-1: Marktanteile von EMS-Herstellern im Industriesektor Vgl. George (1996). 15

10 High Rebuild J.D. Edwards Remain SAP R/3 American Software SSA BPCS C/S Functionality Marcam non-oot CA-PRMS Cincom JBA QAD Baan Datalogix Ross CA-MMX WDS Fourth Shift MDIS JIT Symix SCT Oracle Avalon DBS Spectrum Marcam Protector Low SSA DOCA Low Review Reinforce High Technology Quelle: Gartner Group (1995) Abb. 2-2: Die Positionierung verschiedener Anbieter von EMS In einer von der Gartner Group veröffentlichten Gegenüberstellung verschiedener EMS 28 im Hinblick auf die vorhandene Funktionalität und die dem EMS zugrundeliegende Technologie entsteht ein vergleichbares Bild (vgl. Abb. 2-2). SAP R/3 nimmt hier ebenfalls die Führungsposition ein. Aber auch diese Einschätzungen beziehen sich vor allem auf sehr grosse, international tätige Konzerne; häufig wird allerdings eher die Mittelstandsfähigkeit von SAP R/3 als seine Konzernfähigkeit in Frage gestellt. 29 Bei der Evaluation mag zwar die Markposition des Anbieters eine gewisse Rolle spielen, dennoch sollte bei der Entscheidfindung primär die Abdeckung der unternehmensspezifischen Bedürfnisse im Vordergrund stehen. Da sich eine EMS-Einführung, wie bereits darauf hingewiesen wurde (vgl. Tab. 2-2), nur mit grossem Aufwand wieder rückgängig machen lässt und hohe Kosten verursacht, wird in der Regel nach einer Vorselektion, Vgl. Keller (1995). Vgl. Hufgard (1995), S

11 welche die generelle Eignung der auf dem Markt befindlichen Produkte überprüft, eine detaillierte Evaluation von maximal 3 Produkten empfohlen. 30 Bevor sich ein Unternehmen für den Einsatz eines EMS entscheidet, sollten alternative Lösungen geprüft und gegebenenfalls in die Betrachtungen einbezogen werden. Denkbar ist dabei die Entwicklung von Individualsoftware oder die Verwendung von Component Ware als Basis für den Bau von integrierten Systemen. Beide Alternativen werden im folgenden Abschnitt ausführlich diskutiert Alternativen zum Einsatz von EMS Individualsoftware Durch die Entwicklung von Individualsoftware können die Bedürfnisse eines Unternehmens exakt abgebildet werden. Verbesserte Softwareentwicklungsmethoden und -werkzeuge (CASE-Tools, Repositories, objektorientierte Programmiersprachen) ermöglichen die Realisierung von Kosten- und Zeiteinsparungen im Entwicklungsprozess. Die gesamten Entwicklungskosten liessen sich in der Vergangenheit durch die Verwendung der genannten Methoden und Werkzeuge nur geringfügig reduzieren, da die finanziellen Aufwendungen für die Programmierung in Grossprojekten nur ca % ausmachen. Die Hauptvorteile bei der Verwendung von modernen Softwarenetwicklungsmethoden und -werkzeugen gegenüber herkömmlichen Vorgehensweisen liegen vor allem bei der besseren Beherrschbarkeit der Komplexität von Entwicklungsprojekten. 31 Durch die Dynamik der Märkte und die Geschwindigkeit der technischen Entwicklung werden die Entwickler ständig mit neuen Anforderungen konfrontiert. Der damit verbundene Wartungsaufwand von existierenden Anwendungssystemen ist erheblich und bindet einen Grossteil der vorhandenen Entwicklungsressourcen. Für Neuentwicklungen stehen zunehmend weniger personelle Ressourcen zur Verfügung. Dies führt mit der Zeit zu einem schwer überwindbaren Anwendungsstau Vgl. Brenner (1990), S. 13. Vgl. Österle (1990a), S. 27. Vgl. Füller/Thomae (1990), S. 39; Hüttenhain (1990), S

12 Für die Entwicklung von komplexen Anwendungssystemen mit vergleichbarem Leistungsumfang, Integrationsgrad und entsprechender Qualität, wie sie heute von Standardsoftware geboten wird, muss mit einer Entwicklungsdauer von 5-10 Jahren gerechnet werden. 33 Während dieser Zeit müssen die Anforderungen durch die Dynamik im betrieblichen Umfeld ständig angepasst und erweitert werden. Dieser Umstand erhöht die Entwicklungsdauer zusätzlich. Dem steht die relativ kurze Einführungszeit von EMS (in der Regel 1-2 Jahre) gegenüber. Hohe Entwicklungskosten, fehlende personelle Ressourcen und lange Entwicklungszeiten sind die wesentlichsten Nachteile von Individualsoftware. Weitere Vor- und Nachteile von Individuallösungen können Tab. 2-1 entnommen werden. Der Hauptvorteil von Individuallösungen liegt in der Erlangung von Wettbewerbsvorteilen durch Verwendung von einzigartigen und speziell auf das Unternehmen zugeschnittenen Anwendungssystemen. Dieser Aspekt spricht stark für die Entwicklung von Individuallösungen. Können solche Potentiale durch den vorhandenen Anwendungsstau nicht genutzt werden, gehen Wettbewerbsvorteile verloren und die Konkurrenzfähigkeit wird geschwächt. Werden hingegen die für die Weiterentwicklung von administrativen Systemen notwendigen Entwickler durch die Beschaffung eines EMS freigesetzt, können diese Ressourcen für strategisch wichtige und standardmässig nicht lösbare Aufgaben eingesetzt werden. 34 Moderne EMS decken die betrieblichen Anforderungen in den Anwendungsfeldern des Rechnungs- und Personalwesens in hohem Masse ab. Selbst im Bereich der Produktion und Logistik sind heutige EMS in den meisten Fällen in der Lage, alle erforderlichen Funktionen für die Beschaffung, die Fertigung und den Vertrieb zu unterstützen, so dass sich auch in diesem, in der Vergangenheit eher durch Individualsoftware geprägten Anwendungsbereich Standardsoftware einsetzen lässt. 35 Ist die funktionale Abdeckung gegeben und werden die bereits erwähnten Vorteile Einführungsgeschwindigkeit, geringere Kosten und höhere Flexibilität in die Betrachtungen Vgl. Österle (1990a), S. 23. Vgl. z.b. Kirchmer (1996), S. 14; Mertens/Knolmayer (1995), S. 32 f.; Österle (1990a), S 22 ff. Vgl. z.b. Losbichler (1988), S

13 einbezogen, fällt die Beantwortung der "Make-or-Buy"-Frage 36 ist in den meisten Fällen zugunsten des EMS-Einsatzes eindeutig aus Component Ware Das Prinzip der Verwendung einzelner Softwarebausteine (Component Ware) bei der Anwendungskomposition entstammt der Objektorientierten Programmierung (OOP). Die Wiederverwendbarkeit stellt eines der Grundprinzipien der OOP dar. 37 Die einzelnen Softwarebausteine sollen nach der Idee der Object Management Group (OMG) in Form von Objekten an einer Börse gehandelt werden und für die Anwendungsentwicklung zur Verfügung gestellt werden. Die Vertreter dieses Ansatzes erhoffen sich dadurch eine erhebliche Verkürzung der Entwicklungszeiten. 38 In der Literatur besteht keine einheitliche Auffassung bezüglich des angemessenen Umfangs einzelner Anwendungskomponenten. Das Spektrum reicht von einfachen Softwarebausteinen ohne betriebswirtschaftliche Logik (z.b. Objektbibliotheken zur Oberflächensteuerung) bis hin zu komplexen Anwendungskomponenten in Form von vollständigen Business Objekten 39 Kreditwürdigkeitsprüfung). (z.b. für die Offerterstellung, Kundenbestellung oder Eines der Grundprinzipien der Component-Ware-Architektur ist die Wiederverwendbarkeit der Anwendungskomponenten. 40 Das ComponentWare Consortium schlägt vor, zur Gewährleistung der Wiederverwendbarkeit folgende Bedingungen einzuhalten: 41 Unabhängigkeit von einem Object Framework (z.b. COM, CORBA, OpenDoc) Plattformunabhängigkeit auf Client- und auf Server-Ebene Sprach- und Werkzeugunabhängigkeit Gewährleistung von Datenrobustheit und Performance Vgl. z.b. Mertens/Knolmayer (1995), S. 31 ff. Vgl. Udell (1994), S. 46. Vgl. Froitzheim (1994), S Dodd (1994), S. 7. (Dodd definiert Business Objekte wie folgt: "A business object is a software unit that corresponds to a real world entity from the user's domain." ) Vgl. Keller/Teufel (1997), S. 64 f. Vgl. ComponentWare Consortium (1995). 19

14 Gewährleistung unternehmensübergreifender Wiederverwendbarkeit. Neben das Kriterium der Wiederverwendbarkeit treten zusätzlich die Kriterien Anpassbarkeit und Erweiterbarkeit. 42 Der Anpassbarkeit sind insofern Grenzen gesetzt, als Modifikationen nicht vollständig frei vorgenommen werden können, sondern sich diese nach dem vom Hersteller bereitgestellten Beziehungswissen richten sollen. Bei der Erweiterung von Anwendungskomponenten gilt es zu berücksichtigen, dass die Konsistenz des Gesamtprozessmodells nicht gefährdet werden sollte. Zur technischen Realisierung des Component-Ware-Konzepts schlägt die Object Management Group die in Abb. 2-3 beispielhaft dargestellte Grundarchitektur vor. Framework-Komponenten (z.b. CORBA 43 ) stellen die Drehscheibe zwischen den Client- Applikationen und den RDBMS-Komponenten (Application Components) dar. Die zusätzliche Schicht ermöglicht die Loskoppelung zwischen den Desktop-Application und den RDBMS-Applikations-Komponenten. Dadurch können die einzelnen Komponenten unabhängig voneinander ausgetauscht werden. Der Object Request Broker (ORB) übernimmt dabei eigentliche Vermittler- und Transportfunktion. Die Verbindung zwischen den Framework-Komponenten und dem ORB wird durch spezifische APIs (Application Programming Interfaces) hergestellt Vgl. Keller/Teufel (1997), S. 65 f. CORBA = Common Object Request Broker Architecture. 20

15 Desktop Applications C++ APP. CW Framework Component CORBA Application Component CW RDBMS Enterprise RDBMS OTHER SYBASE ORACLE OBJECT REQUEST BROKER Naming Persistence Transaction Event Object Services Common Facilities Abb. 2-3: Component-Ware-Architektur der OMG. Ein Beispiel für die Umsetzung des Component-Ware-Prinzips stellt das von der Universität Erlangen mit wissenbasierenden Ansätzen entwickelte Produktionsplanungssystem GEPRODEX dar. Die Entwicklung der PPS-Funktionalitäten erfolgte bei diesem Anwendungsbeispiel auf der Basis von Microsoft-Standardanwendungskomponenten (insbes. MS-Project, MS-Excel, MS-Access). Die in den einzelnen Softwarebausteinen enthaltenen Funktionen werden gezielt durch Visual-Basic-Komponenten erweitert und an die Bedürfnisse der Produktionsplanung angepasst. Durch die Verwendung von Standardanwendungskomponenten, welche sich bereits tausendfach auf dem Markt bewährt haben und bei den Endanwendern ausreichend bekannt sind, ist mit einer geringeren Fehleranfälligkeit und kürzeren Einführungszeiten zu rechnen Vgl. Möhle et al. (1996), S. 30 ff. 21

16 MS- Excel MS- Project PPS-System Visual Basic MS- Access MS- Exchange Abb. 2-4: Beispiel für ein auf dem Component-Ware-Prinzip basierendes PPS-System. Ein weiteres Beispiel für die Umsetzung des Component-Ware-Prinzips auf der Grundlage von Business Objekten stellt das Business Framework der SAP dar. Die bereitgestellten Business Objekte (z.b. Kundenbestellung oder Stellenbewerbung) werden von einem Business Object Repository (BOR) verwaltet und kommunizieren über sogenannte Business Application Programming Interfaces (BAPIs). Die einzelnen Business Objekte können nach dem "Lego-Prinizp" zu ganzen Applikationen z.b. für den Bereich des Electronic Commerce oder für die Unterstützung des Workflow Managements erstellt werden. 22

17 R/3 Anwendungen, SAP Business Workflow CORBA Client Visual Basic, MS-Excel, MS Project,... CORBA COM DCOM Object Bridge DCOM Component Connector R/3 Anwendungen B r o k e r BAPI BAPI BAPI BAPI BAPI Business Object Repository Material Internet Explorer, Netscape,... HTML Internet Transaction Server R/3 Datenbank Lieferanten- auftrag Bedarfs- anforderung Java- Anwendungen Java Java Component Connector Abb. 2-5: Business Framework der SAP. 45 Einige Autoren 46 sprechen bereits bei der Integration von herstellerfremden Softwarebausteinen in bestehende EMS von der Anwendung des Component-Ware-Prinzips. Im R/3-Umfeld stellen Drittanbieter eine grosse Zahl von Add-Ons (z.b. Archivierungsoder Zeiterfassungssysteme) zur Ergänzung von einzelnen Funktionen des R/3-Systems bereit (vgl. Abb. 2-6). Durch Hinzufügen von weiteren Softwarekomponenten soll ein besser auf die Anwenderbedürfnisse zugeschnittenes Informationssystem entstehen. Teilweise werden solche Add-Ons vom Hersteller zu einem späteren Zeitpunkt in ein EMS übernommen Vgl. SAP AG (1996e), S. 19. Vgl. dazu Froitzhein (1994), S. 188 ff.; Udell (1994), S

18 BDE BDE EDI EDI BOR R/3 Zeitwirtschaft Zeitwirtschaft Zugangskontrolle Zugangskontrolle Reise kostenabrechnung kosten- Reise abrechnung Electronic Banking Electronic Banking CAD CAD Abb. 2-6: Anwendungsbereiche von Add-On-Produkten für das R/3-System. 47 In anderen Bereichen (z.b. bei Textverarbeitungssystemen) ist es ebenfalls möglich durch die Objekt-Technologie einzelne Anwendungskomponenten (z.b. den Formeleditor) durch andere Komponenten zu ersetzen. Die sich durch Component Ware eröffnenden Möglichkeiten sind sehr vielfältig und bieten insbesondere beim Customizing von grösseren Anwendungssystemen entscheidende Vorteile durch die rasche Verfügbarkeit und die bessere Robustheit der am Markt erhältlichen Zusatzkomponenten. Für die Realisierbarkeit der Entwicklung von komplexen Anwendungssystemen nach dem "Lego-Prinzip" sind allerdings einige Fragezeichen zu setzen. Es ist zu befürchten, dass solche Vorhaben an den gleichen Problemen scheitern werden wie der Versuch der Integration von getrennt entwickelten Anwendungssystemen Ein Überblick über Add-on-Produkte für SAP R/3 ist unter den WWW-Adressen oder zu finden. Vgl. Meinhardt/Teufel (1995), S

19 2.3 Auswahl von EMS Vorgehen Die Einführung eines EMS ist meist nur mit grossem Aufwand wieder rückgängig zu machen. Einer sorgfältigen Auswahl des zu beschaffenden System kommt deswegen erhebliche Bedeutung zu. Der Auswahlprozess erfolgt in der Regel anhand eines mehrstufigen Verfahrens (vgl. Abb. 2-7), welches durch den Projektauftrag ausgelöst wird. Auf der Grundlage einer Ist-Analyse und der daraus resultierenden Schwachstellenanalyse wird ein Soll-Konzept erstellt. Basierend auf dem Sollkonzept werden für das Anforderungsprofil Muss-Kriterien (K.O.-Kriterien) formuliert. Anhand dieser Kriterien wird eine Vorselektion getroffen und die Auswahl auf wenige Produkte (z.b. drei 49 ) eingeschränkt. Die Bewertung der noch übrig gebliebenen Produkte kann anhand der restlichen Kriterien (Kann-Kriterien) durch die Anwendung entscheidtheoretischer Verfahren (z.b. Nutzwertanalyse) erfolgen. Nach Auswahl des EMS sind Projektauftrag und Zielsetzungen zu überprüfen und gegebenenfalls anzupassen. Zielformulierung Rahmenbedingungen Projektauftrag Kriterienkatalog Leistungsumfang EMS, Konzeption des EMS, Anwendererfahrungen, Stellung des Lieferanten, Wirtschaftlichkeitsbetrachtung, etc. Erhebungstechniken, Darstellungstechniken Ermittlung von Mängeln und Ursachen Darstellungstechniken (z.b. ERM und EPK) Grad der Detaillierung ist unterschiedlich Ist- Analyse Schwachstellenanalyse Soll- Konzept Nutzwertanalyse Auswahl Überprüfung Projektauftrag/ Zielsetzungen Abb. 2-7: Auswahlverfahren von EMS. 49 Vgl. Brenner (1990), S

20 2.3.2 Ist-Analyse und Soll-Konzept Die Art und Weise der Erstellung eines Soll-Konzepts ist in der Literatur umstritten. 50 Einige Autoren 51 empfehlen die Anwendung des gleichen Vorgehens wie bei der Softwareentwicklung (Detaillierte Analyse der Ist-Situation, Ableitung eines Soll-Konzepts, Erstellung eines Pflichtenhefts). SAP hingegen empfiehlt ihren Kunden, auf eine detaillierte Ist-Analyse zu verzichten und schlägt vor, die Anforderungen an das System aufgrund der vorhandenen Referenzmodelle festzulegen. 52 Diese Vorgehensweise setzt allerdings voraus, dass der Systementscheid bereits gefallen ist. Grundlage für ein Projekt stellt der Projektauftrag dar. Darin werden Projektbezeichnung, Zielsetzungen, Inhalt des Anwendungssystems und Rahmenbedingungen für die Projektdurchführung festgelegt. Durch eine einfache und möglichst treffende Projektbezeichnung wird dem Vorhaben eine eindeutige Identität gegeben. Die Formulierung von Zielsetzungen verdeutlicht Zweck eines Projektes. Zielsetzungen in Zusammenhang mit Informatikprojekten beziehen sich häufig auf Kosteneinsparungen, eine Erhöhung der Durchlaufzeiten, Verbesserung der Kundenserviceleistungen oder Produktequalität etc. Anhand einer fachlichen Abgrenzung werden in groben Zügen die betrieblichen Funktionen beschrieben, welche durch das neue Anwendungssystem abgedeckt werden sollen. Ferner werden alle für das Projekt relevanten Rahmenbedingungen (z.b. Einbezug von Beratungsunternehmen, Projektdauer, Berichterstattung, verfügbare personelle und finanzielle Ressourcen, Kompetenzen des Projektleiters) festgehalten. Die Grundlage für die Erstellung des Soll-Konzepts stellen die Ergebnisse der Ist-Analyse dar. Das Ziel der Ist-Analyse ist die Aufnahme und Bewertung der vorhandenen Abläufe (Geschäftsprozesse) und der damit verbundenen Daten. 53 Der Detaillierungsgrad der Ist-Analyse hängt im wesentlichen vom Ausmass der beabsichtigten organisatorischen und technischen Änderungen während der Einführung eines EMS ab. Von einer reinen Automatisierung ohne Veränderung der betrieblichen Ablauforganisation ist erfahrungs Vgl. Stahlknecht (1995), S Vgl. z.b. Losbichler (1988), S. 90; Stahlknecht (1995), S Vgl. Vaske (1996), S. 7. Vgl. Stahlknecht (1995), S

21 gemäss eher abzuraten. 54 Alternativ dazu wird die Anpassung der Organisation im Rahmen der EMS-Einführung der reinen Automatisierung vorgezogen. Bezüglich der Wahl der Anpassungsstrategien herrscht keine einheitliche Auffassung. Während die Anhänger des Business Process Reengineering (BPR) quantensprungartige Verbesserung von Geschäftsprozessen 55 fordern, ziehen die Verfechter des Continous System Reengineering (CSE) kurzfristige Verbesserungen in kleinen Schritten vor 56 (vgl. Abb. 2-8). Während beim CSE behauptet wird, dass durch ständige Anpassung des EMS eine bessere Übereinstimmung zwischen Betriebsorganisation und Informationsverarbeitung 57 erreicht werden kann, sind die Anhänger des BPR der Auffassung, dass Verbesserungen nur durch eine radikale Änderung der Organisation 58 realisiert werden können. Informationsund Organisations- Qualität CSE Ausgangslage Heute BPR Zeit Abb. 2-8: Continous System Engineering vs. Business Process Reengineering. Diese beiden Denkansätze setzen auch unterschiedliche Auffassungen bezüglich der Durchführung einer Ist-Analyse voraus. Während beim BPR gefordert wird, dass die Ablauforganisation weitgehend unabhängig von der Ist-Situation neu entworfen werden Vgl. Buxmann/König (1997), S Vgl. Brenner/Keller (1995), S. 27; Hammer/Stanton (1995), S. 3. Thome/Hufgard (1996), S. 79 f. Thome/Hufgard (1996), S. 83 f. Hammer/Champy (1994), S. 49 f. 27

22 soll, 59 wird beim CSE die Bedeutung der Ist-Analyse nicht grundsätzlich in Frage gestellt. 60 SAP empfiehlt ihren Kunden die Ist-Analyse wie auch das Soll-Konzept nicht zu detaillieren, sondern für die Festlegung der notwendigen Funktionen das vom Hersteller zur Verfügung Referenzmodell zu nutzen. 61 Aber auch diese Empfehlung ist kritisch zu betrachten, da für die anforderungsgerechte Festlegung der zu nutzenden Funktionen eine detaillierte Kenntnis der betrieblichen Abläufe vorausgesetzt werden muss. 62 Für und gegen die Durchführung einer detaillierten Ist-Analyse sprechen viele einleuchtende Argumente. Ungeachtet dieser Diskussion wird im folgenden kurz dargestellt, wie eine Ist-Analyse im Zusammenhang mit einer EMS-Einführung aussehen könnte. In der Literatur lässt sich zum Beispiel folgender Vorschlag finden: 63 Beschreibung der Arbeitsabläufe (mit zeitlichem Ablauf und beteiligten Stellen) Entstehung, Verwendung und Mengengerüst aller relevanten Daten Schnittstellen zu internen und externen Stellen sowie bei der Prozessabwicklung anfallenden Kosten. Im Zentrum der Ist-Analyse steht die Darstellung der betrieblichen Prozesse und der mit einem Prozess verbundenen Organisationseinheiten. Diese können beispielsweise anhand verschiedener "W-Fragen" beschrieben werden. Am Beispiel der Nachbestellung eines Lagerartikels könnte diese Prozessbeschreibung wie folgt aussehen: 64 W-Frage Antwort W-Frage Antwort Wer? Abteilung Einkauf Wozu? Nachbestellung An Wen? Lieferanten Wann? Falls Meldebestand erreicht Was? Lagerartikel Wie? Schriftliche Bestellung Tab. 2-3: Prozessbeschreibung der Nachbestellung eines Lagerartikels Davenport/Stoddard (1994), S. 122 f. Thome/Hufgard (1996), S. 20. Stahlknecht (1995), S Thome/Hufgard (1996), S. 20. Stahlknecht (1995), S. 254 ff. Stahlknecht (1995), S

23 Ein weiterer Kernbereich der Ist-Analyse stellt die Beschreibung der relevanten Daten dar. Dabei wird die Frage gestellt, welche Daten für die Durchführung eines Prozesse notwendig sind und welche Daten allenfalls bei der Durchführung eines Prozesses erzeugt werden. In diesem Zusammenhang stellt sich auch die Frage nach dem Mengengerüst, d.h. über die Menge der benötigten resp. erzeugten Daten. Diese Angaben sind insbesondere für die Dimensionierung der Rechenleistung, des Massenspeichers und der Kommunikationsleitungen massgebend. Zusätzlich zu Ermittlung der Prozesse und der Daten sind die von einem Prozess tangierten internen (z.b. Abteilung Rechnungswesen) und externen Schnittstellen (z.b. Lieferant) betreffend Datenaustausch und bei der Abwicklung eines Prozesses entstehenden Kosten zu erfassen. Für die Erfassung und Beschreibung der Ist-Situation können verschiedene Erhebungsund Darstellungstechniken zum Einsatz kommen. Die wichtigsten Techniken zur Erhebung des Ist-Zustandes sind 65 Unterlagenstudium Fragebogen Interview Konferenz Beobachtung und Selbstaufschreibung. Für die Darstellung der vorhandenen Geschäftsprozesse und der damit verbundenen Daten sind ebenfalls die verschiedensten Techniken einsetzbar. Grundsätzlich können verbale tabellarische oder grafische 65 Vgl. Schmidt (1991), S. 116 ff.; Stahlknecht (1995), S. 259 f. 29

24 Beschreibungswerkzeuge eingesetzt werden. 66 Einige Beispiele für heute gebräuchliche Darstellungstechniken aus dem Umfeld der Informationsverarbeitung sind: Entity-Relationship-Modell 67 (ERM Structured Analysis 68 (SA) Structured Analysis and Design Technique 69 (SADT) Hierarchy of Input-Process-Output 70 (HIPO) Petri-Netze 71 Object Modeling Technique 72 (OMT) Ereignisgesteuerte Prozessketten 73 (EPK). Neben den IT-basierten Darstellungstechniken können eine grosse Zahl BWL-orientierter Methoden zur Aufgaben- und Aufbauorganisationsbeschreibung herangezogen werden. 74 Darunter fallen z.b. Organigramme Stellenbeschreibungen Kommunikationsdiagramme Belegflussdiagramme oder GANTT-Diagramme (Balkendiagramme). Die genannten Methoden stellen eine Auswahl möglicher Darstellungstechniken für die betrieblichen Prozesse und die Aufbauorganisation dar. Bei der Einführung von EMS (z.b. SAP R/3) wird häufig die Methode der Ereignisgesteuerten Prozessketten 75 verwendet Vgl. Keller/Teufel (1997), S. 137 ff.; Stahlknecht (1995), S. 261 ff. Chen (1976), S De Marco (1978), S Marca/McGowan (1988), S Stevens/Myers/Constantine (1974), S. 115 ff. Petri (1962). Rumbaugh (1991), S. 21 ff. ASAP World Consultancy/Blain, S. 94 ff.; Keller/Teufel (1997), S. 158 ff.; Scheer (1995), S. 49 ff. Vgl. z.b. Keller/Teufel (1997), S. 145 ff.; Schmidt (1991), S. 263 ff. Vgl. Kap

25 Parallel zur Erfassung des Ist-Zustandes erfolgt die Ermittlung der existierenden Mängel in der vorhandenen Ablauforganisation. Im Rahmen einer nachfolgend durchgeführten Schwachstellenanalyse müssen die Ursachen dieser Mängel bestimmt und die daraus resultierenden Folgeschäden quantifiziert werden. Beispiele für Mängel sind durch ein mangelhaftes Mahnwesen verursachte hohe Debitorenausstände. Die sich daraus ergebenden Schäden sind Liquiditätsengpässe und damit verbunden die Notwendigkeit der Beschaffung von teurem Fremdkapital (z.b. Bankkredite) zur Überwindung dieser Engpässe. Durch Erfassung und Bewertung der Schwachstellen wird die Möglichkeit geschaffen, die festgestellten Mängel bei der Festlegung des Soll-Konzepts zu beseitigen. Das Soll-Konzept legt auf der Basis der ermittelten Bedürfnisse und Schwachstellen sowie aufgrund der erkennbaren Potentiale des aktuellen Entwicklungsstandes der Informationstechnologie die Anforderungen an das neue System fest. Zusätzlich zur Anforderungsdefinition werden die Wirtschaftlichkeit des aktuellen und des geplanten Zustandes verglichen. Der Übergang von der Analyse der Ist-Situation zum Soll-Konzept ist eine schwierige Aufgabe. 76 Für die Ableitung der Anforderungen sind verschiedene Vorgehensweisen denkbar: Ableitung eines auf eigenen Überlegungen basierenden Sollkonzepts (Einsatz von Kreativitätstechniken). Ableitung eines auf allgemeinem Erfahrungswissen basierenden Sollkonzepts (Einsatz von branchenspezifischen Referenzmodellen). Ableitung eines Sollkonzepts auf der Basis eines produktbezogenen Referenzmodells (z.b. R/3-Referenzmodell). 76 Vgl. Thome/Hufgard (1996), S

26 Das erstgenannte Verfahren bietet zwar den Vorteil, dass unternehmensspezifische Merkmale meist besser berücksichtigt und damit Wettbewerbsvorteile erhalten oder neu dazu gewonnen werden können. Gleichzeitig verbirgt sich hinter dieser Vorgehensweise ein enormer Aufwand und es besteht die Gefahr der Zementierung der vorgedachten Prozesse. EMS decken die aufwendig erarbeiteten Soll-Prozesse meist in anderer Form ab, so dass der in den kreativen Prozess investierte Aufwand obsolet wird. Bei der Verwendung von branchenspezifischen Referenzmodellen für die Anforderungsdefinition kann ein Grossteil des durch den kreativen Gestaltungsprozesses verursachten Aufwandes eingespart werden. Der Abdeckungsgrad mit der Funktionalität der am Markt erhältlichen EMS wird durch die Verwendung von standardisierten Prozessen erheblich grösser sein. Allerdings wird die Chance zur strategischen Differenzierung durch die Angleichung der Geschäftsprozesse an branchenübliche Vorgehensweisen vertan. Die Ableitung des Anforderungskatalogs aufgrund eines produktspezifischen Referenzmodells garantiert bei der Einführung den geringsten Anpassungsaufwand. Allerdings ist diese Vorgehensweise als Grundlage für die Evaluation mehrerer Produkte wenig sinnvoll, da die zu wählende Alternative präjudiziert wird. Dieses Vorgehen kommt eigentlich nur bei der strategischen Auswahl einer Produktefamilie zur Ermittlung des Funktionsabdeckungsgrades in Frage. Ein Anforderungskatalog für die Evaluation von EMS orientiert sich primär an den formulierten Zielsetzungen und kann die in Tab. 2-4 dargestellten Kriterien umfassen. Damit eine Vorselektion von EMS möglich ist, wird zwischen Muss- (K.O.-) und Kann- Kriterien unterschieden. Der Kriterienkatalog umfasst neben fachlichen, technischen und wirtschaftlichen Anforderungen auch Erfordernisse, welche sich auf die Eigenschaften des Lieferanten beziehen. Für die Evaluation von EMS ist der Beizug externer Berater lohnenswert. Die Bewertung der in die Betrachtungen einbezogenen Systeme erfolgt aufgrund dieses Kriterienkatalogs. Für die Auswahl des am besten geeignetsten Produkts wird häufig die Nutzwertanalyse eingesetzt. 32

27 Kriterienkatalog zur Auswahl von EMS Leistungsumfang Daten, Funktionen Integrationsgrad Anpassungaufwand Schnittstellen zu anderen Anwendungen Konzeption des EMS Basisarchitektur (Portabilität, Offenheit, Skalierbarkeit) Systemvoraussetzungen Erfüllung bestimmter Softwarestandards Benutzerfreundlichkeit Antwortzeitverhalten Dokumentation (Benutzerdokumentation, technische Dokumentation) Weitere Softwarekomponenten (Data Dictionary, Referenzmodelle, Einführungsunterstützungswerkzeuge, Office-Komponenten etc. Erfahrungen von Anwendern Fachliche Erfahrungen Branchenbezogene Erfahrungen Länderbezogene Erfahrungen Herstellerbezogene Erfahrungen Lieferant Stellung des Lieferanten am Markt Qualifikation der Mitarbeiter des Lieferanten Branchenerfahrung geographische Nähe Vertragsbedingungen, Garantien Zusatzleistungen des Anbieters (Beratung, Schulung etc.) Kosten/Nutzen-Relation Anschaffungskosten (Lizenzen) Einführungskosten Hardwarekosten Betriebs- und Wartungskosten Tab. 2-4: Kriterien zur Auswahl von EMS Informationsbeschaffung zur Evaluation von EMS Für die Informationsbeschaffung zur Evaluation von EMS steht eine Vielzahl von Informationsquellen zur Verfügung. Diese eignen sich aufgrund ihrer Sichtweise und aufgrund des Detaillierungsgrades in unterschiedlichem Ausmass zur Wissensgewinnung in den verschiedenen Phasen des Evaluationsprozesses. Darüber hinaus wurden in den letzten Jahren die Informationsbeschaffungsmöglichkeiten durch die starke Ausdehnung elektronischer Medien (insbes. Internet) grundlegend verändert. Tab. 2-5 zeigt eine Auswahl verschiedener Informationsquellen für die Evaluation von EMS und bewertet diese nach Eignung für die verschiedenen Phasen des Evaluationsprozesses. 77 Vgl. z.b. Brenner (1990), S. 15 ff.; Horváth/Petsch/Weihe (1983), S. 12 ff.; Stahlknecht (1995), S

28 Informationsquellen Produktsuche Vorselektion Produktbeurteilung Softwarekataloge (z.b. ISIS-Report) Fachzeitschriften Messen (z.b. CeBIT) World Wide Web / Compuserve Konferenzen/Seminare/Tagungen Fachliteratur Herstellerinformationen (Informationsmaterial) Beratungsunternehmen Marktforschungsinstitute (z.b. Gartner Group) Universitäten (Fallstudien, empirische Studien) Erfahrungsberichte von Anwendern (Usergroups) Testinstallation ungeeignet Tab. 2-5: Mögliche Informationsquellen zur Auswahl von EMS. 78 teilweise geeignet gut geeignet Zur Produktsuche bieten sich Verzeichnisse in Software-Katalogen 79, Marktübersichten in Fachzeitschriften 80 oder von Marktforschungsunternehmungen an. Die dabei gewonnen Information haben einen sehr geringen Detaillierungsgrad und geben nur groben Hinweise auf die allfällige Eignung eines Produktes im konkreten Anwendungsfall. Die Produktsuche auf dem World Wide Web (WWW) ist grundsätzlich auch möglich. Mit Hilfe von Search Engines können alle über das Internet ansprechbaren WWW- Server nach bestimmten Inhalten durchsucht werden. Da die Präsenz der einzelnen IV-Anbieter auf dem Internet relativ gross ist, können mit einer seriösen Recherche viele für eine Evaluation von EMS in Frage kommende Produkte ausfindig gemacht werden. 81 Tab. 2-6 zeigt ist eine Auswahl verschiedener Search Engines für die Suche nach bestimmten Begriffen auf dem Internet. Die einzelnen Search Engines unterscheiden sich In Anlehnung an Horvàth/Petsch/Weihe (1983), S. 15. Vgl. Nomina Information Services (1995a-c). Vgl. z.b. Chen/Geitner (1993), S. 52 ff. Vgl. Knolmayer (1996a); Knolmayer (1996b); Knolmayer (1996c). 34

29 hauptsächlich nach dem bereitgestellten Datenvolumen und den Suchmechanismen. Die Bedienung ist relativ einfach und in einigen Fällen ausführlich dokumentiert. Internet Search Engines Name WWW-Adresse Besonderes Merkmal Alta Vista - Lycos - Hotbot - WebCrawler - Yahoo! Kategorisierte Auflistung der Einträge Infoseek Ultra - Excite - Cyber Parallele Suche auf mehreren Search Engines DejaNews Suche in News-Archiven (Newsgroups) Lycos (CH,D,A) Server mit Extensionen ch, de, at Tab. 2-6: Internet Search Engines. Mehrere Suchbegriffe können durch boolsche Verknüpfungsopertoren (AND, OR, NOT) kombiniert werden (z.b. ERP AND "Market Share") und erlauben so eine Präzisierung der gesuchten Informationen. Bei der Wahl der Suchbegriffe müssen verschiedene Überlegungen angestellt werden. Meistens existieren für einen Suchbegriff (z.b. Integrierte betriebswirtschaftliche Standardsoftware) verschiedene Synonyme 82 (z.b. Betriebswirtschaftliche Anwendungssoftware) nach welchen ebenfalls gesucht werden sollte. Bei Akronymen (z.b. ERP) und mehrdeutig verwendeten Begriffen (z.b. Sun) besteht darüber hinaus das Problem von Homonymen 83. Die Ergebnisse einer Suche sind in solchen Fällen durchmischt mit Fundstellen, welche in einem völlig anderen Zusammenhang stehen Vgl. dazu Tab Vgl. dazu Abb. 2-3; Beispiel: Anstelle von Enterprise Management Systems steht dieses Akronym auch für Begriffe wie Eligibility Review Program, Event-Related Potential, Evoked Response Potential etc. Vgl. Knolmayer (1996), S. 87 ff. 35

30 Ferner muss bei der Auswahl von Suchbegriffen die für das entsprechende Fachgebiet am meisten verbreitete Sprache verwendet werden. In den Publikationen zur Themen der Wirtschaftsinformatik dominiert auf dem Internet die englische Sprache. Aus diesem Grund sind bei der Suche nach englischen Suchbegriffen die meisten Fundstellen zu erwarten. Eine weiterer Aspekt stellt das Problem der Aktualität der durch Search Engines ermittelten Informationen dar. Durch die Dynamik im Internet und durch den Time Lag der Informationsbereitstellung auf Search Engines ist es wahrscheinlich, dass einzelne Fundstellen zum Zeitpunkt der Recherche gar nicht mehr aufrufbar sind. Ausserdem besteht das Problem der Aktualität der Informationen. Auf schlecht gewarteten Web Servern befinden sich häufig inhaltlich überholte Informationen. 85 Abb. 2-9: Ergebnisse einer Internet-Recherche mit Hotbot nach dem Suchbegriff 'ERP'. 85 Vgl. Knolmayer/Buchberger (1997). 36