Projektbasiertes Software-Offshoring

Untersuchung der Möglichkeiten des webbasierten Software-Offshorings


Diplomarbeit, 2011

176 Seiten, Note: 1,9


Leseprobe


Inhaltsverzeichnis

I. ABBILDUNGSVERZEICHNIS

II. TABELLENVERZEICHNIS

1 EINLEITUNG

2 THEORETISCH-METHODISCHE GRUNDLAGEN
2.1 OFFSHORING UND DESSEN RECHTLICHE GESTALTUNG
2.1.1 Offshoring - Abgrenzung und Definition
2.1.2 Offshoring-Formen und -Typen
2.1.3 Chancen und Risiken von Offshoring
2.1.4 gesellschaftlicher und kultureller Vergleich
2.1.5 nationale und internationale Rechtsgrundlagen
2.1.6 Vertragsgestaltung beim Software-Offshoring
2.1.6.1 Vertragstypen
2.1.6.2 Vertragsbestandteile
2.2 SPEZIALISIERTE INTERNETPORTALE
2.2.1 Geschäftskonzept Web 2.0 Offshoring
2.2.2 elektronischer Geldtransfer
2.3 SOFTWAREENTWICKLUNG
2.3.1 Spezifikationserstellung
2.3.2 Vorgehensmodelle
2.3.3 Risikomanagement
2.3.4 Softwareabnahme
2.4 WIRTSCHAFTLICHKEITSBETRACHTUNGEN
2.5 PROJEKTMANAGEMENT
2.5.1 Begrifflichkeiten
2.5.2 Projektmanagementphasen
2.5.3 Projektorganisation

3 ANALYSE DES PROJEKTES„SCHICHTPLAN“ DER FIKTIV GMBH
3.1 PROJEKTSTRUKTUR
3.1.1 Projektierung und das Umfeld der Fiktiv GmbH
3.1.2 Offshoring Entscheidung
3.1.3 Anforderungserhebung
3.1.4 Erstellung der Spezifikation
3.2 EINSATZ VON SPEZIALISIERTEN INTERNET-PORTALEN
3.2.1 Lieferantenauswahl und Auftragsvergabe
3.2.2 webbasierte Projektsteuerung mit dem Offshore-Partner
3.2.3 Risikomanagement
3.2.4 Abnahme und Abschluss des Projektes
3.3 WIRTSCHAFTLICHE BETRACHTUNG DES PROJEKTES„SCHICHTPLAN“
3.3.1 Kosten und deren Struktur im Vergleich
3.3.2 Nutzwertanalysen zur qualitativen Bewertung

4 EINSATZSZENARIEN FÜR SPEZIALISIERTE INTERNET-PORTALE IN OFFSHORING- PROJEKTEN

5 ZUSAMMENFASSUNG DER ERGEBNISSE

LITERATURVERZEICHNIS

EHRENWÖRTLICHE ERKLÄRUNG

GLOSSAR

ANLAGE 1 PROJEKTIERUNG

ANLAGE 2 LASTENHEFT

ANLAGE 3 RISIKOANALYSE

ANLAGE 4 VERTRAG

ANLAGE 5 TESTSPEZIFIKATION

ANLAGE 6 PROJEKTABSCHLUSSBERICHT

I. Abbildungsverzeichnis

Abbildung 1: Offshoring-Typen

Abbildung 2: Offshoring-Formen

Abbildung 3: Bewertung von Offshore Standorten

Abbildung 4: Risikoverteilung der Vertragsarten

Abbildung 5: Kosten einer Vertragsauflösung

Abbildung 6: Kategorisierung von Zahlungssystemen

Abbildung 7: Eigenschaften von Techniken der Informationsgewinnung

Abbildung 8: Klassifizierung von Prozess- & Qualitätsmodellen

Abbildung 9: Spiralmodell nach Böhm

Abbildung 10: Der Risikomanagementprozess

Abbildung 11: Black-Box-Tests

Abbildung 12: magisches Dreieck

Abbildung 13: Der Projektstart

Abbildung 14: Matrixprojektorganisation

Abbildung 15: Organigramm Fiktiv GmbH

Abbildung 16: Projektstrukturplan

Abbildung 17: Projektpersonalbedarfsplan

Abbildung 18: Anforderungsliste

Abbildung 19: Anforderung im Lastenheft

Abbildung 20: Projektstatusbericht

Abbildung 21: getacoder.com Nachrichtensystem

Abbildung 22: Risikoanalyse

Abbildung 23: Maßnahmen zur Risikosteuerung

Abbildung 24: Risikoüberwachung

Abbildung 25: Qualitätssicherungsprozess

Abbildung 26: Testspezifikation

Abbildung 27: Kostenstruktur Projekt Schichtplan Internet-Offshore

Abbildung 28: Kostenstruktur bei Onshore-Lieferant

Abbildung 29: Kostenstruktur Projekt Schichtplan classic Offshore

Abbildung 30: Kostenvergleich

Abbildung 31: Nutzwertanalyse Kommunikation

Abbildung 32: Nutzwertanalyse Arbeitsqualität

Abbildung 33: Nutzwertanalyse rechtliche Bewertung

Abbildung 34: magisches Dreieck für Offshoring über Internet-Plattformen

Abbildung 35: Kriterien für Einsatzszenarios

II. Tabellenverzeichnis

Tabelle 1: Vor- und Nachteile von Preismodellen

Tabelle 2: Nutzwertanalyse Anbieterwahl

Tabelle 3: Testergebnisse

Tabelle 4: Abnahmetests

1 Einleitung

Die internationale Vergabe von Aufträgen gehört schon seit über 50 Jahren in einigen Wirt- schaftsbereichen zum Alltag. In den letzten Jahren erfährt auch der IT-Sektor diese Wande- lung und kann mit zweistelligen Zuwachsraten pro Jahr vorweisen. Die vermehrte Auftrags- vergabe in Niedriglohnländer wird„Offshoring“ genannt und resultiert unter anderem aus dem immer stärker werdenden Kostendruck, der auf den internationalen Märkten vorherrscht. Des Weiteren versuchen sich Unternehmen auf ihr Kerngeschäft zu fokussieren.

Ein weiterer Grund, der Offshoring Aktivitäten begünstigt, ist die demographische Entwick- lung in den Industrienationen, welche ein wachsendes Defizit an Fachkräften zu verzeichnen hat.

Ein Projekt wird von der DIN 69901 folgendermaßen definiert:

Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifi- sche Organisation.

Ableitend von dieser Definition ist eine projektbasierte Vergabe von Offshoring Aktivitäten zeitlich begrenzt und auf ein spezielles Vorhaben beschränkt. Dauerhaft angelegte Offshoring Vorhaben werden in der einschlägigen Literatur ausreichend beschrieben und werden in dieser Arbeit nicht weiter behandelt.

Projektmanagement als Grundlage jeder Projektarbeit und -zusammenarbeit wird in allen möglichen Formen zur Verfügung gestellt und nach entsprechenden Standards zertifiziert. Im Zusammenspiel von projektbasiertem Offshoring und der Zielgruppe dieser Arbeit, den mittelständischen Unternehmen, sind Ansätze in der Literatur erkennbar. Darin fehlt aber die Ausführlichkeit der Betrachtungen und der Blick über eine Auftragsvergabe im gleichen Marktsegment heraus, z. B. eine Softwareentwicklungsfirma vergibt Aufträge zur Entwicklung neuer Software an Offshoring-Partner.

Eine wissenschaftliche Betrachtungslücke besteht darin, dass sich Unternehmen aus anderen Marktbereichen am Software Offshoring beteiligen. Hier wird es im internationalen Wettbewerb immer wichtiger sich einen Vorteil zu verschaffen, der mit Standardsoftware kaum noch realisierbar ist. Aufgrund der wachsenden Spezialisierung von Unternehmen und deren Geschäftsprozessen sind entsprechend auf den Kunden zugeschnittene Softwaresysteme immer bedeutender. Projekte dieser Art sind z. B. das Bundeswehrprojekt„Herkules“ oder das„A2LL“ System der Arbeitsagenturen.

Diese Form von Projekten verfügen über ein Budget, welches sich in der Zielgruppe der mit- telständischen Unternehmen nicht realisieren lässt. Insbesondere die beim Offshoring durch die große Entfernung anfallenden Reisekosten zur persönlichen Kommunikation mit dem Auftragnehmer sind nicht zu vernachlässigen. Unter anderem diese Hemmschwelle für klei- nere Unternehmen führt zu einer Verlagerung des Offshoring Prozesses in das Internet und auf dort spezialisierte Portale. Die Verlagerung bietet für die beteiligten Unternehmen zahl- reiche Möglichkeiten aber auch zusätzliche Risiken. Diese werden im Rahmen der Arbeit näher betrachtet.

Ziel dieser Arbeit ist die Analyse und Bewertung der Nutzungsmöglichkeiten von spezialisierten Internetportalen für Offshoring Projekte von mittelständischen Unternehmen.

Die Wirtschaftsinformatik ist die„Wissenschaft von dem Entwurf, der Entwicklung und der Anwendung computergestützter Informations- und Kommunikationssysteme (IuK-Systeme) und -techniken in Unternehmungen und Verwaltungen zur Unterstützung ihrer Geschäftsprozesse „(Gabler Wirtschaftslexikon).

Ableitend von dieser Definition der Wirtschaftsinformatik und der vorhandenen Vielfalt der Aufgabengebiete werden einige methodischen Grundlagen intensiver in dieser Arbeit betrachtet. Dazu gehören die Themenkomplexe der Softwareentwicklung mit den Vorgehensmodellen und die Wirtschaftlichkeitsbetrachtungen von Projekten. Projektmanagement und Recht sind weitere Bestandteile der Wirtschaftsinformatik und dieser Arbeit. Aufbauend auf die Vorüberlegungen werden im Kapitel 2 die angewandten Begriffe konkretisiert und ausführlicher erläutert. Betrachtet werden in diesem Kapitel auch die Phasen der Softwarentwicklung und die Grundzüge des Projektmanagements. Anwendbare Gesetze werden ebenso angesprochen wie die Grundlage des elektronischen Geldaustausches.

Im folgenden Kapitel 3 werden die angesprochenen Punkte anhand eines fiktiven Projektes und Unternehmens aufgenommen und eingeordnet. Das Projekt orientiert sich dabei an den Gegebenheiten der Zielgruppe der mittelständischen Unternehmen und ermöglicht eine Betrachtung aller relevanten Zusammenhänge anhand praktischer Gesichtspunkte.

Im Kapitel 4 werden Einsatzszenarios beschrieben, bei denen die in der Arbeit vorgestellten Offshoring Variante sinnvoll und ökonomisch erscheinen.

Das abschließende Kapitel 5 stellt alle angesprochenen Punkte in Beziehung zueinander, so- dass die zentrale Fragestellung der Nutzungsmöglichkeiten solcher Projekte beantwortet wer- den kann.

