Lade Inhalt...

Potenziale, Risiken und Grenzen von Software-as-a-Service aus Anwendersicht am Beispiel von SAP Business ByDesign

©2012 Diplomarbeit 79 Seiten

Zusammenfassung

Inhaltsangabe:Einleitung:
Die Bereitstellung abstrahierter und skalierbarer IT-Infrastrukturen über Netzwerke, bekannt als ‘Cloud Computing’, gewinnt zunehmend an Bedeutung. Aus einer Umfrage des Marktforschungsunternehmens Gartner geht hervor, dass Cloud Computing von Führungskräften der IT-Branche als wichtigstes Technologiethema des Jahres 2011 bewertet wurde. Man gehe von einer sehr viel schnelleren Adoption der neuen Technologien aus, als ursprünglich angenommen. Gaben heute nur drei Prozent der Führungskräfte an, den Großteil ihrer IT in der Cloud zu betreiben, erwarte man einen Anstieg auf über 40 Prozent innerhalb der nächsten vier Jahre.
Sollten die Prognosen eintreffen, wird das Servicemodell ‘Software-as-a-Service’ (SaaS, auch ‘On-Demand-Software’) eine besondere Rolle spielen, weil es im Gegensatz zu den systemnahen Cloud Computing-Modellen ‘Infrastructure-as-a-Service’ und ‘Platform-as-a-Service’ nicht vor dem Anwender verborgen bleibt und damit die Gestaltung von Geschäftsprozessen direkt beeinflusst.
Sieht man sich das Portfolio verfügbarer SaaS-Lösungen an, ist dort eine positive Entwicklung bezüglich der Produktvielfalt erkennbar. Während bis vor kurzem ausschließlich Software für betriebswirtschaftlich klar abgrenzbare oder hochstandardisierte Teilbereiche wie etwa CRM oder Personalwirtschaft angeboten wurde, sind nun auch für komplexere Anwendungstypen potentielle Alternativen in der ‘Cloud’ verfügbar. Nach mehrjähriger Verzögerung bietet die SAP AG seit Mitte 2010 das bereits für 2008 angekündigte Produkt ‘Business ByDesign’ an. Das System wurde als Untersuchungsgegenstand für diese Arbeit ausgewählt, weil es vom Marktführer für ERP-Software in Deutschland stammt und für kleine und mittelständische Unternehmen eine der ersten vollwertigen Alternativen zu lokalen Installationen, sogenannter ‘On-Premise-Software’, darstellen könnte.
1.1, Zielstellung und Einordnung in den wissenschaftlichen Kontext:
Ziel dieser Arbeit ist es, durch eine exemplarische Untersuchung von SAP Business ByDesign die Potentiale aktuell verfügbarer, komplexer On-Demand-Lösungen im Bereich ERP-Software aufzuzeigen. Gleichzeitig wird analysiert, wo die Grenzen für das Modell Software-as-a-Service liegen und welche Risiken beim Einsatz entsprechender Produkte zu erwarten sind.
Zwar existieren innerhalb des Arbeitsgebiets ‘Softwarearchitektur/Verteilte Systeme’ bereits wissenschaftliche Untersuchungen bezüglich Chancen und Risiken des Cloud Computings , […]

Leseprobe

Inhaltsverzeichnis


Inhalt

I. Abbildungsverzeichnis

II. Tabellenverzeichnis

III. Abkürzungsverzeichnis

1. Einleitung
1.1 Zielstellung und Einordnung in den wissenschaftlichen Kontext
1.2 Abgrenzung
1.3 Aufbau der Arbeit

2. Grundlagen und Begriffsklärung
2.1 Cloud Computing
2.1.1 Definition und Abgrenzung zu anderen Technologien
2.1.2 Servicemodelle
2.1.2.1 Infrastruktur (IaaS)
2.1.2.2 Plattform (PaaS)
2.1.2.3 Anwendung (SaaS)
2.1.3 Einsatzmodelle
2.2 ERP-Systeme
2.2.1 Definition
2.2.2 SAP
2.2.2.1 Unternehmen
2.2.2.2 Produkt “Business ByDesign”

3. Potenziale des Modells “Software-as-a-Service”
3.1 Prozessuale Aspekte
3.1.1 Komplexitätsreduktion durch Standardisierung von Geschäftsprozessen
3.1.2 Leichte Erweiterbarkeit
3.1.3 Standortunabhängigkeit und Mobilität
3.2 Technische Aspekte
3.2.1 Aktualität und Qualität
3.2.2 Verfügbarkeit
3.2.3 Benutzerfreundlichkeit
3.3 Wirtschaftliche Aspekte
3.3.1 Skalierbarkeit
3.3.2 Niedrigere Gesamtkosten

4. Risiken und Grenzen des Modells „Software-as-a-Service“
4.1 Prozessuale Aspekte
4.1.1 Eingeschränkte Personalisierung
4.1.2 Funktionsumfang
4.2 Technische Aspekte
4.2.1 Interoperabilität
4.2.2 Sicherheit
4.3 Wirtschaftliche Aspekte
4.3.1 Firmengrößen
4.3.2 Abhängigkeit vom Servicegeber

5. Fazit und Ausblick

IV. Literaturquellen

V. Internetquellen

VI. Ehrenwörtliche Erklärung

I. Abbildungsverzeichnis

Abb. 1: Vergleich Single- mit Multi-Tenancy-Architektur

Abb. 2: Cloud Computing-Schichtenmodell

Abb. 3: Architektur der PaaS-Plattform Force.com

Abb. 4: Funktionsbereiche von SAP Business ByDesign

Abb. 5: „Scoping“: Auswahl des Lösungsumfang mit dem Business-Konfigurator

Abb. 6: Konzept des SAP Stores

Abb. 7: SAP Business ByDesign auf mobilen Endgeräten

Abb. 8: Welche Serviceverfügbarkeit sichern Sie Ihren Kunden vertraglich zu?

Abb. 9: Work Center „Kundenaufträge“

Abb. 10: Hinzufügen des neuen Felds „Kundenstatus“ im Anpassungsmodus

