Entwicklung eines Vorgehensmodells zur Qualifizierung von Vertriebssoftware für den hybriden Betrieb von On-Premise Software und SaaS in KMU

Inhaltsverzeichnis

1. Einleitung
1.1 Problemstellung
1.2 Ziele der Arbeit und Forschungsfragen
1.3 Vorgehensweise
1.4 Methodik

2. Theoretische Grundlagen
2.1 Modelle und Methoden in der Wirtschaftsinformatik
2.1.1 Modellbegriff und Modellarten
2.1.2 Methoden zur Entscheidungsunterstützung
2.2 Outsourcing
2.2.1 IT-Sourcing
2.2.2 IT-Outsourcing
2.2.3 Modelle und Theorien im IT-Outsourcing
2.3 Arten des Softwarebetriebs
2.3.1 On-Premise Software
2.3.2 Cloud Computing
2.3.3 Software as a Service und hybrider Betrieb
2.3.4 Nutzenbetrachtung von SaaS und hybridem Betrieb
2.4 Vertriebssoftware und-prozesse
2.4.1 Vertriebssoftware
2.4.2 Vertriebsprozesse
2.5 Besonderheiten von KMU
2.5.1 Definition KMU
2.5.2 Eingesetzte Software und deren Auswahl
2.5.3 Vertriebsprozesse
2.5.4 IT-Outsourcing, Cloud Computing und SaaS

3. Vergleich von IT-Outsourcing und SaaS
3.1 Neuerungen durch SaaS im IT-Outsourcing
3.1.1 Gemeinsamkeiten
3.1.2 Unterschiede
3.1.3 Neue Aspekte durch SaaS und hybriden Betrieb
3.2 Folgen der Unterschiede von IT-Outsourcing und SaaS
3.2.1 Anwendbarkeit bisheriger Vorgehensweisen
3.2.2 Modell für SaaS und hybriden Betrieb

4. Grundlagen zur Herleitung des Modells
4.1 Anforderungen an das Modell
4.1.1 Basisanforderungen
4.1.2 Spezifische Anforderungen
4.2 Auswahl und Einsatzmöglichkeiten geeigneter Methoden
4.2.1 Total Cost of Ownership
4.2.2 Total Cost of Utilization
4.2.3 Nutzwertanalyse
4.2.4 Methodeneinsatz im Modell
4.3 Auswahl geeigneter Basismodelle und Theorien
4.3.1 Basismodelle
4.3.2 Theorien
4.4 Erstellung eines Entscheidungskriterienkatalogs
4.4.1 Entscheidungskriterien aus bisherigen Ergebnissen und Literatur
4.4.2 Entscheidungskriterien aus der Praxis
4.4.3 Zusammenfassung der Kriterien

5. Formulierung des Modells
5.1 Vorgehensweise
5.2 Erarbeitung der Phasen und Teilschritte
5.2.1 Generische Phasen
5.2.2 Teilschritte
5.2.3 Anpassung und Erweiterung gemäß der Problemstellung
5.3 Ausformulierung des Modells
5.4 Darlegung der Anforderungserfüllung

6. Anwendung des Modells
6.1 Beispielszenario
6.1.1 Ausgangssituation
6.1.2 Modelleinsatz
6.2 Projekt des Praxispartners
6.2.1 Ausgangssituation
6.2.2 Modelleinsatz
6.3 Diskussion und Auswertung der Anwendung

7. Resumée & Ausblick

Anhang

Literaturverzeichnis

Erklärung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Gartner's Hype Cycle for Emerging Technologies 2011

Abbildung 2: Gartner's Hype Cycle for Cloud Computing 2011

Abbildung 3: Cloud Computing, SaaS und Outsourcing bei Google Trends

Abbildung 4: Methodik der Arbeit

Abbildung 5: Dimensionen des IT-Sourcings

Abbildung 6: Formen des Outsourcing gemäß BITKOM

Abbildung 7: Ebenen des Cloud Computing nach IT-Leistungen und Zielgruppen

Abbildung 8: Grafische Darstellung des neuen Vorgehensmodells

Abbildung 9: EEPK der Prozesse im Beispielprojekt von Trendmark Fashion

Abbildung 10: IT-Architektur von Trendmark Fashion

Tabellenverzeichnis

Tabelle 1: Vor- und Nachteile von SaaS

Tabelle 2: Gemeinsamkeiten von SaaS und Applikations-Outsourcing

Tabelle 3: Generelle Unterschiede zwischen SaaS und Applikations-Outsourcing

Tabelle 4: Unterschiedlicher Ausprägungsgrad von Gemeinsamkeiten

Tabelle 5: Neuerungen durch SaaS verglichen mit Applikations-Outsourcing

Tabelle 6: Herleitung der generischen Modellphasen

Tabelle 7: NWA zum Vergleich von status quo und CRM-Online

Tabelle 8: NWA zum Vergleich der Lösungen von Mobimedia und pulsd

Tabelle 9: TCO-Analyse für ein On-Premise CRM-System

Tabelle 10: TCU-Analyse für ein SaaS CRM-System

1. Einleitung

Das Thema Cloud Computing hält seit seinem Aufkommen vor einigen Jahren immer größeren Einzug in Wissenschaft und Praxis.^[1] An manchen Stellen wird schon davon gesprochen, dass das Wort „Hype“ für Cloud Computing aufgrund seiner zunehmenden Verbreitung und technologischen Reife nicht mehr angebracht sei.^[2] Trotzdem wird nun mit einem Blick auf Gartner’s aktuellen „Hype Cycle for Emerging Technologies“ aufgezeigt, wie hoch Erwartungen an Cloud Computing und dessen Sichtbarkeit heute sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Gartner's Hype Cycle for Emerging Technologies 2011^[3]

