Der teure Preis der Sicherheit: Warum IT-Projekte in der Pharma wirklich so viel kosten (und was davon vermeidbar wäre)
Wenn man einen IT-Projektleiter aus der Automobilbranche fragt: "Was kostet es, dieses Feature live zu bringen?", nennt er vielleicht 2.000 Euro und drei Tage. Fragt man dasselbe in der pharmazeutischen Industrie, lautet die Antwort möglicherweise: "20.000 Euro und zwei Monate."
Wir haben bereits diskutiert, dass der "neue" US-Trend CSA (Computer Software Assurance) eigentlich nur das ist, was uns der europäische Standard GAMP 5 schon lange erlaubt: Den Fokus auf das Testen statt auf das Papier zu legen.
Doch die Realität in den Unternehmen sieht oft anders aus. Die "Angst-Validierung" regiert. Und diese Angst hat einen Preis.
In diesem Artikel schauen wir uns an, wo dieser massive Mehraufwand eigentlich herkommt – und warum wir hier nicht nur über Zeit, sondern über harte Währung sprechen.
Woher kommt der Mehraufwand? Die "Unsichtbare Rechnung"
Es wird oft pauschal gesagt, die Validierung (CSV) mache "30% bis 50%" des Projekts aus. Doch das ist oft untertrieben. Bei kleineren Änderungen oder der Einführung von Standardsoftware kann der Validierungsanteil die eigentlichen technischen Kosten um den Faktor 2 bis 5 übersteigen.
Die Kosten entstehen primär an drei Stellen:
1. Der Personal-Luxus (Teure Ressourcen für banale Aufgaben)
In einem regulierten Projekt arbeiten nicht nur Entwickler und Key-User.
-
Der CSV-Manager / QA-Experte: Diese Spezialisten sind rar und teuer. Ihre Tagessätze liegen oft deutlich über denen von Senior-Entwicklern. Wenn diese Experten ihre Zeit damit verbringen, Screenshot-Dokumente auf Formatierungsfehler zu prüfen, verbrennt das Unternehmen bares Geld.
-
Das "Signaturen-Sammeln": Ein Dokument im GxP-Umfeld (z.B. ein Testplan) benötigt oft vier Unterschriften (Autor, Reviewer, Business Owner, QA). Bis diese Unterschriften vorliegen, steht das Projekt still. Diese "Wartezeit" kostet Geld, weil das Projektteam "Stand-by" ist.
2. Die Dokumentations-Lawine (Papier statt Produkt)
Ein einfaches Software-Update erfordert im klassischen (nicht optimierten) CSV-Ansatz:
-
Change Request & Impact Analysis (Was könnte kaputtgehen?)
-
Update der User Requirements (URS)
-
Update der Funktionalen Spezifikation (FS)
-
Genehmigung dieser Dokumente (Pre-Approval)
-
Anpassung der Testskripte (IQ/OQ)
-
Durchführung der Tests (mit Screenshots für jeden Schritt!)
-
Review der Testergebnisse
-
Validation Summary Report
-
Freigabe zur Nutzung (Release)
Jeder dieser Schritte ist Arbeitszeit. Wir bezahlen hochqualifizierte Menschen dafür, Word-Dokumente zu pflegen, nicht immer um das System zu verbessern.
3. Die Opportunitätskosten (Der teuerste Posten)
Dies ist der Punkt, der in Projektkalkulationen oft fehlt. Wenn ein Pharma-Unternehmen 6 Monate braucht, um ein neues CRM-System zu validieren, das die Konkurrenz in 4 Wochen einführt, entgehen dem Vertrieb 5 Monate Effizienzsteigerung.
Time-to-Market ist Geld. Die Trägheit durch überbordende CSV-Prozesse bremst die Innovation des gesamten Unternehmens.
Ein Rechenbeispiel: "Nur ein kleiner Button"
Um den Unterschied greifbar zu machen, vergleichen wir eine kleine Änderung (z.B. ein neues Pflichtfeld in einer Eingabemaske) in einem nicht-regulierten Umfeld mit einem klassischen GxP-Umfeld.
| Phase | Nicht-Reguliertes Umfeld (Agil) | Pharma GxP Umfeld (Klassisch/Konservativ) | Kosten-Faktor |
| Analyse & Auftrag | Kurzes Ticket in Jira, Absprache im Daily. (1 Std.) | Formaler Change Request, Impact Analyse Meeting, QA-Konsultation. (4-8 Std.) | ~6x |
| Umsetzung | Entwickler setzt Feld, lokaler Test. (2 Std.) | Entwickler setzt Feld (2 Std.) + Update der URS & FS Dokumente (4 Std.). | ~3x |
| Testen | Automatisierter Test läuft durch, kurzer Check. (0,5 Std.) | Schreiben des Testskripts (2 Std.), Genehmigung Skript (1 Std.), Ausführung mit Screenshots (2 Std.), Review des Testprotokolls (1 Std.). | ~12x |
| Freigabe | Merge Request, Deploy to Prod. (0,5 Std.) | Validation Summary Report schreiben, Unterschriftenumlauf QA & Business. (4-8 Std. Wartezeit/Arbeitszeit). | ~16x |
| Gesamtaufwand (ca.) | 4 Stunden | ca. 20 - 25 Stunden | Faktor 5-6 |
Fazit: Für eine technische 2-Stunden-Aufgabe zahlt das Pharma-Unternehmen fast drei Personentage.
Bringt dieser Preis wenigstens Qualität?
Die ketzerische Frage: Ist das Feld im Pharma-Beispiel am Ende "besser"?
-
Nein, technisch ist es das gleiche Feld.
-
Vielleicht, weil man vorher gezwungen war, über die Auswirkungen (Impact Analysis) nachzudenken.
-
Aber oft auch schlechter, weil das Budget für das eigentliche Testen (Exploratives Testen, Belastungstests) aufgebraucht wurde, um die Dokumente schön zu machen ("Audit Ready").
Der hohe Preis entsteht oft nicht durch die Vorschrift (GAMP 5 und Annex 11 erlauben schlankes Vorgehen!), sondern durch die Angst vor der Lücke. Man kauft sich mit dem Mehraufwand eine (teure) Versicherung gegen kritische Fragen im Audit – oft weit über das notwendige Maß hinaus.
Der Ausweg: Investition in Prozess statt Papier
Um diese Kosten zu senken, ohne die Compliance (GAMP 5, ALCOA++) zu gefährden, müssen Unternehmen investieren – aber an der richtigen Stelle:
-
Tools statt Word: Die Einführung von papierlosen Validierungstools (z.B. ValGenesis, Kneat oder validiertes Jira) eliminiert den Aufwand für Formatierung, Drucken und Scannen. Das reduziert die Admin-Kosten drastisch.
-
Supplier Leverage: Warum testen wir SAP-Standardfunktionen, die SAP schon getestet hat? GAMP 5 fordert explizit, die Arbeit des Lieferanten zu nutzen. Das spart interne Testkosten.
-
Risk-Based Testing (Echt angewandt): Nur was kritisch für Patient oder Daten ist, wird formal und teuer getestet. Unkritische Features (z.B. GUI-Farben, Hilfetexte) laufen als "Normal Change". Das reduziert den "Faktor 6" aus der Tabelle oben wieder auf einen vernünftigen "Faktor 1,5".
Zusammenfassung:
Der Mehraufwand in der Pharma-IT ist real und teuer. Er liegt oft bei Faktor 3 bis 5 im Vergleich zur normalen IT. Doch ein Großteil dieser Kosten fließt nicht in die Sicherheit des Patienten, sondern in ineffiziente, papierbasierte Verwaltungsprozesse, die aus einer veralteten Auslegung der Regeln resultieren.
Quellen und Referenzen
| Thema | Organisation | Beschreibung | Link |
| GAMP 5 (2nd Edition) | ISPE | Standardwerk. Betont in der 2. Edition explizit die Nutzung von Tools und Critical Thinking zur Kostensenkung. | ISPE GAMP 5 |
| Kosten der Validierung | Diverse Fachartikel | Diskussionen über den ROI von Validierung und die Verschiebung zu CSA (Computer Software Assurance) zur Kostenreduktion. | FDA CSA Draft Guidance |
| EU GMP Annex 11 | EU Kommission | Gesetzliche Basis, die fordert, dass der Aufwand dem Risiko angemessen sein muss (Prinzip der Verhältnismäßigkeit). | EudraLex Annex 11 |
| ALCOA++ | PIC/S & WHO | Prinzipien der Datenintegrität. Oft Kostentreiber, wenn Systeme nicht "by Design" compliant sind und manuelle Workarounds nötig werden. | WHO TRS 996, Annex 5 |