2 Theoretisch-methodische Grundlagen

2.1 Offshoring und dessen rechtliche Gestaltung

2.1.1 Offshoring - Abgrenzung und Definition

Offshoring wird in den Medien immer wieder aufgegriffen und thematisiert, wie im Handels- blatt vom 28.10.2010 geschehen. Dabei werden Begriffe wie„Offshoring“ und„Outsour- cing“ in einem Atemzug genannt, was nicht immer korrekt ist. Outsourcing wird schon seit den 60-iger Jahren des letzten Jahrhunderts praktiziert, als die ersten Produktionsstätten von US-amerikanischen Unternehmen nach China verlagert wurden. (vgl. Gadatsch, 2006, S.12) Outsourcing ist dabei ein Kunstwort und setzt sich aus den Einzelworten„outside“,„resource“ und„using“ zusammen. Es beschreibt ein Konzept, bei dem ausgewählte Prozesse an externe Dienstleister übergeben werden und für diese Prozesse auch ein Verantwortungsübergang stattfindet. (vgl. Ebert, Outsourcing Kompakt, 2006, S.1)

Dabei spielt es keine Rolle, wo dieser Dienstleister seinen Sitz hat und die Prozesse für den Kunden realisiert. Der erste Versuch, IT-Prozesse auszulagern, wurde 1962 von Ross Perot unternommen. Er war seines Zeichens Gründer der Firma EDS (Electronic Data System Corporation), die heute einer der großen IT-Dienstleister ist und Outsourcing in weltweit 60 Ländern anbietet. (vgl. Ebert, Outsourcing Kompakt, 2006, S.2) Offshoring bekam erst später eine Bedeutung durch die Verlagerung von Standorten der Finanzbranche in„Steuerparadiese“. Diese lagen meist auf Inseln in Küstennähe, wodurch sich auch das Wort bildete:„off shore“ übersetzt„außerhalb der Küstengewässer liegend“. (vgl. Kunz & Neuhaus, 2006, S.2)

Erst Ende der 90iger Jahre wurde das Thema Offshoring auch für IT-Unternehmen interessant, als sich herausstellte, dass viele Softwaresysteme für den Jahrtausendwechsel nicht gerüstet waren und dringend angepasst werden mussten. Viele der Systeme waren zu diesem Zeitpunkt aber kaum noch in Wartung und die Programmiersprachen überholt, so dass in den Industrienationen kaum noch dafür benötigtes Wissen vorhanden war. Eine weltweite Suche nach gut ausgebildeten Personal mit entsprechenden Kentnissen führte nach Indien. Dieses bis dahin als unterentwickeltes geltenes Land konnte die Nachfrage nach Experten befriedigen und zusätzlich eine hohes Qualitätsniveau bieten. Indien stieg dadurch zum weltweit größten Anbieter von IT-Dienstleistungen auf und führte zu einem„Offshoring- Hype“ bei den IT-Unternehmen. (vgl. Ebert, Outsourcing Kompakt, 2006, S.2)

Offshoring ist dabei nicht gleichzusetzen mit Outsourcing auch wenn die Beweggründe ähnlich erscheinen mögen. Großer Unterschied dabei ist, dass Offshoring eine Verlagerung von Unternehmensaktivitäten in ein Land fokussiert, welches ein niedrigeres Lohnniveau als das Usprungsland bietet, deshalb auch„Niedriglohnland“ genannt. Die Verlagerung muss damit nicht zwangsläufig ausserhalb des eigenen Unternehmens stattfinden. Dies stellt den westentlichen Unterschied zu Outsourcing dar, welches wie oben erwähnt, eine Vergabe an einen externen Dienstleister zum Ziel hat. Es besteht aber grundlegend auch die Möglichkeit beide Strategien zu kombinieren, die verschiedenen Varianten werden in Kapitel 2.1.2 tiefergehend behandelt. Eine weit verbreitete Auffassung ist, dass Offshoring eine spezielle Unterform des Outsourcing darstellt, welche aufgrund der wirtschaftlichen Bedeutung und Nähe der beiden Themen in dieser Arbeit geteilt wird. (vgl. Nicklisch, Borchers, Krick, & Rucks, 2008, S.39 sowie Boes & Schwemmle, 2005, S.9) Zum Offshoring gehört wie in diesem Kapitel mehrfach erwähnt die Verlagerung in Niedriglohnländer, welche sich auf anderen Kontinenten befindet. Verlagerungen in Niedriglohnländer auf dem eigenen Kontinent werden dagegen als Nearshoring bezeichnet. Zur Vereinfachung wird in dieser Arbeit nicht weiter zwischen Near- und Offshore differenziert, sondern auf den Begriff Offs- hore reduziert.

2.1.2 Offshoring-Formen und -Typen

In den vergangenen Jahren haben sich zum klassischen Offshoring, welches auch OffshoreOutsourcing genannt wird, noch viele weitere Typen und Formen entwickelt.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Schaaf, 2004

Abbildung 1: Offshoring-Typen

Nationale Fremdvergabe oder auch„Onshore Outsourcing“ stellt die in Deutschland am häufigsten verwendete Auftragsvergabe an externe Dienstleister in der Softwareentwicklung dar. Hierbei befinden sich Auftraggeber und -nehmer im gleichen Land. Unter„Captive Offshoring“ wird ein Entwicklungszentrum in einem Offshoring-Land verstanden, welches organisatorisch zum Auftraggeber gehört. (vgl. Abbildung 1)

Der Umfang der betroffenen Dienstleistungen hat sich in den vergangenen Jahren in unter- schiedliche Richtungen entwickelt und hat dabei mehrere Formen des Offshorings definiert. Diese werden anhand der Organisations-, der Leistungs- und der Gestaltungsform unterschie- den.

Jedes Unternehmen muss sich beim Offshoring entscheiden, ob es eine partielle oder totale Verlagerung der Aktivitäten vornehmen möchte. Beim totalen Offshoring werden mehr als 80 Prozent des Prozesses an den Dienstleister gegeben. (vgl. Amberg & Wiener, 2006, S.18-19) Der Einfluss des Auftraggebers auf den verlagerten Prozess stellt oft ein entscheidendes Kri- terium dar. Das Tochterunternehmen ist dabei die Form mit dem größten Einfluss, da kein Fremdunternehmen involviert ist. Die Gründung eines eigenen Tochterunternehmens ist eine Möglichkeit, die Andere ist der Kauf und Integration eines ortsansässigen Anbieters. Die Re- alisierung dieser Organisationsform birgt aufgrund der hohen Anfangsinvestitionen große Risiken, welche durch die Gründung eines Shared-Service-Centers etwas abgeschwächt wer- den können. Die Center bieten ihre Dienstleistungen nicht nur dem eigenen Unternehmen in Form der internen Leistungserbringung an, sondern auch externen Kunden, was eine zusätzli- che Einnahmequelle bedeutet. Des Weiteren erhöht die Teilnahme am internationalen Wett- bewerb das Verständnis für Qualität und verringert die Kosten aufgrund des Konkurrenzdru- ckes. Eine weitere Form ist die Gründung eines Joint Venture Unternehmens, wobei die Ressourcen von mindestens zwei Unternehmen zum Aufbau erforderlich werden. Im Normalfall werden die Ressourcen eines ortsansässigen Unternehmens mit Erfahrungen genutzt um Synergieeffekte auszunutzen. Die Anfangsinvestitionen sind dabei geringer und die Risiken auf alle Unternehmen verteilt, wodurch dies einen Mittelweg darstellt zwischen Tochterunternehmen und der kompletten Vergabe an ein Fremdunternehmen. Diese letzte Form erhöht die Flexibilität und verringert die Kosten auf ein Minimum, da der komplette Auftrag vergeben wird. (vgl. Abbildung 2) Im Fall von Offshore Outsourcing ist auch ein Personalübergang zum Dienstleister möglich. Ein Großteil der bestehenden Risiken wird auf den Auftragnehmer übertragen, dafür ist die Einflussnahme des Auftraggebers nur begrenzt möglich. (vgl. Amberg & Wiener, 2006, S. 21-26)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Offshoring-Formen

Die Art der verlagerten Dienstleistung wird als Leistungsform bezeichnet. Eines der belieb- testen Dienstleistungen im Offshoring ist das„Infrastructure Service Offshoring“ bei dem Hardware oder Software verlagert wird. Die weltweite Vernetzung und Erhöhung der Band- breiten im internationalen Datenaustausch stellt eine ideale Basis für diese Form der Verlage- rung dar. Der Auftraggeber kann über das Internet oder spezielle Datenverbindungen die zentral vom Auftragnehmer zur Verfügung gestellten Ressourcen nutzen und zahlt nur für die reine Benutzung. Die Kosten für Anschaffung, Wartung oder Reparatur verbleiben beim Offshoring-Partner und erhöhen die finanzielle Flexibilität beim Auftraggeber. Das„Software Development Offshoring“ war in der Vergangenheit der Wachstumstreiber für Offshoring- Aktivitäten speziell beim Jahrtausendproblem. Dabei wird die Softwareentwicklung im Gan- zen oder Teilen an einen Auftragnehmer vergeben, der sich dann um die Softwareentwick- lung, die Softwaremigration oder die Wartung und Pflege von Softwaresystemen kümmert. Es spielt dabei meistens keine Rolle, ob es sich um bestehende Software handelt oder um neu zu entwickelnde Individualsoftware.„Business-Process-Offshoring“ ist eine noch neue Form des Offshorings, wobei ein kompletter Geschäftsprozess verlagert wird. Diese Prozesse zeichnen sich durch häufige Wiederholungen des Prozesszyklus aus, was aber ein hohes Branchenwissen beim Offshoring-Partner voraussetzt. Diese Form ist eine der kosteninten- sivsten, da ein hoher Kommunikationsaufwand vorliegt und alle Phasen mit dem Partner durchlaufen werden müssen. (vgl. Amberg & Wiener, 2006, S.10-15)

2.1.3 Chancen und Risiken von Offshoring

