Verifikation-getriebenes Engineering in MedTech: warum späte Fixes am teuersten sind
Ich habe starke Teams scheitern sehen, nicht weil die Technik schlecht war, sondern weil Nachweise und Systemgrenzen zu spät definiert wurden. In regulierter MedTech führt diese Verzögerung zu Rework, Kostenexplosionen und Risiko in QA und Zulassung.
Ein Muster, das ich mehr als einmal gesehen habe
Projekte starten mit guten Absichten: Zieltermin, erster URS-Entwurf, motiviertes Team. Entscheidungen werden früh getroffen, aber ohne vollständigen Systemkontext — Schnittstellen sind angenommen, Datenflüsse geraten, und Cybersecurity ist keinem klar zugeordnet. Verifikation wird nach hinten geschoben, damit der erste Build schnell steht.
Dann kommt die Realität: neue Anforderungen, geänderte Risiken oder QA-Fragen zu Nachweisen, die nie in den Testmethoden vorgesehen waren. Plötzlich müssen Spezifikationen neu geschrieben werden, Protokolle werden hektisch angepasst, und die Verifikation bläht sich spät im Zeitplan auf. Technisch wird gearbeitet, aber genau dann, wenn Änderungen am teuersten sind.
Was die Kosten wirklich explodieren lässt
- Späte Cybersecurity-Anforderungen erzwingen Änderungen an Architektur, Schnittstellen und Risikokontrollen.
- Spezifikationen ziehen Änderungen in Testplänen, Protokollen und Reports nach sich.
- Zusätzliche Verifikationszyklen entstehen, weil sich die Baseline im Projekt verschiebt.
- Externe Berater müssen unter Zeitdruck fehlende Nachweise liefern.
- Produktion oder Release verzögern sich, weil QA späte Änderungen neu bewertet.
Regulierte Erwartungen sind hier klar: Audits und Einreichungen verlangen nachvollziehbare Anforderungen, objektive Nachweise und eine saubere Traceability.
Cybersecurity am Ende: was wirklich bricht
Wenn Cybersecurity-Ownership früh fehlt, kommen Security-Anforderungen spät. Es gibt keinen Cybersecurity-Testplan, kein klares Threat-Modell und keine Zuordnung zu Safety- oder Datenintegritätsanforderungen. Parallel entwickeln sich Standards weiter, während das Projekt läuft.
Das Ergebnis ist vorhersehbar: Updates in der Systemdokumentation, neue Tests ohne Planung und ein Umbau von Risikoakte und Traceability. Die Technik mag funktionieren, aber die Nachweiskette ist fragmentiert und zu spät.
Testen und Aging: warum Timing zählt
High-Risk-Elemente sollten früh validiert werden — Langläufer-Tests, Aging und Stabilitätsnachweise brauchen Zeit und sind empfindlich gegen Designänderungen. Wenn Aging gestartet wird, bevor Design und Testmethoden stabil sind, gehen Monate verloren, die oft wiederholt werden müssen.
Ohne interne Testkapazität bleibt nur das externe Labor oder die Vendor-Verfügbarkeit. Diese Slots sind langsam, oft ausgebucht, und späte Designänderungen schieben dich in der Queue nach hinten. Timing wird zum Kostentreiber.
Wie verifikation-getriebenes Engineering in der Praxis aussieht
- Vom Ende her denken: Welche Nachweise brauchen wir für Release oder Submission?
- Systemgrenzen früh definieren, damit Anforderungen und Tests denselben Scope abdecken.
- Anforderungen mit real testbaren Nachweisen verbinden — keine verwaisten Anforderungen.
- Akzeptanzkriterien vor der Umsetzung festlegen, damit Tests Design-Inputs sind.
- Den Evidenz-Paketplan schreiben, solange Engineering noch flexibel ist.
Das ist kein Standard-Checklist. Es ist eine Arbeitsweise, die Engineering und Verifikation parallel laufen lässt statt nacheinander.
Wo dieser Ansatz am meisten zahlt
- Änderungen an Produktionsanlagen
- Prüfstände und Vorrichtungen
- Embedded- oder vernetzte Systeme
- Legacy-Platform-Änderungen
- FAT/SAT und Inbetriebnahme