Handbuch IT-Outsourcing

e) Auslagerungsbereiche für Offshore

355

Sicher gehören zu den häufigsten Auslagerungsbereichen beim Offshore-Outsourcing i.d.R. nicht die Bereiche aus der IT-Infrastruktur. Der Betrieb von Rechenzentren ist bspw. zum einen nicht personalintensiv und zum anderen würden die Übertragungskosten nach wie vor die Standortvorteile zunichtemachen. Dies scheidet somit für Offshoring aus. Vielmehr werden Geschäftsprozesse oder IT-Prozesse (z.B. Service Desk) ausgelagert. Zu den ersten verlagerten Tätigkeiten gehörten Back-Office-Prozesse wie das Verarbeiten von Belegen, die Dateneingabe, das Erstellen von Folien für Unternehmensberater (nach deren Skizzen) oder das einfache Kodieren von SW nach genau spezifizierten Vorgaben. Zunehmend werden nun auch höherwertige Tätigkeiten ausgelagert (sogenannte „White Collar Jobs“). Gute Beispiele sind die eigenständige Entwicklung von Software, Architektur und Design von komplexen Anwendungen, Testen entsprechender Applikationen und auch deren Wartung und Pflege. Aber auch umfassende Tätigkeiten in der Buchhaltung, dem Personalmanagement etc., werden immer mehr ausgelagert.

Abb. 19:

QSU

356

Die Entwicklung von Software eignet sich insbesondere für Offshoring (Outsourcing der ständigen Systemintegration und deren Weiterentwicklung), denn es gibt klar definierbare Übergabepunkte. Die Tätigkeit kann in sich als abgeschlossen betrachtet werden. Insbesondere die Entwicklung und das Testen der Applikationen bietet sich für den entfernten Standort an. Anders verhält sich das wieder für die „Software Lifecycle Services“, also Dienstleistungen rund um die Entwicklung, Integration, Implementierung und Wartung der Applikation. Folgende Projekte sind typische Aufgabenstellungen in Einzelprojekten:

            –

            Design und Architektur von Lösungen entsprechend spezieller Anforderungen

            –

            Anpassungen und Implementierung von Standardprodukten („COTS = Commercial of the Shelf“)

            –

            Wartung und Support von schon in Betrieb befindlichen Systemen

            –

            Re-engineering/Migration von veralteten („Legacy“) Applikationen

            –

            Verifikation, Validierung und Test von komplexen Systemen

            –

            die Übernahme der vollständigen Applikationsbetreuung von in Betrieb befindlichen Systemen

357

Der Prozess der Applikationsentwicklung findet natürlich nicht auf dem Produktiv-System des Kunden statt. Vielmehr wird der Offshore Provider bei sich auf einem Entwicklungssystem entwickeln, auf einer Qualität-Sicherungs-Unit (Kurzform „QSU“) testen und dann erst in den Betrieb des Kunden gehen (siehe Abbildung 19)

358

Häufig sind Offshore- oder Nearshore-Unternehmen Tochterunternehmen großer Provider. Das Service Offering Portfolio (SOP) dieser Provider wird i.d.R. aus Outsourcing-Services aus dem eigentlichen Kernland des Providers stammen und einem bestimmten Prozentsatz an Nearshore und Offshore Services (siehe Abbildung 20), da nicht alle IT Services Offshore bzw. Nearshore erbracht werden können. Der Provider stellt mit dieser Aufstellung seines SOPs für den Kunden sicher, dass er für den Kunden die gesamte Wertschöpfungskette von IT-Services erbringen kann und die IT-Services, die aus Offshore oder Nearshore Regionen stammen, besonders kostengünstig erbracht werden können.

Abb. 20:

Service Offering Portfolio

f) Beispiele

359

