Vom Sourcing Need bis zur Vorauswahl: So strukturieren Sie die Software Engineering Partner Selection.

Die Software Engineering Partner Selection lässt sich leichter handhaben, wenn der Prozess mit dem Sourcing Need beginnt und nicht mit einer Liste von Unternehmen. Bevor sie Software Engineering Partner miteinander vergleichen, sollten Tech Buyers definieren, was sie benötigen, welche Kriterien entscheidend sind, wie breit sie suchen möchten und welche Nachweise sie benötigen, bevor sie von einer Longlist zu einer Shortlist übergehen.

Beginnen Sie mit dem Sourcing Need, nicht mit der Vorauswahl

Software Engineering Partner Selection sollte beginnen, bevor ein Software Engineering Partner kontaktiert wird.

Zu den relevanten Fragen können gehören:

• Welches Geschäftsziel soll das Projekt unterstützen?
• Welche Kompetenzen im Bereich Softwareentwicklung sind erforderlich?
• Wie sieht der aktuelle technologische Kontext aus?
• Bezieht sich der Bedarf auf ein Projekt, ein festes Team, eine Teamerweiterung oder ein anderes Einsatzmodell?
• Welche Delivery Models sind realistisch?
• Gibt es Anforderungen hinsichtlich des Standorts, der Zeitzone oder der Sprache?
• Wie sollten interne und externe Teams zusammenarbeiten?
• Welche Anforderungen an die Unternehmensführung gelten?
• Welche wirtschaftlichen Zwänge müssen berücksichtigt werden?
• Gibt es Anforderungen hinsichtlich Sicherheit, Regulierung oder Compliance?

Nicht jede Frage wird in jeder Beschaffungssituation das gleiche Gewicht haben. Das Ziel besteht nicht darin, ein möglichst umfangreiches Anforderungsdokument zu erstellen, sondern die Kriterien zu ermitteln, die wichtig genug sind, um die Auswahl der in Betracht zu ziehenden Software Engineering Partner zu beeinflussen.

Ein klar definierter Sourcing Need trägt zudem dazu bei, zu verhindern, dass die Suche davon bestimmt wird, welche Unternehmen gerade im Blickfeld stehen, bekannt sind oder bereits zum Netzwerk gehören.

Sobald der Sourcing Need klar genug definiert ist, können Tech Buyers diesen in Bewertungskriterien umsetzen.

Dies sollte vor eingehenden Gesprächen mit den Software Engineering Partnern erfolgen. Andernfalls können eine überzeugende Präsentation, eine enge Geschäftsbeziehung oder ein attraktives kommerzielles Angebot unbeabsichtigt zu einer Neugewichtung der Kriterien führen, nachdem der Prozess bereits angelaufen ist.

Die Bewertungskriterien können unter anderem folgende Bereiche umfassen:

• Capability Fit,
• einschlägige Projekterfahrung,
• verfügbare Delivery Evidence,
• technologischer Kontext,
• Teamzusammensetzung und Seniorität
• Delivery Model,
• Kooperationsmodell,
• Governance,
• Standort- und Zeitzonen-Fit,
• kommerzielles Modell
• Sicherheits- oder Compliance-Erwägungen,
• Skalierbarkeit und Kontinuität,
• Kommunikation und Zugang zu Führungskräften.

Nicht alle Kriterien müssen das gleiche Gewicht haben. Einige können zwingend vorgeschrieben sein, während andere dazu dienen, zwischen ansonsten gleichwertigen Optionen zu unterscheiden.

So kann beispielsweise eine bestimmte Zertifizierung in einer Beschaffungssituation unerlässlich sein, in einer anderen hingegen irrelevant. Ein bestimmter Lieferort kann entscheidend sein, wenn eine Zusammenarbeit in Echtzeit erforderlich ist, während ein anderes Projekt möglicherweise erheblich mehr Flexibilität zulässt.

Eine frühzeitige Festlegung dieser Prioritäten schafft eine stabilere Vergleichsgrundlage.

Bilden Sie sich zunächst einen Überblick über den Markt, bevor Sie die Auswahlliste erstellen

Tech Buyer haben mehrere mögliche Quellen, um Software Engineering Partner zu finden.

Jede Quelle vermittelt eine andere Sicht auf den Markt.

Der Sourcing Need sollte bestimmen, wie breit die Suche sein muss.

Die Vorauswahl sollte nicht automatisch von einer einzigen Quelle bestimmt werden.