Abb. 11: Beispielprozess: Vom ersten Kundenkontakt bis zur Zahlungsabwicklung

Abb. 12: Klassifizierung von Services in SAP Business ByDesign

Abb. 13: Standardzugriff auf SAP Business ByDesign

Abb. 14: Public und Private Clouds – Gesamtkosten in Abhängigkeit von Firmengrößen

Abb. 15: Architektur von SAP Business ByDesign

II. Tabellenverzeichnis

Tab. 1: Preismodell für SAP Business ByDesign, Stand 01.12.2011

Tab. 2: Total Cost of Ownership über 7 Jahre (Beträge in Tausend Dollar)

III. Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Die Bereitstellung abstrahierter und skalierbarer IT-Infrastrukturen über Netzwerke, bekannt als „Cloud Computing“, gewinnt zunehmend an Bedeutung. Aus einer Umfrage des Marktforschungsunternehmens Gartner geht hervor, dass Cloud Computing von Führungskräften der IT-Branche als wichtigstes Technologiethema des Jahres 2011 bewertet wurde. Man gehe von einer sehr viel schnelleren Adoption der neuen Technologien aus, als ursprünglich angenommen. Gaben heute nur drei Prozent der Führungskräfte an, den Großteil ihrer IT in der Cloud zu betreiben, erwarte man einen Anstieg auf über 40 Prozent innerhalb der nächsten vier Jahre[1].

Sollten die Prognosen eintreffen, wird das Servicemodell „Software-as-a-Service“ (SaaS, auch „On-Demand-Software“) eine besondere Rolle spielen, weil es im Gegensatz zu den systemnahen Cloud Computing-Modellen „Infrastructure-as-a-Service“ und „Platform-as-a-Service“ nicht vor dem Anwender verborgen bleibt und damit die Gestaltung von Geschäftsprozessen direkt beeinflusst.

Sieht man sich das Portfolio verfügbarer SaaS-Lösungen an, ist dort eine positive Entwicklung bezüglich der Produktvielfalt erkennbar. Während bis vor kurzem ausschließlich Software für betriebswirtschaftlich klar abgrenzbare oder hochstandardisierte Teilbereiche wie etwa CRM oder Personalwirtschaft angeboten wurde, sind nun auch für komplexere Anwendungstypen potentielle Alternativen in der „Cloud“ verfügbar. Nach mehrjähriger Verzögerung bietet die SAP AG seit Mitte 2010 das bereits für 2008 angekündigte Produkt „Business ByDesign“ an. Das System wurde als Untersuchungsgegenstand für diese Arbeit ausgewählt, weil es vom Marktführer für ERP-Software in Deutschland stammt und für kleine und mittelständische Unternehmen eine der ersten vollwertigen Alternativen zu lokalen Installationen, sogenannter „On-Premise-Software“, darstellen könnte.

1.1 Zielstellung und Einordnung in den wissenschaftlichen Kontext

Ziel dieser Arbeit ist es, durch eine exemplarische Untersuchung von SAP Business ByDesign die Potentiale aktuell verfügbarer, komplexer On-Demand-Lösungen im Bereich ERP-Software aufzuzeigen. Gleichzeitig wird analysiert, wo die Grenzen für das Modell Software-as-a-Service liegen und welche Risiken beim Einsatz entsprechender Produkte zu erwarten sind.

Zwar existieren innerhalb des Arbeitsgebiets „Softwarearchitektur/Verteilte Systeme“ bereits wissenschaftliche Untersuchungen bezüglich Chancen und Risiken des Cloud Computings[2], dabei wird aber nicht detailliert auf ERP-Software eingegangen. Andere wissenschaftliche Arbeiten, die eher der Teildisziplin „Betriebliche Informationssysteme“ zuzuordnen sind, konzentrieren sich stärker auf ERP-Produkte in der Cloud. Sie beschränken sich aber auf die Analyse von Produkten, die sich vorwiegend an Kleinunternehmen richten, weil ein komplexes Produkt wie SAP Business ByDesign zum Zeitpunkt der Untersuchung noch nicht zur Verfügung stand[3]. Standardwerke zu SAP Business ByDesign wiederum gehen auf das Produkt, nicht aber objektiv auf das „as-a-Service“-Paradigma und die damit verbundenen Vor- und Nachteile ein. Das Thema dieser Arbeit ist deshalb interdisziplinär angelegt, betrifft sowohl den Bereich „Softwarearchitektur/Verteilte Systeme“, als auch die Teildisziplin „Betriebliche Informationssysteme“ der Wirtschaftsinformatik.

Um die sehr umfängliche Fragestellung in angemessener Form beantworten zu können, wird im Vorfeld eine klare Abgrenzung des Themas vorgenommen.

1.2 Abgrenzung

Die Betrachtung erfolgt ausschließlich aus Sicht des Servicenehmers, d. h. des Kunden. Beziehung innerhalb des Software-Ecosystems, z. B. zwischen SAP, Distributionspartnern und Lieferanten von Komplementärprodukten sind nicht Gegenstand der Untersuchung.

Die Analyse beschränkt sich außerdem auf technische, prozessuale und betriebswirtschaftliche Aspekte, juristische Aspekte sind von der Betrachtung ausgeschlossen[4]. Die Arbeit erhebt keinen Anspruch auf Vollständigkeit, es werden vielmehr die aus Anwendersicht wichtigsten Aspekte aufgegriffen und detailliert untersucht.

1.3 Aufbau der Arbeit

Im Kapitel „Grundlagen“ wird der Begriff „Cloud Computing“ definiert, außerdem werden die derzeit verfügbaren Modelle für den Bezug von Cloud-Services vorgestellt. Das Kapitel „ERP-Systeme“ enthält neben einer allgemeinen Definition des Begriffs „ERP-System“ auch ein Firmenprofil der SAP, sowie einen Überblick über das Produkt „Business ByDesign“, das Gegenstand der folgenden Untersuchungen sein wird.