Offshoring suggeriert großes Einsparpotential für den Auftraggeber durch die niedrigen Lohnkosten in den Niedriglohnländern. Dieses Image ist unvollständig und gefährlich, da es Hoffnungen weckt, die nicht erfüllt werden können. Für eine umfassende Analyse und Ent- scheidung sollten alle Chancen und Risiken bekannt sein. Die Chancen lassen sich in drei Bereiche einteilen: die finanziellen, qualitativen und strategischen Chancen. Die finanziellen Chancen umfassen zum einen die Reduzierung der IT-Kosten, welche auf den schon oben genannten niedrigen Lohnkosten und der Verbesserung der Produktivität durch Spezialisie- rung beruhen. Internen Abteilungen werden anfallende Kosten über die Kostenstellenrech- nung zugerechnet, die Gemeinkosten sind dabei aber nur pauschal angesetzt, sodass eine kor- rekte Zuordnung aller Kosten in den meisten Unternehmen nicht möglich ist. Offshoring Ver- träge legen die Kosten für die gleiche Dienstleistung fest, wodurch eine korrekte Zuordnung aller Kosten möglich ist. Dies erhöht die Transparenz und ermöglicht eine bessere Budget- planung. Bei Personal- oder Sachübergängen lassen sich die bis dahin angefallenen Fixkosten dem Offshoring-Partner übergeben und Kapitalbindungen durch Verkäufe von Hardware, Lizenzen oder Infrastruktur auflösen, was Ressourcen für andere Projekte zur Verfügung stellt. (vgl. Amberg & Wiener, 2006, S. 39-42) Die Verbesserung der Servicequalität durch den internationalen Wettbewerbsdruck, dem die internen Abteilungen in der Regel nicht standhalten müssen, gehört zu den qualitativen Chancen. Vertraglich geregelte Service Level Agreements für Verfügbarkeiten mit den Optionen der Vertragsstrafen oder -auflösung und Zugang zu technischem Know How des Offshoring-Partners sind weitere Bestandteile der qualitativen Chancen. Große Möglichkeiten bieten sich im strategischem Umfeld. Neben den Kostenvorteilen ist es für Auftraggeber besonders wichtig sich zu flexibilisieren, indem Personalengpässe und -überhänge bei Auftragsschwankungen durch Offshoring umgangen werden. Des Weiteren kann sich ein Unternehmen auf seine Kernkompetenzen konzentrieren, wenn interne Arbeiten mit hohem Verwaltungsaufwand und geringen Nutzen für den Unternehmenserfolg an spezialisierte Dienstleister vergeben werden. Die freiwerdenen Ressourcen beim Auftraggeber können für andere Aktivitäten verwendet werden, die einen höheren Unternehmenserfolg erwarten lassen. In der schnelllebigen IT-Welt haben immer mehr Unternehmen Schwierigkeiten auf den neusten Stand der Technik zu sein und eigene Mitarbeiter entsprechend weiterzubilden. Das kann ein entscheidener Wettbewerbsnachteil gegenüber den Mitbewerbern sein. Offshoring bietet die Möglichkeit das fehlende Wissen einzukaufen und die Nachteile auszugleichen oder eventuell auch in Vorteile umzuwandeln. Dieser strategische Gewinn kann auch bei zeitkritischen Entwicklungen zur Marktreife genutzt werden, indem zusätzliche Ressourcen beim Offshoring-Partner aquierierbar sind. (vgl. Amberg & Wiener, 2006, S.42-46 und Steimle, 2007, S.17-18)

Viele Unternehmer lassen sich von den vielen Chancen und Möglichkeiten blenden und über- stürzen ihre Offshoring-Entscheidung, wobei die Risiken vernachlässigt werden. Die Risiken fangen schon im Auftrag gebenden Unternehmen an, wenn nicht geeignete Prozesse oder Unternehmensaktivitäten ausgewählt werden. Insbesondere unternehmenskritische Prozesse oder Aktivitäten sollten nicht für Offshoring-Vorhaben ausgewählt werden, da die Risiken für das Unternehmen zu hoch wären. Die Auswahl des richtigen Geschäftspartners ist schon in- nerhalb des eigenen Landes eine komplizierte und schwierige Situation. Die Entfernungen des Offshorings verkomplizieren diesen Auswahlprozess erheblich, das liegt zum Einen an den sprachlichen Barrieren aber auch an unterschiedlichen Qualitätsstandards. Ist der richtige Partner gefunden, können im Laufe der Zusammenarbeit weitere Probleme entstehen. Eine Insolvenz des Offshoring-Partners führt zu einem Verlust der Anfangsinvestitionen und eine Neuvergabe oder Reintegration der Prozesse ist die Folge. Die dafür benötigten zusätzlichen Ressourcen stehen nach der Verlagerung im Regelfall nicht mehr zur Verfügung, durch Ver- kauf von Sachmitteln und Abbau oder Umschulung von Mitarbeitern. Insbesondere der Ver- lust des Expertenwissens birgt auch andere Risiken, denn dadurch ist die Verhandlungsposi- tion mit dem Partner geschwächt und dessen Leistungen lassen sich nur schwer auf Qualität überprüfen. Negative Auswirkungen auf den Geschäftsbetrieb kann aber auch die eigene Be- legschaft haben, die durch die Verlagerung demotiviert und verängstigt ist. Die Mitarbeiter- motivation wird bei vielen Offshoring-Entscheidungen eher vernachlässigt, obwohl die Aus- wirkungen hohe Risiken beherbergen. (vgl. Amberg & Wiener, 2006, S.48-53 und Steimle, 2007, S.22-23) Offshoring-Risiken liegen auch in der Kooperation und Kommunikation zwi- schen den Vertragspartnern vor und beinhalten die schon vorher angesprochene Sprachbarrie- re, sowie kulturelle Unterschiede. Indien als führender Offshore-Anbieter hat den Vorteil, dass englischsprachige Mitarbeiter weit verbreitet sind, deren Englisch durch den asiatischen Dialekt aber für Europäer gewöhnungsbedürftig ist. Der kulturelle Unterschied zwischen Asi- en und Europa dagegen ist noch sehr stark ausgeprägt und kann zu schwerwiegenden Prob- lemen in der Zusammenarbeit führen. Eine nähere Betrachtung der Unterschiede findet in Kapitel 2.1.4 statt. Bei einer Prozessverlagerung müssen in der Regel auch interne Daten aus- getauscht werden, welches durch das deutsche Datenschutzgesetz stark reglementiert ist. Die Einhaltung der Vorschriften ist am Offshore-Standort nur schwer durchzusetzen und birgt das Risiko einer Veröffentlichung der Daten. Umwelteinflüsse und instabile politische Rahmen- bedingungen im Offshore-Land können ebenso eine Gefahr für die Verlagerung bedeuten und sollten daher vermieden oder abgeschwächt werden. (vgl. Amberg & Wiener, 2006, S.53-55)

2.1.4 gesellschaftlicher und kultureller Vergleich

Kulturelle Unterschiede sind schon innerhalb eines Landes zu erkennen, wie die„Boulette“ in Berlin und die„Weißwürstel“ in München. Dieser Unterschied ist auffällig und führt auch zu hitzigen Diskussionen, behindert aber die Zusammenarbeit relativ wenig. Anders sieht es beim Vergleich zwischen Deutschland und den Offshore-Standorten aus. Eine verkürzte Übersicht der besten Offshore-Standorte bietet AT Kearny, wobei Indien als Marktführer und asiatischer Vertreter und Osteuropa als Ländergruppe durch die geographische Nähe zu Deutschland detaillierter betrachtet werden. (vgl. Abbildung 3)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Bewertung von Offshore Standorten

In Indien ist Deutsch als Fremdsprache ohne Bedeutung, aus diesem Grund muss auf Eng- lisch ausgewichen werden. Dies kann zu Missverständnissen und einem Vertrauensproblem führen. (vgl. Buxmann, Berz, & Hahn, 2007, S.402) In Osteuropa findet man viel deutschsprachiges Personal und auch in den Schulen wird Deutsch als Fremdsprache angeboten. Kommunikationsprobleme sind aus diesem Grund selten zu erwarten. Direkter Kontakt zu indischen Anbietern wird durch drei bis vier Stunden Zeitverschiebung, hohen Reisekosten und langen Reisezeiten beeinflusst. Ein osteuropäischer Anbieter muss sich nur auf ein bis zwei Stunden Zeitverschiebung und kurzen Reisezeiten einstellen, was den persönlichen Kontakt einfacher gestaltet. (vgl. Steimle, 2007, S.73-75) Indien kann ein hohes Humankapital vorweisen, das bedeutet, dass jedes Jahr über 400.000 hoch qualifizierte Fachkräfte die indischen Universitäten verlassen und dem Arbeitsmarkt zur Verfügung stehen. Eine ähnlich hohe Zahl an Hochschulabsolventen können die Länder in Osteuropa nicht bieten. Ein weiterer Punkt sind die Kosten in Form von Arbeitslohn und Steuern, welche in Indien sehr vorteilhaft für Offshoring-Aktivitäten sind. Im Vergleich sind die osteuropäischen Länder kostengünstiger als es in Deutschland der Fall wäre, aber immer noch um einiges teurer als in Indien. (vgl. Abbildung 3) Kulturell gibt es kaum Unterschiede zwischen Deutschland und osteuropäischen Ländern, was einer erfolgreichen Zusammenarbeit zu Gute kommt. Indische Arbeitnehmer haben ein anderes Hierachieverständnis als es in Europa der Fall ist. Bei Entscheidungen oder Fragen werden immer die Vorgesetzten eingeschaltet, auch wenn es sich um kleine Fragstellungen handelt. Es muss daher mit Verzögerungen gerechnet werden. Es gilt in Indien als Gesichtsverlust, wenn gegenüber einem Auftraggeber oder Vorgesetzten eine negative Nachricht überbracht werden muss. Aus diesem Grund ist es oft schwierig eine konkrete und ehrliche Einschätzung zu erhalten. (vgl. Buxmann, Berz, & Hahn, 2007, S.402)

2.1.5 nationale und internationale Rechtsgrundlagen

