Praxisfall: Ein polnisches Delivery-Team für eine IT-Beratung prüfen
Wie ein IT-Beratungsunternehmen mit knapp 100 Mitarbeitern eigenes Team, Dienstleister und Hybridmodell anhand von Kontrolle, Talent, Kundenanforderungen und Skalierbarkeit vergleichen kann.
Ausgangslage
Der Kontext betrifft ein IT-Beratungsunternehmen mit knapp 100 Mitarbeitern. Ein polnisches Team kann Zugang zu zusätzlichen Profilen schaffen, Kundenprojekte skalierbarer machen und Wissen im Unternehmen halten. Gleichzeitig besteht das Risiko, lediglich eine entfernte Kapazitätseinheit ohne Produktnähe, Führung und Entwicklungsperspektive aufzubauen.
Vor der ersten Einstellung muss deshalb geklärt werden, welche Verantwortung tatsächlich nach Polen soll: austauschbare Lieferkapazität, ein dauerhaftes Delivery-Team, ein Kompetenzzentrum oder eine hybride Erweiterung bestehender deutscher Teams.
Die Modellentscheidung
| Kriterium | Eigenes Team | Dienstleister | Hybridmodell |
|---|---|---|---|
| Kontrolle über Prioritäten | hoch, wenn Produkt- und Führungsrechte klar sind | vertraglich definiert, operativ begrenzt | geteilt; klare Schnittstellen nötig |
| Startgeschwindigkeit | abhängig von Recruiting und Arbeitgeberfähigkeit | häufig schneller bei verfügbaren Profilen | Pilot über Partner, Kernrollen intern |
| Know-how-Bindung | hoch bei echter Teamzugehörigkeit | abhängig von Fluktuation und Vertrag | Kernwissen intern, variable Kapazität extern |
| Skalierung | kontrolliert, aber führungsintensiv | flexibler, sofern Anbieter liefern kann | flexibel mit höherem Governance-Aufwand |
| Kundenanforderungen | direkt steuerbar | Unterauftrag, Datenschutz und Sicherheit prüfen | Rollen und Datenzugriffe trennen |
Rollenarchitektur vor Recruiting
Eine reine Liste offener Technologien führt selten zu einem stabilen Team. Benötigt wird eine Rollenarchitektur mit Verantwortungsniveau, Senioritätsmix, Kundenkontakt, Sprachbedarf, Delivery-Prozess und technischer Führung. Für den Start sind wenige Schlüsselrollen wichtiger als viele parallele Vakanzen.
- Delivery- oder Engineering-Lead: verbindet Kundenanforderungen, Qualität und Teamaufbau.
- Kernprofile: decken den häufigsten Technologie- und Projektbedarf ab.
- Qualität und DevOps: sichern Lieferfähigkeit statt nur Entwicklungsstunden.
- Recruiting und People Operations: halten Prozessgeschwindigkeit und Candidate Experience stabil.
Kunden- und Sicherheitsanforderungen als frühes Gate
Bei einer Beratung hängen Liefermodelle oft von Kundenverträgen ab. Unterauftragnehmer, Arbeitsort, Zugriffsrechte, Datenschutz, Geheimhaltung, Informationssicherheit und branchenspezifische Vorgaben müssen deshalb vor dem Recruiting geprüft werden. Eine technisch attraktive Teamidee ist nicht tragfähig, wenn der geplante Zugriff oder die Lieferkette vertraglich nicht zulässig ist.
Ein sinnvoller Pilot verwendet einen realen, aber kontrollierbaren Leistungsumfang: wichtig genug, um Zusammenarbeit und Qualität zu testen, aber begrenzt genug, um Lernen zu ermöglichen. Abnahmekriterien sollten Qualität, Durchlaufzeit, Kommunikation, Wissenstransfer und Kundenfeedback abbilden.
Ein belastbarer 90-Tage-Pfad
- Woche 1–2: Zielbild, Kundenrestriktionen und Make-or-buy-Kriterien klären.
- Woche 2–4: Rollen, Gehaltskorridore und geeignete Städte testen.
- Woche 3–6: Arbeitgebermodell, Verträge, Security und operative Führung synchronisieren.
- Woche 5–10: Lead-Rolle und erstes Kernteam auswählen.
- Woche 8–12: Pilot, Onboarding, Qualitätsmetriken und Übergabe etablieren.
Nearshore funktioniert dann, wenn Verantwortung übertragen wird – nicht nur Arbeit.
Welche Kennzahlen wirklich helfen
Stundensätze und Besetzungszahlen allein zeigen keine Delivery-Qualität. Sinnvoll sind unter anderem Time-to-productive, Stabilität der Kernrollen, Planbarkeit von Zusagen, Fehler- und Nacharbeitsquote, Durchlaufzeit, Wissenstransfer sowie Zufriedenheit der internen und externen Kunden. Diese Kennzahlen müssen bereits im Pilot definiert werden.
Was auf andere IT-Unternehmen übertragbar ist
Übertragbar ist die Reihenfolge: Kunden- und Sicherheitsfähigkeit vor Vertragsmodell, Rollenarchitektur vor Recruiting, Lead-Rolle vor breiter Skalierung und echte Ergebnisverantwortung vor Headcount-Ziel. Die Make-or-buy-Matrix für Nearshore-Softwareentwicklung vertieft die Modellwahl. Der Readiness Check zeigt offene Voraussetzungen im eigenen Vorhaben.