Die Untersuchungsergebnisse werden in den Kapiteln „Potenziale“ bzw. „Risiken und Grenzen“ vorgestellt, pro Aspekt findet sich ein Kapitel auf der dritten Gliederungsebene. Zwecks Übersichtlichkeit wurde vom Autor eine Kategorisierung nach prozessualen, technischen und wirtschaftlichen Aspekten vorgenommen. In den Kapiteln wird zunächst der theoretische Hintergrund des jeweiligen Aspekts erörtert und welche Rolle ihm innerhalb des „as-a-Service“-Paradigmas zukommt, es folgt dann eine konkrete Analyse in Bezug auf „Business ByDesign“.

2. Grundlagen und Begriffsklärung

In den folgenden Kapiteln werden die Grundlagen für das Verständnis dieser Arbeit vermittelt. Neben einer Einführung in die Themenbereiche „Cloud Computing“ und „ERP“, erfolgt eine genaue Definition und Abgrenzung von Begrifflichkeiten.

2.1 Cloud Computing

2.1.1 Definition und Abgrenzung zu anderen Technologien

Für den Begriff „Cloud Computing“[5] gibt es derzeit keine einheitliche Definition, jedoch existieren mehrere Definitonsansätze. Laut Analyst James Staten von Forrester Research ist „Cloud Computing“ ein

„Pool aus abstrahierter, hochskalierbarer und verwalteter IT-Infrastruktur, die Kundenanwendungen vorhält und nach Verbrauch abgerechnet wird“[6].

Gartner fasst den Begriff etwas weiter und beschreibt die neue Technologie als das

„Bereitstellen skalierbarer IT-Services über das Internet für eine potentiell große Zahl externer Kunden“[7].

Am häufigsten zitiert wird die 2009 veröffentlichte Definition der US-amerikanischen Standardisierungsstelle NIST (National Institute for Standards and Technology).

"Cloud Computing ist ein Modell, das es erlaubt bei Bedarf, jederzeit und überall bequem über ein Netz auf einen geteilten Pool von konfigurierbaren Rechnerressourcen (z. B. Netze, Server, Speichersysteme, Anwendungen und Dienste) zuzugreifen, die schnell und mit minimalem Managementaufwand oder geringer Serviceprovider-Interaktion zur Verfügung gestellt werden können."[8]

Die Definition des NIST ist in wissenschaftlichen Fachkreisen weitestgehend akzeptiert und wird deshalb als Grundlage für die vorliegende Arbeit dienen. Sie enthält neben der Erläuterung des Begriffs „Cloud Computing“ auch eine Beschreibung möglicher Einsatzmodelle und der drei Servicemodelle, die zu einem De-Facto-Standard für die Kategorisierung von Cloud-Services geworden sind und auf die in den gleichnamigen Kapiteln detailliert eingegangen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Vergleich Single- mit Multi-Tenancy-Architektur

(Quelle: itwissen.info)

Häufig wird Cloud Computing als „alter Wein in neuen Schläuchen“ betitelt, weil es starke Parallelen zu dem in den 90ern propagierten ASP („Application Service Providing“) aufweist, das sich am Markt nie durchsetzen konnte. Während die Idee beim klassischen ASP jedoch das schlichte Outsourcing von lizenzierter Software und die Bereitstellung derselben über das Internet war, geht Cloud Computing einen Schritt weiter. Eine sog. „Multi-Tenancy-Architektur“ ermöglicht es mehreren Kunden auf einer einzigen Plattform und mit der gleichen Software zu arbeiten, pro Kunde wird jeweils eine virtuelle Instanz der Software erzeugt (Abb. 1). Hierdurch entfällt die beim ASP notwendige Installation eines dedizierten Servers pro Kunde und man profitiert von Skaleneffekten (vgl. Kapitel „Skalierbarkeit“).

Cloud Computing weist ebenfalls einige Gemeinsamkeiten mit dem in der Wissenschaft zum Einsatz kommenden „Grid Computing“ auf. Neben den deutlich unterschiedlichen Geschäftsmodellen – Cloud Computing ist kommerziell ausgerichtet, Grid Computing wird überwiegend durch staatliche Förderungen zu Forschungszwecken finanziert – existieren auch technische Unterschiede, wie etwa die fehlende zentrale Kontrollinstanz beim Grid Computing[9].

2.1.2 Servicemodelle

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Cloud Computing-Schichtenmodell

(Quelle: cloudlist.de)

Cloud Computing stellt Dienstleistungen auf drei verschiedenen Schichten (auch „Service-“ oder „Bezugsmodelle“ genannt) zur Verfügung: „Infrastructure-as-a-Service“, „Platform-as-a-Service“ und „Software-as-a-Service“. Die Schichten bilden in Bezug auf den Abstraktionsgrad eine Hierarchie, angefangen bei Infrastructure-as-a-Service (kurz: IaaS) auf der untersten Abstraktionsebene, über PaaS, bis hin zu SaaS (siehe Abb. 2). Es existieren Erweiterungen des Modells um XaaS-Schichten[10], auf die in dieser Arbeit nicht näher eingegangen wird, weil sie nicht standardisiert sind und in der Definition des NIST nicht vorkommen.

Obwohl sich die Schichten in der Theorie klar voneinander abgrenzen lassen, werden sie in der Praxis häufig kombiniert angeboten und präsentieren sich so dem Anwender gegenüber wie eine einzige Lösung. Auf eine exakte Abgrenzung soll an dieser Stelle dennoch nicht verzichtet werden.

2.1.2.1 Infrastruktur (IaaS)

Infrastructure-as-a-Service bezeichnet die Bereitstellung virtueller Computerinfrastruktur, wie etwa Rechenleistung oder Speicherkapazität, als Service. Auf den angemieteten Ressourcen können Kunden beliebige Betriebssysteme oder Anwendungen laufen lassen. Die im Kapitel 2.1.1 beschriebene Multi-Tenancy-Architektur ermöglicht dabei eine Skalierung entsprechend des aktuellen Bedarfs. Für einmalig oder selten ausgeführte Software muss so keine zusätzliche Hardware angeschafft werden, es ist außerdem möglich Bedarfsspitzen kurzfristig durch das temporäre Zuschalten von Recheninstanzen abzudecken.