Provider wie Accenture, Fujitsu, Hewlett Packard (HP) und IBM bauen ihre Offshore-Partnerschaften aus oder eröffnen bzw. erweitern ihre Niederlassungen in Übersee. Die Beratungsfirma Accenture hat ihre Offshore-Belegschaft eigenen Angaben zufolge schon bis Ende 2003 auf 12.000 Mitarbeiter erhöht. Ein exemplarisches Beispiel ist die Siemens Information Systems Ltd. (SISL) mit der Zentrale in Mumbai (Bombay) und Niederlassungen in Städten wie Bangalore, Delhi und Madras. Mit über 1.000 Mitarbeitern ist die SISL die zweitgrößte multinationale Software-Firma Indiens. Das Service Offering Portfolio (SOP) der SISL bietet Lösungen für Bürosoftware und Bildverarbeitung ebenso wie für Medizintechnik und Autoelektronik oder für die Telekommunikation (Software für Call Center der Polizei oder Sprachgesteuerte Systeme). Die SISL ist darüber hinaus indischer Partner von SAP und Microsoft und kann hoch qualifizierte Experten für Beratungsleistungen bieten.

360

Auch die Bedienung der Kunden aus näher gelegenen Regionen, das sogenannte Nearshore-Outsourcing, verspricht eine Reihe von Vorteilen. Für US-Firmen entwickelt sich Mexiko zunehmend zur Outsourcing-Alternative, entweder in Gestalt von regionalen Ablegern großer IT-Dienstleister wie IBM Global Services oder von mexikanischen Anbietern wie zum Beispiel Softtek. Abgesehen davon, dass die Personalkosten kaum höher sind als in Indien, profitieren US-Unternehmen von den kurzen Wegen und den Handelserleichterungen zwischen den USA und Mexiko, vor allem aber von der gleichen Zeitzone – ein Aspekt, der die Region besonders gegenüber Indien überlegen macht. Für Europa sind die Länder Portugal, Tschechien, Slowenien, Polen und Irland klassische Nearshore-Regionen.

g) Vorgehensweise

361

Die häufigste Vorgehensweise ist, dass das Offshore-Team zum Kunden in dessen Heimatland kommt, sich dort die Prozesse oder IT-Infrastruktur anschaut (Onsite) und dann später im Heimatland des Providers Offshore (Offsite) zuarbeitet. Wobei es immer ein kleineres Onsite-Team gibt, dass vor Ort beim Kunden den sog. Single Point of Contact (SPOC) stellt und immer im direkten Kontakt zum Offsite-Team steht.

362

Diesen Prozess kann man sich vereinfacht wie folgt vorstellen:

            –

            Das Team des Providers kommt aus dem Ausland (Offshore) zur Aufnahme der Anforderungen und der Strukturierung des Projektes mit dem Kunden.

            –

            Das Team kehrt zu seinen Standorten zurück und setzt die vereinbarten Projektziele um (z.B. die Entwicklung von Individualsoftware oder die Durchführung von fundierten Analysen und Studien)

            –

            Das Team kehrt zum Kunden zurück, um die erarbeitete Leistung beim Kunden zu implementieren und den notwendigen Wissenstransfer durchzuführen.

            –

            Es findet ein Wissenstransfer statt.

Insbesondere unter den folgenden Randbedingungen erscheint der Prozess geeignet:

            –

            Es gibt einen umfangreichen Block an Aufgaben, der von dem Provider eigenständig bearbeitet werden kann.

            –

            Der Kunde benötigt Wissenstransfer aus dem Ausland (Offshore).

            –

            Der Kunde braucht Support für die Implementierung der vom Dienstleister bearbeiteten Aufgaben.

363

I.d.R. werden von den großen IT-Providern Offshore-Leistungen nicht separt angeboten, sondern im Paket mit inländischen Outsourcing-Leistungen. So bietet ein IT-Provider SAP-Hosting als Leistungen, welche innerhalb von der Landesgrenzen erbracht wird, während die Call Center-Leistungen oder Entwicklung von Schnittstellen zur Anbindung der SAP-Applikationen in einer Offshore-Region erbracht werden.

h) Rechtliche Fragen

364

Die rechtlichen Fragen sind natürlich immer davon abhängig, in welches Land ausgelagert wird. Hierbei ist wie bereits erwähnt der chinesische Markt mangels fehlender Urheberrechtsrichtlinien sowie der grundsätzlich völlig anderen Gesetzeslandschaft rechtlich sehr schwer einzuschätzen. Auch in anderen Auslagerungsländern stellt sich die Frage, inwieweit Service-Level Agreements auch tatsächlich juristisch eingefordert werden können.

365