Ein genauerer Blick auf den Hype Cycle lässt vermuten, dass die bereits angesprochene technologische Reife noch nicht erreicht ist. Dies mag daran liegen, dass der hier dargestellte Hype Cycle das Phänomen Cloud Computing als Ganzes und nicht seine jeweiligen Ausprägungen differenziert betrachtet, von denen es immer mehr gibt.

Aus diesem Grund hat Gartner für den Bereich Cloud Computing einen eigenen Hype Cycle entworfen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Gartner's Hype Cycle for Cloud Computing 2011^[4]

Wie zu erkennen ist, sind die Technologien über alle Phasen verstreut. Hierbei liegt „Software as a Service“, welches in dieser Arbeit thematisiert wird, bereits im „Slope of Enlightment“. Dies besagt, dass sich der Nutzen für Unternehmen bereits herauskristallisiert, Marktanteile wachsen und das Verständnis für die Technologie reift.^[5]

Auch die Suchanfragen bei Google zeigen das Interesse am Thema Cloud Computing:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Cloud Computing, SaaS und Outsourcing bei Google Trends^[6]

Beachtlich ist hierbei, dass das Suchvolumen nach „SaaS“ und „Cloud Computing“ jenes nach „Outsourcing“ bereits übersteigt.

Bei allem Enthusiasmus und öffentlichem Interesse für das Thema darf jedoch, wie bei jeder technologischen Neuerung, nicht vergessen werden, dass vor dem Einsatz einer neuen Technologie eine genaue Prüfung bezüglich deren Nutzen zu erfolgen hat.^[7]

Auch wird insbesondere bei den Themen Cloud Computing und SaaS die Frage gestellt, worin die eigentliche Neuerung liegt bzw. ob diese überhaupt vorhanden ist.^[8] Dies zeigt sich zum Beispiel darin, dass noch vor wenigen Jahren kaum ein Unterschied zwischen SaaS und ASP gesehen wurde, während man sich heute mehr und mehr der neuen Möglichkeiten durch SaaS bewusst wird.^[9] Pelzl und Herzwurm kritisieren ebenfalls, dass die wenigsten Anbieter bisher dazu in der Lage sind, ihre Cloud-Services komplett online anzubieten.^[10]

Trotz einiger Kontroversen steht fest, dass Cloud Computing ein hochaktuelles Thema ist, welches für viele Unternehmen zunehmend interessanter wird.^[11]

Doch auch aus persönlichem Interesse habe ich mich für eine Abschlussarbeit im Bereich Cloud Computing entschieden. Geweckt wurde mein Interesse für die Thematik durch meine Seminararbeit zur wirtschaftlichen Betrachtung von Cloud Computing.^[12] Da wirtschaftliche Aspekte in der vorliegenden Arbeit auch eine Rolle spielen, werden die Ergebnisse der Seminararbeit teilweise in diese Arbeit einfließen.

Die finale Idee zur Entwicklung eines neuen Modells entstand in einem Meeting mit Markus Eilers, dem CEO des Praxispartners für diese Arbeit, der runtime software GmbH in Waiblingen, und dem Betreuer dieser Arbeit, Norman Pelzl.

Die runtime software GmbH ist ein mittelständisches Technologieberatungs-Unter-nehmen mit starkem Fokus auf Cloud Computing und stellt daher einen passenden Partner dar, dessen Know How in die Ergebnisse dieser Arbeit einfließen wird.

Diese Arbeit richtet sich vornehmlich an Leser mit gewissen Vorkenntnissen im Bereich Cloud Computing und IT im Allgemeinen, was bedeutet, dass manche Begrifflichkeiten als bekannt vorausgesetzt und nicht näher erläutert werden.

1.1 Problemstellung

Immer mehr Unternehmen machen sich Gedanken darüber, „in die Cloud zu gehen“. Dieser Umstand impliziert die Notwendigkeit eines methodischen Vorgehens bei der Auswahl von Systemen, die ausgelagert werden sollen bzw. die hierfür geeignet sein könnten sowie jener Systeme, die diese ersetzen werden.^[13] Der diesbezügliche Wissensstand im Bereich Cloud Computing ist in Forschung und Praxis noch relativ gering und es existieren keine oder wenig zufriedenstellende Ansätze.^[14]

Es scheint die Meinung vorzuherrschen, dass Prozesse und Systeme entweder ganz oder gar nicht ausgelagert werden können.^[15] Dies kann dazu führen, dass auf eine Auslagerung verzichtet wird, wenn nur ein einzelner Teilaspekt oder -prozess (zwingend) dagegen spricht, z. B. aus Gründen des Datenschutzes oder der Datensicherheit. Dieser Umstand kann wiederum zur Folge haben, dass eventuell vorhandenes Potential einer Auslagerung nicht ausgeschöpft wird.

Einen Lösungsansatz hierfür könnte der hybride Betrieb von On-Premise Software und Software as a Service (SaaS) bieten. Dieser hybride Betrieb ist eine sehr junge Thematik im Bereich Cloud Computing, was vermuten lässt, dass in Forschung und Praxis ebenfalls noch wenige Kenntnisse vorhanden sind.

Zwar war der „hybride“ Betrieb von ausgelagerten- und On-Premise-Anwendungen auch in bisherigen Ansätzen des IT-Outsourcing möglich (partielles/selektives- oder Multisourcing), jedoch nur mit technischen und rechtlichen Hürden.^[16] Cloud Computing ermöglicht hier eine flexiblere und einfachere Umsetzung,^[17] was ein zusätzlicher Anreiz für ein neues Modell ist, welches diese technologischen Neurungen berücksichtigt.