Einer der bekanntesten Anbieter von IaaS-Services ist Amazon.com. Das Handelsunternehmen „muss IT-Ressourcen in einem erheblichen Umfang vorhalten, der sich am saisonalen Spitzenaufkommen – zur Weihnachtszeit und zum Erntedankfest, dem amerikanischen Thanksgiving Day – orientiert. Ein Großteil dieser Ressourcen liegt im Jahresverlauf jedoch brach. So entstand die Geschäftsidee, die freien Ressourcen gegen Entgelt in Zeiten schwacher Nutzung dritten zur Verfügung zu stellen.“[11]. Unter dem Namen „Amazon Web Services“ werden deshalb zahlreiche Dienste, wie etwa die „Amazon Elastic Computing Cloud“ (kurz „EC2“), zur Bereitstellung von Rechenleistung, oder der „Amazon Simple Storage Service“ (kurz „S3“) vermarktet. Die Dienste sind voll integriert, so lassen sich z. B. die für EC2 erstellten Recheninstanzen in S3 speichern.

2.1.2.2 Plattform (PaaS)

Unter Platform-as-a-Service werden Services zusammengefasst, die Laufzeit- und/oder Entwicklungsumgebungen zur Verfügung stellen und sich in erster Linie an Entwickler für Web-Anwendungen richten. Im Gegensatz zu IaaS ist es nicht möglich, direkten Einfluß auf die Recheninstanzen zu nehmen. Der Entwickler bringt lediglich die Programmlogik ein und kann die Verarbeitung indirekt durch Parametrisierung der Laufzeitumgebung beeinflussen. Der administrative Aufwand liegt somit beim PaaS-Provider, was auf Kundenseite den Entwicklungsprozess vereinfachen und beschleunigen soll.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Architektur der PaaS-Plattform Force.com

(Quelle: Adaptiert von force.com)

Häufig sind es Anbieter von Software-as-a-Service (siehe folgendes Kapitel), die auch PaaS-Lösungen im Portfolio haben. Sieht man sich prominente Anbieter wie Salesforce.com an, wird schnell deutlich, warum das so ist: Um es Kunden zu ermöglichen, die CRM-Lösung Salesforce.com mit hauseigenen Apps oder den Add-Ons von Partnern zu erweitern, war es nötig eine Programmierschnittstelle zur Verfügung zu stellen. Hierfür wurde die Plattform Force.com geschaffen, die man auch Drittanbietern für die Entwicklung unabhängiger Anwendungen zugänglich machte[12]. Ein weiteres bekanntes Beispiel sind die Microsoft .NET-Services, die eine Entwicklung von Drittanbieter-Anwendungen für Microsofts Laufzeitumgebung „Windows Azure“ ermöglichen, auf der auch eigene Produkte wie etwa eine Office-Lösung oder Dynamics CRM gehostet werden.

2.1.2.3 Anwendung (SaaS)

Beim Bezugsmodell Software-as-a-Service stellt der Service-Provider standardisierte Anwendungen über das Internet zur Verfügung. Im Gegensatz zu „On Premise“-Produkten ist auf Kundenseite keine Installation von Software notwendig, abgesehen von einem Webbrowser, über den in der Regel auf SaaS-Anwendungen zugegriffen wird. Der Service-Provider stellt die Infrastruktur zur Verfügung, kontrolliert die Recheninstanzen und übernimmt außerdem jegliche Updates und Wartungsarbeiten für den Kunden. Dieser kann mit vergleichsweise geringem Aufwand die Software entsprechend seinen Bedürfnissen konfigurieren. Dem Kunden werden keine Software-Lizenzen berechnet, stattdessen fallen nutzungsabhängige Gebühren an, man spricht deshalb auch von „Mietsoftware“. Je nach Preismodell wird z. B. nach Anzahl der Benutzer, Funktionsumfang, Dauer der Nutzung, Anzahl der Transaktionen oder einer Kombination der genannten Faktoren abgerechnet.

Bei den meisten Technologien lässt sich beobachten, dass sie zuerst in Unternehmen zum Einsatz kommen und später, ausgereift und zu erschwinglichen Preisen, auf dem Verbrauchermarkt angeboten werden. Bei Software-as-a-Service vollzieht sich ein Trend in die entgegengesetzte Richtung: Während für Privatanwender die Nutzung von SaaS-Lösungen wie flickr von Yahoo, Microsofts virtueller Festplatte SkyDrive oder Google Maps bereits zu einer Selbstverständlichkeit geworden ist, haben die Unternehmen erst begonnen zu reagieren.

Als Pionier für Software-as-a-Service-Produkte gilt Salesforce.com. Das 1999 gegründete Unternehmen mit Hauptsitz in San Francisco schaffte es so viele „frühe Adaptoren“ für seine „On Demand“-CRM-Lösung zu gewinnen, dass es von Forbes 2009 direkt hinter Google als das am drittschnellsten wachsende Technologie-Unternehmen der Welt eingestuft wurde[13]. Konkurrent Google zählte zu diesem Zeitpunkt immerhin 20 Millionen Kunden, die das Web-Officepaket „Google Apps“ in der kostenlosen Standard Edition nutzten. Weitere zwei Millionen Unternehmen hatten sich bereits für den Bezug der kostenpflichtigen Premier Edition registriert[14]. „SAP Business ByDesign“ ist eines der ersten komplexeren SaaS-Produkte, das seit 2010 am Markt angeboten wird. Ob dem System das Potential zugesprochen werden kann, zu einem ebenso etablierten Produkt wie die Lösungen von Google und Salesforce.com zu avancieren, wird die folgende Untersuchung zeigen.

2.1.3 Einsatzmodelle

Die „Cloud Computing“-Definition des NIST beinhaltet auch eine Unterscheidung verschiedener Einsatzmodelle. Diese sind im Hinblick auf die technische Implementierung beinahe identisch, unterscheiden sich aber in strategischer Hinsicht erheblich.

