Outsourcing Checkliste

Lesezeit 5 min

Sie möchten ein Produkt oder einen Teil davon extern entwickeln lassen? Sie möchten sich beraten lassen?

Was sollten Sie dabei beachten? Wie macht man Outsourcing? Wie lesen Sie den richtigen Partner aus?

Wir haben hier für Sie eine Outsourcing Checkliste zusammengestellt. Sie lässt sich dazu verwenden, bei Entwicklungsprojekten und Beratungsmandaten die richtigen Fragen zu stellen. Bitte beachten Sie, dass die Checkliste Body-Leasing so nicht abdeckt!

Was ist der Grund für die Vergabe?

Zuerst ist es vorteilhaft, sich über den zugrundeliegenden Anlass für das Outsourcing klar zu werden.

• Zeit: Die Vergabe dient dazu, schneller am Markt zu sein.
• Ressourcen: Die Vergabe dient dazu, interne Ressourcen zu schonen oder mehr davon zur Verfügung zu haben.
• Expertise: Die Vergabe dient dazu, Wissen einzukaufen.
• Innovation: Die Vergabe dient dazu, neue Ideen einzukaufen.
• Preis: Die Vergabe dient dazu, mit einem kleineren Budget zu entwickeln.

Was sind die Charakteristika des Projektes?

Nicht nur die kommerziellen und technischen Anforderungen sind für eine Projektvergabe wichtig, sondern es macht Sinn, sich auch ein paar Fragen über das Projekt zu stellen.

Ziele

• Haben wir die übergreifende Absicht hinter dem Projekt definiert, eine Projektvision?
• Haben wir klare zu erreichende Projektziele und -resultate bestimmt?
• Was ist das strategische Ziel des Projektes?
  • Ideen erzeugen
    • Wie weit soll das Projekt gehen?
    • Was sind die Randbedingungen? Sind diese Randbedingungen nicht zu einschränkend?
  • Eine Idee testen
    • Haben wir ein Projekt für ein Funktionsmuster, einen Rapid Protoype definiert, oder schon eine Produktentwicklung? Ist der Rapid Prototype wirklich minimalistisch?
    • Erlaubt er uns, die Informationen zu gewinnen, die wir erwarten: technische Machbarkeit, Markt...?
  • Entwicklung bis zur Seriereife
    • Wie findet die Integration mit unseren Systemen und Produkten statt?
    • Wissen wir, wie wir uns die Validation (Feldtests, Dauertests...) vorstellen?
    • Wer macht die Serieneinführung (inkl. Testeinrichtungen, Betreuung der Nullserie...)?
    • Wieviel Support brauchen wir nach der Serieneinführung?

Projektsteuerung

• Wie weit können oder wollen wir uns während des Projektes involvieren?
• Welche technischen und Projektmanagement-Entscheide wollen wir selbst fällen?
• Wer übernimmt das Projektmanagement?
  • Wir selbst:
    • Haben wir die Prozesse, Abläufe und Mitarbeiter, um ein externes Projekt zu führen?
    • Sind wir uns des Kommunikationsaufwandes bewusst? Z.B., dass sich wichtige Entscheide nur in der persönlichen Interaktion fällen lassen?
  • Der Partner:
    • Haben wir auch für diesen Fall genügend Mitarbeiter eingeplant als Schnittstelle zum Projektleitung des Partners, vor allem in den Spezifikations-, Integrations- und Validations-Phasen?

Wissen/ Kernkompetenzen

• Wird Wissen erzeugt, welches zu unserem Kernwissen/ unserer Kernkompetenz beiträgt, über welches wir unbedingt verfügen müssen?
  • ja:
    • Haben wir einen Rücktransfer-Plan (Zeit, Mitarbeiter auf unserer Seite, Formate...), wie wir das geistige Eigentum komplett zurück in unsere Organisation bekommen?
  • nein, es geht nur um Durchführung ("Execution")
    • Haben wir alle Rechte an allem resultierenden geistigen Eigentum (Quellcodes, Schemas, Fabrikationsunterlagen, Testunterlagen, Bibliotheken...), so dass wir bei Änderungen nicht an den Partner gebunden sind ("Lock-In")?

Wie wähle ich für dieses Projekt den optimalen Partner?

