Praxiswissen · Praxisleitfaden

CSV-Projekt festgefahren: Vom Dokumentenstapel zur Freigabe

Die Dokumente gehen in die nächste Kommentarrunde. Der Freigabetermin rückt weiter weg. Wenn ein CSV-Projekt feststeckt, braucht es zuerst eine klare Diagnose: Fehlt ein Nachweis, eine fachliche Entscheidung oder die Person, die beides zusammenführen kann?

Daniel Herrmann
Compliance-Experte für Life Sciences
Fachlicher Stand: 7 Minuten Lesezeit
Inhaltsverzeichnis

Das Wichtigste vorab

Was tun, wenn ein CSV-Projekt nicht zur Freigabe kommt?

Sichern Sie den tatsächlichen System- und Nutzungsstand. Ordnen Sie die offenen Punkte nach Anforderung, Risiko, Nachweis und Entscheidung. Klären Sie zuerst kritische Befunde und echte Blockaden. Danach planen Sie konkrete Ergebnisse mit Verantwortlichen und Kriterien. Eine weitere Dokumentenrunde hilft nur, wenn sie eine benannte Prüfaussage oder Entscheidung voranbringt.

Die Blockade beschreiben, bevor neue Arbeit beauftragt wird

Ein festgefahrenes Projekt kann unterschiedliche Ursachen haben. Der Scope verändert sich, Anforderungen bleiben unklar, vorhandene Tests passen nicht zum aktuellen Stand oder Entscheidungen werden zwischen Fachbereich, IT und QA weitergereicht. Eine große Zahl offener Kommentare zeigt zunächst nur Arbeitsbedarf, noch nicht dessen Ursache.

Betrachten Sie eine konkrete noch nicht mögliche Entscheidung. Beispiel: „Die Schnittstellenfunktion kann nicht als nachgewiesen gelten, weil das Zielobjekt nach Wiederholung ungeklärt ist.“ Das ist bearbeitbar. „Validierung noch nicht fertig“ beschreibt dagegen keinen nächsten Schritt.

Dieser Beitrag behandelt ein laufendes CSV-Vorhaben. Bei einem bereits genutzten System kommen Bewertung des laufenden Betriebs und gegebenenfalls Rückschau auf erzeugte Aufzeichnungen hinzu. Ein ungeklärtes kritisches Risiko wird nicht durch die Projektbezeichnung oder einen neuen Plan vertretbar.

Quellen: [1] [2]

Einen verlässlichen Arbeitsstand herstellen

Erfassen Sie den aktuellen Systemstand einschließlich Konfiguration, Schnittstellen und relevanter Änderungen. Legen Sie fest, welcher Stand Gegenstand der nächsten Nachweisführung ist. Ohne diese Basis kann das Team einen Fehler beheben, während andere Tests noch eine frühere Konfiguration betrachten.

Sammeln Sie die maßgeblichen Anforderungen, Risiken, Testbelege, Befunde und Entscheidungen. Erzeugen Sie dafür keine neue Kopie jeder Unterlage. Ein präziser Index mit Version und Fundstelle kann ausreichen. Kennzeichnen Sie widersprüchliche oder veraltete Informationen, statt sie stillschweigend in eine gemeinsame Liste zu übernehmen.

Halten Sie anschließend fest, ob das System noch im Projekt, im Pilotbetrieb oder bereits produktiv verwendet wird. Dieser Unterschied beeinflusst die nötigen Maßnahmen. Bei laufender Nutzung sind Auswirkungen auf aktuelle und frühere Vorgänge gegebenenfalls unmittelbarer zu bewerten als ein rein zukünftiger Testbedarf.

Quellen: [1]

Triage: sechs Arten offener Punkte unterscheiden

Ordnen Sie offene Punkte nach ihrer Funktion. Scopefragen klären, was nachgewiesen werden soll. Anforderungsfragen klären die fachliche Regel. Nachweislücken betreffen eine fehlende oder ungeeignete Prüfaussage. Befunde betreffen tatsächlich beobachtete Abweichungen. Entscheidungsblockaden betreffen Verantwortung oder Kriterien. Kapazitätsengpässe betreffen die ausführbare Arbeit.