In den bisherigen Ausführungen wurde stets von einer „Public Cloud“ ausgegangen, d. h. der Provider bietet seine Dienste – SaaS, IaaS oder PaaS – meist auf kommerzieller Basis der Öffentlichkeit an. Wird eine Cloud-Infrastruktur hingegen nur für ein einziges Unternehmen (meist in dessen lokalem Netzwerk) unterhalten, spricht man von einer „Private Cloud“. Damit lassen sich wirtschaftliche Abhängigkeiten vermeiden (siehe Kapitel „Abhängigkeit vom Servicegeber“) und gesteigerte Anforderungen an die Sicherheit, wie z. B. von Banken oder öffentlichen Einrichtungen gefordert, erfüllen.

Es existieren außerdem Mischformen, wie die „Community Cloud“ (gemeinsame Infrastruktur mehrerer Unternehmen oder Interessensgemeinschaften) oder die „Hybrid Cloud“ (Kombinationen von „Public“, „Private“ oder „Community Clouds“).

2.2 ERP-Systeme

2.2.1 Definition

Der Begriff „ERP“ (Enterprise Resource Planning) bezeichnet die betriebswirtschaftliche Aufgabe, die Ressourcen eines Unternehmen möglichst effizient in Geschäftsprozessen einzusetzen. Die hierfür verwendete Software nennt sich „ERP-System“, und wird häufig übersetzt mit „Betriebliche Anwendungssoftware“ oder „Anwendungssystem“.

Ein ERP-Systeme „deckt die Planung und Steuerung der gesamten Wertschöpfungskette eines Unternehmens ab. ERP-Systeme bestehen aus mehreren Applikationen, die in ihren wesentlichen Modulen dem Einkauf, der Materialwirtschaft, der Produktionsplanung und Produktionssteuerung, der Lagerverwaltung, der Personalverwaltung, der Qualitätssicherung und dem Finanzmanagement dienen.“[15]. Ein wesentliches Merkmal von ERP-Systemen ist die Integration, angefangen bei den Daten (z. B. abteilungsübergreifend genutzter Materialstamm) bis hin zu gemeinsamen Geschäftsprozessen (z. B. Kundenauftrag durchläuft ohne Medienbrüche die Abteilungen Vertrieb, Versand und Rechnungsstelle).

Ein wesentlicher Aspekt bei der Einführung und Erweiterung von ERP-Systemen ist heute die Nutzung von standardisierten Prozessen, wodurch sich eine Reihe von Vorteilen ergibt[16]:

- Standardisierung erhöht die Produktivität. Somit besteht die Möglichkeit einer Rationalisierung der Aktivitäten. Die vorhandenen Sachmittel können ökonomisch eingesetzt werden, die Zahl der Arbeitsstationen und Transportwege minimiert werden.
- Standardisierung erleichtert die Koordination, weil Doppelbearbeitungen vermieden werden können. Die zu bearbeitenden Objekte und ihre Bereitstellung können geplant werden. Durch die Festlegung klarer Kompetenzen wird das organisatorische Konfliktpotential reduziert und ein lückenloses Ineinandergreifen der Verrichtungshandlungen gewährleistet.
- Standardisierung entlastet die Führungskräfte, weil die Steuerung der Prozesse in einem gewissen Sinne automatisiert wird. Die Leitungsprozesse der Führungskräfte können zeitlich gestrafft werden, das Setzen von Schwerpunkten wird möglich.
- Schließlich erhöht Standardisierung die Stabilität des organisatorischen Systems, da die einzelnen Aktivitätsfolgen von den beteiligten Personen weitgehend unabhängig werden.

Zu starke Standardisierung führt andererseits zu Nachteilen, weil nicht mehr adäquat oder nur sehr langsam auf ungeplante Veränderungen in der Geschäftsabwicklung, wie z. B. die Erschließung neuer Geschäftsfelder, reagiert werden kann. Ein weiteres Problem besteht darin, dass die Standardisierung aus Sicht des Softwareherstellers erfolgt. Dieser wählt bei der Konzeption einen branchenübergreifenden „Best Practice“-Ansatz, der häufig zu aus Sicht des Einzelnen umständlichen oder unnötig komplizierten Prozessen führt.

Die „Anpassung betrieblicher Anwendungen an die betrieblichen Erfordernisse“[17] erfolgt mit Hilfe des sog. „Customizings“. Durch entsprechende Parametrisierung lassen sich so Umfang und Verhalten der vom Hersteller ausgelieferten Standardprozesse verändern. Zusätzlich werden in der Regel Programmierschnittstellen zur Verfügung gestellt, die es ermöglichen nicht vorhandene Funktionalität an dafür vorgesehenen Stellen in Prozessen zu ergänzen. Die Programmierung erfolgt meist in proprietären Programmiersprachen, wie ABAP/4 (SAP ERP), oder C/AL (Microsoft Dynamics NAV). Als dritte Alternative besteht häufig die Möglichkeit direkt den Quellcode von Standardprogrammen zu verändern, man spricht von „Modifikationen“. Diese sind grundsätzlich nicht realeasefähig, was einen erhöhten Aufwand bei jedem Update verursacht. Im Fehlerfall ist auch keine Unterstützung seitens des Herstellers zu erwarten, Modifikationen sind deshalb unbedingt zu vermeiden.

2.2.2 SAP

2.2.2.1 Unternehmen

Das Unternehmen SAP (zum Gründungszeitpunkt: „Systemanalyse und Programmentwicklung GbR“) wurde 1972 von fünf ehemaligen Mitarbeitern der IBM in Weinheim gegründet. Sie hatten eine Vision, die gleich in zweierlei Hinsicht revolutionär war: Betriebswirtschaftliche Standard-, statt der damals marktbeherrschenden Individualsoftware, anzubieten, diese sollte außerdem in Echtzeit ablaufen und nicht, wie zu dieser Zeit üblich, im Batchbetrieb. Eine Tatsache, die sich auch im Produktnamen wiederfindet: Das „R“ im Namen der ersten 1973 fertig gestellten Finanzbuchhaltungs-Software „RF“, stand für „Real Time Processing“. In den folgenden Jahren wurden weitere Module, wie „RM“ (Materialwirtschaft), „RA“ (Anlagenbuchhaltung), „RV“ (Vertrieb) ergänzt, woraus später „R/1“ und - nach Weiterentwicklung der Datenbank- und Dialogsteuerungssysteme und Einführung der Programmierumgebung ABAP/4 - im Jahre 1981 das System „R/2“ entstand. Das in der Zwischenzeit nach Walldorf umgezogene Unternehmen zählte zu diesem Zeitpunkt bereits 200 Kunden, die SAP-Software einsetzten.