Hybrider Betrieb macht es notwendig, Systeme zu klassifizieren bzw. zu qualifizieren, um herauszufinden, welche Systeme on-premise und welche als SaaS umgesetzt werden sollen. Unter „Qualifizierung“ wird dabei Folgendes verstanden:

Qualifizierung bedeutet in dieser Arbeit die Klassifikation und Einordnung von Software hinsichtlich ihrer Eignung zur Auslagerung in Form von Software as a Service bzw. zum hybriden Betrieb.^[18]

1.2 Ziele der Arbeit und Forschungsfragen

Aufbauend auf der Problemstellung werden nun die Ziele der Arbeit und die in diesem Zuge zu bearbeitenden Forschungsfragen dargelegt.

Ziel der Arbeit ist die Erarbeitung eines Vorgehensmodells, mit dessen Hilfe Software bezüglich ihrer Eignung zur Auslagerung in Form von SaaS qualifiziert werden kann. Um den Rahmen einer Masterarbeit nicht zu sprengen und das Thema konkret und spezifisch zu halten, beschränkt sich diese Arbeit hierbei auf Vertriebsprozesse in kleinen und mittelständischen Unternehmen (KMU). Dies bietet sich an, da SaaS vor allem für KMU ein hohes Potential bietet^[19] und der SaaS-Markt in diesem Bereich relativ groß ist sowie eine hohe technologische Reife aufweist.^[20] Auch haben KMU eine nicht zu unterschätzende volkswirtschaftliche Bedeutung.^[21] Als Cloud-Architektur wird nur die sogenannte Public Cloud berücksichtigt. Diese scheint für KMU besser geeignet, da KMU in besonderem Ausmaß von IT-Outsourcing an externe Dienstleister profitieren können.^[22] Auch kann davon ausgegangen werden, dass kleine Unternehmen weder die notwendigen Mittel noch den Bedarf haben, eine eigene Private Cloud aufzubauen.

Diese Eingrenzungen sind auch daher zweckmäßig, da Prozessstrukturen und eingesetzte Systeme sich je nach Unternehmensgröße und Anwendungsgebiet ändern.^[23] Auch wird in dieser Abreit davon ausgegangen, dass bereits Software On-Premise vorhanden ist, d.h. es geht bei der Auslagerung der Software in Form von SaaS in dieser Arbeit stets um einen Systemwechsel.

Durch diese Fokussierung gelangt man zu einem spezifischeren Modell, welches konkrete Gegebenheiten besser berücksichtigt und somit auch ein Alleinstellungsmerkmal besitzt, mit dem es sich von anderen Modellen abhebt und daher für einen speziellen Anwendungsfall besser geeignet sein kann.

Da ein Vorgehensmodell aber auch abstrahierend und auf eine Vielzahl von Fällen anwendbar sein muss,^[24] wird auf einen Branchenfokus verzichtet. So soll bei dem Modell ein sinnvolles Maß an Übertragbarkeit einerseits und Spezifität andererseits gewährleistet werden. Auch fließt die Branchenthematik ohnehin indirekt in den Entscheidungsprozess ein, da die Wahl der Software im Vertrieb stark von der Branche abhängt.^[25]

Um das oben genannte Ziel erreichen zu können, werden ebenso folgende Forschungsfragen bearbeitet:

- Wie in welchem Umfang lassen sich Konzepte des IT-Outsourcing auf die Problemstellung übertragen?
- Welche neuen Möglichkeiten und Herausforderungen bringen SaaS und der hybride Betrieb in diesem Umfeld mit sich bzw. worin liegen Gemeinsamkeiten und Unterschiede zum herkömmlichen IT-Outsourcing?
- Wie kann man Vertriebssoftware in KMU für den hybriden Betrieb qualifizieren und damit auch:
- Welche sind die hierfür entscheidenden Aspekte und Entscheidungskriterien, wie fließen diese in das Vorgehensmodell ein und welche Methoden Einsatz kommen?

1.3 Vorgehensweise

Nachdem die Ziele der Arbeit und die zu beantwortenden Forschungsfragen erläutert wurden, wird nun die allgemeine Vorgehensweise in dieser Arbeit erörtert.

Im Theorieteil der Arbeit werden, neben der Darlegung der zum Verständnis dieser Arbeit notwendigen Begrifflichkeiten, die Anforderungen an Vorgehensmodelle anhand entsprechender Literatur erarbeitet. Diese werden im Laufe der Arbeit um spezifischere, auf die Problemstellung passende, Aspekte erweitert. Nach der Modellformulierung wird die Erfüllung der jeweiligen Anforderungen aufgezeigt.

Für ein methodisch korrektes Vorgehen bietet es sich an, als Basis für ein neues Modell bereits bestehende Modelle und Methoden des IT-Outsourcing sowie Theorien aus diesem Umfeld heranzuziehen. Deren Eignung für die Problemstellung wird anhand wissenschaftlicher Literatur überprüft.

Diese Herangehensweise impliziert, dass man sich zunächst über die Gemeinsamkeiten und Unterschiede zwischen dem klassischen IT-Outsourcing und SaaS klar werden muss. Aus diesen ergeben sich neue Aspekte, welche das Vorgehensmodell ebenfalls berücksichtigen muss.

Es muss anschließend festgelegt werden, welches die zur Qualifizierung der Software relevanten Entscheidungskriterien sind. Dies können zum Beispiel Lock-In Effekte oder Fragestellungen aus dem Bereich der Datensicherheit sein. Diese Kriterien werden unter anderem mit Hilfe von Interviews und Umfragen bei dem Praxispartner erarbeitet.

Aufbauend auf dem Vergleich von IT-Outsourcing und SaaS sowie den ausgewählten Basismodellen und Theorien wird das neue Modell abgeleitet und formuliert, wobei wiederum Beispiele zur Modellentwicklung aus der Literatur herangezogen werden. Die Praxiseignung des Modells wird anschließend durch dessen Anwendung auf ein fiktives Szenario und ein Projekt der runtime software GmbH aufgezeigt.