Ein Punkt kann mehrere Ursachen verbinden. Dann beschreiben Sie die Abhängigkeit. Ein Test kann beispielsweise erst sinnvoll geplant werden, wenn der Fachbereich die Grenzwertregel entschieden hat. Wird vorher nur ein neues Protokoll erstellt, verlagert sich die Unklarheit in die nächste Kommentarrunde.

Trennen Sie redaktionelle Verbesserungen von freigaberelevanten Fragen. Beides kann sinnvoll sein. Es sollte aber erkennbar bleiben, ob eine Formulierung korrigiert wird oder ob die Eignung einer kritischen Funktion ungeklärt ist. Die Reihenfolge richtet sich nach der fachlichen Wirkung.

Eigene Triage-Matrix: aus einem Kommentar einen Arbeitsauftrag machen
BlockadeKlärungsfrageKonkretes Ergebnis
ScopeWelche Schnittstelle gehört zur vorgesehenen Nutzung?Abgestimmte Systemgrenze mit Ein-/Ausschlüssen
AnforderungWas soll bei fehlender Spezifikation passieren?Fachliche Soll-Regel mit Verantwortlichem
NachweisWelcher Fall belegt die Fehlerbehandlung?Geeigneter Test mit unabhängigen Kriterien
BefundWelche Aufzeichnungen sind betroffen?Bewertung, Maßnahme und Wirksamkeitsnachweis
EntscheidungWer darf den verbleibenden Umfang beurteilen?Benannte Rolle und dokumentierte Entscheidung
KapazitätWelche Voraussetzung fehlt tatsächlich?Verfügbarer Input und umsetzbare Reihenfolge

Quellen: [1] [2]

Beispiel: eine Schnittstelle blockiert den Abschluss

Das Szenario ist konstruiert. Ein Laborergebnis wird an das ERP übertragen. Der Normalfall ist bestanden. Bei einem Verbindungsabbruch zeigt die Anwendung einen Fehler. Unklar ist, ob die Nachricht beim Ziel bereits verarbeitet wurde. Das Team diskutiert seit mehreren Runden die Formulierung „Übertragung erfolgreich“ im Protokoll.

Die Triage zeigt: Es fehlt eine fachliche Regel für unklaren Verarbeitungsstatus und Wiederholung. Der nächste Schritt ist daher keine Textkorrektur. Fachbereich und Systemverantwortlicher legen fest, wie ein Vorgang identifiziert, der Zielstatus geprüft und eine doppelte Verarbeitung verhindert beziehungsweise erkannt wird.

Anschließend wird ein gezielter Fall ausgeführt: Unterbrechung nach dem Senden, Prüfung des Zielstatus, kontrollierte Wiederholung und Abgleich des fachlichen Ergebnisses. Der Nachweis verbindet die Nachrichtenidentität mit dem Zielvorgang. Erst jetzt lässt sich eine präzise Protokollaussage schreiben und der verbleibende Befund bewerten.

Eigene Entscheidungskette für den Schnittstellenfall
SchrittBenötigte EntscheidungÜberprüfbares Ergebnis
Unklaren Status definierenWann ist die Verarbeitung fachlich ungeklärt?Eindeutiger Zustand statt pauschalem Erfolg
Wiederholung regelnWer prüft den Zielvorgang vor erneutem Senden?Zugeordneter Arbeitsablauf
Fehlerfall testenWelche Unterbrechung bildet das Risiko ab?Tatsächlicher Quell- und Zielzustand dokumentiert
Ergebnis bewertenBleibt ein doppelter oder fehlender Vorgang möglich?Begründeter Befund und Maßnahme
Abschluss vorbereitenWelche Nutzung ist tatsächlich belegt?Klare Freigabegrundlage und Grenzen

Quellen: [1]

Den Scope stabilisieren, ohne notwendige Änderungen zu verdrängen

Ein stabiler Scope bedeutet eine kontrollierte Entscheidungsbasis. Notwendige neue Erkenntnisse werden nicht ignoriert. Änderungen werden darauf geprüft, welche Anforderungen, Risiken und Nachweise sie berühren. Ein zusätzlicher Bericht und eine neue Freigabelogik haben unterschiedliche Auswirkungen.