Bei jedem Vertrag müssen unterschiedliche Gesetze und Vorschriften berücksichtigt werden. Im innerdeutschen Handel ist die Gesetzesgrundlage das Bundesgesetzbuch (BGB), welches die meisten vertraglichen Bestandteile sehr ausführlich regelt. Im Buch 2 des BGB werden Schuldverhältnisse, Verträge und Vertragsstörungen beschrieben, welche auch bei Software- entwicklungsprojekten zum Tragen kommen. Der Werksvertrag spielt dabei eine gesonderte Rolle bei der Entwicklung von Individualsoftware. In den dazugehörigen Paragraphen wer- den viele Möglichkeiten zur Risikominderung beschrieben, diese werden im Einzelnen in Kapitel 2.1.5.3 näher erläutert. Im internationalen Handel treffen dagegen mindestens zwei verschiedene Rechtsformen auf- und in Konkurrenz zueinander. Differenzen können vertrag- lich geregelt werden aber dennoch sind die öffentlich-rechtlichen Vorschriften der Ur- sprungsländer zu berücksichtigen. (vgl. Stadler, 2007, S.3) 1980 wurde in Wien das UN- Kaufrecht von 42 der 62 anwesenden Länder unterzeichnet um eine Grundlage für den internationalen Handel zu schaffen. Aktuell haben 76 Ländern unterschrieben, darunter sind viele Entwicklungsländer, was auf eine breite Zustimmung und weitere Erweiterung schließen lässt. (vgl. Stadler, 2007, S.6) Viele Länder haben das UN-Kaufrecht in nationales Recht integiert, so auch Deutschland, wo internationales Recht automatisch gilt, wenn nicht explizit die deutsche Rechtsordnung vertraglich festgelegt wurde. Das UN-Kaufrecht ist besonders für kleine und mittelständische Unternehmen geeignet, da es ein Grundgerüst für Verträge bietet und teure Individualverträge vermieden werden können. Indien ist kein Mitglied des UN-Kaufrechtes. Dennoch ist es sinnvoll entsprechende Regelungen zu nutzen um grobe Fehler zu vermeiden. (vgl. Stadler, 2007, S.7-8) Das UN-Kaufrecht beinhaltet Regelungen zur Vertragsaufhebung, die etwas anders sind als im BGB. Eine Vertragsaufhebung kann nur dann erfolgreich durchgeführt werden, wenn ein Vertragsbruch vorliegt, der wesentliche Nachteile mit einem zu beziffernden Schaden für eine Vertragsseite bedeutet. Bei entsprechenden vertraglichen Regelungen können dabei auch Nebenpflichten so wichtig darsgestellt werden, dass sie einen Vertragsbruch bedeuten, dies ist im BGB so nicht möglich. Mangelhafte Leistungen sind im Regelfall keine Gründe für eine Vertragsaufhebung, es besteht die Möglichkeit der Nachbesserung oder des Schadensersatzes. (vgl. Schlechtriem, 2007, S.92-97) Streitigkeiten zwischen Vertragspartnern werden vor Gerichten in den jeweiligen Ländern verhandelt, wobei der Grundsatz gilt, die Rechtssprechung der anderen Mitgliedsländer in die eigene zu berücksichtigen. (vgl. Stadler, 2007, S.7-8) Das UN-Kaufrecht regelt aber nicht alle Bestandteile eines Vertrages, so sind zum Beispiel Vertragsstrafen nicht geregelt und müssen individuell festgelegt werden. (vgl. Stadler, 2007, S.13)

2.1.6 Vertragsgestaltung beim Software-Offshoring

2.1.6.1 Vertragstypen

Rechtlich sind Offshoring-Verträge als Kauf- oder Werksvertrag einzustufen, die im Buch 2 des BGB geregelt werden. Beim Erwerb einer Standardsoftware findet im Regelfall der Kaufvertrag Anwendung, da nur ein Nutzungsrecht erworben wird. Der Werksvertrag bietet dagegen erweiterte Möglichkeiten Risiken zu verteilen und Einfluss auf den Auftragnehmer während der Entwicklungsphase zu nehmen. Es haben sich unterschiedliche Preismodelle entwickelt, die entsprechend des Lieferanten- und Kundenrisikos differenziert werden kön- nen. (vgl. Abbildung 4)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Risikoverteilung der Vertragsarten

„Value-based Arrangement“ Vertrag wird nicht betrachtet, da der Offshoring-Partner intensi- ve Branchen- und Markt-Kenntnisse benötigt, die im Normalfall nicht vorhanden sind. Bei dieser Vertragsart werden Umsätze oder Gewinne des Softwaresystems an den Offshore- Partner als Entlohnung ausgezahlt. (vgl. Steimle, 2007, S.40) Der Dienstleistungsvertrag er- möglicht dem Auftragnehmer eine Abrechnung auf Basis eines Stundenlohnes. Im Gegensatz dazu steht der Festpreisvertrag, bei dem ein fester Preis für ein System vereinbart wird. Beide Varianten bieten unterschiedliche Chancen und Risiken. (vgl. Tabelle 1)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Vor- und Nachteile von Preismodellen

Quelle: modifiziert nach Steimle, 2007

Bei beiden Preismodellen sind die Risiken für jeweils eine Vertragspartei als hoch einzuschätzen. (vgl. Abbildung 4) Aus diesem Grund hat sich das Festpreismodell bei Teillieferungen durchgesetzt, welches ein System in mehrere Teile stückelt und für jedes einen festen Preis festlegt. Dieses Modell erlaubt es beiden Parteien ihre Risiken zu minimieren. Egal welche Vertragsform und Preismodell gewählt wird, muss beachtet werden, dass es bei Problemen je nach Rechtssystem schwierig sein kann, den Vertrag durchzusetzen. In Indien können dies fast 40 % der eigentlichen Projektkosten bedeuten, die aufgebracht werden müssen um den vertraglichen Anspruch durchsetzen zu können.

Zusätzlich zu den Kosten kommen auch die Zeiten, die durchschnittlich anfallen, welche in Indien mehr als 1400 Tage betragen. (vgl. Abbildung 5) Diese Schwierigkeiten müssen im Risikomanagement berücksichtigt werden, welches in Kapitel 2.3.4 näher beleuchtet wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Kosten einer Vertragsauflösung

2.1.6.2 Vertragsbestandteile

Die Bestandteile eines Vertrages können sehr individuell geregelt werden. Sie sollten aber einige Themengebiete zwingend abdecken um Probleme und Verzögerungen zu vermeiden. Folgende Punkte sollten vertraglich geregelt werden, wobei die Liste je nach Projekt und An- sprüchen erweiterbar ist. (vgl. Ebert, Outsourcing Kompakt, 2006, S.66 und Steimle, 2007, S.40-41)

- Detaillierte Spezifikation des Systems
- Liefertermin für das System oder Module
- Eskalationsmanagement
- Change Management
- Beauftragung von Subunternehmen durch den Auftragnehmer
- Mitwirkungspflichten beider Parteien
- Folgen bei Nicht- oder Schlechterfüllung
- Beschreibung des Abnahmeverfahrens und der Kriterien
- Gewährleistung, Urheberrechte und Haftung
- Kündigungskriterien
- Zahlungsmodalitäten, Preise
- Reporting
- Risikomanagement

Die Spezifikation des geforderten Systems ist ein sehr wichtiger Teil des Vertrages, damit beide Vertragsparteien den Lieferumfang anerkennen. Die Inhalte der Spezifikation werden in Kapitel 2.3.1 definiert. Bei Problemen innerhalb der Zusammenarbeit ist es sehr sinnvoll ein Eskalationsmanagement vertraglich festzulegen. Dabei werden klare Zuständigkeiten auf beiden Seiten definiert, die in Eskalationsfällen ein Schlichtungsverfahren leiten können. Der Preis und andere Zahlungsmodalitäten werden festgeschrieben, unter anderem auch wenn Termine an den Zahlungen gekoppelt sind oder Abnahmeverfahren. Die Definition der Test- kriterien für die Abnahmen sollten daher auch vertraglich festgehalten werden, um Diskussi- onen im späteren Verlauf zu verhindern. Sollten die Termine nicht eingehalten werden kön- nen oder die Qualität des Produktes nicht stimmen, müssen die Folgen bei Nicht- oder Schlechterfüllung definiert werden.

2.2 spezialisierte Internetportale

2.2.1 Geschäftskonzept Web 2.0 Offshoring

Offshoring Vorhaben locken mit zweistelligen Einsparpotentialen, schrecken aber gleichzei- tig mit hohen Anfangsinvestitionen und Risiken ab. Dazu gehören die Kosten für Beratungs- leistungen, eventuell einer spezialisierten Offshoring-Agentur oder auch die Kommunikati- ons- und Reisekosten. Dies führt dazu, dass insbesondere kleine und mittelständische Unter- nehmen eher vorsichtig agieren, wenn es um Offshore-Projekte geht. Frank A. Koch be- schreibt die Sinnhaftigkeit von Individualsoftware so, dass„ Software-Produzenten eine Soft- ware mehrere hundert Mal verkaufen müssen, um einen positiven Return on Investment (ROI) zu erhalten.“ Er stellt dazu auch eine entscheidende Frage„ Wie kann ein Unternehmen glau- ben, einmalige Entwicklungen wirtschaftlich umzusetzen?„ Aus Kochs Sicht ist daher die Entwicklung von Individualsoftware folgender Einschränkung unterworfen .„Eigene Soft- ware-Entwicklungen sollte definitiv auf solche Ausnahmen beschränkt bleiben, bei denen es entweder nachweislich keine Standardsoftware im Markt gibt oder ein signifikanter strategi- scher Vorteil erzielbar ist.“ (Koch, 2007, S.14-15) Mit der am Anfang des Kapitels aufgeführten Kostenstruktur hat Koch mit seiner Aussage vollkommen Recht, da sich dies in der Regel nicht rechnen kann. Der Bedarf an kleinerer Individualsoftware ist dennoch da, auch wenn nicht immer unbedingt ein signifikanter Vorteil erzielbar ist. In den letzten Jahren haben sich zur Realisierung, auch solcher Projekte, spezialisierte Internetportale entwickelt.

Auf diesen Plattformen treffen sich Auftraggeber und -nehmer aus aller Welt, wobei die Marktanteile dem des regulären Offshorings ähneln, wodurch indische Anbieter dominieren. Diese Arbeit bezieht sich auf das Portal„www.getacoder.com“, ist in vielen Punkten aber auf ähnliche Angbeote übertragbar. Potentielle Auftraggeber können sich auf dem Portal registrieren und ihre Projekte in einem Anbietungsverfahren vorstellen. Dabei werden Spezifikationen, Budgetvorstellungen und die Länge des Anbietungsverfahrens festgelegt. Eine Auswahl zwischen Festpreis- und Dienstleistungsmodell ist ebenso möglich. Die Anbieter haben sich in der Regel spezialisiert auf einige Teilbereiche, sodass eine Auswahl des Themengebietes möglich und sinnvoll ist, insbesondere wenn der Auftraggeber schon entsprechende Vorstellungen hat. Sollte eine Webseite auf PHP.Basis benötigt werden, dann kann die Ausschreibung nur in dieser Kategorie gestartet werden. Bei der Ausformulierung der Anforderungen ist zu beachten, dass diese in Englisch zu formulieren sind und keine Kontaktdaten enhalten. Beide Einschränkungen sind in den„terms of use“ festgelegt und führen bei Nichtbeachtung zur sofortigen Sperrung des Projektes. Innerhalb der vorgegeben Ausschreibungsphase ist es jedem Anbieter möglich die Beschreibung zu studieren und auf Basis derer eine erweiterte Anfrage zu starten oder ein Angebot abzugeben. Es ist sinnvoll, während dieser Phase das Portal mindestens einmal am Tag aufzusuchen um Anfragen beantworten zu können. Die Angebote sind in der Regel mit einem Text und einem Betrag versehen, sowie dem Namen des Anbieters. Über den Namen ist es möglich die Referenzenliste einzusehen, ähnlich dem Bewertungssystem bei„www.ebay.de“. Während der Bietphase, spätestens aber nach Ablauf, kann sich der Auftraggeber für einen Anbieter entscheiden. Dies sollte aufgrund der Bewertungen, des Preises oder eventuellen Nachrichten, die ausgetauscht entschieden werden. Der Anbieter muss dieser Auswahl zustimmen. Es ist sinnvoll vor der Zustimmung des Anbieters vertragliche Regelungen zu besprechen oder Zahlungsmodalitäten zu konkretisieren, wenn dies in der Ausschreibung nicht schon detailliert festgehalten wurden. Das Modell des Portales sieht vor, dass der Auftraggeber seinen Account mit einem Budget auflädt. Das Budget kann dann einem Anbieter zugewiesen werden, wobei auch Teilzahlungen möglich sind. Das Geld kann der Anbieter auch bereits einsehen, allerdings noch nicht darüber verfügen. Dies hat den Vorteil, dass der Auftragnehmer von der Liquidität des Auftraggebers überzeugt wird und dieser wiederum weiterhin die Kontrolle über das Geld behält und die Zahlung erst nach Abnahme des Systems oder einer Teillieferung freigeben kann. Hat der Auftragnehmer dem Projekt zugestimmt, gilt der Vertrag als geschlossen. Zur Absicherung beider Parteien verläuft die Kommunikation weiterhin nur über das Portal, da dies im Streitfall eine Chronologie bietet und die Portalbetreiber in Streitfällen schlichten können. Nach Abschluss des Projektes und Freigabe aller Zahlungen, kann der Auftraggeber die Arbeit des Lieferanten bewerten. (vgl. Terms of Use of getacoder.com and getacoder.com)

