Engineering zu spät: verifikationsgetriebene Entwicklung in MedTech

Späte Anforderungen, späte Cybersecurity und späte Testbarkeit machen aus guter Arbeit teures Rework. In regulierter MedTech eskaliert das schnell: Scope wächst, Evidence verschiebt sich, submission-driven Evidence wird zum Nachtragsprojekt.

Das späte Trio, das den Scope sprengt

Späte Anforderungen: Akzeptanzkriterien kommen, wenn Designentscheidungen bereits fix sind.
Späte Cybersecurity: Threat Model und Testplan tauchen erst nach Interface-Freeze auf.
Späte Testbarkeit: Kein Prüfstand früh genug, Nachweise kommen erst nach Hardware-Änderungen.

Dann wird Ursachenanalyse zum Feuerwehreinsatz und Retrofit ersetzt geplantes Fertigungsengineering.

Muster aus echten Projekten (NDA-safe)

Cover-Staining-Linie (anonymisiert): EOL-Wechsel + Feldprobleme + Evidence-Updates

In einer anonymisierten Cover-Staining-Linie führte ein EOL-Wechsel des Hauptrechners zu Feldproblemen und machte ein gezieltes Retrofit nötig. Die Lösung war mehr als ein Designfix: Verifikationsmethoden, Testkriterien und Evidence/Pflichtnachweise mussten aktualisiert werden.

Vernetztes System: kleine Embedded-Änderungen, grosse Aenderungsfolgen

In vernetzten Systemen reichen kleine Embedded-Änderungen, um eine grosse Validierungswelle auszulösen. CSV (Computer System Validation) weitet sich über Interfaces, Datenflüsse und Testnachweise aus. Ohne frühe Boundary-Definitionen wird jedes Firmware-Update zum Volltest.

Labore und Tests: warum Prüfstände früh helfen

Externe Labore sind langsam und teuer. Ein interner Prüfstand bringt Risiken früh ans Licht, unterstützt Ursachenanalyse und liefert Nachweise, solange das Design noch beweglich ist.

Was besser funktioniert

Systemgrenzen früh definieren, damit Anforderungen und Tests denselben Scope haben.
Akzeptanzkriterien vor der Umsetzung definieren, um späten Rework zu vermeiden.
Cybersecurity-Evidence als Teil des Engineering-Workflows planen.
Prüfstand und Testmethodik früh aufbauen, damit Repeatability stimmt.
Aenderungsfolgen mit Change-Impact-Regeln begrenzen.
Evidence/Pflichtnachweise eng an das verifizierte System koppeln.