Legen Sie für neue Wünsche fest, ob sie für die vorgesehene Nutzung erforderlich sind oder in einen späteren kontrollierten Umfang gehören. Diese Entscheidung trifft der zuständige Verantwortliche mit fachlicher Bewertung. Ein Projektdruck allein begründet keine Verschiebung kritischer Anforderungen.

Vermeiden Sie gleichzeitig eine künstliche Ausweitung. Wenn ein klar begrenzter Prozess nachgewiesen werden soll, muss nicht jede ungenutzte Produktfunktion getestet werden. Die Grenze wird nachvollziehbar dokumentiert und technisch beziehungsweise organisatorisch eingehalten.

Quellen: [1]

Befunde mit Wirkung statt nur mit Status bearbeiten

Ein Befund braucht die betroffene Funktion, beobachtetes Verhalten, erwartete Regel und mögliche Auswirkung. Bei produktiver Nutzung kann auch eine Bewertung bereits erzeugter Ergebnisse erforderlich sein. Eine Liste „offen/geschlossen“ bildet diese fachliche Arbeit nicht ab.

Unterscheiden Sie Fehlerkorrektur und Ursachenbearbeitung. Eine einmalige falsche Zuordnung kann technisch korrigiert werden. Wenn ein unklarer Prozess regelmäßig dieselbe Zuordnung erzeugt, braucht es zusätzliche Maßnahmen. ICH Q10 bietet dafür einen Rahmen mit Ursachenanalyse und Wirksamkeitsbewertung; nicht jeder redaktionelle Kommentar verlangt jedoch ein CAPA-Verfahren.

Bewerten Sie nach einer Korrektur, welche Prüfaussagen erneut oder ergänzend benötigt werden. Der Wiederholungstest bestätigt die betroffene Funktion. Er sollte zusätzlich relevante Nebenwirkungen berücksichtigen. Ein geschlossener Ticketstatus allein ist kein solcher Nachweis.

Quellen: [2] [1]

Einen ausführbaren Abschlussplan erstellen

Planen Sie Arbeitspakete nach entscheidungsfähigen Ergebnissen. Benennen Sie je Paket Eingaben, Verantwortlichen, Abhängigkeiten und Akzeptanzkriterien. Eine Person, die gleichzeitig alle Tests ausführen, alle Anforderungen klären und alle Unterlagen prüfen soll, bleibt sonst der verdeckte Engpass.

Beginnen Sie mit den fachlichen Blockaden, die nachfolgende Arbeit bestimmen. Führen Sie unabhängige Aufgaben nur dann parallel, wenn dafür tatsächlich Kapazität vorhanden ist. Termine werden aus dem geklärten Umfang abgeleitet und nicht als Begründung für ungeprüfte Abkürzungen verwendet.

Prüfen Sie an jedem Entscheidungspunkt, ob die vereinbarte Aussage nun vorliegt. Wenn nicht, wird die Ursache konkret benannt. Das verhindert, dass ein Paket trotz fehlender Aussage als erledigt zählt, nur weil eine Unterlage erstellt wurde.

Quellen: [2]

Der Abschluss muss in einen tragfähigen Betrieb führen

Vor der produktiven Nutzung werden neben den relevanten Nachweisen auch Rollen, Schulung, Fehlerbehandlung, Änderungen und Übergabe betrachtet. Ein technisch funktionierender Prozess bleibt anfällig, wenn niemand weiß, wer einen Sync-Fehler oder eine geänderte Spezifikation bewertet.

Der Validierungsbericht verbindet den geprüften Stand, Ergebnisse, Befunde und verbleibende Grenzen mit der Entscheidung. Er sollte weder einen ungeklärten kritischen Punkt verdecken noch jede kleine redaktionelle Verbesserung zum gleichen Hindernis erklären. Die Bedeutung wird fachlich begründet.