2.2.2 elektronischer Geldtransfer

Die Nutzung eines Internet-Portals und der Einschränkung, dass jegliche Kommunikation über dieses Portal abgewickelt werden muss, führt zu einem elektronischen Geldtransfer. Da- zu bietet, das hier betrachtete Portal getacoder.com, jedem Benutzer ein internes Konto an, auf dem über verschiedene Zahlungsvarianten ein Guthaben hinterlegt werden kann, über welches die Projekte bezahlt werden. Zur Aufladung des Guthabenkontos werden folgende Zahlungssysteme angeboten:

- Credit/Debit Card
- WireTransfer
- Moneybookers
- PayPal
- Pecunix

In Deutschland sind die Kreditkarte, Moneybookers und PayPal verbreitet und werden etwas näher betrachtet. Zahlungssysteme lassen sich allgemein in drei Kategorien unterteilen.

Abbildung 6: Kategorisierung von Zahlungssystemen

Prepaid-basierte Zahlungssysteme setzen voraus, dass im Vorfeld ein Guthaben aufgeladen wurde, welches dann für Bezahlvorgänge genutzt wird. Getacoder.com arbeitet auch nach dem Prepaid Verfahren. Die zweite Kategorie ist das Pay-Now Verfahren bei dem direkt eine Abbuchung des fälligen Betrages stattfindet, dazu gehören auch die beiden Bezahldienste PayPal und Moneybookers. Die letzte Kategorie ist das Pay-Later System, hierbei wird dem Kunden ein Kredit gewährt und die Begleichung des fälligen Betrages zu einem späteren Zeitpunkt gesammelt durchgeführt. Die Kreditkarte fällt, wie ihr Name schon suggeriert, in diese Kategorie. (vgl. Abbildung 6)

PayPal wurde 1998 in den USA gegründet und gilt dort als erfolgreichstes Bezahlsystem für das Internet. Entstanden um die Restriktionen der amerikanischen Zahlungsgewohnheiten für den Online-Handel zu überwinden. In den 90-iger Jahren wurde in den USA meist mit Bar- geld, Schecks oder Kreditkarten gezahlt, wobei alle drei Möglichkeiten für den Handel über das Internet, insbesondere der Handel zwischen Privatpersonen nicht die Anforderungen er- füllten oder unmöglich machten. Zur gleichen Zeit entstand die Auktionsplattform„eBay“, welche den Handel zwischen Privatpersonen fokussiert. Aus diesem Grund wurde von An- fang an ein Großteil der Transfers von eBay Auktionen über PayPal abgewickelt, was die Verantwortlichen bei eBay dazu veranlasste, PayPal zu kaufen. Beim Zahlungsverkehr ist nur eine E-Mail Adresse des Empfängers zu wissen, dabei werden keinerlei Bankdaten zwischen beiden Parteien ausgetauscht. (vgl. Lammer & Stroborn, 2006, S.139-144 und Zapkau & Schwickert, S.63) Moneybookers wurde erst später in Großbritannien gegründet und bietet ein sehr ähnliches Verfahren wie PayPal an. Es operiert dabei unter englischem Recht und bedient fast ausschließlich den europäischen Markt. PayPal dagegen ist in 190 Nationen tätig. (vgl. Zapkau & Schwickert, S.63)

Die Kreditkarte ist als Zahlungsmittel in den USA äußerst beliebt und weit verbreitet. In Europa nimmt die Zahl der Kreditkarten weiter zu und auch die Umsätze steigen weiter an. Dennoch hat die Kreditkarte in Deutschland ein Image, welches immer wieder Sicherheitsbedenken hervorruft. Die beiden größten Anbieter VISA und Master Card versuchen mit neuen Sicherheitsmerkmalen und -protokollen die Bedenken auszuräumen. (vgl. Zapkau & Schwickert, S.64-66)

2.3 Softwareentwicklung

2.3.1 Spezifikationserstellung

Bei jeder Softwareentwicklung ist die Anforderungsanalyse eines der wichtigsten Schritte im Entwicklungsprozess und Grundlage für das spätere Spezifikationsdokument. Anforderungen beinhalten alle wichtigen Systemeigenschaften, Beschränkungen und wichtigen Systemver- halten. (vgl. Sommerville, 2007, S.148) Zwei unterschiedliche Anforderungstypen sind defi- niert, zum einen die Benutzeranforderungen, welche in natürlicher Sprache formuliert werden und die Funktionalitäten des Systems aus Benutzersicht darstellen. Probleme können dabei sein, dass die Anforderungen zu ungenau beschrieben sind oder sich mit weiteren Beschrei- bungen überschneiden. (vgl. Sommerville, 2007, S.158) Zum anderen die Systemanforderun- gen, die alle Funktionen, Beschränkungen und Dienste sehr detailliert und präzise beschrei- ben. Die daraus resultierende funktionale Spezifikation definiert, was genau implementiert werden soll und kann im Vertrag verankert werden. Zur Vermeidung von Mehrdeutigkeiten, wie es bei den Benutzeranforderungen des Öfteren passieren kann, sollten bei den Systeman- forderungen Notationen benutzt werden. Folgende Notationen sind dabei möglich:

- Strukturierte natürliche Sprache
- Sprachen zur Entwurfsbeschreibung
- Grafische Notation
- Mathematische Spezifikationen

Die strukturiere natürliche Sprache ist die meistgenutzte Notation und beschreibt die Anfor- derungen in Standardformulierungen, wodurch die natürliche Sprache erhalten bleibt aber die Verständlichkeit erhöht wird. Tabellen und Grafiken können die Formulierungen dabei unter- stützen. (vgl. Sommerville, 2007, S162-163) Eine weitere mögliche Unterteilung von Anfor- derungen ist die funktionale und die nicht funktionale Anforderung, wobei ersteres alles be- schreibt, was das System können oder nicht können soll. Nicht funktionale Anforderungen beinhalten alle globalen Beschränkungen und Standards, die das System erfüllen muss. Dabei geht es in der Regel nicht um einzelne Funktionen des Systems. (vgl. Sommerville, 2007, S.151)

Die Anforderungsanalyse ist ein Ablaufmodell mit vier Entwicklungsteilprozessen und ist für die Erstellung und Pflege des Anforderungsdokumentes zuständig. Die vier Prozesse lassen sich wie folgt unterteilen. (vgl. Sommerville, 2007, S.176)

- Durchführbarkeitsstudie
- Anforderungsbestimmung und -analyse
- Standardisierung
- Validierung

Die Durchführbarkeitsstudie sollte bei allen Neuentwicklungen durchgeführt werden und in einem Bericht klären, ob weitere Entwicklungsprozesse Anwendung finden sollten. Bei der Anforderungsbestimmung und -analyse werden Gespräche mit Benutzern und anderen Betei- ligten geführt, um alle Anforderungen für das System und die Hardware zu sammeln. Dabei können einige Probleme entstehen, die auf einem falschen Verständnis oder Unwissenheit der Benutzer beruhen. Es passiert auch nicht selten, dass unterschiedliche Benutzer gegenteilige Anforderungen haben, die in einem Kompromiss zusammengefasst werden müssen. (vgl. Sommerville, 2007, S.180) Die Erhebung der Anforderungen können durch Interviews, Fra- gebögen oder Beobachtungen gesammelt werden. Interviews ermöglichen einen direkten Kontakt zum Benutzer und es können offene Fragen geklärt werden. Dadurch ist diese Tech- nik sehr beliebt und effektiv jedoch auch zeitintensiv. Der Fragebogen als Technik der An- forderungsbestimmung ermöglicht die Parallelisierung der Befragungen und einen höheren Teilnehmerkreis. Erfahrungen zeigen aber, dass die Rücklaufquote solcher Fragebögen eher gering ist und Missverständnisse bei den Fragen zu falschen Antworten führen. Beobachtun- gen ermöglichen eine Analyse von Arbeitsabläufen bei deren Abarbeitung, was jedoch sehr zeitintensiv ist und den Beobachteten beeinflussen könnte. (vgl. Häuslein, 2004, S.49-59) Ein Vergleich der Techniken zeigt die Vor- und Nachteile für spezielle Bereiche der Informationsgewinnung. (vgl. Abbildung 7) Dokumente wurden bisher nicht angesprochen, da sie bei Neuentwicklungen keine wirkliche Rolle spielen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Eigenschaften von Techniken der Informationsgewinnung

Die gewonnen Anforderungen werden gruppiert, klassifiziert, priorisiert und in die vorgese- hen Standardformulierung übertragen. (vgl. Sommerville, 2007, S.182) Der letzte Schritt im Prozess ist die Validierung der Anforderungen. In dieser Phase wird überprüft, ob die gestell- ten Anforderungen das wiederspiegeln, was der Kunde auch erwartet. Die Validierung lässt sich durch verschiedene Prüfungen realisieren. Alle Anforderungen werden einer Gültig- keitsprüfung unterzogen, bei der analysiert wird, ob es zu den bestehenden Anforderungen noch weitere sinnvolle gibt. In der Konsistenzprüfung wird sichergestellt, dass sich Anforde- rungen nicht gegenseitig ausschließen oder überschneiden. Ob alle Funktionen und Dienste des Systems beschrieben wurden, wird in der Vollständigkeitsprüfung sichergestellt. Die Realisierbarkeitsprüfung stellt sicher, dass alle Anforderungen technisch überhaupt umsetz- bar sind oder ob es zu Schwierigkeiten kommen könnte. (vgl. Sommerville, 2007, S.192)