Auch die Fragen des Datenschutzes sollten bereits im Vorfeld eines Offshore-Projektes geregelt sein. In der Praxis wird wahrscheinlich ein Offshoring in eine klassische Offshore-Region nur mit Einwilligung der betroffenen Personen zu personenbezogenen Daten möglich sein. Siehe hierzu

3. Kap.

366

All dies sollte in einer Risikobetrachtung eines Offshore-Outsourcing nicht fehlen und in einer entsprechenden Vertragsgestaltung berücksichtigt werden. Zur Vertragsgestaltung eines Offshore-Outsourcings siehe

4. Kap.

Zu den aufsichtsrechtlichen Fragen im Rahmen eines Offshoring bzw. Nearshoring-Projekt in der Kreditwirtschaft nach § 25a KWG siehe

8. Kap.

 Outsourcing in der Kreditwirtschaft.

2

 ›

I

 › 8. ASP/SaaS

8. ASP/SaaS

367

Das Geschäftsmodell Application Service Providing (Kurzform ASP), bzw. das Geschäftsmodell Software as a Service (Kurzform SaaS) beruht auf der Idee, dass nicht jede Applikation auf jedem Rechner (Client) zur Verfügung stehen muss, sondern zentral von einem Server auf einen Client geladen werden kann. Durch die erhebliche Steigerung der Bandbreiten im Bereich des WANs und durch die Etablierung von Server based Computer/Thin-Clients Lösungen gewinnen ASP/SaaS-Modelle immer mehr an Attraktivität, auch außerhalb von Outsourcing-Projekten. Aus diesem Grund muss die Vertragsgestaltung eine Rechtssicherheit bieten, um solche Projekte auch tatsächlich durchführen zu können.

368

ASP/SaaS kann durchaus auch ein Teil eines Cloud Computing Modells sein. Bei einem Cloud Computing Modell stellt der Provider neben den Applikationen zusätzlich Storage/Filespace und Datenbanken zur Verfügung, was im Wesentlichen auch die Unterscheidung von Cloud Computing Modell zum Geschäftsmodell ASP/SaaS ausmacht.

a) Geschäftsmodell ASP/SaaS

369

Ein ASP/SaaS-Anbieter bietet i.d.R. seinen Kunden dabei den Zugriff auf verschiedenste Software-Applikationen an. Diese Applikationen kommen von leistungsfähigen, sicheren und hoch verfügbaren Rechenzentren. Im Gegensatz zu herkömmlichen Unternehmen verkaufen sie ASP/SaaS-Anwendungen wie Office-Pakete oder Betriebssysteme nicht an ihre Kunden, sondern stellen diese Leistungen den Unternehmen gegen eine Gebühr zur Verfügung (sog. Business bzw. IT-Services on demand). Die Anwendungen werden auf einem zentralen Server über das LAN oder WAN zur Verfügung gestellt und von den Unternehmen oder auch von Endanwendern über das Internet oder Virtual Private Networks (VPN) abgerufen (siehe Abbildung 21). Application Service Providing (ASP)/Software as a Service (SaaS) wird z.T. auch als Software-Outsourcing bezeichnet.

Abb. 21:

Application Service Providing (ASP)

370

Häufig werden über ASP-Server folgende Applikationen angeboten:

            –

            SAP ERP Applikationen

            –

            Microsoft Office

            –

            Netscape Navigator/Internet Explorer

            –

            Datenbank-Clients (z.B. Siebel)

            –

            Fax-Applikationen

b) Abgrenzung zum Housing

371

