Software-Partner onboarden: Die ersten 14 Tage

Beispiel: Ein externer Software-Partner startet am Montag, aber das Testsystem ist gesperrt und niemand kann das erste Ticket freigeben. Aktivität in Meetings ersetzt in diesem Fall keinen Fortschritt. Planen Sie die ersten zwei Wochen um ein kleines überprüfbares Ergebnis: Benennen Sie fachliche und technische Entscheider, begrenzen Sie Zugänge, dokumentieren Sie offene Hindernisse und prüfen Sie gemeinsam die erste Änderung. Die Zahl der Tage ist ein Planungsrahmen, keine Garantie für Systemkenntnis.

Dieser Artikel beginnt nach der Partnerwahl. Wenn Sie noch Anbieter vergleichen, nutzen Sie zuerst unseren Leitfaden zur Auswahl eines Software-Partners.

Vor dem Start: Auftrag und Zugänge begrenzen

Benennen Sie einen fachlichen und einen technischen Ansprechpartner. Definieren Sie das erste Problem, den betroffenen Prozess, die verfügbaren Umgebungen und die Entscheidung, die der Partner selbst treffen darf. Stellen Sie Architekturübersicht, Repository, Testzugang und bekannte Risiken bereit. Vergeben Sie nur die Rechte, die für den ersten Schritt nötig sind, und dokumentieren Sie, wer sie wieder entzieht.

Ein Partner sollte fehlende Informationen sichtbar machen können, statt eine vollständige Anforderungsliste vorzutäuschen. Ein kurzes gemeinsames Systembild und ein offenes Risikoprotokoll sind zu Beginn oft nützlicher als viele Folien.

Ein prüfbarer Plan für die ersten zwei Wochen

• Start
  Erwartetes Ergebnis: Auftrag, Zuständigkeiten und Zugriffsliste
  Abnahmefrage: Sind Ziel und Sicherheitsgrenzen verstanden?
• Erste Woche
  Erwartetes Ergebnis: Systemkarte, offene Fragen und kleinster Testfall
  Abnahmefrage: Kann das Team den Ablauf erklären und lokal testen?
• Zweite Woche
  Erwartetes Ergebnis: Erster kleiner Beitrag oder belastbare technische Entscheidung
  Abnahmefrage: Ist das Ergebnis überprüfbar und das nächste Risiko benannt?

Ein komplexes Legacy-System oder ein regulierter Prozess kann länger brauchen. Dann ist ein dokumentierter Engpass ein ehrliches Ergebnis. Behauptungen wie „volle operative Kontrolle in 14 Tagen“ sind ohne Kenntnis des Systems nicht belastbar.

Das erste Ticket an die echte Teamstruktur anpassen

Scorpion Power nennt für die Financed-Sweden-Plattform unter anderem Entwicklung, QA, DevOps und Business Analyse; die Referenz sagt nichts über den tatsächlichen Onboarding-Ablauf. Für ein Projekt mit solchen Rollen sollten Sie im eigenen Startplan festlegen, wer Anforderungen klärt, wer einen Testfall liefert, wer Zugang zur Zielumgebung freigibt und wer die erste Änderung abnimmt. Fehlt eine dieser Rollen im neuen Partnerteam, muss die Zuständigkeit beim Kunden oder einem weiteren Dienstleister ausdrücklich benannt sein.

Wählen Sie das erste Ticket so, dass es diese Übergaben sichtbar macht. Eine kleine Änderung an einer externen Schnittstelle kann reichen: Business Analyse beschreibt den erwarteten Datensatz, Entwicklung baut die Änderung, QA prüft einen Fehlerfall, DevOps zeigt den Rückweg. Das ist ein vorgeschlagenes Prüfbeispiel, keine Behauptung über das genannte Projekt. Bei der Auswahl des Beraters sollten Sie bereits klären, wer diese Arbeit später tatsächlich übernimmt.

Wie Wissen im Unternehmen bleibt

Vereinbaren Sie, wo Entscheidungen, Schnittstellen, Tests und Betriebsabläufe dokumentiert werden. Lassen Sie interne Mitarbeitende den ersten Beitrag mitprüfen. Ein guter Übergang endet nicht mit einer Präsentation, sondern mit einem reproduzierbaren Build, klaren Zugängen, einem nachvollziehbaren Ticket und einer Person, die offene Fragen beantworten kann.

Besprechen Sie auch den Ausstieg: Was passiert, wenn die Zusammenarbeit nach einem Monat endet? Können Ihr Team oder ein anderer Dienstleister den Code bauen, den Betrieb verstehen und die Arbeit fortsetzen? Diese Frage verbessert das Onboarding, selbst wenn der Partner lange bleibt.