In den 80ern wurde das auf Großrechnern ablaufende und mit Terminals zu bedienende R/2 kontinuierlich weiterentwickelt. Der Erfolg des Produkts ermöglichte es SAP im Jahre 1990 die Umsatzmarke von 500 Millionen DM zu überschreiten. Der Nachfolger R/3 wurde ein Jahr später auf der CeBIT in Hannover vorgestellt und unterstützte neben der moderneren Client/Server-Technologie auch den Betrieb auf Rechnern unterschiedlicher Hersteller. An Stelle der textbasierten Terminals trat eine grafische Benutzeroberfläche für Microsoft Windows – das SAP GUI. Der Funktionsumfang von R/2 wurde in den darauf folgenden Jahren sukzessive auf R/3 portiert und weiter ausgebaut, SAP konnte infolge dessen zwischen 1991 und 1996 den Umsatz mehr als verfünffachen.

Mit Vorstellung der neuen Technologie „SAP NetWeaver“, einer offenen Integrations- und Applikationsplattform, schuf SAP 2004 die Möglichkeit Anwendungen von Drittanbietern effizient zu integrieren. R/3 wurde unter dem Namen „SAP ERP“ auf die NetWeaver-Plattform portiert und bildet seitdem zusammen mit anderen Komponenten wie CRM, SRM und Branchenlösungen die „Business Suite“. Parallel gelang es der bis dahin auf Großkunden spezialisierten SAP mit dem 2002 am Markt eingeführten Produkt „Business One“, ein kleines ERP-System für Unternehmen bis 100 Mitarbeitern, neue Zielgruppen anzusprechen.

SAP ist heute der „weltweit drittgrößte unabhängige Softwareanbieter, mit Niederlassungen in über 50 Ländern. Im Geschäftsjahr 2010 erzielte das Unternehmen einen Umsatz von 12,5 Mrd. Euro.“[18]. Größte Konkurrenten sind Oracle und Infor Global Solutions.

2.2.2.2 Produkt “Business ByDesign”

Ähnlich wie bei Business One versucht SAP auch mit seiner ersten „as-a-Service“-Lösung Business ByDesign einen neuen Kundenkreis anzusprechen. Mit SAP ERP wollte man vorwiegend Großkunden, mit Business One Kleinunternehmen bis 100 Mitarbeiter erreichen. Business ByDesign positioniert sich als ERP-System für KMUs (kleine und mittlere Unternehmen bis 500 Mitarbeiter) genau dazwischen. Das neue System nimmt außerdem „eine zentrale Rolle in SAPs Cloud-Strategie ein“[19], die auch einen neuen Ansatz für den Vertrieb enthält: Im „SAP Store“, ein Application Store vergleichbar mit Apples iTunes, soll der Kunde zukünftig Zusatzlösungen zur Ergänzung des Kernsystems von Business ByDesign auswählen können, ohne einen Vertriebspartner konsultieren zu müssen. Auch die Ersteinführung des Systems soll grundsätzlich ohne Unterstützung durch Berater und sogar ohne eigene IT-Abteilung möglich sein.

Business ByDesign wird derzeit ausschließlich vom Hersteller gehostet, der Bezug ist daher nur über die „Public Cloud“, d. h. über das Internet, möglich. Der Zugriff erfolgt über den Webbrowser oder – bei portablen Geräten – über gerätespezifische Anwendungen (sog. „Apps“, siehe Kapitel „Standortunabhängigkeit und Mobilität“). Als technische Infrastruktur war zunächst SAPs strategische Plattform, der NetWeaver, vorgesehen. Um die Software überhaupt profitabel anbieten zu können und die Komplexität zu reduzieren, mussten die NetWeaver-Komponenten aber bereits vor der Markteinführung wieder weitestgehend aus dem System entfernt werden[20].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Funktionsbereiche von SAP Business ByDesign

(Quelle: SAP)

Eine wesentlich Neuerung stellt die in SAP Business ByDesign vollintegrierte „In-Memory“-Technologie dar. Dabei werden Datensätze nicht zeilen-, sondern spaltenweise abgelegt, was die Performance beim Lesen erhöht. Die Daten werden außerdem vollständig im Direktzugriffsspeicher (RAM) abgelegt, Daten sind so innerhalb von Sekunden verfügbar[21] und Analysen und Auswertungen in einem Bruchteil der bisher benötigten Zeit möglich.

Funktional deckt der branchenneutrale Kern von SAP Business ByDesign in der aktuellen Version 3.0 das Finanz- und Rechnungswesen, sowie Produktion und Logistik (Supply Chain Management) ab. Einkaufs- und Vertriebsprozesse werden durch Module für elektronische Beschaffung (Supplier Relationship Management) bzw. Customer Relationship Management ergänzt. Das System bietet außerdem Unterstützung für Projektmanagement und das Personalwesen (siehe Abb. 4).

3. Potenziale des Modells “Software-as-a-Service”

3.1 Prozessuale Aspekte

3.1.1 Komplexitätsreduktion durch Standardisierung von Geschäftsprozessen

On-Demand-Services „sind so ausgelegt, dass sie gleichförmig für viele Kunden gemeinsam erbracht werden, indem deren Anwendungen, z. B. auf gleichen Datenbanken und auf virtualisierten, gemeinsamen Server-Infrastrukturen laufen“[22]. Bei einfachen Anwendungen, wie etwa den Google Apps, die von allen Kunden praktisch identisch genutzt werden, stellt dies kein Problem dar. Für Unternehmenslösungen jedoch ist die Vielfalt der Geschäftsgestaltung durch die verschiedenen Kunden eine Grundgegebenheit, die zunächst dem Wunsch eines gleichförmigen Betriebes über alle Kunden in der Cloud entgegensteht[23]. Es gilt also für On-Demand-Unternehmenssoftware einen Kompromiss zwischen Flexibilität einerseits und Vereinheitlichung andererseits, die die Voraussetzung für eine gemeinsame Nutzung von Ressourcen bildet, zu finden.