2.3.2 Vorgehensmodelle

In der Softwareentwicklung sind spezielle Modelle entwickelt worden um die Komplexität übersichtlicher und strukturierter zu gestalten. Diese Modelle sind branchenspezifisch und werden„Prozess- oder auch Vorgehensmodelle“ genannt. Ein Modell sollte durchzuführende Aktivitäten, Fertigstellungskritieren für Teilprodukte, notwendige Qualifikationen, anzuwen- dende Standards, Richtlinien und Werkzeuge enthalten. (Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.449) Neben den Vorgehensmodellen gibt es auch Qualitätsmodelle, diese stellen Werkzeuge bereit, um unter anderem möglichst fehlerfreien Quellcode zu erstellen. Aufgrund der Überlappung von beiden Modellvarianten werden sie hier zusammen behandelt. (vgl. Abbildung 8) In der Literatur werden diese Modelle nach verschiedenen Kriterien unterschieden. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.516)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Klassifizierung von Prozess- & Qualitätsmodellen

Die ersten Modelle, die entstanden sind, können unter dem Begriff„Basismodelle“ aggregiert werden. Die bekanntesten und wichtigsten Modelle sind hier im Folgenden kurz erläutert. Für eine ausführlichere Behandlung aller Modelle sei auf Balzert, Lehrbuch der Softwaretechnik Softwaremanagement aus 2008 im Teil III verwiesen.

Das Wasserfallmodell ist eines der bekanntesten Vorgehensmodelle in der Softwareentwicklung und steht als Vertreter für das sequentielle Modell. Dabei werden alle Phasen nacheinander abgearbeitet, wobei die nächste Phase erst starten kann, wenn der Vorgänger abgeschlossen ist. Das Wasserfallmodell bietet zum ursprünglichen Modell noch die Erweiterung der Rückkopplung zur vorherhigen Phase. Die Rückkopplung erlaubt eine Validierung der Ergebnisse und kann bei Abweichungen zur Berichtigung der Resultate die Vorgängerphase nochmals durchlaufen lassen. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.518-521) Da die Bearbeitungszeit des sequentiellen Modells genau so lange dauert, wie die Summe aller Bearbeitungsschritte, kann dies zu unnötig langen Zeiten führen. Das nebenläufige Modell soll diesen Nachteil aufheben indem sich Phasen überlagern können. Dies reduziert die Laufzeit des Modells, jedoch auch die Kosten aufgrund der höheren Planungskomplexität. Ein Vertreter dieses Modells ist„XP“ die Kurform für„eXtreme Programming“. Das Modell wurde zum ersten Mal in der Fertigungsindustrie eingesetzt um Fertigungsstraßen zu prallelisieren. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S. 523-526) Das aktuelle„V-Modell XT“ wird zu den inkrementellen Vorgehensmodellen gezählt und ist sehr bekannt, da es für Entwicklungen in der öffentlichen Verwaltung als Voraussetzung gilt. Bei diesem Modell werden Teilprodukte definiert und unabhängig voneinander entwickelt, somit kann der Auftraggeber schon früh die Teilprodukte nutzen. Gewonnene Erfahrungen aus den frühen Tests einzelner Teilprodukte können in spätere Versionen einfließen. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.526-529 und S. 553-555) Eine zusätzliche Weiterentwicklung im Rahmen des inkrementellen Modells ist das„Spiralmodell“. Diese Modell vereint die Vorteile der anderen Modelle in sich, indem es vier Phasen zyklisch durchläuft und bei jeder Phase die Möglichkeit eines anderen Vorgehensmodells bietet. Diese Konstellation erlaubt es, je nach Entwicklungsstand, das richtige Prozessmodell zu wählen. (vgl. Abbildung 9) Aus diesem Grund wird das Spiralmodell auch als Metamodell bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Spiralmodell nach Böhm

In der Phase 1 werden die Ziele festgelegt und nach Alternativen gesucht. In der zweiten Phase werden die Alternativen nach ihren Risiken bewertet und durch eine kosteneffektive Strategie versucht diese zu überwinden. Dazu kommen Prototypen oder Simulationen in Frage. In Phase 3 wird anhand der noch verbliebenen Risiken ein geeignetes Prozessmodell gewählt und die Entwicklung durchlaufen. Die 4. Phase dient zur Abnahme der Ergebnisse und der Planung für den nächsten Zyklus.

Die im Vorfeld beschriebenen Basismodelle beziehen sich hauptsächlich auf die Projektebe- ne. Später entstanden aufbauend darauf Modelle, die auch in der Unternehmensebene ange- siedelt sind. Diese Modelle werden„Rahmenmodelle“ genannt und haben„ nicht das Ziel Prozess- oder Qualitätsschritte weiter zu detaillieren, sondern Ziele für die Prozessdurchfüh- rung und die Qualitätssicherung vorzugeben „. (Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.565) Die Rahmenmodelle lassen sich in zwei Kategorien einteilen, einerseits die softwarespezifischen und die allgemeinen Modelle. Das bekannteste spezifische Modell ist das„CMMI-Modell“. 1987 entwickelte das SEI (Software Engineering Institute) im Auftrag des amerikanischen Verteidigungsministeriums einen Fragebogen zur Bewertung von Software-Lieferanten. In den kommenden Jahren wurde der Fragebogen zu einem Referenzmodell ausgebaut. Ziel dabei war es, Software Lieferanten vergleichen zu können. 1991 wurde die Version 1.0 des CMM (Capability Maturity Modell) veröffentlicht. Die Version 1.1 folgte 1993 und wurde zum Standard für Zusammenarbeiten mit dem Verteidigungsministerium. Zwischen 1993 und 2000 wurden weitere CMM’s für die System- und integrierte Produktentwicklung entworfen. Die drei CMM’s wurden im Capability Maturity Modell Integration (CMMI) zusammengeführt und standardisiert. Das CMMI wurde 2000 in der Pilotversion 1.0 vorgstellt und 2002 mit Version 1.1 und 2006 mit Version 1.2 entscheidend verbessert. CMMI hilft Unternehmen bei der Verbesserung der eigenen Prozesse mit dem Ziel der ordentlichen Projektarbeit. Das Modell wird in zwei Darstellungen definiert. Die stufenförmige Darstellung hat fünf Reifegrade, wobei alle Anforderungen eines Reifegrades erfüllt werden müssen um den nächsthöheren zu erreichen. Die kontinuierlichee Darstellung besitzt sechs Kategorien, bei denen sich die Unternehmen nur den Teilen widmen müssen, die für sie wichtig sind. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.565-566) In die gleiche Kategorie gehört das„SPICE- Modell“, was für„Software Process Improvement and Capability Determination“ steht und für die Softwareentwicklung nutzbar ist. Für zusätzliche Informationen wird auf Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S. 582-587 verwiesen.

Das„ISO9000-Modell“ ist ein weltweit anerkanntes Modell, das verschiedene Normen beinhaltet. Ein Rahmenmodell, welches ein Qualitätsmanagement beschreibt. Balzert definiert das Qualitätsmanagement so: „Ein Qualitätsmanagementsystem ist ein Managementsystem, das es erm ö glicht, eine Organisation - bezogen auf Qualität - zuleiten und zu lenken„ (Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.590) Ziel dieses Modells mit seinen Normen ist die Gestaltung aller Unternehmensprozesse und Beziehungen zu Kunden und Lieferanten, um die höchstmögliche Qualität zu erreichen. Diese Prozesse lassen sich zertifizieren, wodurch eine bessere Aussenwirkung entsteht und Wettbewerbsvorteile nutzbar werden. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.591-600) Ein weiteres Qualitätsmodell ist das„TQM-Modell“ (Totales Qualitätsmanagement), welches ursprünglich aus Japan stammt und die japanische Kultur integriert. Einziges Ziel des Modells ist die Zufriedenheit des Kunden, ist diese erreicht, verbessern sich automatisch auch alle anderen Prozesse und die Qualität dazu. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.601-617)

Eine weitere Kategorisierung von Modellen sind die monumentalen und die agilen Modelle. Monumentale Modelle sind sehr ausführlich beschriebene Dokumente, in denen detailliert die durchzuführenden Aktivitäten beschrieben sind. Beispielmodelle sind: RUP, PSP, TSP und V-Modell XT. Agile Modelle sind der genaue Gegensatz dazu, bei denen nur wenige Prozessschritte beschrieben sind. Ein Manifest aus dem Jahre 2003 beschreibt die Kernideen dieser Modelle. Beispiele für diese Kategorie sind: Scrum, FDD und XP. (vgl. Balzert, Lehrbuch der Softwaretechnik Softwaremanagement, 2008, S.619 und 651)

2.3.3 Risikomanagement

Jeder Mensch betreibt täglich Risikomanagement ohne sich dessen bewusst zu sein. Zum Beispiel beim morgendlichen Blick aus dem Fenster und was man zu dem unsicheren Wetter anziehen könnte. Da es noch regnen könnte, entscheidet man sich für die Regenjacke, so ist man für den Regenfall gerüstet. Man schützt sich damit vor dem Risiko nass zu werden. (vgl. Ahrendts & Marton, 2008, S.8) In der Norm ONR 49000 wird ein Risiko wie folgt definiert:

Risiko bezeichnet das Ausmaß, in dem die Erreichung geschäftlicher Ziele und die Umset- zung geschäftlicher Strategien gefährdet sind durch Ereignisse oder Handlun- gen/Unterlassungen innerhalb oder außerhalb des Unternehmens „(Ahrendts & Marton, 2008, S.9)

Eine natürlichere Definition von Risiko kommt aus dem Chinesischem, wo es aus zwei Wörtern besteht:„Gefahr“ und„Wind“. Die Übersetzung besagt:„Eine Gefahr im Wind“, sie ist somit spürbar aber nicht greifbar. (vgl. Picot, Reichwald, Franck, & Möslein, 2008, S.5) Wenn man über Risiken spricht, wird immer von einer negativen Situation ausgegangen, dabei können ohne Risiken auch keine Chancen genutzt werden. Aus diesem Grund muss Risikomanagement betrieben werden, dass bedeutet mit den Risiken umgehen, sie erkennen und bei Bedarf abzuschwächen. Es ist nicht das Ziel, sie zu vermeiden, sondern zu kontrollieren. Der Prozess für das Risikomanagement lässt sich in vier Zyklen einteilen, die iterativ durchlaufen werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Der Risikomanagementprozess