Ein konkreter erster Beitrag

Angenommen, ein Partner soll eine bestehende Kundenplattform weiterentwickeln. Ein geeignetes erstes Ticket könnte einen kleinen, gut abgegrenzten Fehler im Export betreffen. Dafür muss das Team den Build ausführen, einen Testfall reproduzieren, den Datenfluss verstehen und eine Änderung durch Review und Deployment-Vorbereitung bringen. Das zeigt deutlich mehr als eine allgemeine Präsentation der Zielarchitektur.

Wenn dieses Ticket am Ende der zweiten Woche nicht fertig ist, prüfen Sie den Engpass: Fehlt ein Zugang, eine Testumgebung, eine Entscheidung oder tatsächliches Systemwissen? Erst danach beurteilen Sie die Leistung des Partners. Der gleiche Ablauf schützt Ihr internes Team davor, unklare Voraussetzungen dem externen Team zuzuschreiben.

Ein gutes Onboarding kann auch mit der Entscheidung enden, einen riskanten Eingriff zu verschieben. Wenn der Partner die Ursache belegt, eine sichere Zwischenlösung vorschlägt und die offene Entscheidung dokumentiert, ist das wertvoller als ein schneller, schlecht getesteter Patch.

Woran Sie früh nachsteuern

• Der Partner kann das erste Ziel nicht in eigenen Worten erklären.
• Zugänge sind zu breit oder die nötige Testumgebung fehlt.
• Entscheidungen bleiben in Chats und Köpfen statt im Projekt.
• Es gibt viel Aktivität, aber keinen kleinen überprüfbaren Fortschritt.

Wenn eines dieser Signale auftritt, klären Sie Ursache, Verantwortlichen und nächsten Nachweis. Mehr Meetings allein beheben keinen unklaren Auftrag.

Die erste Änderung sauber abnehmen

Vereinbaren Sie für das erste kleine Ticket eine klare Definition von fertig: Der Fehler ist reproduziert, der geänderte Ablauf getestet, die Änderung geprüft und der Weg in die Zielumgebung bekannt. Halten Sie auch fest, was bewusst offenbleibt. Ein Screenshot der neuen Oberfläche reicht nicht, wenn die Ursache unklar oder der Rückweg bei einem Fehler fehlt.

Lassen Sie eine interne Person die Änderung mit dem Partner durchgehen. Sie sollte erklären können, wo der Code liegt, welcher Test die Änderung schützt und wer den nächsten Schritt freigibt. Wenn das nicht gelingt, fehlt nicht zwangsläufig Können beim Partner; vielleicht ist die Zuständigkeit auf Ihrer Seite ungeklärt. Das Abnahmegespräch soll diesen Engpass sichtbar machen.

Häufige Fragen

Welche Zugänge braucht ein Software-Partner am ersten Tag?

Nur die Zugänge für den vereinbarten ersten Schritt, idealerweise zunächst zu Dokumentation, Code und Testumgebung. Produktionsrechte sollten gesondert begründet, freigegeben und zeitlich begrenzt werden. Halten Sie fest, wem Konten gehören und wer sie bei Rollenwechsel oder Vertragsende entzieht.

Was tun, wenn Freigaben die ersten zwei Wochen blockieren?

Machen Sie den Engpass sichtbar und setzen Sie den Plan neu auf. Der Partner kann mit anonymisierten Beispielen, einer Systemkarte oder einem Testfall weiterarbeiten, solange die nötigen Zugänge fehlen. Bewerten Sie ihn nicht nach einer verfehlten Tageszahl, wenn Ihr Unternehmen die Voraussetzung noch nicht geschaffen hat.

Woran erkennen wir eine unzureichende Übergabe?

Wenn nur eine Person die Architektur erklären oder einen kleinen Fehler beheben kann, ist Wissen noch nicht übertragen. Bitten Sie das neue Team, den ersten Ablauf und die offenen Risiken selbst zu beschreiben. Prüfen Sie, ob ein interner Ansprechpartner die Dokumentation findet und die nächste Entscheidung nachvollziehen kann.

Nächster Schritt

Scorpion Power unterstützt laut Leistungsübersicht Softwareprojekte mit Spezialisten, Teams und Entwicklung. Beschreiben Sie uns Ihr System und das erste gewünschte Ergebnis, wenn Sie eine Zusammenarbeit mit einem klaren Startplan prüfen möchten.