ASP/SaaS steht auch immer in Abgrenzung zum Serverhousing bzw. Housing. Als Serverhousing (oder auch Serverhoming, Colocation, Co-Location) bezeichnet man die Unterbringung und Netzanbindung eines Kundenservers im Rechenzentrum eines Internet Service Providers (ISP) oder bzw. eines Providers. Der Anbieter von Housing-Lösungen stellt seinem Kunden die Infrastruktur zur Nutzung von Server und anderem IT-Equipment in seinem Rechenzentrum zur Verfügung. Die Unterbringung des IT-Equipment des Kunden erfolgt in speziell für diesen Zweck konzipierten Rechenzentren, die klimatisiert und alarmgesichert sind, die über Gaslöschanlagen und eine mehrfach abgesicherte unterbrechungsfreie Stromversorgung (USV) verfügen und auch die jeweils aktuellen rechtliche Anforderungen erfüllen. Der Housing-Anbieter stellt zum Teil auch Personal zur Verfügung, welches auftretende Hardwarestörungen behebt. Vorteil gegenüber einem Betrieb in den Räumen des Kunden ist i.d.R., dass der Kunde keine Investitionen in die Anschaffung von Rechenzentrums-Infrastruktur investieren muss und dass er relativ flexibel bei der Anmietung der Flächen ist. Rechtlich dürfte ein Housing-Vertrag in den Bereich des Mietrechts nach §§ 535 ff. BGB fallen, da der Provider dem Kunden lediglich Platz in seinem Rechenzentrum zur Verfügung stellt. Sofern die Serviceleistung nur eine Nebenleistung ist und die Hauptleistung in der Zurverfügungstellung eines bestimmten Bereichs im Rechenzentrum des Housing-Providers besteht, sollte sich an dem Mietcharakter des Vertrages nichts ändern. Vergleichbar ist der vom BGH entschiedene Fall bei der Überlassung von Fahrzeugen oder Maschinen mit Bedienungspersonal, welche der BGH als Miete mit Dienstverschaffung ansieht. Um einen Werkvertrag nach §§ 631 BGB ff. handelt es sich nach der Ansicht des BGH erst, wenn der Fahrzeughalter den Transport verspricht, also einen bestimmten Erfolg.

372

In der Abgrenzung zu ASP/SaaS stellt beim Housing der Provider lediglich den Betrieb der Hardware (i.d.R. Server) sicher, während beim ASP/SaaS der Provider auch für das WAN, das Hosting (OS, Middleware, usw.) und die Applikation verantwortlich ist.

c) Outsourcing-Form vs. Auslagerungsbereich

373

Ob es sich bei ASP/SaaS tatsächlich um eine Form des Outsourcings handelt, erscheint fraglich. Häufig ist ASP/SaaS nur ein Teil eines größeren Outsourcings und verbindet die unterschiedlichen Auslagerungsbereiche des RZ-Outsourcing bzw. SAP-Hostings mit den Auslagerungsbereichen AMS und WAN. Findet ASP ohne ein Auslagern von anderen Teilbereichen statt, so kann es auch als Outtasking betrachtet werden.

374

Beim Applikationen-Hosting werden die Applikationen des Kunden (z.B. SAP ERP) im Rechenzentrum des Providers gehostet bzw. betrieben (Operating). Dies wird häufig auch als RZ-Outsourcing bezeichnet. Darüber hinaus kann der Kunde zusätzlich sog. Application-Management-Services (AMS) beauftragen, die die Pflege und sonstige Leistungen rund um die Applikationen des Kunden beinhalten. Zusätzlich zu den Leistungen auf dem Layer der IT-Infrastruktur werden gerade beim ASP auch Leistungen als „add on“ auf dem Layer der IT-Prozesse angeboten. Hierzu zählen i.d.R. sämtliche IT-Prozesse des IT-Service-Managements nach der ITIL V3 (2011).

375

Beim ASP/SaaS übernimmt der ASP-Anbieter i.d.R. das Hosting/Operating der Applikationen sowie sämtliche notwendige Application-Management-Services (AMS), häufig inkl. der WAN-Anbindung hin zum Outsourcing-/ASP-/SaaS-Kunden. Im Vordergrund des ASP/SaaS steht eigentlich das Vergütungsmodell. Der ASP/SaaS-Kunde zahlt nicht mehr für die einzelne Lizenz einer Applikation, sondern nur die temporäre Nutzung dieser Applikationen über das Netz. Er bezieht quasi die Nutzung der Applikation wie Strom aus der Steckdose (wird auch als „Strommodell“ bezeichnet); ASP/SaaS stellt somit ein IT-Service-on-demand-Produkt dar.

Abb. 22:

Application Service Providing

d) Rechtliche Betrachtung

376

Die rechtliche Betrachtung eines ASP-Modells basiert im Wesentlichen auf der vertraglichen Beziehung, da die gesetzlichen Regelungen i.d.R. nicht ausreichend sind, um ein ASP-Modell wirksam zu regeln.

377

In der Regel hat der Application Service Provider seine Applikationen nicht selbst entwickelt und programmiert. Meist erwirbt der Provider die Lizenzen für diese Applikationen im Rahmen eines schuldrechtlichen Kaufvertrags nach §§ 433 ff. BGB vom Hersteller (1. Vertragsverhältnis) und einer Übertragung nach § 31 UrhG, um sie später im Rahmen eines ASP/SaaS an seine Kunden zu vermieten (2. Vertragsverhältnis: das eigentliche ASP/Saas). Ein ASP/SaaS Modell besteht somit aus zwei Vertragsverhältnissen. Das erste Vertragsverhältnis besteht zwischen dem Hersteller der Applikation oder Händler der Applikation und dem Application Service Provider/SaaS Anbieter. Das zweite Vertragsverhältnis besteht zwischen dem Application Service Provider/SaaS Anbieter und seinem Kunden. Diese vertraglichen Beziehungen und die eindeutige vertragstypologische Zuordnung nach dem Gesetz stellen die wesentlichen Fragen beim ASP/SaaS in der Vergangenheit dar. Im Vertragsverhältnis #1 spielen eher lizenzrechtliche Fragen eine Rolle, sprich welche Nutzungsrechte überträgt der Hersteller dem Application Service Provider. Beim Vertragsverhältnis #2 wird das eigentliche ASP-Modell vertraglich definiert. Neben den vertragstypologischen und nutzungsrechtlichen Fragen spielen im Vertragsverhältnis #2 auch die Definition von Service-Level-Agreements (SLA) eine erhebliche Rolle.

Abb. 23:

Vertragsverhältnisse

aa) Vertragsverhältnis 1: Softwareproduzent und Application Service Provider

378

Will der Application Service Provider/SaaS Anbieter seinem Kunden ein ASP/SaaS-Modell im Rahmen des Vertragsverhältnis #2 anbieten, so muss er seine Intention für das ASP/SaaS -Modell bereits im Kaufvertrag des Vertragsverhältnisses #1 berücksichtigen. Der Application Service Provider muss beim Erwerb der Lizenzen deutlich darauf achten, dass im Lizenzvertrag zwischen ihm und dem Hersteller eine Erlaubnis zur Nutzung der Applikationen in einem ASP-Modell enthalten ist. Denn die Vermietung der Applikationen/der Software an den ASP-Kunden ist nur mit der ausdrücklichen Zustimmung des Produzenten zulässig. Das Vertragsverhältnis #1 muss das zwingende Recht zur Unterlizenzierung sowie ggf. eine erlaubte Mehrplatznutzung beinhalten.

379

Ohne die rechtliche Betrachtung im Vertragsverhältnis #2 vorweg zunehmen, wird es sich hierbei nach der gängigen Rechtsprechung des BGH um ein Mietverhältnis handeln. Damit also der Application Service Provider/SaaS Anbieter sein Geschäftsmodell im Vertragsverhältnis #2 anbieten kann, muss er nicht nur die reinen Lizenzen, sprich das einfache Nutzungsrecht nach § 31 Abs. 1 Satz 2 Var. 1 UrhG erwerben, sondern benötigt gem. § 69c Nr. 3 UrhG auch das Vermietrecht. Der Einwand, dass erworbene Gegenstände auch vermietet werden dürfen, greift nur bei Sachen und nicht bei Rechten. Zwar wird vertreten, dass Software auch als Sache angesehen wird. Aber bei urheberrechtlich geschützten Werken wie Software/Nutzungsrechten erschöpft sich gem. § 69c Nr. 3 UrhG das Verbreitungsrecht in Bezug auf das Vervielfältigungsstück nur mit der Ausnahme des Vermietrechts.

380

Dem wiederum wird entgegen gehalten, dass kein Gleichlauf zwischen dem bürgerlichrechtlichen und dem urheberrechtlichen Begriff des Vermietens besteht. Während das BGB eine Besitzverschaffung nicht zwingend voraussetzt, sondern lediglich eine Gebrauchsgewährung erfordert, folgt aus der Zuordnung des Vermietrechts als Unterfall des Verbreitungsrechts zur Gruppe der körperlichen Werkvertretungen i.S. § 15 Abs. 1 UrhG, dass eine Vermietung i.S.d. des Urheberrechts die körperliche Überlassung eines Werkstücks an den Nutzer erfordert. Eine urheberrechtsrelev