Engineering Dienstleister: Entwicklung erfolgreich auslagern?

Gründe für und gegen das Auslagern an einen Engineering Dienstleister

Was dafür spricht

Viele Medizinproduktehersteller verfügen schlicht nicht über die Kompetenzen, um komplexe Produkte entwickeln zu lassen. System- und Software-Engineering Know How fehlt, Verständnis über die regulatorischen Anforderungen ist nicht ausreichend gegeben, und der Fokus der eigenen Kompetenz liegt in einem anderen Bereich.

Häufig veranlassen Kapazitätsengpässe die Hersteller dazu, Aufgaben an einen Engineering Dienstleister auszulagern. Wer nicht kontinuierlich Entwicklungsprojekte durchführt, kann „Lastspitzen“ gut abfedern.

Damit verbunden ist die Time to Market. Der Einsatz von Spezialisten, das Erhöhen von Ressourcen und die damit einhergehende Parallelisierung können die Entwicklungsdauer erniedrigen.

Auch Kostenerwägungen spielen bei der Entscheidung eine Rolle, ob man Aufgaben an einen externen Engineering Dienstleister überträgt. Diese externen Dienstleister können unter Umständen zu niedrigeren Stundensätzen anbieten, weil sie

• nicht an einen Tarifvertrag des Herstellers gebunden sind,
• im Ausland operieren (Near Shoring oder Off Shoring), wo andere Lebenshaltungskosten üblich sind,
• auf Grund der geringeren Firmengröße weniger Komplexität und Overhead zu bewältigen haben oder
• sich auf eine Tätigkeit/Kompetenz spezialisieren und so Skaleneffekte nutzen.

Die Vorsicht, mit der die Medizinproduktehersteller (Inverkehrbringer) ihren Dienstleistern entgegen treten, führt dazu, dass sie die Anforderungen an das zu entwickelnde präziser und damit normenkonformer dokumentiert, als das bei einer Inhouse-Entwicklung der Fall gewesen wäre.

Was dagegen spricht

In unseren Beratungsprojekten stoßen wir regelmäßig auf Schwierigkeiten, die dadurch entstanden sind, dass die Entwicklung an einen Engineering Dienstleister übertragen wurde.

• Die Kompetenzen bleiben beim Dienstleister. Das führt zu einer Abhängigkeitsbeziehung, die manchmal von Entwicklungspartner ausgenutzt wird.
• Die Medizinproduktehersteller glauben blind den Engineering Dienstleistern, dass man das Projekt problemlos übergeben/übernehmen könnte. Doch nicht selten fehlt diesen Domänenwissen, oder sie sind aus anderem Grund mit der spezifischen Aufgabenstellung überfordert. Die Kosten steigen, die Entwicklungszeit auch. Ein Zurückholen des Projekts ist kaum noch möglich.
• Die Komplexität steigt, insbesondere die Aufteilung von Aufgaben und Verantwortlichkeiten ist nicht klar geregelt. Unklare Spezifikationen tragen dazu bei und führen ebenfalls zu verzögerten und überteuerten Projekten.
• Die Inverkehrbringer unterschätzen die regulatorischen Implikationen, glauben irrtümlich den Engineering Dienstleister die Verantwortung übertragen zu können. Lesen Sie dazu mehr weiter unten.
• Domänenwissen wandert an den Dienstleistern ab, die sich teilweise sogar zu Konkurrenten entwickelt haben.

Falls sich als Medizinproduktehersteller oder als Engineering Dienstleister in einer Situation befinden, in der man sich gegenseitig die Schuld für verzögerte und überteuerte Projekte gibt oder in der das Vertrauensverhältnis getrübt ist, dann melden Sie sich bei uns. Wir haben viel Erfahrung darin, mit klaren und einfachen „Spielregeln“ Aufgaben und Verantwortlichkeiten zu regeln und Projekte dauerhaft auf die Erfolgsspur zu bringen.

Kontakt aufnehmen

Engineering Dienstleister aus regulatorischer Sicht

Verantwortlich für die Einhaltung der regulatorischen Anforderungen bleibt immer der Inverkehrbringer; sei es im europäischen, US-amerikanischen oder jedem anderen Rechtssystem. Damit kann auch nur der Inverkehrbringer für die Einhaltung der Qualitäts(management)anforderungen verantwortlich gemacht werden, nicht der Engineering Dienstleister.

Natürlich übertragen die Inverkehrbringer den Dienstleistern vertraglich Aufgaben wie das Erstellen von Dokumenten. Die juristische Verantwortung lässt sich aber nicht übertragen. Die Behörden und benannten Stellen erlauben keine Lücken in dem Qualitätssicherungssystem. Generell gibt es zwei Szenarien, um dem Rechnung zu tragen:

1. Im ersten Szenario verfügt der Engineering Dienstleister über eine ISO 13485. Dann genügt es, wenn der Dienstleister dem Inverkehrbringer die Dokumentation zusammen mit den Entwicklungsergebnissen übergibt. Ein Audit beim Inverkehrbringer würde sich auf die Prüfung dieser Dokumentation und des ISO 13485 Zertifikates des Entwicklungsdienstleisters beschränken.
2. Im zweiten Szenario arbeitet der Engineering Dienstleister nach dem QM-System des Inverkehrbringers. Dann muss der Inverkehrbringer nicht nur die Dokumente prüfen, sondern auch den Prozess, d.h. idealerweise ein „Supplier Audit“ durchführen. Lesen Sie hier mehr zu Lieferantenaudits. Wenn der Inverkehrbringer selbst auditiert wird, kann es (und muss es eigentlich) sein, dass das Audit auf den Dienstleister „durchschlägt“. D.h. der Auditor sollte den Engineering Dienstleister besuchen. Genau deshalb bevorzugen Inverkehrbringer meist ISO 13485 zertifizierte Entwicklungspartner.