Trennen Sie die Longlist von der Shortlist

Eine Longlist und eine Shortlist dienen unterschiedlichen Zwecken.

Eine Longlist enthält Software Engineering Partner, die auf der Grundlage einer ersten Bewertung des Sourcing Needs und der verfügbaren Marktinformationen als potenziell relevant erscheinen.

Eine Auswahlliste umfasst eine kleinere Gruppe, bei der ausreichende Anhaltspunkte für eine mögliche Eignung vorliegen, um eine eingehendere Bewertung zu rechtfertigen.

Diese Unterscheidung ist von Bedeutung, da es selten eine effiziente Nutzung der Zeit darstellt, bei jedem auf dem Markt identifizierten Unternehmen die gleiche Sorgfaltsprüfung durchzuführen.

Die ursprüngliche Longlist lässt sich daher anhand von Kriterien eingrenzen, die relativ einfach zu bewerten sind, wie zum Beispiel:

• entsprechende Fähigkeiten,
• technische Erfahrung,
• Lieferorte,
• Unternehmensgröße oder Verfügbarkeit des Teams,
• Delivery Model,
• Branchenkontext,
• einschlägige Case Studies oder sonstige verfügbare Informationen.

Der Übergang von der Longlist zur Shortlist sollte mit einer größeren Gewissheit einhergehen, dass der Software Engineering Partner tatsächlich für das Sourcing Need relevant ist.

Es gibt keine allgemein gültige Anzahl von Unternehmen, die in eine der beiden Listen aufgenommen werden sollten.

Die geeignete Größe hängt von Faktoren wie den folgenden ab:

• die Komplexität des Sourcing Needs,
• wie spezialisiert die erforderlichen Fähigkeiten sind,
• die Anzahl realistischer Marktoptionen,
• die strategische Bedeutung des Einsatzes,
• die Dringlichkeit der Entscheidung,
• der Umfang der verfügbaren internen Bewertungskapazitäten.

Das Ziel besteht nicht darin, die Anzahl der bewerteten Software Engineering Partner zu maximieren. Vielmehr geht es darum, genügend aussagekräftige Alternativen zu erhalten, um eine fundierte Entscheidung treffen zu können.

Nicht jede Software Engineering Partner Selection erfordert denselben Prozessumfang.

Der erforderliche Umfang der Bewertung kann von folgenden Faktoren abhängen:

• voraussichtliche Dauer des Auftrags,
• finanzielles Risiko,
• Abhängigkeit vom Software Engineering Partner,
• Kritikalität des Systems oder Produkts,
• aufsichtsrechtliche oder sicherheitstechnische Anforderungen,
• die Schwierigkeit, den Partner später zu ersetzen,
• Größe und Zusammensetzung des vorgeschlagenen Teams,
• Komplexität des Delivery Models,
• Anforderungen an die Unternehmensführung.

Ein umfassenderer Prozess könnte Interviews mit mehreren Beteiligten, Fachworkshops, Referenzgespräche, geschäftliche Verhandlungen sowie die Validierung der vorgeschlagenen Projektteams umfassen.

Entscheidend ist, dass das Verfahren in einem angemessenen Verhältnis zur Entscheidung steht.

Legen Sie die Anforderungen an die Nachweise ausdrücklich fest

Verschiedene Informationsquellen sollten nicht als gleichwertige Beweismittel behandelt werden.

Ein Unternehmensprofil beschreibt in erster Linie, was ein Software Engineering Partner über seine Kompetenzen, seine Erfahrung und seine Projektabwicklung aussagt.

Eine Case Study kann als Nachweis für Erfahrungen mit erfolgreich abgeschlossenen Projekten dienen, wobei der Umfang der Nachweise variieren kann.

Kundenstimmen liefern Hinweise auf Erfahrungen aus früheren Geschäftsbeziehungen und der Zusammenarbeit.

Zertifizierungen, Technologiepartnerschaften und Qualifikationen der Mitarbeiter können zusätzliche Einblicke in die Standards eines Unternehmens oder in spezifisches Fachwissen vermitteln.

„Partner Insights“ können Fachkompetenz, Verständnis für Problemstellungen und das Bewusstsein für relevante Abwägungen belegen. Sie sollten jedoch nicht als Nachweis dafür gewertet werden, dass der Software Engineering Partner ein vergleichbares Projekt erfolgreich umgesetzt hat.