Am Anfang des Risikomanagements steht die Risikoidentifizierung, um eine Übersicht aller bestehenden Risiken zu erhalten. Zur Identifizierung gibt es mehrere Techniken. Zum Bei- spiel Brainstorming, welches sehr offen ist und viele Ideen fördert aber durch Vorurteile und Betriebsblindheit beeinflusst werden kann. (vgl. Abbildung 10) Weitere Techniken können die SWOT-Analyse, Erfahrungsschatz nutzen, Interviews und Checklisten sein. (vgl. Ebert, Risikomanagement kompakt, 2006, S. 19-20) In der Risikoanalyse-Phase werden die Risiken auf ihre Gefährdung der Unternehmensziele eingestuft. Dabei werden häufig die Größen Eintrittswahrscheinlichkeit und Verlusthöhe zur Bestimmung des Gefährdungspotentials verwendet. Der Zukunftsbezug der Risikoanalyse ist aufgrund unvollständiger Informationen sehr schwierig vorzunehmen. Zur Schätzung der beiden Größen sind mehrere Methoden relevant, wobei die Genauigkeit auf der Qualität der zugrunde liegenden Daten beruht. (vgl. Picot, Reichwald, Franck, & Möslein, 2008, S.17) Die dritte Phase„Risikosteuerung“ beinhaltet die Entscheidungen, welche Risiken wie behandelt werden. Es können vier verschiedene Methoden angewendet werden. Die erste Methode ist das Risiko komplett zu vermeiden, indem die Eintrittswahrscheinlichkeit auf Null abgesenkt wird und das Risiko nicht eintreten kann. Bei dieser Methode muss allerdings auf die optimale Lösung verzichtet und Chancen ungenutzt gelassen werden. Das Risiko begrenzen ist eine weitere Methode, bei der durch zusätzlichen Aufwand oder Budget die Auswirkungen zu begrenzt oder geschwächt werden, zum Beispiel durch Versicherungen. Durch Behandlung der Risiken werden Aktionen entwickelt, um die Auswirkungen und die Wahrscheinlichkeit zu reduzieren, zum Beispiel durch Notfallpläne oder Checklisten im Falle eines Problemes. Die letzte Methode ist das Risiko zu ignorieren in der Hoffnung, dass sie nicht eintreten. Einige Risiken können auch gar nicht behandelt werden, zum Beispiel Naturkatastrophen. (vgl. Ebert, Risikomanagement kompakt, 2006, S.60-66) Die Risikoüberwachungsphase„ ist das Kontrollinstrument, das Risikomanagement wirtschaftlich sinnvoll macht. „(Ebert, Risikomanagement kompakt, 2006, S.73) In dieser Phase wird kontrolliert, ob die Maßnahmen gegriffen haben und ob wie sich dadurch das Risiko verändert hat. Weiterhin wird geprüft, ob aus Risiken Probleme geworden sind oder neue Risiken aufgetreten sind. Die Ergebnisse dieser Phase dienen der ersten Phase wieder als Datenmaterial und komplettiert den Risikomanagementkreislauf. (vgl. Ebert, Risikomanagement kompakt, 2006, S.73)

2.3.4 Softwareabnahme

Am Ende jeder Softwareentwicklung muss getestet werden, ob das System in seinen Funktio- nen und Verhaltensweisen der Spezifikation entspricht. Diese Testreihe nennt man Abnahme- tests oder funktionale Tests, weil nur die reine Funktionalität betrachtet wird. Darüber hinaus gibt es noch Integrationstests, bei denen während der Entwicklung und Zusammenführung von Systemteilen der Quellcode schon auf Fehler überprüft wird. Bei diesen Tests ist der Auftraggeber aber noch nicht unbedingt involviert, im Gegensatz zu den Abnahmetests. Bei dieser Form des Testens wird das Black-Box-Verfahren angewendet. (vgl. Sommerville, 2007, S.586)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Black-Box-Tests

In diesem werden nur die Eingaben in das System und Ausgaben aus diesem heraus bewertet und verglichen, ob sie die Anforderungen erfüllen. Wie das System intern arbeitet und wo genau der Fehler liegt, ist durch die Black-Box nicht zu erkennen und auch nicht gewollt. Normalerweise ist es unmöglich alle in Frage kommenden Eingaben zu testen, aus diesem Grund muss eine Auswahl erfolgen, in der Grafik mit„E“ gekennzeichnete Menge. Die Er- gebnisse dieser Eingaben werden in die Menge Testergebnisse und in„A“ aufgeteilt, wobei„A“ die fehlerhaften Ausgaben darstellt. Die Auswahl von„E“ sollte so gewählt werden, dass durch fehlerhafte Eingaben Fehlausgaben provoziert werden, zum Beispiel durch zu lange Eingaben oder vom falschen Format. (vgl. Sommerville, 2007, S.586-587) Im Vorfeld sollten Testfälle definiert werden, die genau die Eingaben vorgeben und die erwarteten Ausgaben beschreiben. (vgl. Abbildung 11) Dabei sollten diese im Allgemeinen beginnen und immer detailliertere Fälle betrachtet werden. (vgl. Sommerville, 2007, S. 595) Die Abnahme sollte sehr sorgfältig vorbereitet werden, da sie die Grundlage für die Abschlusszahlungen bildet und die letzte Chance bietet, Fehler im System anzumahnen und Nachbesserung zu verlangen. (vgl. Koch, 2007, S.67)

2.4 Wirtschaftlichkeitsbetrachtungen

Viele Projekte sind technisch umsetzbar, aber sind sie auch wirtschaftlich sinnvoll? Wirtschaftlichkeit bedeutet im Allgemeinen mit so wenig Aufwand wie möglich ein Ziel zu erreichen (Minimalprinzip) oder mit vorhandenen Mitteln den größten möglichen Nutzen zu erzielen (Maximalprinzip). (vgl. Kubicek & Lofthouse, 2010, S. 121) Kubicek & Lofthouse definieren„ Ein IT-Projekt ist wirtschaftlich gesehen eine spezielle Form einer Investition „(Kubicek & Lofthouse, 2010, S.121) Nach dieser Einordnung werden Ressourcen zur Verwirklichung des Projektes aufgewendet, in der Erwartung, dass der spätere Nutzen den Aufwand übersteigt. Um diese Beurteilung vornehmen zu können, müssen die Kosten des Projektes und der spätere Nutzen ermittelbar sein.

Die Kosten eines Projektes sind sehr unterschiedlich definiert und betriebswirtschaftlich nicht immer korrekt zugeordnet. Es stellt sich zum Beispiel die Frage, ob die Anschaffungskosten für benötigte Hardware zu den Projektkosten gezählt werden oder nicht. Ein Unternehmen kann diese Kostenform auf die Nutzungsdauer abschreiben und damit nicht mehr zu den Projektkosten zählen. Die Betriebskosten werden ebenfalls jährlich abgerechnet auch über das Projektende hinaus und dürfen nicht den Projektkosten zugeordnet werden. Kosten, die sich nur einem Projekt zuordnen lassen, sind hauptsächlich die Personalkosten für interne und externe Mitarbeiter und für das Projekt genutzte Sachmittel. (vgl. Kubicek & Lofthouse, 2010, S. 122-125) Der Projektnutzen berechnet sich durch die Kosten vor und nach der Projektlaufzeit oder der Gewinnveränderung durch das Projekt. In der Betriebswirtschaft werden Vorher-Nacher-Vergleichrechnungen den Methoden der Investitionsrechnung zugeordnet, was zur Einordnung eines IT-Projektes passt. (vgl. Kubicek & Lofthouse, 2010, S.125-126)„ Diese passen jedoch nur bedingt für die Beurteilung der Wirtschaftlichkeit von IT-Projekten. „(Kubicek & Lofthouse, 2010, S.126)

Die Feststellung von Kubicek & Lofthouse ist aufgrund der Eigenheiten von IT-Projekten und der eigentlichen Aufgabe der Investitionsrechnung nachvollziehbar. Zur Vollständigkeit und weil einige Methoden doch angewendet werden können, wird das Thema kurz erläutert. Dabei wird dieser Themenkomplex in die statische und dynamische Investitionsrechnung unterteilt. Die statische Berechnung berücksichtigt den zeitlichen Verlauf von Zahlungen nur ungenügend. Beispiele hierfür sind die Kostenvergleichsrechnung, Gewinnvergleichsrechnung, Rentabilitätsrechnung und Amortisationsrechnung. Die Kostenvergleichsrechnung vergleicht die Kosten von mehreren Alternativen miteinander, das funktioniert aber nur, wenn sich die Erlöse oder Nutzen bei allen betrachteten Varianten nicht unterscheidet. Die Gewinnvergleichsrechnung vergleicht die Gewinnänderungen der unterschiedlichen Varianten miteinander, was in den frühen Phasen eines Projektes nur selten mit qualitativen Daten untermauert werden kann. In der Rentablitätsrechnung wird der Gewinn in ein Verhältnis zu dem Investitionsvolumen gesetzt und die betrachteten Varianten miteinander vergleichbar. Bei der Amortisationsrechnung ist der Zeitraum das Vergleichsobjekt bis die Investition wieder durch den Nutzen ausgeglichen worden ist (vgl. Kubicek & Lofthouse, 2010, S.127-128). Die dynamische Investitionsrechnung berücksichtigt die Zahlungszeitpunkte beim Gewinn oder Krediten. Zur Berechnung können die Kapitalwertmethode, Annuitätenmethode oder die Methode des internen Zinsfußes genutzt werden. Bei IT-Projekten sind die dynamischen Berechnungsmethode, jedoch kaum einsetzbar, da sie in der Regel keine validen Daten liefern. (vgl. Kubicek & Lofthouse, 2010, S.128) Kubicek & Lofthouse vergleichen dies„ mit Kanonen auf Spatzen schießen „(Kubicek & Lofthouse, 2010, S.128), da es das Gefühl von Genauigkeit erzeugen könnte, welche nicht gegeben ist. Das grundlegende Problem bei der Investitionsrechnung ist die Voraussetzung von eindeutigen Geldgrößen zur Berechnung, die bei IT-Projekten nicht immer gegeben ist. Die Kosten- und Gewinnvergleichsrechnung können mit einigen Unsicherheiten genutzt werden, die Nutzwertanalyse passt ingesamt aber besser zur Betrachtung der Wirtschaftlichkeit innterhalb von IT-Projekten. Diese Analyseform betrachtet nicht nur Geldgrößen, wie es bei der Investitionsrechnung der Fall ist, sondern auch qualitative Aspekte. (vgl. Kubicek & Lofthouse, 2010, S.128) In der Nutzwertanalyse werden alle möglichen Nutzen mit einer Gewichtung versehen, die je nach Unternehmensstrategie unterschiedlich ausfallen kann, und nach einer Bewertungsskala eingeschätzt. Die Summe aller Multiplikationen von Bewertung und Gewichtung ermöglicht einen Vergleich aller Varianten (vgl. Kubicek & Lofthouse, 2010, S.138-139). Hierbei ist eine Einbeziehung von Nutzen möglich, die bei anderen Berechnungen keinem Wert zugeordnet werden können. Mögliche Nutzen können sein:

- Imageverbesserung
- Wettbewerbsvorteile
- Besserer Kundenservice
- Besseres Prozesshandling
- Steigende Mitarbeitermotivation
- Vereinheitlichungen