Entwicklungsaufgaben auslagern: Was Sie beachten sollten

1. Seien Sie sich im Klaren, weshalb Sie einen Engineering Dienstleister einbinden

Die Hoffnung, die Entwicklungszeit verkürzen zu können, in dem man die Entwicklung auslagert, ist nicht immer gerechtfertigt. Eine Beschleunigung durch Parallelisierung wird Ihnen erst gelingen, wenn Sie die Systemarchitektur erstellt haben. Erst diese lässt die Komponenten erkennen, die dann verschiedene Gruppen parallel entwickeln können. Vorher, d.h. die Phasen „Erheben der System-Anforderungen“ und „Erstellen der System Requirements Specification“ lassen sich nur sequenziell durchlaufen.

Das bedeutet: Wenn Sie die frühen Phasen schneller durchlaufen wollen, dann verstärken Sie Ihr Team (temporär) um zusätzlich Kompetenzen. Die Auslagerung an einen Engineering Dienstleister führt zu keinem Zeitgewinn.

2. Klären Sie Rollen und Verantwortungen

In manchen Entwicklungsprojekten vermischen sich Body Leasing und Engineering Dienstleistung. Davor sei gewarnt: Entweder Sie haben einen oder mehrere Entwickler eines externen Partners bei sich im Team. Dann verbleibt die Verantwortung für den Erfolg bei Ihnen. Oder Sie lagern eine Aufgabe an einen Dienstleister aus. Dann ist es Ihre Verantwortung, die Aufgabe klar zu spezifizieren (wie das geht, lesen Sie weiter unten), und die Verantwortung des Dienstleisters, diese Aufgabe zu erfüllen. Dazu hat er alle Freiheiten. Sie, als Medizinproduktehersteller, dürfen ihm dann nicht mehr reinreden.

Freiheit und Verantwortung sind untrennbar miteinander verbunden.

Wenn Sie an diesem Grundsatz rütteln, sind Konflikte vorprogrammiert.

3. Spezifizieren Sie die Anforderungen für Ihren Dienstleister präzise und vollständig

Die Aufteilung in Pflichten- und Lastenhefte führt regelmäßig zu Problemen:

• Die Inhalte der Dokumente sind nicht disjunkt und unterscheiden sich eher in der Granularität.
• Die beiden Dokumente vermischen Projekt- und Produktaspekte.
• Die Dokumente beschreiben das Projekt aus Auftraggeber- und Auftragnehmersicht. Die regulatorischen Anforderungen erfüllen sie hingegen nicht.
• Pflichtenhefte vermischen Systemanforderungen und Systemarchitektur, Lastenhefte Systemanforderungen und Zweckbestimmung.
• Beide Dokumente sind weder vollständig und präzise noch enthalten sie prüfbare Anforderungen.

Definieren Sie die Aufgaben an Entwicklungsdienstleister, indem Sie „Blackboxes“, d.h. Komponenten anhand deren Schnittstellen spezifizieren. Eine Komponente kann ein komplettes Medizinprodukt sein, eine PESS (progammierbares elektronisches Subsystem), ein Software-System, eine Software-Komponente usw.

Sie wollen unbedingt die Schnittstellen an die zu entwickelnden Komponenten vollständig und präzise beschreiben! Im eigenen Interesse ebenso wie im Interesse des Dienstleisters. In den Videotrainings des Auditgarant lernen Sie Schritt für Schritt solche Spezifikationen präzise und normenkonform zu erstellen und damit Differenzen zwischen Entwicklungsdienstleister und Medizinproduktehersteller zu minimieren.

Videotrainings im Auditgarant ansehen

4. Schnittstellen definieren: Für Produkt und Projekt

Die Schnittstellen Ihrer Komponenten definieren auch die Schnittstellen Ihres Projekts, d.h. des vom Engineering Dienstleister zu übernehmenden Auftrags.

Ihnen muss damit genau klar sein, wo in obiger Abbildung die Schnittstelle zwischen Engineering Dienstleister und Medizinproduktehersteller verläuft. Die Abbildung macht auch klar, dass alle(!) Aufgaben unterhalb der Schnittstelle (für den jeweils zu entwickelnden Teil) ausschließlich in der Verantwortung des Dienstleisters liegen. Es ist dann die Aufgabe des Herstellers auf der zugehörigen Teststufe sicher zu stellen, dass die spezifizierten Anforderungen auch umgesetzt sind. Natürlich kann er sich auch für diese Tests den Dienstleistungen des externen Partners bedienen, aber dieser ist dann in einer anderen Rolle.

5. Was Sie auslagern können und was nicht

Sie können an einem Engineering Dienstleister nicht nur alle Tätigkeiten unterhalb eines der roten Striche in der obigen Abbildung übertragen, sondern auch alle dazu gehörige Dokumentation wie Software-Architekturen, Komponententests, Komponentenspezifikationen usw.

Sie können aber nicht das Risikomanagement in Gänze auslagern.

Wie wir Sie unterstützen können

Wir unterstützen Sie gerne dabei

• als Medizinproduktehersteller, Entwicklungsaufträge präzise und erfolgreich zu formulieren
• als Dienstleister, Aufträge auf Vollständigkeit und Umsetzbarkeit zu prüfen,
• sicherzustellen, dass die regulatorischen Anforderungen erfüllt sind und nicht im Audit das große Erwachen kommt
• verfahrene Projekte schnell und zuverlässig wieder dauerhaft auf die richtige Spur zu bekommen und negative Emotionen durch klare Spielregeln zu ersetzen.

Nehmen Sie einfach mit uns Kontakt auf.