Nutzen Sie die Erkenntnisse für das IT-GxP-Compliance Framework. Wiederkehrende Ursachen wie unklare Lieferantenübernahme oder fehlende Prozessverantwortung werden dort verbessert. Das nächste Projekt soll dadurch mit einer verständlicheren Grundlage starten, nicht mit einem noch größeren Stapel identischer Vorlagen.

Quellen: [1] [2]

Häufige Fragen zu CSV-Projekt neu ordnen

Sollten wir ein festgefahrenes CSV-Projekt komplett neu starten?

Nicht automatisch. Sichern und bewerten Sie zunächst vorhandene geeignete Arbeit. Ein Neustart kann nötig sein, wenn Scope oder Grundlage nicht tragfähig sind. Häufig lassen sich aber konkrete Lücken und Entscheidungsblockaden gezielt bearbeiten. Die Entscheidung sollte aus der Bestandsbewertung folgen, nicht aus der Zahl der Kommentare.

Kann man die Validierung durch nachträgliche Unterschriften abschließen?

Unterschriften bestätigen keine fehlende Prüfaussage. Klären Sie, welche Ergebnisse tatsächlich vorhanden sind und wer sie bewertet. Fehlende relevante Nachweise müssen geeignet ergänzt werden. Eine formale Freigabe kann die fachliche Eignung des Systems nicht allein herstellen.

Quellen: [1]

Wie unterscheiden wir einen Kommentar von einem kritischen Befund?

Ein Kommentar kann Verständlichkeit oder Form betreffen. Ein Befund beschreibt eine Abweichung vom benötigten Verhalten oder eine relevante Nachweislücke. Bewerten Sie die mögliche Wirkung auf Prozess und Daten. Diese Bedeutung bestimmt Priorität und Bearbeitung, nicht die Länge des Kommentars.

Darf das System während der Neuordnung weiterlaufen?

Bewerten Sie die tatsächliche Nutzung und die offenen Risiken. Je nach Befund können geeignete Zusatzkontrollen, begrenzte Nutzung oder eine Unterbrechung erforderlich sein. Eine neue Projektplanung gibt keine pauschale Erlaubnis zur Fortsetzung eines unvertretbaren Zustands.

Quellen: [1]

Wann braucht ein Projektbefund CAPA?

Bewerten Sie Ursache, Wiederholung und systemische Bedeutung nach dem Qualitätssystem. Nicht jeder Tippfehler oder einzelne IT-Incident erfordert CAPA. Wiederkehrende oder relevante Ursachen können eine strukturierte Ursachenbearbeitung und Wirksamkeitsprüfung benötigen. Die reine Ticketkorrektur reicht dann möglicherweise nicht.

Quellen: [2]

Wie erkennen wir, dass der neue Abschlussplan besser funktioniert?

Jedes Arbeitspaket sollte eine zuvor benannte Prüfaussage oder Entscheidung ermöglichen. Verfolgen Sie geklärte Blockaden, belastbare Ergebnisse und verbleibende Risiken. Mehr Dokumente oder ein verschobener Termin allein zeigen noch keine Verbesserung der Freigabegrundlage.

Quellen & fachlicher Stand

Stand: 14. Oktober 2026. Regulatorische Einordnung und Herstellerfunktionen sind getrennt belegt. Beispiele, Testmatrizen und Vorlagen sind eigene Arbeitshilfen; sie werden für den tatsächlichen Einsatzzweck angepasst.

  1. Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
  2. EMA / ICH: Q10 Pharmaceutical Quality System, Step 5 (2008)

Zuletzt fachlich geprüft am 14.10.2026.

Daniel Herrmann, Daniel Herrmann Consulting

Daniel Herrmann Consulting

Wie wir Sie dabei unterstützen

Daniel Herrmann Consulting verbindet die fachliche Bewertung mit der Arbeit am konkreten System. Im Erstgespräch klären wir Ihren Einsatzzweck, vorhandene Nachweise und den nächsten sinnvollen Schritt.

  • IT-GxP-Audit →

    Den tatsächlichen Handlungsbedarf bewerten und Maßnahmen begründet priorisieren.

Ihr Vorhaben besprechenEinblicke in unsere Projektarbeit →