Nearshore-Partner bewerten: Ein Leitfaden für DACH-Entscheider

Die Wahl eines Engineering-Partners ist eine der folgenreichsten Entscheidungen, die ein CTO oder IT-Leiter treffen kann. Anders als bei der Beschaffung von Standardsoftware prägt eine Engineering-Partnerschaft die Architektur Ihrer Produkte, die Fähigkeiten Ihres Teams und Ihre Wettbewerbsposition über Jahre. Hier zeigen wir, wie sorgfältige Due Diligence in der Praxis aussieht.

Die Grundlage: Eigenes R&D-Center vs. Personalvermittler

Die erste Frage an einen potenziellen Partner ist einfach: Betreiben Sie ein echtes Engineering-Center? Ein seriöses R&D-Center bedeutet Festangestellte, aktive Weiterbildungsprogramme, eigene IP und architektonische Governance. Ein Personalvermittler stellt auf Abruf Auftragnehmer zusammen — kurzfristig praktisch, aber außerstande, das angesammelte institutionelle Wissen zu liefern, das komplexe Unternehmensprojekte erfordern.

Deka Technology betreibt ein Engineering-Center mit 150 Ingenieuren in Istanbul — Festangestellte, organisiert in Practice Areas: Software Engineering, Data & AI sowie Cloud & Infrastructure. Diese Struktur stellt sicher, dass ein Integrationsarchitekt für einen Bankkunden und ein Datening­enieur für einen Logistikkunden gemeinsame Organisationskenntnisse, Code-Standards und Tools teilen — etwas, das kein Auftragnehmer-Netzwerk replizieren kann.

Zertifizierungen als Mindestvoraussetzung

Für DACH-Unternehmen, die unter DSGVO, ISO 27001 und branchenspezifischen Regularien (BaFin, Solvency II, GxP) operieren, ist ein Partner ohne relevante Zertifizierungen ein Compliance-Risiko. Ihre Checkliste sollte enthalten:

• ISO 27001 — Informationssicherheitsmanagement; prüfen Sie, ob der Geltungsbereich das Lieferteam umfasst, nicht nur den Hauptsitz
• ISO 9001 — Qualitätsmanagement für wiederholbare Lieferung
• Herstellerzertifizierungen — Microsoft Solutions Partner, AWS Partner, Camunda Certified; diese signalisieren echte Praxistiefe, nicht nur Vertriebsbeziehungen
• DSGVO-Verarbeitungsverträge — EU-konforme AVV, Unterauftragnehmer-Listen und Klarheit zur Datenhaltung

Verlangen Sie die tatsächlichen Zertifikate, nicht nur Logos auf einer Website. Gleichen Sie den Zertifizierungsumfang mit dem Team ab, das tatsächlich an Ihrem Projekt arbeiten wird.

Technische Tiefe bewerten

Eine Credential-Prüfung zeigt Ihnen die Mindestanforderungen. Technische Tiefe ist schwerer zu bewerten, aber aussagekräftiger für den Projekterfolg. Bewährte Evaluierungsmethoden:

1. Architektur-Review-Sessions — Präsentieren Sie eine anonymisierte Version Ihrer aktuellen Architektur und bitten Sie den Partner, sie zu analysieren und Verbesserungen vorzuschlagen. Schwache Partner geben generische Ratschläge; starke Partner stellen gezielte Fragen zu Ihren SLAs, Ihrer Teamstruktur und Ihren Deployment-Anforderungen.
2. Referenzgespräche mit vergleichbaren Unternehmen — Sprechen Sie mit einem Kunden ähnlicher Branche und Projektgröße. Fragen Sie konkret, wie der Partner mit Änderungen im Scope, Produktionsvorfällen und Teamfluktuation umgegangen ist.
3. Code- und Artefaktprüfung — Fordern Sie Muster-Lieferobjekte an: anonymisierte Testberichte, ADRs (Architecture Decision Records) oder Runbooks. Diese zeigen die Reife der Engineering-Kultur.
4. Team-Stabilitätskennzahlen — Fragen Sie nach der jährlichen Ingenieur-Fluktuationsrate. Der Branchenmedian für Nearshore-Center liegt bei 18–25 %; alles über 30 % signalisiert kulturelle oder vergütungsbezogene Probleme, die mitten im Projekt auftreten werden.

Engagement-Modelle: Dedicated Team vs. Projektbasiert

Das richtige Engagement-Modell hängt von der Art Ihres Projekts und Ihren internen Kapazitäten ab.

Ein Dedicated Team integriert Ingenieure in Ihre Produktorganisation unter Ihren Prozessen und Tools. Dies funktioniert gut, wenn Sie ein Produkt-Backlog haben, einen internen PO oder Product Manager, und über 12+ Monate eine nachhaltige Velocity benötigen. Der Partner stellt Ingenieure, Team Lead und technisches Mentoring; Sie setzen die Prioritäten.

Ein projektbasiertes Modell überträgt Scope, Budget und Lieferverantwortung auf den Partner. Dies eignet sich für klar definierte Projekte — ein neues Modul, eine Migration, ein Data Warehouse — bei denen die Erfolgskriterien eindeutig sind.

Warnsignal: Ein Partner, der darauf besteht, dass jedes Engagement auf Time-and-Materials-Basis ohne Meilensteinverpflichtungen läuft, priorisiert sein eigenes Risikomanagement über Ihre Geschäftsergebnisse.

Vertragsstrukturen, die beide Seiten schützen

Solide Verträge regeln klar das geistige Eigentum (alle Arbeitsergebnisse werden dem Kunden übertragen), enthalten Source-Code-Escrow-Bestimmungen für kritische Systeme, legen Datenverarbeitungs- und Löschverfahren fest und definieren SLAs sowohl für die Entwicklung (Reaktionszeiten, Fehlerbeseiti­gung) als auch für den Betriebssupport. Bestehen Sie auf einer Governance-Struktur: vierteljährliche Business Reviews, benanntes Account Management und einen Eskalationsweg, der innerhalb von 24 Stunden nach einem kritischen Vorfall die Führungsebene erreicht — nicht nur den Projektmanager.

Die obige Checkliste garantiert keinen Erfolg, eliminiert aber die Partner, die am wahrscheinlichsten versagen werden.