Die Arbeit gliedert sich wie folgt: Nach der Darlegung der zum Verständnis der Arbeit relevanten Theorie erfolgt ein Vergleich zwischen konventionellem IT-Outsourcing und SaaS sowie eine Prüfung der Anwendbarkeit von bestehenden Modellen auf SaaS. In den folgenden Kapiteln wird das Modell hergeleitet und formuliert. Abschließend wird dessen Eignung und Übertragbarkeit anhand eines fiktiven Szenarios und eines konkreten Projektbeispiels aus der Praxis dargelegt, bevor die Arbeit mit Ausblick und Resumée abgeschlossen wird.

1.4 Methodik

In diesem Abschnitt wird die Methodik bei der Beantwortung der Forschungsfragen und der Erstellung des Vorgehensmodells dargelegt.

In Kapitel 2 werden, neben weiteren theoretischen Aspekten, die Besonderheiten von KMU dargelegt und Basisanforderungen an Vorgehensmodelle erarbeitet. Zusammen mit den Ergebnissen aus Kapitel 3, in welchem ein Vergleich zwischen SaaS und IT-Outsourcing erfolgt, auf dessen Basis wiederum die Neuerungen durch SaaS erarbeitet werden, bilden diese die Grundlage für eine Definition von Anforderungen an das neue Vorgehensmodell.

Durch eine Übertragung der Aspekte, welche sich durch die Unterschiede von SaaS und IT-Outsourcing ergeben, auf ein Vorgehensmodell des IT-Outsourcing, wird in Kapitel 3 ebenso aufgezeigt, dass bisherige Modelle im Falle von SaaS nicht ohne Weiteres angewandt werden können.

In Kapitel 4 werden die erarbeiteten Anforderungen an das neue Modell konkretisiert. Auch werden Kriterien für eine spätere Nutzwertanalyse, welche zur Entscheidungsfindung innerhalb des Modells zum Einsatz kommt, erarbeitet. Diese Kriterien stammen dabei aus vorangegangenen Arbeitsergebnissen, Literatur sowie Interviews und Umfragen beim Praxispartner. Die in Kapitel 2 vorgestellten Methoden, welche im Bereich SaaS angewandt werden, werden in Kapitel 4 auf ihre Eignung zum Einsatz innerhalb des Modells untersucht. Ebenso findet hier eine Auswahl von Theorien, wie beispielsweise der Transaktionskostentheorie, sowie bestehenden Modellen, welche als Basis für das neue Modell dienen können, statt.

Somit werden in Kapitel 4 die Rahmenbedingungen zur letztendlichen Formulierung des Modells geschaffen, welche in Kapitel 5 erfolgt.

In Kapitel 6 wird das Modell schließlich auf zwei Beispielszenarien angewandt, um dessen Praxiseignung und Übertragbarkeit aufzuzeigen. Hierbei handelt es sich um ein fiktives Beispielszenario, welches für diese Arbeit konstruiert wurde, und ein konkretes Kundenprojekt des Praxispartners, welches in der Vergangenheit stattgefunden hat, also bereits abgeschlossen ist. Die Ergebnisse der Anwendung des Modells auf das Beispielszenario und das Kundenprojekt werden anschließend ausgewertet.

Die folgende Grafik veranschaulicht die Methodik bei der Erstellung des Modells:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Methodik der Arbeit

2. Theoretische Grundlagen

Nachdem einleitend die Problemstellung und die Ziele der Arbeit verdeutlicht wurden, werden im nun folgenden Kapitel die theoretischen Grundlagen erörtert, die zum Verständnis dieser Arbeit notwendig sind.

2.1 Modelle und Methoden in der Wirtschaftsinformatik

Da das Hauptziel dieser Arbeit in der Entwicklung eines Vorgehensmodells besteht, wird nun anhand von Quellen aus der Literatur festgelegt, was unter dem Begriff „Modell“ zu verstehen ist und welche Arten von Modellen es gibt.

Da innerhalb des zu erarbeitenden Modells auch Methoden zur Entscheidungsfindung und -unterstützung bzw. zur Bewertung der Wirtschaftlichkeit zum Einsatz kommen werden, wird diese Thematik ebenfalls erläutert.

2.1.1 Modellbegriff und Modellarten

Es gibt eine Vielzahl an Modellbegriffen und Möglichkeiten zu deren Abgrenzung. Auch in der Wirtschaftsinformatik findet der Begriff „Modell“ an vielen Stellen und in verschiedenstem Kontext Verwendung.^[26] Aufgrund der hohen Anzahl an Definitionen und möglichen Einordnungen beschränkt sich dieser Abschnitt auf die Definition der wichtigsten Begrifflichkeiten, ohne einen umfassenden Einblick in die Modelltheorie zu geben. Dies würde den Rahmen der Arbeit sprengen und wäre für das Erreichen der Ziele dieser Arbeit nicht zweckdienlich.

Ein früher Modellbegriff mit betriebswirtschaftlichem Hintergrund geht zurück auf Erich Kosiol, dem zufolge man dann von einem Modell sprechen kann, "wenn es sich um zusammengesetzte Gedankengebilde handelt, die aus der Totalinterdependenz der Wirklichkeit abgegrenzte und übersehbare Teil zusammenhänge ausgliedern."^[27] Dies bedingt als ein wichtiges Kriterium für ein Modell, dass dieses abstrahierend sein und die Realität vereinfacht darstellen muss.^[28]

Herbert Stachowiak, Verfasser des Standardwerks „Allgemeine Modelltheorie“, betont in seinem Modellbegriff die Zweckorientierung^[29] und definiert drei Hauptmerkmale für Modelle:^[30]