SAP Business ByDesign versteht sich deshalb als eine adaptive Geschäftsplattform. Die Services des Kernsystems wurden so granular modelliert, dass eine branchen- und kundenübergreifende Nutzung innerhalb der Plattform gewährleistet sein soll. Individuelle Konfigurationen entstehen durch Parametrisierung und das Aktivieren bzw. Deaktivieren einzelner Elemente. Dieser Konfigurationsprozess wird von SAP als „Scoping“ bezeichnet und ermöglicht es ausschließlich innerhalb vorgegebener Szenarien unternehmensspezifische Geschäftsprozesse zu konfigurieren.

Das hierfür angebotene Tool, der „Business-Konfigurator“, ist vergleichbar mit dem Fahrzeug-Konfigurator eines Automobilherstellers. Er präsentiert sich dem Anwender als Fragenkatalog, auf Basis der Antworten wird ein entsprechender Geschäftsprozess konfiguriert. Dabei achtet die sog. „Konfigurations-Engine“ darauf, dass keine inkonsistenten Konfigurationen entstehen. Die Auswahl des Lösungsumfangs ist in einem betriebswirtschaftlichen Vokabular gehalten und kann so direkt vom Anwender vorgenommen werden (siehe Abb. 5). Hierdurch werden Sprachbarrieren zwischen Geschäftswelt und IT überwunden, die bei eher technischen Ansätzen, wie dem klassischen Customizing, oft zu Abweichungen zwischen den betriebswirtschaftlichen Anforderungen im Pflichtenheft und den tatsächlich von Beratern am System vorgenommenen Einstellungen führen.

Bei der Auswahl des Lösungsumfangs unterstützt der Business-Konfigurator im ersten Schritt durch Empfehlungen auf Basis einiger elementarer Vorauswahlen, wie etwa der Branchentyp (Dienstleistungen, Fertigung, Großhandel, usw.) des Unternehmens. Der Vorschlag kann durch das Aktivieren oder Deaktivieren von Teillösungen unternehmensspezifisch angepasst werden. Die Auswahl wird nach Fachbereichen strukturiert dargestellt und lässt dann über drei Auswahlebenen („Fachthema“, „Funktionen“ und „Optionen“) eine immer feinere Konfiguration zu. Die Pflege eines Organisationsmodells, das die Aufbauorganisation des eigenen Unternehmens abbildet, ist ebenfalls Bestandteil des Scopings. Das Ergebnis kann am Ende direkt als Business Blueprint dargestellt werden[24], durch das betriebswirtschaftliche Vokabular des Konfigurators entfällt dabei erneut der Aufwand für die Übersetzung von technischen Begrifflichkeiten.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: „Scoping“: Auswahl des Lösungsumfang mit dem Business-Konfigurator

(Quelle: SAP)

Nicht aktivierte Funktionalitäten bleiben nach dem Scoping vor dem Servicenehmer verborgen, so dass die für ihn „sichtbare Komplexität“[25] abnimmt. Damit ist es für den Kunden leichter, den Überblick zu behalten, als bei klassischen ERP-Systemen: On-Premise-Software wird üblicherweise in Maximalausprägung ausgeliefert, d. h. alle zum Zeitpunkt der Auslieferung bedeutenden und für die nahe Zukunft möglicherweise relevanten Funktionen sind in dem Produkt enthalten. Vom fertig implementierten System nutzt der Kunde nach Einführung nur einen Bruchteil der vorgesehenen Funktionalitäten – 30 % entspricht einer guten Nutzungsrate – und ist trotzdem oft kaum noch in der Lage das laufende System zu ändern, weil Abhängigkeiten und Folgekosten bedingt durch die Komplexität des Produkts nicht mehr überschaubar sind[26]. Business ByDesign hingegen zeigt dem Kunden nur die genutzten Funktionen, unabhängig davon, „was unter der Haube sonst noch steckt“[27].

Der Business-Konfigurator unterstützt den Anwender sowohl bei der Ersteinführung von Business ByDesign, als auch bei späteren Geschäftsveränderungen. Dabei beschreibt er den jeweils aktuellen Stand der Konfiguration und zeigt außerdem an, welche Verfeinerungen möglich sind und welche Zusatzfunktionen sich aktivieren lassen[28]. Um das Hinzufügen von Drittanbieter-Lösungen zu vereinfachen ist für zukünftigen Releases von SAP Business ByDesign eine noch stärkere Integration des SAP Stores (siehe folgendes Kapitel) in den Business-Konfigurator geplant.

So flexibel der Aufbau des Kernsystems sein mag, die starke Standardisierung von Geschäftsprozessen geht dennoch zu Lasten der Individualität von kundeneigenen Geschäftsprozessen. Auf hieraus resultierende Nachteile wird im Kapitel „Risiken und Grenzen“ näher eingegangen. Neben der bereits genannten Komplexitätsreduktion und der anwenderfreundlichen Anpassung mittels Scoping, die bei einem klassischen ERP-System mit theoretisch unendlich vielen Konfigurationsmöglichkeiten schnell an ihre Grenzen stoßen würde, ergeben sich aber durch die Standardisierung auch Vorteile hinsichtlich der Kompatibilität, die im folgenden Kapitel deutlich werden.

3.1.2 Leichte Erweiterbarkeit