Wenn wir uns über das Projekt im Klaren sind, können wir den Partner aussuchen.

Zusammenarbeit

• Bringt der Partner ein eigenes Projektmanagement mit (vor allem bei Projekten welche über längere Zeit und mit mehreren Entwicklern laufen)?
  • Führt der Partner auch Risikomanagement für das Projekt durch?
  • Hat der Partner klare und sinnvolle Kommunikationsprozesse?
  • Ist ein transparentes Reporting geplant, mit dem wir den Projektfortschritt auch zwischen Meilensteinen verfolgen können?
• Passt der Partner zu unserer Firmenkultur?
  • Haben wir die gleiche Ideen von Qualität, Zuverlässigkeit, Terminen?
• Was ist die Distanz zum Partner?
  • Wie wirkt sich diese auf unsere Zusammenarbeit aus?
    • Örtliche Distanz: Reisespesen, Reisezeit, Zeitverschiebung, Art der Kommunikation: wie wirkt sich der Mix von real oder virtuell auf die Kommunikation aus?
    • Kulturelle Distanz: Qualitäts- und Zeitverständnis, Verständnis von Verträgen
    • Sprachliche Distanz: Unsere Sprache, Englisch, unsere Branchen- und Projektsprache

Wissen & Können

• Kann ich den Partner mit einem kleineren (Vor-)Projekt testen?
• Hat der Anbieter die Ingenieure mit der benötigten Erfahrung für mein Projekt?
• Hat der Partner der Projektgrösse angepasste, klare Prozesse und auch die Mitarbeiter, die sie leben?
  • Hat der Partner die Kompetenzen für das Projekt (komplexe Software, Signalverarbeitung, funktionale Sicherheit, Cybersicherheit...)?
• Hat der Partner die nötigen Werkzeuge für das Projekt?
• Sind die Entwickler wirklich qualifiziert für die geplanten Arbeiten?
  • Für die benötigten Architektur- und Design-Aufgaben?
  • Für die eingesetzten Werkzeuge?
  • Für die verwendeten Programmiersprachen?
• Gibt es einen guten Mix zwischen jungen und erfahrenen Entwicklern?
  • Wie kann ich das sicherstellen?
• Mein Domänenwissen: hat der Partner gezeigt, dass er sich schnell in das spezifische Wissen für neue Produkte einarbeiten kann?
  • Gibt es dazu Referenzprojekte über verschiedene Branchen und Technologien?

Preis

• Ist der Gesamtpreis ("Total Cost of Ownership") bis zur Markteinführung wirklich berücksichtigt? Unter Beachtung von:
  • Entfernung: Reisekosten, Missverständnisse durch Kultur
  • Qualität: nicht alle Qualität ist mit Normen (ISO 9001...) und Metriken erfassbar
• Nebenkosten: Was ist in den offerierten Kosten inbegriffen (Software-Werkzeuge, Reisespesen, Gebühren, Messlabore/ Messungen...)?

Rechte

• Geistiges Eigentum: ist in der Offerte/ dem Vertrag oder den Geschäftsbedingungen klar festgehalten, dass wir die Rechte an allem erzeugten geistigen Eigentum bekommen?
  • Dies gilt auch für Resultate von Vorphasen, z.B. das Pflichtenheft und die Systemarchitektur: wenn wir daran die Rechte haben, dann können wir für die weitere Entwicklung auch andere Partner anfragen.

Geschäftsmodell

• Was sind die internen Prioritäten des Partners? Ist das Projektgeschäft sein Kerngeschäft oder sind wir nur Lückenbüsser für die Entwickler, welche in seiner eigenen Entwicklung oder Produktion gerade nicht gebraucht werden?
• Ist der Partner bereit, uns auch nach dem Projekt zu unterstützen? Mit Support, mit Massnahmen bei abgekündigten Komponenten, mit Anpassungen, bei der Lösung von Problemen im Feld?
  • Dazu gehört auch die Fluktuationsrate der Entwickler beim Partner: ist in einem Jahr niemand mehr da, welcher uns und das Projekt kennt?

Ich hoffe, diese Vergabe-Checkliste hilft Ihnen bei der Auswahl.

Andreas Stucki

Haben Sie zusätzliche Punkte, die zu beachten sind? Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!