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.
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:
- 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.
- 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.
Hallo Herr Professor Dr. Johner,
bei mir kommen immer mal wieder solche Stellen an (s. unten), wo es um recht kurze Aufträge geht, an sich das erwartete Profil, aus meiner Sicht, mir anspruchsvoll erscheint. Kümmert sich hier die betreffende Firma selber um die Einbeziehung in sein ISO13485 ? Ich wundere mich auch vor allem, das Aufgaben aus dem Gebiet der
Regulatory Affairs ausgelagert sind.
Ist das eine Tendenz, das solche Aufgaben jetzt an Freiberufler gegeben werden? Ist das nicht für Audits eher problematisch?
Stellenbeschreibung exemplarisch:
.. ich bin auf der Suche nach einem Freiberufler (m/w) aus dem Bereich Regulatory Affairs mit IVD Erfahrungen asap. Detaillierte Informationen entnehmen Sie bitte unten. Sollte dieses Projekt keine Relevanz für Sie haben und Sie kennen jemanden der Interesse daran haben könnte, geben Sie bitte meine Kontaktdaten weiter. Enthalten Sie diese Möglichkeit niemanden vor.
Was bringen Sie mit?
• Background Medizintechnik
• Kenntnisse der ISO Norm 13485 und 9001
• IVD Erfahrungen
• Hands-on Mentality
• Gute Deutsch- und Englischkenntnisse (Word und Schrift)
Idealerweise bringen Sie noch folgendes mit:
• Teamfähigkeit und Diskussionsfähigkeit
Was erwartet Sie?
Das Unternehmen sucht Sie zur Unterstützung im Bereich Regulatory. Zu Ihrem Verantwortungsbereich gehört unter anderem die Vorbereitung und Einreichung von Registrierungsdossiers der Medizinprodukte.
Start: asap
Projektlaufzeit: 3 Monate (Option auf Verlängerung)
Ort: auf Anfrage
———–
Schönen Gruß aus B,
Hagen Rehbein
Lieber Herr Rehbein,
Ihre Skepsis kann ich gut verstehen: Kernelemente wie ein Qualitätsmanagement auszulagern, halte ich auch für bedenklich. Andererseits kann ich sehr kleine Firmen verstehen, die nicht die finanzielle Kraft haben, jemanden dafür Vollzeit zu engagieren. Das interne Audit an einen Dritten zu übertragen, ergibt aber oft Sinn. So hat man wirklich eine Neutralität und Unabhängigkeit.
Viele Grüße
Christian Johner
Lieber Herr Professor Johner,
vielen Dank für die Information.
„Kernelemente wie ein Qualitätsmanagement auszulagern, halte ich auch für bedenklich“.
Ja, sollte das nicht schon per Norm ausgeschlossen werden ?
Solche „Subunternehmer-Verantwortlichkeiten“ kennt man aus anderen Bereichen der Wirtschaft. Die Verantwortung wird dann auf die finanziell schwächeren Schultern verlagert…
Schönen Gruß,
H.
Durch die Auslagerung wird keine Verantwortung verlagert, darf das auch nicht. Hier ist die Gesetzeslage eindeutig. Daher sehe ich auch nicht die Notwendigkeit einer Verschärfung der Norm.
Die Firmen sollten zuerst die aktuellen Forderungen erfüllen, bevor wir diese Forderungen erhöhen.
Derlei Anfragen wie in dem Beispiel beschrieben geistern derzeit zu hunderten durch die Foren und landen in den EMails der Berater, meist von Personalvermittlern. Was wir hier sehen, ist eine Ausprägung des Fachkräftemangels. Ich halte das Vorgehen der Unternehmen für im Grunde legitim, allerdings haben Sie recht, manchmal bekommt man den Eindruck, als dass sich Unternehmen eher für Einzelprobleme jemanden kaufen möchten, als in eine langristige Strategie zu investieren. Das wird auf lange Sicht keinen Erfolg bringen. Wenn der externe Dienstleister dann im AUdit nicht mit dabei ist, sollte das Know-How erhalten geblieben sein.
Zurück zum Thema des Blogs von heute: Ich halte es im Kontext der Auslagerung der Entwicklung für immens wichtig, wie die Risikoanalyse vereinbart wird. Wer hat hier welchen Beitrag zu leisten? Denn nach meiner Meinung kann es weder nur der Supplier, noch ausschließlich der einkaufende Partner sein, der die Risikoanalyse komplett allein macht. Man braucht immer die Ankopplung an Zweckbestimmung und Markt, die über den Hersteller geht. Und man braucht (oft) das Know-How des tatsächlichen Entwicklers, um Gegenmaßnahmen zu bestimmen und zu implementieren.
Lieber Herr Knipp,
Ihr Punkt mit der Risikoanalyse bzw. der Aufteilung der Aufgaben ist ein entscheidender. Ich werde am Wochenende dazu etwas schreiben. Danke für die Anregung!
Christian Johner
Hallo Herr Johner,
Haben Sie zur Aufteilung der Aufgaben etwas geschrieben? Das Thema ist für uns aktuell interessant.
Grüße,
Wolfgang Reich
Lieber Herr Johner,
danke für den Beitrag heute, dem ich in ganz vielen Punkten zustimen kann und möchte. Nur an einer Stelle wäre ich etwas zurückhaltender:
Bloß weil zwei Dokumente „Lasten- und Pflichtenheft“ heißen, müssen nicht alle von Ihnen genannten Fehler und Zustände auftreten. Der Name des Dokuments ist mir nicht so wichtig, solange es die richtigen Inhalte enthält. Gute Dienstleister können das.
Allerdings zeigt auch bei uns die Erfahrung, dass, wenn Dokumente diese Namen tragen, jemand die Normanforderungen (IEC 62304) nicht gelesen hat und hinterher mit der Doku Schwierigkeiten hat.
Viele Grüße
Peter Knipp