Um auf branchen- oder kundenspezifische Anforderungen eingehen zu können, sind vom Servicegeber Möglichkeiten vorzusehen, die eine Erweiterung des Kernsystems erlauben. Dies können in beschränktem Rahmen Tools sein, die eine Personalisierung der Standardprozesse durch den Kunden selbst ermöglichen (siehe Kapitel „Eingeschränkte Personalisierung“), für umfangreiche Erweiterungen sind aber mächtigere Schnittstellen zur Integration von Nöten. Viele SaaS-Anbieter wie Microsoft oder Amazon haben deshalb mit ihren Kernprodukten „die Basis für neue, „as-a-Service“-basierte Software-Ecosysteme gelegt“[29]. Unter Ecosystem wird dabei die Einheit aus einem Kernhersteller und Komplementärherstellern verstanden, die auf dem Kernprodukt aufsetzende Komponenten entwickeln. Charakteristisch für solch ein Ecosystem ist, dass alle Beteiligten – ähnlich wie bei aus der Biologie bekannten Ökosystemen – Vorteile aus dem Engagement ziehen und, dass ihr Engagement zwingend notwendig für den langfristigen Fortbestand des Ecosystems ist[30]. Bei Software-as-a-Service profitiert der Kernprodukthersteller von durch Drittanbieter bereitgestellten Funktionen, die in der Regel nicht zu den Kernkompetenzen des Herstellers gehören. Für neue Drittanbieter wiederum sind die Einstiegsbarrieren bei der Entwicklung auf einer standardisierten und gut dokumentierten Platform-as-a-Service geringer. Aber auch der Kunde profitiert von dieser Situation, weil neue Anbieter eine stärkere Konkurrenz für etablierte Anbieter darstellen und so zu geringeren Kosten für die Gesamtlösung und eine größere Auswahl an Komplementärangeboten führen[31].

SAPs kommerzielle Plattform für die Integration von Drittanbieter ist der SAP Store. Er präsentiert sich Komplementärherstellern („Partnern“) als Platform-as-a-Service, auf der diese digitale Ergänzungsprodukte entwickeln können, die sich nahtlos in den bestehenden Betrieb der Kundenplattform einfügen und wie eine Kernkomponente betrieben werden. Durch modellbasierte Adaptionstools wird sichergestellt, dass auch das Erscheinungsbild von Erweiterungen sich nicht von der des Kernsystems unterscheidet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Konzept des SAP Stores

(Quelle: SAP)

Die fertigen Erweiterungen („Apps“) werden nach einer Qualitätskontrolle durch SAP im Store publiziert und stehen dort für den Kunden bereit. Vor dem Kauf einer Erweiterung hat der Kunde die Möglichkeit mit einer „Kompatibilitätsprüfung“ fehlende Voraussetzungen und potentielle Konflikte in seinem Kernsystem aufzudecken. Dabei findet nicht etwa - wie bei On-Premise-Produkten üblich - eine Prüfung auf technische Kompatibilität statt. Diese ist bereits durch die konsequente Standardisierung von Services sichergestellt. Es handelt sich vielmehr um eine Konsistenzprüfung. Ein Negativbeispiel wäre die Auswahl einer Integrationslösung für Lohn- und Gehaltsabrechnungen per DATEV, ohne dass vorher die Personalwirtschaft im aktuellen Lösungsumfang des Kunden aktiviert wurde oder ein Versionskonflikt zwischen App und Kernsystem. Alle erworbenen Apps werden zusammen mit den Kernkomponenten in der betriebswirtschaftlichen Konfiguration des Zielsystems dargestellt und lassen sich dort aktivieren bzw. deaktivieren[32].

[...]


[1] Vgl. Gartner (2011)

[2] Beispielsweise Armbrust, M. et al. (2009), S. 14 ff.

[3] Vgl. Grobman, J. (2009), S. 23

[4] Software-as-a-Service stellt aus rechtlicher Sicht kaum eine besonders neue Herausforderung dar, vergleichbare Probleme waren bereits bei ASP und anderen Formen der Softwareüberlassung bekannt, vgl. Spindler, G. (2010), S.40

[5] In Netzwerkdiagrammen wird die Wolke (engl. „Cloud“) häufig als Symbol für das Internet verwendet, ist deshalb zum Synonym dafür geworden. „Cloud Computing“ lässt sich sinngemäß mit „Rechnen im Internet“ übersetzen.

[6] Vgl. Staten, J. (2008)

[7] Vgl. Gartner (2009)

[8] Vgl. Mell, P./Grance, T. (2009)

[9] Detaillierter Vergleich bei Kunze, M./Baun, C. (2008)

[10] Dabei steht „X“ als Platzhalter für beliebige Dienstleistungen, Beispiele sind „Hardware-as-a-Service“ und „Process-as-a-Service“.

[11] Baun, C. et al. (2011), S. 44

[12] Vgl. Baun, C. et al. (2011), S. 39

[13] Vgl. Föckeler, C. (2010), S. 112

[14] Vgl. Gutzeit, K. (2010), S. 145

[15] Helmke, J. (2010), S. 13

[16] Vgl. Schertler, W. (1985), S. 58

[17] Helmke, J. (2010), S. 67

[18] SAP (2011a)

[19] Lorenz, P./Eichin, R. (2012), S. 53

[20] Vgl. Wirtschaftswoche (2009)

[21] Vgl. Computerwoche (2010)

[22] Zencke, P. (2012), S. 29

[23] Vgl. Zencke, P. (2012), S. 29 f.

[24] Vgl. Hufgard, A./Krüger (2012), S. 156 ff.

[25] Zencke, P. (2012), S. 27

[26] Vgl. Zencke, P. (2012), S. 25 ff.

[27] Zencke, P. (2012), S. 27

[28] Vgl. Zencke, P. (2012), S. 28

[29] Hilkert, D. et al. (2010), S. 58

[30] Vgl. Schuster, M./Weiß M. (2001), S. 113

[31] Vgl. Hilkert, D. et al. (2010), S. 58 ff.

[32] Vgl. Hufgard, A./Krüger, S. (2012), S. 210 ff.

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2012
ISBN (eBook)
9783842829336
DOI
10.3239/9783842829336
Dateigröße
1.7 MB
Sprache
Deutsch
Institution / Hochschule
Hochschule Wismar – Wirtschaft, Wirtschaftsinformatik
Erscheinungsdatum
2012 (Februar)
Note
1,8
Schlagworte
cloud computing software service business design erp-system demand
Zurück

Titel: Potenziale, Risiken und Grenzen von Software-as-a-Service aus Anwendersicht am Beispiel von SAP Business ByDesign
Cookie-Einstellungen