Diese Unterscheidung gewinnt an Bedeutung, wenn man von einer ersten Marktübersicht zur Erstellung einer Auswahlliste übergeht.

Tech Buyer sollten sich nicht nur folgende Frage stellen:

Lücken in den Nachweisen führen nicht automatisch zum Ausschluss eines Software Engineering Partners. Sie geben vielmehr Aufschluss darüber, welche Aspekte in der nächsten Phase des Auswahlverfahrens geprüft werden müssen.

Stellen Sie klar, wer für das Auswahlverfahren verantwortlich ist

Bei der Software Engineering Partner Selection sind in der Regel mehrere interne Beteiligte beteiligt.

Je nach Beschaffungssituation können zu den relevanten Beteiligten gehören:

• Führungsrolle im Bereich Technologie oder Ingenieurwesen,
• Produkt- oder Geschäftsakteure,
• Beschaffung,
• Lieferantenmanagement,
• Informationssicherheit,
• Rechts- oder Compliance-Teams,
• Finanzen,
• Führungskräfte als Förderer.

Eine klare Zuständigkeit ist wichtig, da diese Beteiligten möglicherweise unterschiedliche Aspekte derselben Entscheidung bewerten.

Die technische Leitung konzentriert sich möglicherweise auf die technische Eignung und den Umsetzungsansatz. Die Beschaffungsabteilung legt den Schwerpunkt möglicherweise auf die geschäftliche Struktur und die Vertragsbedingungen. Sicherheitsteams verlangen unter Umständen spezifische Kontrollmaßnahmen oder Zertifizierungen. Die Stakeholder aus dem Geschäftsbereich sind möglicherweise eher an Ergebnissen, Kommunikation und Schnelligkeit interessiert.

Es muss noch jemand diese Perspektiven zu einem einheitlichen Prozess der Partnerauswahl zusammenführen.

Externe Unterstützung kann unter anderem in folgenden Fällen hilfreich sein:

• Die interne Markttransparenz ist begrenzt,
• Das Unternehmen führt nicht häufig Software Engineering Partner Selection durch,
• Die Kriterien müssen festgelegt werden, bevor man sich dem Markt zuwendet,
• die internen Kapazitäten für Marktforschung oder Evaluierung sind begrenzt,
• Es müssen mehrere Software Engineering Partner einheitlich miteinander verglichen werden,
• Eine zweite Meinung zu einer bestehenden Longlist oder Shortlist wäre hilfreich.

Externe Unterstützung sollte den Entscheidungsprozess des Tech Buyers stärken, anstatt die interne Verantwortung für die endgültige Entscheidung zu ersetzen.

Wechsel von der Vorauswahl zur eingehenderen Partner Evaluation der Software Engineering Partner

Die Erstellung einer Auswahlliste ist nicht der Abschluss der Software Engineering Partner Selection. Sie markiert den Zeitpunkt, an dem eine eingehendere Bewertung sinnvoll wird.

In dieser Phase können die Tech Buyers die Annahmen überprüfen, aufgrund derer die einzelnen Software Engineering Partner in die engere Auswahl aufgenommen wurden.

Dazu können gehören:

• die Durchsicht relevanter Case Studies,
• die Erörterung vergleichbarer Projekterfahrungen,
• die Bewertung des vorgeschlagenen Teams,
• die Untersuchung des Delivery Models und des Kooperationsmodells,
• Überprüfung der Governance-Verantwortlichkeiten,
• Erörterung von Eskalations- und Entscheidungswegen,
• Überprüfung von Sicherheits- oder Compliance-Anforderungen,
• Verständnis der kommerziellen Bedingungen,
• Überprüfung der Kommunikation und des Senior-Level Engagement,
• die Klärung noch bestehender Evidenzlücken.

Bei allen in die engere Wahl gekommenen Software Engineering Partnern sollten durchgehend dieselben zentralen Bewertungskriterien angewendet werden.

Das bedeutet nicht, dass jedes Gespräch oder jeder Workshop identisch sein muss. Es bedeutet vielmehr, dass der abschließende Vergleich auf Kriterien basieren sollte, die mit dem ursprünglichen Sourcing Need in Zusammenhang stehen, und nicht auf unterschiedlichen Eindrücken aus nicht damit zusammenhängenden Gesprächen.

Für einen tieferen Einblick in diese Phase lesen Sie bitte „Wie Sie einen Software Engineering Partner über seine Fähigkeiten hinaus bewerten“.