- Abbildungsmerkmal: Ein Modell ist immer ein Abbild einer Sache, welche auch selbst ein Modell sein kann.
- Verkürzungsmerkmal: Ein Modell umfasst nicht alle Eigenschaften des Originals, sondern nur jene, die der Modellierer als relevant erachtet. Dieses Merkmal bestätigt Kosiols Auffassung, dass ein Modell abstrahierend sein muss.
- Pragmatisches Merkmal: Modelle haben eine Ersetzungsfunktion bezüglich ihrer Originale, wobei diese Ersetzung zu einem bestimmten Zweck, in einem bestimmten Zeitraum und für ein bestimmtes Subjekt erfolgt. In diesem Merkmal spiegelt sich die Zweckorientierung Stachowiaks Modellbegriffs wider.

Die genannten Kriterien finden auch in modernen Modelldefinitionen im Bereich der Wirtschaftsinformatik Verwendung.^[31]

Bei der Modellart, die in dieser Arbeit entwickelt werden soll, handelt es sich um ein Vorgehensmodell. Diese Art von Modellen wird zu den Referenzmodellen gezählt.^[32] Referenzmodelle wiederum „stellen Modellmuster dar, die als idealtypisch für die Klasse der zu modellierenden Sachverhalte betrachtet werden.“^[33] Dies bedeutet, dass Referenzmodelle zum Ableiten neuer, spezifischerer Modelle genutzt werden können (was die Bezeichnung Referenz modell bereits vermuten lässt). Referenzmodelle werden auch zum Evaluieren von Alternativen herangezogen, wobei das Ergebnis als Reifegrad angegeben wird.^[34]

Dies unterstreicht die Eignung von Vorgehensmodellen für die in dieser Arbeit gegebene Problemstellung.

Unter dem Begriff Vorgehensmodell wiederum versteht man „jede modellhafte, abstrahierende Beschreibung von Vorgehensweisen, Richtlinien, Empfehlungen oder Prozessen, die für einen abgegrenzten Problembereich gelten und in einer möglichst großen Anzahl von Einzelfällen anwendbar sind.“^[35] Diese Definition spiegelt genau jene Anforderungen an Spezifität und Übertragbarkeit des zu entwickelnden Vorgehensmodells wider, die einleitend gestellt wurden.

Auch zeichnen sich Vorgehensmodelle durch eine Einteilung in Phasen aus, in denen beschrieben wird, wie und womit (z.B. mit welcher Methode) Dinge auszuführen sind.^[36]

Zusammenfassend lassen sich für ein Vorgehensmodell folgende Kriterien festhalten, welche somit auch das zu entwickelnde Modell als Basiskriterien erfüllen sollte:

- Abstraktion
- Vereinfachung
- Zweckorientierung
- Spezifität
- Übertragbarkeit
- Phasenorientierung

2.1.2 Methoden zur Entscheidungsunterstützung

Betriebswirtschaftliche Entscheidungen können mit Hilfe von Methoden unterstützt werden.^[37] Da es in dem zu entwickelnden Vorgehensmodell auch um die Herbeiführung einer Entscheidung bzw. die Unterstützung bei deren Findung geht, werden auch innerhalb des Modells solche Methoden zum Einsatz kommen.

Zur wirtschaftlichen Beurteilung von SaaS als Alternative zu On-Premise-Lösungen haben sich, wie in diesem Abschnitt noch dargelegt wird, die von Gartner entwickelte Total Cost of Ownership (TCO) Analyse und die Nutzwertanalyse (NWA) etabliert, welche, wie später ersichtlich wird, auch in Kombination angewandt werden können. Daher könnten sie sich auch für den Einsatz in dem neuen Vorgehensmodell eignen. Eine genaue Prüfung, ob dies tatsächlich der Fall ist, findet in Abschnitt 4.2 statt.

Die TCO, als aufwandsorientierte Art der Wirtschaftlichkeitsanalyse, berücksichtigt nur monetäre Aspekte.^[38] Dieser eindimensionalen Sichtweise kann vorgeworfen werden, dass qualitative Aspekte unberücksichtigt bleiben.^[39] Daher bietet sich die Kombination mit der NWA als mehrdimensionales Verfahren an, welches auch nicht-monetäre Kriterien betrachtet. Wichtig hierbei ist ein gewisser Erfahrungsschatz der Beteiligten.^[40]

Total Cost of Ownership

Die Originaldefinition für TCO findet sich auf den Webseiten von Gartner:

„A comprehensive assessment of information technology (IT) or other costs across enterprise boundaries over time. For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses, and the opportunity cost of downtime, training and other productivity losses.”^[41]

Bei der TCO handelt es sich folglich um ein Verfahren, mit dem die anfallenden Kosten für Anwendungen und der dazugehörigen IT-Infrastruktur sowie deren Betrieb ermittelt werden können. Die Gesamtkosten ergeben sich hierbei aus direkten, berechneten Kosten und indirekten, nicht berechneten Kosten.^[42]

Die TCO-Methode wird in der Praxis eingesetzt, um die Wirtschaftlichkeit von Cloud Computing-Anwendungen zu ermitteln.^[43]

Wie zu erkennen ist, handelt es sich bei TCO um ein Verfahren, bei dem der monetäre Aspekt im Vordergrund steht.

Doch auch die indirekten Kosten werden im Verlauf des Verfahrens quantifiziert, was allerdings, je nach Komplexität der Anwendung, einen höheren Aufwand verursacht als bei den direkten Kosten.^[44]

Total Cost of Utilization