Dieser kleine Auszug aus den möglichen Nutzen eines IT-Projektes zeigt, dass die Bewertung des Nutzens sehr subjektiv ist. (vgl. Kubicek & Lofthouse, 2010, S.138)

2.5 Projektmanagement

2.5.1 Begrifflichkeiten

Projektmanagement befasst sich mit der Planung, Steuerung und Kontrolle von Projekten, wobei es keine einheitliche Definition vom Projekt gibt. Das Projekt Management Institute beschreibt ein Projekt wie folgt:„ A temporary endeavour undertaken to create a unique product, Service, or result. „(PMI). Die aktuelle DIN69901-5 Norm definiert ein Projekt ähnlich (DIN69901-5:2009-01, 2009) als„Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B.

- Zielvorgabe
- Zeitliche, finanzielle, personelle und andere Begrenzungen
- Abgrenzungen gegenüber anderen Vorhaben
- projektspezifische Organisation„

„Prince2“ ein Managementframework aus Großbritannien definiert ein Projekt wiederum als„ a management environment that is created für the purpose of delivering one or more business products according to a specified business case „(Köhler, S.2)

Obwohl die Vielzahl an Definitionen immer etwas abweichend voneinander sind, lassen sich Übereinstimmungen finden, die ein Projekt als Vorhaben mit besonderen Merkmalen, wel- ches ein eindeutiges Ziel verfolgt und einmalig beschreiben. Dabei besteht eine hohe Kom- plexität und eine Begrenzung in den zur Verfügung gestellten Ressourcen. (vgl. Kubicek & Lofthouse, 2010, S. 13) Das Projektziel definiert sich dabei durch alle Einzelziele, wobei darunter auch Budgeteinhaltung oder die Projektdauer zählen können. (vgl. Kubicek & Lofthouse, 2010, S.14) Um ein Projekt erfolgreich abschließen zu können, bedarf es Instrumente des Projektmanagements, wie zum Beispiel der Projektstrukturplan oder das Controlling. Die DIN Norm beschreibt Projektmanagement als„ Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initalisierung, Definition, Planung, Steuerung und Abschluss von Projekten. „(DIN69901-5:2009-01, 2009) Die Umsetzung dieser Ziele orientiert sich auch am„magischen Dreieck“, bei dem die Wechselwirkungen von Leistung, Budget und Zeit innerhalb eines Projektes aufgezeigt werden. Die drei Seiten bedingen sich und konkurrieren miteinander, wenn die Termine überschritten werden oder sich die Zeitachse ändert, dann ist mit einer Überschreitung des Budgets zu rechnen. Soll die Zeitüberschreitung ausgeglichen werden, muss eine höhere Leistung erbracht werden, wodurch sich das Budget nicht mehr halten lassen wird. (vgl. Abbildung 12)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: magisches Dreieck

Wie anhand der Definitionsvielfalt bereits zu erkennen ist, sind auch viele Normen und Standards national und international definiert worden, um die Zusammenarbeit und das Verständnis zu erleichtern. Kostenreduktion und Zeitersparnis sind das Ziel eines definierten Rahmens für Projekte, welches sich aber nicht automatisch durch die Einhaltung der Normen erreichen lässt. (vgl. Kubicek & Lofthouse, 2010, S.20-25) Die Entscheidung welche Normen oder Standards angewendet werden, muss der Projektleiter fällen beziehungsweise dessen Umsetzung kontrollieren. Der Projektleiter ist verantwortlich für die operative Abwicklung des Projektes und hat folgende Aufgaben: das Projektteam zusammenstellen, die Schnittstelle zum Projektauftraggeber bilden, Koordination aller projektinternen Aktivitäten, die Risikoanalyse durchführen und die Workshops und Treffen moderieren. (vgl. Kuster, et al., 2008, S.100-101)

2.5.2 Projektmanagementphasen

Ein Projekt besteht aus mehreren unterschiedlichen Phasen, welche nicht mit den Phasen des Projektmanagements verwechselt werden dürfen. Die fünf Phasen für das Projektmanagement nach der DIN 69901: Initialisierung, Definition, Planung, Steuerung und Abschluss sind im- mer gleich. Die Phasen des Projektes orientieren sich an das verwendete Modell, welche für die Softwareentwicklung in Kapitel 2.3.2 näher beschrieben sind. Egal welches Projektma- nagementkonzept angewandt wird, allen ist gemein, dass sehr viel Wert auf den Startprozess des Projektes gelegt wird. Fehler und Versäumnisse in dieser Phase sind im späteren Verlauf kaum noch auszugleichen und führen oft zu gescheiterten Projekten. Ein Projekt startet im Allgemeinen dann, wenn im Unternehmen Einigkeit darüber herrscht, dass zu einem be- stimmten Thema etwas getan werden muss und dafür auch entsprechende Aufwände entste- hen werden. (vgl. Kubicek & Lofthouse, 2010, S.32) Ziel des Projektstartes ist die Untersuchung der Idee und Schaffung einer Informationsbasis, auf der die Entscheidungsträger über eine Fortsetzung oder Einstellung verhandeln können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Der Projektstart

Es ist sinnvoll den Projektstart in drei kleine Teilprozesse zu untergliedern. (vgl. Kubicek & Lofthouse, 2010, S.33) Während der Ideenprüfung muss geklärt werden, wofür der betrachtete Teilprozess bedeutend ist und wie er in das Unternehmensbild passt. Ein weiterer zu klärender Punkt ist die Feststellung, wo der aktuelle Prozess steht. Als sinnvoll hat sich dafür die SWOT-Analyse herausgestellt, um den aktuellen Prozess zu untersuchen.„ Ziel der SWOT-Analyse ist es herauszufinden, inwieweit die gegenwärtige Strategie/das Geschäftsmodell eines Unternehmens (inkl. seiner Stärken und Schwächen) geeignet ist, um auf Veränderungen der Unternehmenswelt zu reagieren „(Klandt, 2006, S.220) SWOT steht dabei für Strengths, Weakness, Opportunities, Threats oder übersetzt für Stärken, Schwächen, Chancen und Risiken. Die Gegenüberstellung der SWOTs ermöglicht einen Überblick, wie die Idee beeinflusst wird und welche Möglichkeiten daraus entstehen. (vgl. Kubicek & Lofthouse, 2010, S.70) Zu überprüfen sind auch die Ziele, welche mit der Idee realisiert werden sollen. Die Zielvorgaben sollten messbar anhand überprüfbarer Kriterien sein. Letzter Punkt der Ideenprüfung ist die Strategie, wie die Idee umgesetzt werden kann und welche Ressourcen werden dafür benötigt werden. Die Ergebnisse werden den Entscheidungsträgern vorgestellt und entschlossen ob daraus eine Projektidee entsteht, die weiter analysiert wird. (vgl. Kubicek & Lofthouse, 2010, S.68-80) Zur Vorbereitung des Projektauftrages wird die Projektidee weiter verfeinert und geprüft, ob die technische Machbarkeit gegeben ist. Sollte dies nicht oder nur mit hohen Aufwänden möglich sein, ist eine Beendigung der Analyse möglich. Ein weiterer Schritt ist die Analyse und Berechnung der Wirtschaftlichkeit, um zu prüfen, ob das Projekt einen wirtschaftlichen Vorteil bringen kann. Damit dies berechnet werden kann muss ein Projektstrukturplan erstellt weden, die Kosten ermittelt werden und eine Zeitplanung erstellt werden. Mit diesen Informationen wird der Projektantrag erstellt und wieder zur Entscheidung vorgestellt. Nur wenn dieser Projektantrag genehmigt wird, startet das Projekt offiziell. (vgl. Kubicek & Lofthouse, 2010, S.98-105) (vgl. Abbildung 13)

2.5.3 Projektorganisation

Projekte erfolgen außerhalb der normalen Linienorganisation und erfordern daher eine eigene Projektorganisation, die sich an der Komplexität und der Häufigkeit von Projekten orientiert. drei Organisationsformen haben sich etabliert: die Stabsorganisation, die reine Projektorgani- sation und die Matrixorganisation. Bei der Stabsorganisation hat der Projektleiter nur Koor- dinierungsbefugnisse und beeinflusst das Projekt durch seine fachlichen Kenntnisse. Er trifft dabei aber keinerlei Entscheidungen selbst und hat für die Projektziele nicht die letzte Ver- antwortung. Die reine Projektorganisation ist genau das Gegenteil, bei der der Projektleiter die fachliche und personelle Führungsverantwortung besitzt. Alle Projektmitarbeiter werden organisatorisch unter den Projektleiter versetzt, wodurch er alle Entscheidungen zum Projekt im Ergebnis verantwortet. Die Matrixorganisation ist eine Mischform aus den beiden ersten Formen und besonders häufig bei IT-Projekten anzutreffen. In dieser Organisationsform wird der Mitarbeiter mehreren Stellen zugeordnet, wobei die disziplinarische Verantwortung in der Linienorganisation verbleibt und ein Teil der Arbeitskraft an ein oder mehrere Projekte aus- geliehen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Matrixprojektorganisation

Die IPMA definiert noch Unterschiede in der Matrixorganisation, abhängig vom Einfluss der Linien- oder Projektorganisation in: Dominanz bei der Linie, ausgewogen und Dominanz beim Projekt. Die Befugnisse des Projektleiters ist eine der wichtigsten Entscheidungen am Anfang des Projektes. Insbesondere bei der kommunikationsintensiven Matrixorganisation kann eine mangelnde Abgrenzung der Befugnisse zu Unsicherheiten und dem Misserfolg des Projektes führen. (vgl. Kubicek & Lofthouse, 2010, S. 107-108 und Kuster, et al., 2008, S.102-107 und Abbildung 14)

[...]

Ende der Leseprobe aus 176 Seiten

Details

Titel
Projektbasiertes Software-Offshoring
Untertitel
Untersuchung der Möglichkeiten des webbasierten Software-Offshorings
Hochschule
Hochschule Wismar
Note
1,9
Autor
Jahr
2011
Seiten
176
Katalognummer
V179349
ISBN (eBook)
9783656016861
ISBN (Buch)
9783656017219
Dateigröße
2403 KB
Sprache
Deutsch
Schlagworte
Offshoring, Outsourcing, Software, Entwicklung, Software-Engineering, Projektmanagement, Spezifikation, Verlagerung, Risikoanalyse, Chancen, Risiken, Mittelstand, Untersuchung, Machbarkeit, Projekt, Auslagerung, KMU, Softwareentwicklung, Analyse, Bewertung, Web, Webentwicklung, Indien, Getacoder
Arbeit zitieren
Martin Zieroth (Autor:in), 2011, Projektbasiertes Software-Offshoring, München, GRIN Verlag, https://www.grin.com/document/179349

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Projektbasiertes Software-Offshoring



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden