Onshore, Nearshore, Offshore: was die Begriffe bedeuten
Die Begriffe beschreiben, wo der Partner im Verhältnis zu Ihnen sitzt. Onshore bedeutet ein Partner im eigenen Land. Nearshore bedeutet ein Partner in einem nahegelegenen Land, meist in derselben oder einer benachbarten Zeitzone. Für Unternehmen in Deutschland und Österreich ist IT-Nearshoring daher in der Regel die Zusammenarbeit mit einem Partner in einem anderen europäischen Land. Offshore bedeutet ein entferntes Land mit großem Zeitunterschied.
Der Standort ist nur die Hälfte der Entscheidung. Die andere Hälfte ist das Kooperationsmodell, also wer die Arbeit führt und wer für das Ergebnis verantwortlich ist:
| Modell | Wer führt die Arbeit | Wer verantwortet das Ergebnis | Typischer Einsatz |
|---|---|---|---|
| Internes Team | Sie | Sie | Langfristiges Kernprodukt |
| Dediziertes Entwicklungsteam | Teamleitung des Partners mit Ihrem Product Owner | Geteilt, wie vertraglich vereinbart | Längere Projekte, die ein stabiles, skalierbares Team brauchen |
| Staff Augmentation | Sie | Sie | Kompetenzlücken schließen oder schnell Kapazität aufstocken |
| Projektbasiertes Outsourcing | Der Partner | Der Partner, für den vereinbarten Umfang | Gut spezifizierte, zeitlich begrenzte Arbeit |
Jedes Kooperationsmodell kann onshore, nearshore oder offshore umgesetzt werden. Ein dediziertes Nearshore-Team und ein Offshore-Vertrag über Staff Augmentation sind völlig unterschiedliche Konstellationen, auch wenn beide als „Outsourcing“ bezeichnet werden.
Wann welches Modell funktioniert
- Ein internes Team ist am besten, wenn Software Ihr zentraler Wettbewerbsvorteil ist, die Arbeit dauerhaft anfällt und von tiefem Fachwissen abhängt. Der Preis sind langsameres Recruiting und weniger Flexibilität.
- Ein dediziertes Nearshore-Team passt zu längeren Projekten mit regelmäßiger, oft täglicher Zusammenarbeit und einem Team, das mit der Arbeit wachsen oder schrumpfen kann. Durch überlappende Arbeitszeiten gehören gemeinsame Planung, Reviews und kurze Rückfragen zum normalen Arbeitstag.
- Staff Augmentation ist der schnellste Weg zu einer Spezialistin oder einem Spezialisten, etwa für Data Engineering oder mobile Entwicklung, aber nur, wenn Sie bereits eine starke technische Führung haben. Ohne sie kaufen Sie Stunden, keine Ergebnisse. Achten Sie in Deutschland und Österreich zudem auf eine saubere vertragliche Abgrenzung zur Arbeitnehmerüberlassung.
- Projektbasiertes Outsourcing eignet sich für eine Integration, eine Migration oder ein separates Modul mit klaren Anforderungen. Schwierig wird es, wenn sich die Anforderungen ständig ändern.
- Offshore kann bei klar spezifizierter Arbeit mit wenig Fachwissen funktionieren, die keine Echtzeit-Abstimmung erfordert.
In der Praxis sind Kombinationen üblich: Product Ownership und Architektur intern, ein dediziertes Team für den Großteil der Entwicklung und eine externe Fachkraft für eine bestimmte Kompetenz.
Partner nach Qualität bewerten, nicht nach Stundensatz
Der Stundensatz ist die am leichtesten vergleichbare und zugleich am wenigsten aussagekräftige Zahl. Entscheidend ist, ob der Partner in gleichmäßigem Tempo funktionierende, wartbare Software liefert. Vergleichen Sie Angebote nach den Gesamtkosten: Einarbeitungszeit, Steuerungsaufwand auf Ihrer Seite, Nacharbeit, Verzögerungen und die Kosten eines späteren Partnerwechsels.
Konzentrieren Sie die Bewertung auf Nachweise:
- Referenzen aus vergleichbaren Projekten mit Ansprechpartnern, die Sie anrufen können,
- Seniorität und Stabilität des tatsächlichen Teams, nicht des Vertriebs,
- Engineering-Praktiken: Code-Reviews, automatisierte Tests, CI/CD und Dokumentation,
- Sicherheitspraktiken und, wo relevant, Zertifizierungen wie ISO/IEC 27001,
- Kommunikation: feste Ansprechperson, regelmäßiges Reporting und sichere Beherrschung Ihrer Arbeitssprache, ob Deutsch oder Englisch.
Steuerung und Kommunikation
Die meisten Probleme bei der Auslagerung der Softwareentwicklung sind Führungsprobleme. Legen Sie von Anfang an fest, wer über Prioritäten entscheidet (Ihr Product Owner), wer die Architektur freigibt, was „fertig“ bedeutet und wie über den Fortschritt berichtet wird. Gemeinsame Werkzeuge helfen: Ihr Repository, Ihr Ticketsystem und Ihre CI-Pipeline, damit die Arbeit sichtbar ist und bei Ihnen bleibt.
Die Überlappung der Arbeitszeiten ist wichtiger, als sie scheint. Ein Team, das den Großteil Ihres Arbeitstags teilt, kann an Daily Stand-ups teilnehmen, Rückfragen in Minuten beantworten und direkt mit Ihren Entwicklern arbeiten. Bei großem Zeitunterschied kostet jede unklare Anforderung einen Tag.
DSGVO, NIS2 und Branchenvorgaben
Hat der Partner Zugriff auf personenbezogene Daten, etwa über Testdaten, Logs oder Produktionssupport, handelt er als Auftragsverarbeiter, und Sie brauchen einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Die Regeln der DSGVO zur Übermittlung in Drittländer (Kapitel V) greifen, sobald personenbezogene Daten die EU bzw. den EWR verlassen. Ein Partner mit Sitz und Verarbeitung in der EU bzw. im EWR vermeidet diese Frage, sofern auch seine Unterauftragsverarbeiter und Tools dort angesiedelt sind. Lassen Sie sich die Liste geben.
Fällt Ihr Unternehmen unter die NIS2-Richtlinie (EU) 2022/2555, in Deutschland umgesetzt durch das NIS2UmsuCG und in Österreich durch das NISG 2026, gehört die Sicherheit der Lieferkette zu den verpflichtenden Risikomanagementmaßnahmen. Die Richtlinie verlangt, die Schwachstellen Ihrer direkten Anbieter und die Qualität ihrer Cybersicherheitspraktiken einschließlich sicherer Entwicklungsverfahren zu berücksichtigen. Ein Entwicklungspartner ist genau ein solcher Anbieter. Vereinbaren Sie daher Sicherheitsanforderungen, Meldung von Vorfällen und Auditrechte im Vertrag.
Im Finanzsektor stellt die DORA-Verordnung (EU) 2022/2554 besondere Anforderungen an IKT-Drittdienstleister. Gesundheitswesen und öffentlicher Sektor haben eigene Vorgaben. Prüfen Sie diese vor der Unterschrift, nicht danach.
Vertrag, geistiges Eigentum und Exit
Das EU-Recht weist dem Arbeitgeber die wirtschaftlichen Rechte an Software zu, die Beschäftigte in Wahrnehmung ihrer Aufgaben schaffen. Bei der Arbeit eines externen Unternehmens sollten Sie sich nicht auf Annahmen verlassen: Der Vertrag muss Ihnen ausschließliche Nutzungs- und Verwertungsrechte an Quellcode, Dokumentation und weiteren Ergebnissen klar einräumen. Praktische Absicherungen:
- Quellcode vom ersten Tag an in Ihrem Repository, die Konten auf den Namen Ihres Unternehmens,
- eine klare Liste der Open-Source-Komponenten und ihrer Lizenzen,
- Vertraulichkeit für Ihre Daten und Ihre Geschäftslogik,
- Kündigungsfristen und vereinbarte Vorlaufzeiten für das Auf- und Abstocken des Teams,
- ein Exit-Plan: Übergabe von Code, Dokumentation, Zugängen und Wissen sowie die Pflicht des Partners, den Übergang zu unterstützen.
Den Partner mit einem 30-Tage-Piloten prüfen
Ein Angebot zeigt, wie ein Partner verkauft. Ein Pilotprojekt zeigt, wie er arbeitet. Geben Sie dem Partner in der engeren Wahl eine kleine, aber echte Aufgabe, vereinbaren Sie die Erfolgskriterien vorab und führen Sie sie in Ihrer Umgebung durch: zuerst Onboarding und eine einfache Aufgabe, dann eine Lieferung mit Code-Review und Tests, dann eine Aufgabe, die Ihre Fachdomäne oder eine Integration berührt, und zum Schluss eine Retrospektive mit Ihren Entwicklern. Das Tool oben erstellt einen Pilotplan und eine auf Ihre Situation gewichtete Checkliste.
Achten Sie auf Warnsignale: Sie können die Personen nicht kennenlernen, die die Arbeit machen, der Partner will Code oder Rechte behalten, Referenzen sind nicht erreichbar, ein niedriger Preis wird zugesagt, bevor jemand Ihre Anforderungen versteht, oder Antworten zu Sicherheit und Subunternehmern bleiben vage.
Wenn Ihr Projekt ERP-Integrationen umfasst, nutzen Sie auch die Checkliste für die ERP-System Auswahl. Wenn Sie Ihr Softwareprojekt und das passende Liefermodell besprechen möchten, sprechen Sie mit uns.