Äquivalent zur TCO existiert für IT-Services die weniger bekannte Methode Total Cost of Utilization (TCU) aus der ITIL, welche im späteren Verlauf für SaaS angewandt wird. Die TCU wird im Umfeld des IT-Outsourcings sowohl auf Kunden- als auch auf Anbieterseite genutzt^[45] und unterstützt die Entscheidungsfindung im Sourcing-Bereich, indem die kompletten IT-Service-Kosten über deren Lebenszyklus bestimmt werden.^[46] Das Vorgehen ist das gleiche wie bei der TCO, da beide Methoden dasselbe ermitteln.

Nutzwertanalyse

Im Rahmen einer NWA werden mehrere Alternativen hinsichtlich ihres Erfüllungsgrads bezüglich bestimmter Kriterien miteinander verglichen. Hierbei können auch nicht direkt quantifizierbare Aspekte berücksichtigt werden.^[47] Grundsätzlich wird eine NWA in drei Schritten erstellt, wobei auch Varianten möglich sind:^[48]

1. Formulierung der Kriterien: Diese sollten möglichst unabhängig voneinander sein und sich sinnvoll quantifizieren bzw. skalieren lassen.
2. Festlegung von Gewichtungen der Kriterien: Hierbei kann beispielsweise eine Gesamtpunktezahl von 100 Punkten auf die Kriterien verteilt werden (Verteilungsmethode).
3. Festlegung von Nutzenwerten: Beispielsweise durch eine Zuordnung von Punktewerten, die den Erfüllungsgrad eines Kriteriums widerspiegeln.

Nun wird für jede Alternative der Gesamtnutzen bestimmt, indem die Kriteriengewichtung mit dem jeweiligen Erfüllungsgrad multipliziert wird. Die hierbei erhaltenen Zielerträge werden zum Nutzwert aufaddiert. Die aus wirtschaftlicher Sichtweise beste Alternative ist nun jene mit dem höchsten Nutzwert.^[49]

Die NWA wurde in der Praxis bereits des Öfteren im Umfeld von Cloud Computing-Projekten eingesetzt,^[50] dies auch ergänzend zur TCO-Methode.^[51]

Zu beachten ist, dass bei der NWA in jedem Schritt subjektive Einschätzungen des Er-stellers einfließen. Daher kann es sinnvoll sein, die Ergebnisse durch Veränderung der Gewichte und Nutzenwerte auf ihre Stabilität hin zu prüfen.^[52]

2.2 Outsourcing

In diesem Abschnitt wird das Thema Outsourcing aus Sicht der IT erläutert. Es wird der Bezug zwischen Outsourcing und Cloud Computing dargestellt und aufgezeigt, wie sich SaaS in diesem Umfeld einordnen lässt. Auch wird auf den allgemeinen Begriff des Sourcings bzw. des IT-Sourcings eingegangen.

Generell wird Outsourcing verstanden als die „dauerhafte Auslagerung von Leistungen mit einer Übertragung von Handlungsverantwortung an Externe. Es wird auf eine langfristige Arbeitsteilung zwischen Unternehmungen abgezielt.“^[53]

Diese sehr allgemeine Definition ist für die Problemstellung jedoch nicht ausreichend. Daher folgt nun, nachdem die Arten des Outsourcing erläutert wurden, eine Konkretisierung der für diese Arbeit relevanten Outsourcing-Arten mit mehr Bezug zur IT.

2.2.1 IT-Sourcing

Sourcing ist ein extrem vielschichtiger Begriff. Generell handelt es sich hierbei um den „Prozess zur Beschaffung von […] Ressourcen“.^[54] Es existieren in diesem Bereich sehr viele Ausprägungen, Definitionen und Möglichkeiten zur Kategorisierung. Die folgende Grafik gibt einen exemplarischen Überblick über eine mögliche Einteilung der IT-Sourcing-Formen und veranschaulicht, wie sich deren jeweilige Bezeichnungen je nach Kontext ändern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Dimensionen des IT-Sourcings^[55]

Eine detaillierte Erläuterung jeder der dargestellten Sourcing-Formen findet an dieser Stelle nicht statt. Für interessierte Leser wird die Lektüre der angegebenen Quelle oder aber des in dieser Arbeit mehrfach referenzierten Leitfadens des BITKOM zur Terminologie im Bereich Outsourcing empfohlen.^[56]

Das für diese Arbeit relevante IT-Outsourcing wird im kommenden Abschnitt erläutert. Hierzu wird eine Einteilung dessen jeweiliger Formen verwendet, die den Bezug zwischen IT-Outsourcing und der Ausprägungen des Cloud Computing deutlich macht.

2.2.2 IT-Outsourcing

Das IT-Outsourcing kann definiert werden als „die vollverantwortliche Übertragung von IT-Funktionen und/oder Geschäftsprozessen mit hohem IT-Anteil an rechtlich selbständige – d.h. externe – Dienstleister über einen definierten Zeitraum.“^[57]

Die folgende Abbildung gibt einen Überblick über die verschiedenen Formen des IT-Outsourcing aus Sicht des BITKOM mit entsprechenden Beispielen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Formen des Outsourcing gemäß BITKOM^[58]

Die jeweiligen Formen des IT-Outsourcing sind dabei wie folgt definiert:

Infrastructure Outsourcing: „Teil des IT-Outsourcing, bei dem Betrieb und Wartung der IT-Infrastruktur bzw. von Teilen der IT-Infrastruktur sowie Support-Dienstleistungen durch einen externen Dienstleister vollverantwortlich erbracht werden.“^[59]

Application Outsourcing: „Form des IT-Outsourcing, bei der die Verantwortung für die sachgerechte Funktionsfähigkeit der Anwendung voll auf einen externen Dienstleister übergeht.“^[60]

BPO: „Übernahme eines kompletten Geschäftsprozesses oder Teilen davon und ggf. der dazu erforderlichen, den Prozess unterstützenden IT-Infrastruktur durch einen externen Dienstleister. […] Im Gegensatz zum Business Transformation Outsourcing (BTO) erfolgt beim BPO i.d.R kein Reengineering der Prozesse.“^[61]

An der hier dargestellten Art der Unterteilung lässt sich der Bezug zum Cloud Computing gut verdeutlichen. Wie später zu erkennen sein wird, ist Infrastructure as a Service (IaaS) dem Infrastructure Outsourcing zuzuordnen und Platform as a Service (PaaS) und SaaS dem Application Outsourcing. Es sei auch erwähnt, dass ebenfalls ein aus SaaS hervorgehendes Business Process as a Service (BPaaS) existiert,^[62] welches man dem BPO zuordnen kann. Auf BPaaS wird in dieser Arbeit jedoch nicht näher eingegangen. Die Ausprägungen IaaS, PaaS und SaaS werden in den Abschnitten 2.3.2 und 2.3.3 näher erläutert.

Eine sehr IT-nahe Definition des Begriffs Outsourcing liefert auch Helmut Krcmar:

„Outsourcing ist eine Zusammensetzung der Wörter Outside, Resource und Using. Es bedeutet, dass einzelne Aufgaben der IT […] auf Basis einer vertraglichen Vereinbarung, für einen definierten Zeitraum an ein anderes Unternehmen abgegeben werden. Dabei ist nicht festgelegt, ob die IT-Funktion zuvor im Unternehmen angesiedelt war oder direkt an einen externen Anbieter ausgelagert wird. Es umfasst die Auslagerung (externes Outsourcing), d.h. die Übertragung von Aufgaben an ein (rechtlich) externes Unternehmen sowie die Ausgliederung (internes Outsourcing) an ein rechtlich verbundenes anderes Unternehmen (Shared Services).“^[63]

Die Problemstellung dieser Arbeit lässt sich gemäß dieser Definition einordnen als ein externes IT-Outsourcing (Public Cloud) von Applikationen (Software/SaaS), wobei die jeweilige Funktion bereits im Unternehmen angesiedelt war (Systemwechsel).

Zu beachten ist hierbei, dass einzelne Outsourcing-Formen nur schwer voneinander zu trennen sind.^[64] IT-Outsourcing umfasst zu einem gewissen Teil immer auch Prozesse,^[65] die sich von den an ihnen beteiligten Applikationen nicht vollständig trennen lassen.^[66] Auch kann sich anwendungsnahes Outsourcing auf Mitarbeiter beziehen.^[67]

2.2.3 Modelle und Theorien im IT-Outsourcing

Die Untersuchung und Auswahl vorhandener Modelle im Bereich des IT-Outsourcing als Basis für ein neues Modell stellt einen wesentlichen Bestandteil dieser Arbeit dar. Aus diesem Grund erfolgt die detaillierte Ausarbeitung dieser Thematik im Ergebnisteil (Kapitel 4). An dieser Stelle erfolgt lediglich eine grobe Einführung.

Im Bereich des IT-Outsourcing existieren zahlreiche Ansätze, welche als Basis für ein neues Modell dienen können. Ein Weg zu einer objektiven Auswahl besteht beispielsweise im Aufstellen von Anforderungen, welche diese zur Eignung für eine spezifische Problemstellung erfüllen müssen.^[68] (Wie im Abschnitt 2.1.1 bereits geschehen)

Vorhandene Vorgehensmodelle, ähnlich dem Auswahlprozess für Standardsoftware^[69] oder Make-or-Buy-Entscheidungen,^[70] können hier als Basis dienen.

Auch verschiedene Theorien, die im Bereich des IT-Outsourcing herangezogen werden, wie beispielsweise die Transaktionskostentheorie, liefern für ein neues Modell wichtige Anregungen.^[71]

Wie nun zu erahnen ist, ist die Fülle an Ansätzen im Bereich des IT-Outsourcing beachtlich. Dies verdeutlicht die hohe Relevanz einer methodisch korrekten und wohl argumentieren Vorgehensweise bei der Auswahl und Bewertung jener Ansätze, die als Basis für ein neues Modell dienen sollen.

2.3 Arten des Softwarebetriebs

Software kann heutzutage auf verschiedene Art und Weise betrieben werden. Dieser Abschnitt gibt einen kurzen Überblick über verschiedene Möglichkeiten des Softwarebetriebs und liefert damit wichtige Grundlagen zum Verständnis der folgenden Kapitel.

2.3.1 On-Premise Software

Die englische Wortwendung „on the premises“ bedeutet übersetzt „im Hause“ oder „an Ort und Stelle“.^[72] Die hiervon abgeleitete Bezeichnung On-Premise Software steht im geschäftlichen Umfeld also für Software, welche in den Räumlichkeiten eines Unternehmens betrieben wird. Dies stellt die „herkömmliche“ Art des Softwarebetriebs dar, die auf dem Software-Markt nach wie vor dominierend ist.^[73]

2.3.2 Cloud Computing

Cloud Computing wird vielerorts als der zurzeit bedeutendste IT-Trend bezeichnet^[74] und ermöglicht ganz neue Geschäftsmodelle.^[75] Dies mag, zusammen mit der Neuheit des Themas, der Grund dafür sein, dass es keine einheitliche und allgemein anerkannte Definition für diesen Begriff gibt.^[76]

Eine Definition, die oft zitiert wird und vielerorts Anerkennung findet,^[77] ist die des National Institute of Standards and Technology (NIST). Diese lautet wie folgt:

“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources […] that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics , three service models, and four deployment models.”^[78]

Dabei werden die folgenden fünf Charakteristika als essentiell betrachtet:^[79]

- Dienstnutzung nach Bedarf: Nutzer können Dienste selbst und ohne menschliche Interaktion seitens des Anbieters anfordern.
- Netzwerkbasierter Zugang: Funktionalitäten sind über Netzwerke mit Hilfe standardisierter Mechanismen nutzbar.

[...]

^[1] Vgl. Baun u.a. (2011), S. 1

^[2] Carr (2011), URL siehe Literaturverzeichnis, zitiert nach: Hülsbömer (2011), URL siehe Literaturverzeichnis, o.V. (2011a), URL siehe Literaturverzeichnis

^[3] Gartner Inc. (2011a), URL siehe Literaturverzeichnis

^[4] Gartner Inc. (2011b), entnommen aus: Columbus (2011), URL siehe Literaturverzeichnis

^[5] Gartner Inc. (2011c), URL siehe Literaturverzeichnis

^[6] Google Inc. (2011), Grafik erstellt mit Google Trends, URL siehe Literaturverzeichnis

^[7] Vgl. Buchta u.a. (2005), S. 9-12

^[8] Vgl. Schröder (2011), S. 144

^[9] Vgl. Abschnitt 2.3.3

^[10] Vgl. Pelzl/Herzwurm (2010), S. 155-157

^[11] Münzl u.a. (2009), S. 16ff.

^[12] Siehe Böttger (2010a)

^[13] Vgl. Wolters/Kaschny (2010), S. 24, Stahlknecht/Hasenkamp (2005), S. 299

^[14] Vgl. Hennenberger u.a. (2010), S. 76

^[15] Vgl. Zogg/Schroth (2011), URL siehe Literaturverzeichnis, Interview mit Markus Eilers am 22.08.2011

^[16] Vgl. Söbbing u.a. (2006), S. 80-81

^[17] Interview mit Markus Eilers am 22.08.2011

^[18] Eigene Arbeitsdefinition

^[19] Vgl. Abschnitt 2.5.4

^[20] Vgl. Experton Group (2009), S. 2, URL siehe Literaturverzeichnis, Weber (2010), S. 20

^[21] Vgl. Wolters/Kaschny (2010), S. 19

^[22] Vgl. Abschnitt 2.5.4

^[23] Vgl. Wolters/Kaschny (2010), S. 20ff.

^[24] Vgl. Abschnitt 2.1.1

^[25] O.V. (2011b), S. 34-37

^[26] Vgl. Strahringer (2010), URL siehe Literaturverzeichnis; Heinrich u.a. (2011), S. 214ff.

^[27] Kosiol (1961), S. 319

^[28] Vgl. Strahringer (2010), URL siehe Literaturverzeichnis

^[29] Vgl. ebenda

^[30] Vgl. Stachowiak (1973), S. 131-133

^[31] Vgl. Schwarzer/Krcmar (2010), S. 94

^[32] Vgl. Stahlknecht/Hasenkamp (2005), S. 214

^[33] Heinrich u.a. (2011), S. 142

^[34] Vgl. ebenda, S. 321

^[35] Vgl. Stahlknecht/Hasenkamp (2005), S. 215

^[36] Vgl. ebenda, S. 459

^[37] Vgl. Herzwurm/Pietsch (2009), S. 269ff.

^[38] Vgl. ebenda, S. 276-277

^[39] Vgl. ebenda, S. 275-276

^[40] Vgl. ebenda, S. 276

^[41] Gartner Inc. (2011d), URL siehe Literaturverzeichnis

^[42] Vgl. Grohmann (2009), S. 38f.

^[43] Vgl. ebenda, S. 39ff., Härting/Folmayer (2008), S. 204f.

^[44] Vgl. Grohmann (2009), S. 38

^[45] Vgl. Küchler (2009), S. 109-110

^[46] Vgl. Ebel 2008, S. 742

^[47] Vgl. Domschke/Scholl (2008), S. 61f.

^[48] Vgl. ebenda, S. 62f.

^[49] Vgl. Herzwurm/Pietsch (2009), S. 283f.

^[50] Vgl. Tamm u.a. (2008), S. 16, Mach (2009), URL siehe Literaturverzeichnis

^[51] Vgl. Härting/Folmayer (2008), S. 206

^[52] Vgl. Domschke/Scholl (2008), S. 63

^[53] Bruch (1998), S. 16

^[54] BITKOM (2008), S. 34

^[55] Schwarze/Müller (2005), S. 12

^[56] Siehe. BITKOM (2008)

^[57] Ebenda S. 19

^[58] Barsch u.a. (2009), S. 13, URL siehe Literaturverzeichnis

^[59] BITKOM (2008), S. 17

^[60] Ebenda, S. 3

^[61] Ebenda, S. 8

^[62] Vgl. Weber 2010, S. 13 und 16

^[63] Krcmar (2010), S. 473

^[64] Vgl. Picot (2011), S. 3

^[65] Vgl. ebenda, S. 5f.

^[66] Vgl. Dittrich/Braun (2004), S. 4

^[67] Vgl. ebenda

^[68] Vgl. Krause 2008, S. 104ff.

^[69] Siehe z.B. Stahlknecht/Hasenkamp (2005), S. 299-304

^[70] Siehe z.B. Laudon u.a. (2006), S. 302

^[71] Vgl. Heinrich u.a. (2011), S. 333ff.

^[72] Eigene Übersetzung

^[73] Vgl. Weber (2010), S. 24

^[74] Siehe Einleitung

^[75] Vgl. Herzwurm u.a. (2010), S. 741-744

^[76] Vgl. ebenda, S.741, Baun u.a. (2011), S. 1

^[77] Vgl. Baun u.a. (2011), S. 5

^[78] Mell/Grance (2010), URL siehe Literaturverzeichnis

^[79] Vgl. ebenda, Übersetzung angelehnt an Baun u.a. (2011), S. 5