Ihr Template für Qualitätsmanagement-Daten
Ihr Template für Qualitätsmanagement-Daten
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Extraktion
Attribute des Qualitätsmanagements
| Name | Beschreibung | ||
|---|---|---|---|
|
Qualitätsereignis
QualityEvent
|
Der eindeutige Identifikator für ein einzelnes Qualitätsereignis, etwa eine Abweichung, Nichtkonformität oder CAPA. | ||
|
Beschreibung
Das Qualitätsereignis dient als primäre Case-ID und verknüpft alle Aktivitäten, Untersuchungen und Lösungen, die zu einem bestimmten Qualitätsproblem gehören. Es bildet den zentralen Zusammenhang, der den gesamten Lebenszyklus eines Vorfalls von der ersten Meldung bis zur endgültigen Schließung verbindet. Im Process Mining ist dieses Attribut entscheidend für die Rekonstruktion des durchgängigen Ablaufs jedes Qualitätsereignisses. Es ermöglicht die Analyse von Prozessvarianten, Zykluszeiten und Compliance über verschiedene Ereignistypen hinweg und vermittelt ein umfassendes Bild davon, wie einzelne Qualitätsvorfälle bearbeitet, untersucht und gelöst werden.
Warum das wichtig ist
Dies ist die erforderliche Case-ID, die alle zugehörigen Aktivitäten zu einer einzelnen Prozessinstanz zusammenfasst und dadurch eine durchgängige Analyse ermöglicht.
Bezugsquelle
Dies ist der primäre Identifikator für Datensätze zu Qualitätsereignissen in Veeva Vault Quality, häufig als „Name“ oder als eindeutiges ID-Feld am Qualitätsereignisobjekt bezeichnet.
Beispiele
QE-2023-00123CAPA-2023-00456DEV-2023-00789
|
|||
|
Aktivitätsname
ActivityName
|
Der Name einer bestimmten Aufgabe oder eines Schritts, der im Lebenszyklus des Qualitätsereignisses stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut beschreibt eine bestimmte Geschäftsaktivität oder ein Ereignis, das während der Bearbeitung eines Qualitätsereignisses stattfindet. Dazu gehören Prozessschritte wie „Untersuchung eingeleitet“ oder „Korrekturmaßnahmenplan genehmigt“. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten bildet den Kern von Process Mining. Sie hilft, den tatsächlichen Prozessablauf zu erkennen, Engpässe zwischen Schritten zu identifizieren und Abweichungen von der Standardarbeitsanweisung festzustellen.
Warum das wichtig ist
Es definiert die Prozessschritte und ermöglicht dadurch die Visualisierung und Analyse des Prozessablaufs.
Bezugsquelle
Dieses Attribut wird typischerweise aus Namen von Workflow-Aufgaben, Statusänderungen oder Audit-Trail-Einträgen in Veeva Vault Quality abgeleitet.
Beispiele
Erste Triage abgeschlossenUrsachenanalyse durchgeführtAbschließende Prüfung und Schließung
|
|||
|
Ereigniszeit
EventTime
|
Der Timestamp, der angibt, wann eine bestimmte Aktivität begonnen hat oder stattgefunden ist. | ||
|
Beschreibung
Dieses Attribut erfasst das genaue Datum und die Uhrzeit, zu denen eine Aktivität ausgeführt wurde. Es liefert den zeitlichen Zusammenhang für alle Ereignisse innerhalb eines Cases. Dieser Timestamp ist die Grundlage für alle zeitbezogenen Process-Mining-Analysen. Er wird zur Berechnung von Zykluszeiten, Wartezeiten zwischen Aktivitäten und der Dauer einzelner Schritte verwendet. Diese Werte sind entscheidend, um Verzögerungen und Leistungsengpässe zu erkennen.
Warum das wichtig ist
Dieser Timestamp ist entscheidend für die chronologische Sortierung von Ereignissen und die Berechnung aller Leistungskennzahlen wie Zyklus- und Wartezeit.
Bezugsquelle
Dies entspricht dem Erstellungs- oder Abschlussdatum von Aufgaben oder dem Timestamp von Ereignissen im Audit-Trail eines Qualitätsereignisobjekts.
Beispiele
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:21:05Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp der letzten Aktualisierung oder Extraktion von Daten aus dem Quellsystem. | ||
|
Beschreibung
Dieses Attribut zeigt, wie aktuell die analysierten Daten sind. Es gibt an, wann die Daten zuletzt aus Veeva Vault Quality extrahiert und in das Process-Mining-Tool geladen wurden. Diese Information ist entscheidend, damit Benutzer die Aktualität der Analyse einschätzen und erkennen können, ob die Dashboards den aktuellen Stand des Betriebs abbilden. Sie ist ein wichtiges Attribut der Data Governance.
Warum das wichtig ist
Informiert Benutzer über Aktualität und Relevanz der Daten und stellt sicher, dass sie den zeitlichen Stand der Prozessanalyse verstehen.
Bezugsquelle
Dieser Timestamp wird während des Prozesses zur Extraktion, Transformation und zum Laden der Daten (ETL) erzeugt und ergänzt.
Beispiele
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Qualitätsmanagementdaten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert die Herkunft der Daten, in diesem Fall Veeva Vault Quality. Es unterstützt die Data Governance und liefert Kontext, insbesondere wenn Daten aus mehreren Systemen kombiniert werden. In der Analyse wird es zum Filtern und zur Sicherstellung der Datenherkunft verwendet. Das Verständnis des Quellsystems hilft bei der korrekten Interpretation der Daten und bei der Behebung von Problemen mit der Datenqualität.
Warum das wichtig ist
Liefert wichtigen Kontext zur Datenherkunft, der für Data Governance, Nachvollziehbarkeit und systemübergreifende Analysen entscheidend ist.
Bezugsquelle
Dies ist ein statischer Wert, der während der Datentransformation ergänzt werden sollte, um alle Datensätze aus dieser Quelle zu kennzeichnen.
Beispiele
Veeva Vault Quality
|
|||
|
Art des Quality Event
QualityEventType
|
Die Klassifizierung des Quality Event, beispielsweise CAPA, Deviation oder Complaint. | ||
|
Beschreibung
Dieses Attribut kategorisiert das Quality Event nach seiner Art. Verschiedene Arten von Quality Events folgen häufig unterschiedlichen Prozesspfaden und unterliegen unterschiedlichen Compliance-Anforderungen sowie Fristen für die Behebung. Die Analyse nach Ereignistyp ist eine wichtige Grundlage, um Prozessvarianten zu verstehen. Sie ermöglicht beispielsweise den Vergleich der Leistung und Effizienz bei der Bearbeitung von Abweichungen und CAPAs und hilft dabei, Verbesserungsmaßnahmen auf den jeweiligen Prozesskontext auszurichten.
Warum das wichtig ist
Unterscheidet verschiedene Arten von Qualitätsprozessen, die häufig eigene Workflows, SLAs und Compliance-Regeln haben.
Bezugsquelle
Dies ist ein Standardklassifizierungsfeld im Quality Event von Veeva Vault Quality, häufig als Auswahlliste.
Beispiele
AbweichungKorrektur- und Vorbeugemaßnahme (CAPA)NichtkonformitätBeschwerde
|
|||
|
Endzeit
EndTime
|
Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit, zu denen eine bestimmte Aktivität oder Aufgabe abgeschlossen wurde. Es unterscheidet sich von StartTime (EventTime) und ist entscheidend, um die Dauer einzelner Prozessschritte zu verstehen. Im Process Mining wird EndTime zusammen mit StartTime verwendet, um die Bearbeitungszeit von Aktivitäten zu berechnen. Dies bildet eine wichtige Grundlage, um Aufgaben zu identifizieren, die besonders viel Zeit beanspruchen und dadurch zur gesamten Durchlaufzeit sowie zu möglichen Verzögerungen beitragen.
Warum das wichtig ist
Ermöglicht die Berechnung von Bearbeitungszeiten für Aktivitäten und ist entscheidend, um Engpässe auf Aufgabenebene zu identifizieren.
Bezugsquelle
Dieser Timestamp ist in der Regel in der Workflow-Historie oder den Audit-Trail-Daten eines Quality Event verfügbar, häufig als Feld 'completed date' oder 'modified on' für eine bestimmte Aufgabe oder einen bestimmten Status.
Beispiele
2023-10-26T11:30:00Z2023-11-01T18:00:10Z2023-11-15T09:45:00Z
|
|||
|
Schweregrad
SeverityLevel
|
Der bewertete Schweregrad oder das Risikoniveau des Quality Event, beispielsweise hoch, mittel oder niedrig. | ||
|
Beschreibung
Dieses Attribut klassifiziert das Quality Event anhand seiner möglichen Auswirkungen auf Produktqualität, Patientensicherheit oder regulatorische Compliance. Der Schweregrad bestimmt häufig die Dringlichkeit und den erforderlichen Umfang der Untersuchung. Die Analyse nach Schweregrad ist entscheidend, um Verbesserungsmaßnahmen zu priorisieren. Sie zeigt, ob Events mit hohem Schweregrad länger bis zur Behebung benötigen, anderen Prozesspfaden folgen oder eine höhere Nacharbeitsrate aufweisen. So erhalten die kritischsten Probleme die notwendige Aufmerksamkeit.
Warum das wichtig ist
Klassifiziert Events nach ihrer Auswirkung und ermöglicht eine risikobasierte Analyse sowie die Priorisierung von Prozessverbesserungen in Bereichen mit hohem Risiko.
Bezugsquelle
Dies ist ein Standardklassifizierungsfeld im Quality Event, häufig eine aus einer Risikomatrix abgeleitete Auswahlliste.
Beispiele
HochMittelNiedrig
|
|||
|
Status des Quality Event
QualityEventStatus
|
Der aktuelle Lebenszyklusstatus des Quality Event. | ||
|
Beschreibung
Dieses Attribut zeigt den aktuellen Status des Quality Event an, beispielsweise 'Open', 'In Investigation', 'Pending Approval' oder 'Closed'. Es gibt einen Überblick darüber, an welcher Stelle seines Lebenszyklus sich jeder Case befindet. Für das Dashboard 'Quality Event Progress Overview' ist dieses Attribut unverzichtbar, da es die laufende Überwachung von Cases ermöglicht. Manager können damit den Fortschritt verfolgen, ins Stocken geratene Events erkennen und die gesamte Arbeitslast wirksam steuern.
Warum das wichtig ist
Gibt einen Überblick über den aktuellen Status eines Case und ist damit entscheidend für die Überwachung laufender Arbeit sowie die Identifizierung ins Stocken geratener Events.
Bezugsquelle
Dies ist ein Standardfeld im Quality Event von Veeva Vault Quality, das dessen Position im Lebenszyklus abbildet.
Beispiele
In der TriageIn UntersuchungCAPA vorgeschlagenGeschlossen
|
|||
|
Zieltermin für die Behebung
TargetResolutionDate
|
Das geplante oder erforderliche Datum für den endgültigen Abschluss des Quality Event. | ||
|
Beschreibung
Dieses Attribut definiert das Service Level Agreement (SLA) oder den Zieltermin für die Behebung eines Quality Event. Häufig wird es anhand des Erstellungsdatums sowie des Schweregrads oder Typs des Events berechnet. Dieses Datum dient als Vergleichsmaßstab für die tatsächliche Leistung. Es ist für das Dashboard 'On-Time Resolution Performance' und den KPI 'On-Time Resolution Rate' entscheidend, da sich damit feststellen lässt, ob Events fristgerecht behoben werden und welche Faktoren zu Verzögerungen beitragen.
Warum das wichtig ist
Definiert das SLA für die Behebung eines Case und ermöglicht die Messung der Termintreue sowie die Analyse von Verzögerungen.
Bezugsquelle
Dies ist wahrscheinlich ein Datumsfeld im Quality Event, das manuell eingegeben oder automatisch vom System berechnet werden kann.
Beispiele
2024-01-15T23:59:59Z2024-02-28T23:59:59Z2024-03-10T23:59:59Z
|
|||
|
Zugewiesene Abteilung
AssignedDepartment
|
Die Abteilung oder der Funktionsbereich, die bzw. der für das Quality Event oder die Aktivität verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut gibt die Geschäftseinheit oder Abteilung an, beispielsweise Quality Assurance, Manufacturing oder R&D, die für die Bearbeitung des Quality Event oder einer bestimmten Aufgabe verantwortlich ist. Häufig wird es aus dem Profil des zugewiesenen Benutzers abgeleitet. Diese Dimension ist für die Leistungsanalyse auf hoher Ebene entscheidend. Sie ermöglicht den Vergleich von Prozesseffizienz und Compliance in verschiedenen Organisationsteilen, hilft beim Erkennen systemischer Probleme in bestimmten Abteilungen und unterstützt das Dashboard 'Investigator Workload Distribution'.
Warum das wichtig ist
Ermöglicht das Filtern und Vergleichen der Prozessleistung in verschiedenen Geschäftseinheiten und macht Abteilungsengpässe oder bewährte Vorgehensweisen sichtbar.
Bezugsquelle
Diese Information ist in der Regel in den mit 'Assigned Investigator' verknüpften Benutzerprofildaten gespeichert oder direkt im Quality Event hinterlegt.
Beispiele
QualitätssicherungProduktionsbetriebForschung und Entwicklung
|
|||
|
Zugewiesener Ermittler
AssignedInvestigator
|
Der Benutzer oder die Ressource, der bzw. die mit der Durchführung einer Untersuchung oder einer bestimmten Aufgabe betraut ist. | ||
|
Beschreibung
Dieses Attribut identifiziert die Person, Rolle oder das Team, die bzw. das für die Ausführung einer bestimmten Aktivität im Lebenszyklus eines Quality Event verantwortlich ist. Dabei kann es sich um den Eigentümer des Quality Event selbst oder um den Bearbeiter einer bestimmten Workflow-Aufgabe handeln. Die Analyse dieses Attributs hilft, die Verteilung der Arbeitslast und die Leistung der Ressourcen zu verstehen sowie überlastete Teams oder Einzelpersonen zu identifizieren. Es ist für das Dashboard 'Investigator Workload Distribution' und die Optimierung der Ressourcenverteilung zur Effizienzsteigerung von zentraler Bedeutung.
Warum das wichtig ist
Zeigt, wer die Arbeit ausführt, und ermöglicht die Analyse von Arbeitslast, Ressourceneffizienz und Schulungsbedarf.
Bezugsquelle
Zu finden in den Feldern für Eigentümer oder zugewiesenen Benutzer des Quality Event oder in den zugehörigen Workflow-Aufgabenobjekten in Veeva Vault Quality.
Beispiele
Alice JohnsonBob WilliamsQA-Untersuchungsteam
|
|||
|
Durchlaufzeit
CycleTime
|
Die gesamte verstrichene Zeit von der Erstellung eines Quality Event bis zu seinem endgültigen Abschluss. | ||
|
Beschreibung
Diese Kennzahl beschreibt die End-to-End-Dauer für die Behebung eines Quality Event. Sie wird als Zeitdifferenz zwischen der ersten Aktivität, beispielsweise 'Quality Event Created', und der letzten Aktivität, beispielsweise 'Final Review and Closure', berechnet. Die Durchlaufzeit ist ein zentraler KPI für die Effizienz des Gesamtprozesses. Im Dashboard 'Quality Event Resolution Time' wird sie verwendet, um Trends zu analysieren, Faktoren für lange Behebungszeiten zu identifizieren und Zielwerte für Prozessverbesserungen festzulegen.
Warum das wichtig ist
Misst die End-to-End-Effizienz des Prozesses und liefert einen wichtigen KPI zur Überwachung der Gesamtleistung sowie der Auswirkungen von Verbesserungsmaßnahmen.
Bezugsquelle
Dies ist eine berechnete Kennzahl. Sie wird auf Case-Ebene ermittelt, indem der Timestamp des ersten Events vom Timestamp des letzten Events subtrahiert wird.
Beispiele
30 Tage 12 Stunden65 Tage 4 Stunden15 Tage 2 Stunden
|
|||
|
Ergebnis der Wirksamkeitsprüfung
EffectivenessCheckResult
|
Das Ergebnis des Verifizierungsschritts zur Bestätigung, ob eine Korrekturmaßnahme wirksam war. | ||
|
Beschreibung
Dieses Attribut erfasst das Ergebnis der Wirksamkeitsprüfung, die nach der Umsetzung einer Korrekturmaßnahme durchgeführt wird. Das Ergebnis lautet typischerweise 'Effective' oder 'Not Effective'. Es misst direkt den Erfolg des CAPA-Prozesses und ist für das Dashboard 'CAPA Effectiveness & Recurrence Rate' sowie den KPI 'CAPA Effectiveness Rate' entscheidend. Damit wird sichtbar, ob die umgesetzten Lösungen tatsächlich verhindern, dass das Problem erneut auftritt.
Warum das wichtig ist
Misst direkt den Erfolg von Korrekturmaßnahmen und liefert wichtige Rückmeldungen zur Verbesserung des Problemlösungsprozesses.
Bezugsquelle
Dies wäre wahrscheinlich ein Auswahllistenfeld in einem CAPA Action- oder Effectiveness Check-Objekt, das mit dem primären Quality Event verknüpft ist.
Beispiele
WirksamNicht wirksamÜberprüfung ausstehend
|
|||
|
Genehmigungszeit
ApprovalTime
|
Die Zeit, die für den Abschluss einer bestimmten Genehmigungsaktivität benötigt wird. | ||
|
Beschreibung
Diese Kennzahl misst die Dauer von Genehmigungsschritten, beispielsweise 'Corrective Action Plan Approved'. Sie wird als Zeitspanne vom Anfordern einer Genehmigung bis zu ihrer Erteilung oder Ablehnung berechnet. Dieses Attribut unterstützt gezielt das Dashboard 'Approval Workflow Bottlenecks' und den KPI 'Approval Workflow Cycle Time'. Indem die Wartezeit auf Genehmigungen isoliert betrachtet wird, lassen sich Verzögerungen durch langsame Entscheidungen oder ineffiziente Genehmigungsprozesse erkennen und beheben.
Warum das wichtig ist
Macht Verzögerungen in kritischen Entscheidungsschritten sichtbar und hilft, Genehmigungs-Workflows zu verbessern sowie die gesamte Durchlaufzeit zu verkürzen.
Bezugsquelle
Diese Kennzahl wird berechnet, indem die Zeitdifferenz zwischen Beginn und Ende genehmigungsbezogener Aktivitäten im Event Log ermittelt wird.
Beispiele
3 Tage 4 Stunden1 Tag 0 Stunden7 Tage 8 Stunden
|
|||
|
Ist fristgerecht behoben
IsOnTimeResolution
|
Ein berechnetes Kennzeichen dafür, ob das Quality Event bis zu seinem Zieltermin geschlossen wurde. | ||
|
Beschreibung
Dieses boolesche Attribut wird durch den Vergleich des tatsächlichen Abschlussdatums eines Quality Event mit seinem 'Target Resolution Date' abgeleitet. Es liefert ein einfaches binäres Ergebnis zur Termintreue. Dieses Kennzeichen bildet die Grundlage für das Dashboard 'On-Time Resolution Performance' und den KPI 'On-Time Resolution Rate'. Es ermöglicht eine einfache Aggregation und Filterung, um zu verstehen, welche Eventtypen, Abteilungen oder Standorte Schwierigkeiten haben, Fristen einzuhalten.
Warum das wichtig ist
Liefert eine klare Erfolgs- oder Fehlermessgröße für die Einhaltung von Fristen und vereinfacht die Leistungsanalyse sowie die Berichterstattung.
Bezugsquelle
Wird durch den Vergleich des Timestamps der Aktivität 'Final Review and Closure' mit dem Attribut 'TargetResolutionDate' berechnet. Formel: Closure Time <= TargetResolutionDate.
Beispiele
truefalse
|
|||
|
Ist Nacharbeit
IsRework
|
Ein berechnetes Kennzeichen, das Aktivitäten oder Cases identifiziert, die Nacharbeit darstellen. | ||
|
Beschreibung
Dieses Attribut ist ein boolesches Kennzeichen dafür, dass eine bestimmte Aktivität oder Abfolge von Aktivitäten Nacharbeit darstellt, beispielsweise die Wiederholung einer Untersuchung oder das erneute Öffnen einer geschlossenen CAPA. Es ist kein Standardfeld, sondern wird anhand von Mustern im Prozessablauf berechnet. Im Process Mining dient dieses Kennzeichen dazu, den Umfang des verschwendeten Aufwands und der entstehenden Kosten im Prozess zu quantifizieren. Es ist für das Dashboard 'Rework Analysis' und den KPI 'Quality Event Rework Rate' entscheidend, da sich damit Ursachen für Ineffizienz und eine unzureichende Qualität beim ersten Durchlauf identifizieren lassen.
Warum das wichtig ist
Quantifiziert die Ineffizienz eines Prozesses, indem wiederholte Arbeit gekennzeichnet wird. Dadurch lassen sich die Ursachen von Qualitätsproblemen und unnötigem Aufwand erkennen.
Bezugsquelle
Dieses Attribut wird nicht direkt aus einer Quelle übernommen. Es wird während der Datentransformation berechnet, indem wiederholte Aktivitätsnamen oder Schleifen im Prozess eines bestimmten Case erkannt werden.
Beispiele
truefalse
|
|||
|
Ist Wiederholung
IsRecurrence
|
Ein Kennzeichen dafür, ob dieses Quality Event eine Wiederholung eines zuvor identifizierten Problems ist. | ||
|
Beschreibung
Dieses boolesche Attribut zeigt an, dass es sich bei einem Quality Event nicht um ein neues, einmaliges Problem handelt, sondern um die Wiederholung eines bereits aufgetretenen Problems. Es ist ein wichtiger Hinweis auf das Versagen früherer Korrekturmaßnahmen. Dieses Kennzeichen bildet eine zentrale Grundlage für das Dashboard 'CAPA Effectiveness & Recurrence Rate'. Die Erfassung wiederkehrender Probleme liefert direktes Feedback zum langfristigen Erfolg des Qualitätsmanagementsystems und hilft, systemische Probleme zu erkennen, die bisher nicht ausreichend behoben wurden.
Warum das wichtig ist
Macht das Versagen von Korrekturmaßnahmen sichtbar und ermöglicht die Analyse wiederkehrender Probleme sowie die Verbesserung langfristiger Lösungen.
Bezugsquelle
Dies kann ein Kontrollkästchen im Quality Event oder ein abgeleitetes Feld sein, das auf Verknüpfungen mit früheren, ähnlichen Events basiert.
Beispiele
truefalse
|
|||
|
Produkt
Product
|
Das Produkt oder Material, das mit dem Quality Event verbunden ist. | ||
|
Beschreibung
Dieses Attribut verknüpft das Quality Event mit einem bestimmten Produkt, Material oder einer Charge. Diese Verbindung ist in regulierten Branchen für Rückverfolgbarkeit und Auswirkungsanalysen von großer Bedeutung. Die Analyse von Quality Events nach Produkt hilft zu erkennen, ob bestimmte Produkte besonders häufig von Problemen betroffen sind. Dadurch lassen sich Produktverbesserungen oder Anpassungen des Herstellungsprozesses ableiten. Außerdem können Dashboards nach bestimmten Produktlinien gefiltert werden.
Warum das wichtig ist
Verknüpft Quality Events mit bestimmten Produkten und ermöglicht die Analyse produktspezifischer Probleme und Trends.
Bezugsquelle
Dies ist in der Regel ein Referenzfeld im Quality Event, das auf ein Product- oder Material-Objekt in Veeva Vault verweist.
Beispiele
Produkt A-100Produkt B-200Rohmaterial C-300
|
|||
|
Standort
Site
|
Der Produktionsstandort, das Werk oder der Ort, an dem das Quality Event aufgetreten ist oder erkannt wurde. | ||
|
Beschreibung
Dieses Attribut gibt den physischen Ort an, beispielsweise ein Produktionswerk oder Labor, der mit dem Quality Event verbunden ist. Es liefert einen geografischen oder organisatorischen Kontext für das Problem. Diese Dimension eignet sich besonders für vergleichende Analysen. Das Management kann damit Prozessleistung, Problemtypen und Behebungszeiten an verschiedenen Standorten vergleichen. So lassen sich standortspezifische Probleme erkennen oder bewährte Vorgehensweisen leistungsstarker Standorte übertragen.
Warum das wichtig ist
Liefert eine geografische oder organisatorische Dimension für die Analyse und unterstützt den Vergleich der Leistung sowie die Identifizierung standortspezifischer Probleme.
Bezugsquelle
Dies ist häufig ein Standardfeld im Quality Event, das mit einer Liste von Unternehmensstandorten oder Orten verknüpft ist.
Beispiele
Standort A, New JerseyStandort B, IrlandStandort C, Schweiz
|
|||
|
Ursache
RootCause
|
Die ermittelte zugrunde liegende Ursache des Quality Event. | ||
|
Beschreibung
Dieses Attribut enthält das abschließende Ergebnis der Root Cause Analysis (RCA). Es kategorisiert den grundlegenden Grund für das Qualitätsproblem, beispielsweise einen Geräteausfall, menschliches Versagen oder einen Verfahrensmangel. Die Analyse der Ursachen ist eine wichtige Grundlage für eine wirksame Problemlösung. Sie hilft, wiederkehrende systemische Probleme zu erkennen, die durch Korrektur- und Vorbeugemaßnahmen behoben werden müssen. Dieses Attribut unterstützt direkt die Dashboards 'Root Cause Analysis Cycle Time' und 'CAPA Effectiveness'.
Warum das wichtig ist
Kategorisiert die grundlegenden Ursachen von Qualitätsproblemen und ermöglicht eine strategische Analyse, um künftige Wiederholungen zu verhindern.
Bezugsquelle
Dies ist in der Regel ein Textfeld oder eine Auswahlliste im Quality Event oder in einem zugehörigen Root Cause Analysis-Objekt.
Beispiele
Fehlfunktion der AnlageVerfahrensfehlerUnzureichende SchulungMaterialfehler
|
|||
Aktivitäten des Qualitätsmanagements
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Abschließende Prüfung und Schließung
|
Bezeichnet die letzte administrative Prüfung des Datensatzes zum Qualitätsereignis, bevor dieser offiziell geschlossen wird. Dieser Schritt stellt sicher, dass die Dokumentation vollständig ist und alle Prozessschritte eingehalten wurden. Die Aktivität ist der letzte Schritt, bevor der Case als gelöst gilt. | ||
|
Warum das wichtig ist
Diese Endaktivität ist entscheidend für die Berechnung der gesamten „Zykluszeit des Qualitätsereignisses“. Sie kennzeichnet den Abschluss aller Arbeiten. Ihr Timestamp wird für die Leistungsmessung mit dem „Zieltermin für die Behebung“ verglichen.
Bezugsquelle
Abgeleitet aus einer Änderung des Lebenszyklusstatus am Qualitätsereignisobjekt in „Geschlossen“, „Gelöst“ oder einen ähnlichen Endstatus.
Erfassen
Aus dem Timestamp der letzten Statusänderung in „Geschlossen“.
Ereignistyp
inferred
|
|||
|
Korrekturmaßnahme umgesetzt
|
Bezeichnet den Abschluss aller im genehmigten Korrekturmaßnahmenplan definierten Aufgaben. Diese Aktivität bestätigt, dass die erforderlichen Maßnahmen zur Behebung der Ursache ergriffen wurden. Erfasst wird dies, wenn der Status des CAPA-Datensatzes auf „Umsetzung abgeschlossen“ aktualisiert wird. | ||
|
Warum das wichtig ist
Dies ist ein wichtiger Meilenstein, der den Übergang von der Planung zur Umsetzung markiert. Die Zeit zwischen diesem Ereignis und der CAPA-Genehmigung zeigt die Effizienz der Umsetzungsphase.
Bezugsquelle
Abgeleitet aus einer Änderung des Lebenszyklusstatus am zugehörigen CAPA-Objekt in einen Status wie „Umgesetzt“ oder „Wirksamkeitsprüfung ausstehend“.
Erfassen
Aus dem Timestamp der Statusänderung am verknüpften CAPA-Objekt.
Ereignistyp
inferred
|
|||
|
Korrekturmaßnahmenplan genehmigt
|
Markiert die formale Genehmigung des vorgeschlagenen Korrekturmaßnahmenplans durch die zuständigen Beteiligten, etwa ein Qualitätsprüfungsgremium. Dies ist ein entscheidendes Gateway, bevor Korrekturmaßnahmen umgesetzt werden können. Erfasst wird die Aktivität, wenn der CAPA-Plan-Datensatz in den Status „Genehmigt“ wechselt. | ||
|
Warum das wichtig ist
Dieser Genehmigungsschritt ist häufig ein wesentlicher Engpass. Die Messung der „Zykluszeit des Genehmigungs-Workflows“ für diese Aktivität hilft, Verzögerungen im Prüfprozess zu erkennen und zu beheben und dadurch die gesamte Bearbeitung zu beschleunigen.
Bezugsquelle
Abgeleitet aus dem Timestamp der Änderung des Lebenszyklusstatus in „Genehmigt“ am zugehörigen CAPA-Planobjekt. Dieses Ereignis kann auch als Statusänderung am übergeordneten Qualitätsereignis gespiegelt werden.
Erfassen
Aus dem Timestamp der Statusänderung am verknüpften CAPA-Planobjekt.
Ereignistyp
inferred
|
|||
|
Qualitätsereignis erstellt
|
Dies ist der Ausgangspunkt des Prozesses und bezeichnet die formale Erstellung eines Datensatzes für ein Qualitätsereignis in Veeva. Die Aktivität wird in der Regel ausgelöst, wenn ein neues Qualitätsproblem, eine Nichtkonformität oder eine Beschwerde erkannt und im System erfasst wird. | ||
|
Warum das wichtig ist
Diese Aktivität markiert den Beginn des Case-Lebenszyklus. Sie ist daher entscheidend für die Berechnung der gesamten Zykluszeit eines Qualitätsereignisses und für die Messung der Dauer früher Prozessphasen, etwa der Zeit bis zum Beginn einer Untersuchung.
Bezugsquelle
Dies ist ein explizites Ereignis, das aus dem Erstellungstimestamp des Qualitätsereignisobjekts in Veeva Vault erfasst wird. Der Audit-Trail des Objekts zeigt das genaue Erstellungsdatum, die Uhrzeit und den Benutzer.
Erfassen
Verwenden Sie den Erstellungstimestamp des zentralen Datensatzes zum Qualitätsereignis.
Ereignistyp
explicit
|
|||
|
Untersuchung eingeleitet
|
Markiert den formalen Beginn der Untersuchung der Ursache des Qualitätsereignisses. In der Regel wird ein Untersucher oder Team zugewiesen und das Ereignis wechselt in eine aktive Untersuchungsphase. Erfasst wird dies, wenn sich der Lebenszyklusstatus des Qualitätsereignisses in „In Untersuchung“ ändert. | ||
|
Warum das wichtig ist
Dies ist ein wichtiger Meilenstein für die Messung des KPIs „Zeit von der Problemerkennung bis zum Untersuchungsbeginn“. Verzögerungen vor diesem Zeitpunkt weisen auf Rückstände bei der Ressourcenzuweisung oder beim Start der kritischen Analyse hin.
Bezugsquelle
Abgeleitet aus dem Timestamp, zu dem der Lebenszyklusstatus des Qualitätsereignisobjekts auf „In Untersuchung“ oder einen ähnlichen Status aktualisiert wird. Auch die Zuweisung eines Untersuchers kann als Auslöser dienen.
Erfassen
Verwenden Sie den Timestamp der Statusänderung auf „In Untersuchung“.
Ereignistyp
inferred
|
|||
|
Ursachenanalyse durchgeführt
|
Bezeichnet den Abschluss der Phase der Ursachenanalyse (RCA), in der die zugrunde liegende Ursache des Qualitätsereignisses identifiziert wurde. Dies wird häufig protokolliert, wenn der Untersucher die RCA-Aufgabe abschließt oder das Ereignis in den Status „CAPA ausstehend“ wechselt. | ||
|
Warum das wichtig ist
Diese Aktivität ist entscheidend für die Messung des KPIs „Durchschnittliche Dauer der Ursachenanalyse“. Die Analyse ihrer Dauer hilft, Engpässe im Analyseprozess zu erkennen und die Qualität der Untersuchung zu verbessern.
Bezugsquelle
Typischerweise abgeleitet aus einer Änderung des Lebenszyklusstatus am Qualitätsereignisobjekt, beispielsweise durch den Wechsel in „RCA abgeschlossen“ oder „Aktionsplan ausstehend“. Die Aktivität kann auch dem Abschluss einer bestimmten Workflow-Aufgabe entsprechen.
Erfassen
Aus dem Timestamp der Statusänderung oder dem Abschluss einer RCA-bezogenen Aufgabe.
Ereignistyp
inferred
|
|||
|
Wirksamkeit der Maßnahme bestätigt
|
Diese Aktivität bestätigt, dass die umgesetzten Korrekturmaßnahmen eine Wiederholung des Problems erfolgreich verhindert haben. Eine formale Prüfung wird abgeschlossen und dokumentiert. Erfasst wird dies, wenn der Status des CAPA- oder Qualitätsereignisses auf „Wirksamkeit bestätigt“ aktualisiert wird. | ||
|
Warum das wichtig ist
Dies ist die abschließende Validierung des Erfolgs der Lösung und entscheidend für die Berechnung der „CAPA-Wirksamkeitsrate“. Ein Fehlschlag in dieser Phase führt häufig zu Nacharbeit und zur erneuten Öffnung der Untersuchung.
Bezugsquelle
Abgeleitet aus einer Änderung des Lebenszyklusstatus am Qualitätsereignis- oder CAPA-Objekt in einen Status wie „Bestätigt“ oder „Geschlossen, wirksam“.
Erfassen
Aus dem Timestamp der Statusänderung, der die erfolgreiche Bestätigung anzeigt.
Ereignistyp
inferred
|
|||
|
Beteiligte über die Lösung informiert
|
Diese Aktivität bezeichnet die Mitteilung an relevante Beteiligte über die Lösung des Qualitätsereignisses. Dabei kann es sich um eine automatische E-Mail-Benachrichtigung handeln, die durch den abschließenden Schließungsschritt ausgelöst wird, oder um eine manuell protokollierte Kommunikationsaufgabe. | ||
|
Warum das wichtig ist
Eine zeitnahe Kommunikation ist entscheidend für die Zufriedenheit der Beteiligten und für Transparenz. Mit dieser Aktivität lässt sich der KPI „Verzögerungszeit bei der Benachrichtigung von Beteiligten“ messen und lassen sich Verzögerungen in der Kommunikation sichtbar machen.
Bezugsquelle
Dies kann ein explizites Ereignis sein, wenn Veeva Vault automatische Benachrichtigungen sendet und protokolliert. Alternativ kann die Aktivität aus dem Abschluss einer manuellen Workflow-Aufgabe „Beteiligte benachrichtigen“ abgeleitet werden.
Erfassen
Aus Systemprotokollen für Benachrichtigungen oder dem Abschluss-Timestamp einer Kommunikationsaufgabe.
Ereignistyp
explicit
|
|||
|
Erste Triage abgeschlossen
|
Bezeichnet den Abschluss der ersten Prüfung und Bewertung des Qualitätsereignisses. In dieser Phase werden grundlegende Informationen erfasst und überprüft, um die Gültigkeit und die unmittelbaren Auswirkungen des Ereignisses zu bestimmen. Dies wird häufig erfasst, wenn sich der Status des Datensatzes von „Neu“ in „In Bewertung“ oder einen ähnlichen Status ändert. | ||
|
Warum das wichtig ist
Die Analyse der in der Triage verbrachten Zeit hilft, Verzögerungen bei der ersten Bearbeitung von Qualitätsereignissen zu erkennen. Sie liefert Erkenntnisse zur Arbeitslast und Ressourcenverteilung am Anfang des Prozesses.
Bezugsquelle
Abgeleitet aus dem Timestamp, zu dem der Lebenszyklusstatus des Qualitätsereignisobjekts aktualisiert wird und den Abschluss der Triage anzeigt, beispielsweise durch den Wechsel von „Neu“ zu „In Bewertung“ oder „Triage abgeschlossen“.
Erfassen
Aus dem Timestamp der Statusänderung am Qualitätsereignisobjekt.
Ereignistyp
inferred
|
|||
|
Korrekturmaßnahmenplan vorgeschlagen
|
Diese Aktivität findet statt, wenn ein formaler Plan zur Behebung der erkannten Ursache erstellt und zur Prüfung eingereicht wird. Häufig wird dazu ein verknüpfter CAPA-Datensatz (Corrective and Preventive Action) zum Qualitätsereignis angelegt. Das Ereignis wird erfasst, wenn der CAPA-Datensatz erstellt oder der Status des Qualitätsereignisses aktualisiert wird. | ||
|
Warum das wichtig ist
Die Nachverfolgung dieses Schritts hilft bei der Analyse der Zeit vom Abschluss der Analyse bis zur Entwicklung einer Lösung. Sie ist eine wichtige Grundlage für das Verständnis der „Zykluszeit der Ursachenanalyse“, vom Abschluss der RCA bis zum CAPA-Vorschlag.
Bezugsquelle
Abgeleitet aus einer Änderung des Lebenszyklusstatus am Qualitätsereignisobjekt in „CAPA-Genehmigung ausstehend“ oder aus dem Erstellungstimestamp eines verknüpften CAPA-Plan-Datensatzes.
Erfassen
Verwenden Sie den Erstellungstimestamp eines verknüpften CAPA-Datensatzes oder eine Statusänderung.
Ereignistyp
inferred
|
|||
|
Problem kategorisiert und priorisiert
|
Diese Aktivität markiert den Zeitpunkt, an dem das Qualitätsereignis formal nach Typ, Schweregrad und Priorität kategorisiert wurde. Dies ist ein entscheidender Schritt, der den weiteren Untersuchungsweg und den Zeitplan bestimmt. Die Erfassung erfolgt typischerweise durch eine Statusänderung, die den Abschluss dieser Klassifizierung anzeigt. | ||
|
Warum das wichtig ist
Dieses Ereignis ist wichtig, um die Prozessanalyse nach Schweregrad oder Typ des Ereignisses zu segmentieren. Es hilft zu verstehen, ob Probleme mit hoher Priorität schneller bearbeitet werden als Probleme mit niedriger Priorität, und stellt eine wirksame Ressourcenverteilung sicher.
Bezugsquelle
Abgeleitet aus einer Änderung des Lebenszyklusstatus am Qualitätsereignisobjekt, beispielsweise durch den Wechsel in einen Status wie „Kategorisiert“ oder „Untersuchung ausstehend“. Alternativ kann der Timestamp herangezogen werden, zu dem wichtige Klassifizierungsfelder ausgefüllt wurden.
Erfassen
Abgeleitet aus einer Statusänderung oder dem Ausfüllen von Feldern wie „Schweregrad“ und „Priorität“.
Ereignistyp
inferred
|
|||
|
Vorbeugemaßnahme identifiziert
|
Diese Aktivität findet statt, wenn eine Vorbeugemaßnahme identifiziert wird, um mögliche künftige Wiederholungen zu verhindern, häufig als Ergebnis der Untersuchung. Erfasst wird sie durch die Erstellung eines mit dem Qualitätsereignis verknüpften Datensatzes für eine Vorbeugemaßnahme (PA). | ||
|
Warum das wichtig ist
Obwohl diese Aktivität nicht zu jedem Case gehört, hilft ihre Nachverfolgung dabei, die proaktive Ausrichtung des Qualitätsprozesses zu verstehen. Sie zeigt, welchen Stellenwert die Organisation der langfristigen Prävention im Vergleich zur unmittelbaren Korrektur einräumt.
Bezugsquelle
Abgeleitet aus dem Erstellungstimestamp eines verknüpften Datensatzes für eine Vorbeugemaßnahme in Veeva Vault.
Erfassen
Verwenden Sie den Erstellungstimestamp eines verknüpften Datensatzes für eine Vorbeugemaßnahme.
Ereignistyp
inferred
|
|||
|
Wirksamkeitsprüfung eingeleitet
|
Markiert den Beginn des Zeitraums, in dem die Wirksamkeit der umgesetzten Korrekturmaßnahmen überwacht wird. Dies ist kein punktuelles Ereignis, sondern der Start einer Prüfphase. Erfasst wird es, wenn das Qualitätsereignis oder der CAPA-Datensatz in den Status „Überwachung“ oder „Wirksamkeitsprüfung ausstehend“ wechselt. | ||
|
Warum das wichtig ist
Diese Aktivität leitet die abschließende Validierungsschleife ein. Die Dauer der Wirksamkeitsprüfungsphase ist wichtig, um zu verstehen, wie lange die Bestätigung des erfolgreichen Abschlusses einer Maßnahme dauert.
Bezugsquelle
Abgeleitet aus einer Änderung des Lebenszyklusstatus am Qualitätsereignis- oder CAPA-Objekt in einen Status wie „In Wirksamkeitsprüfung“.
Erfassen
Aus dem Timestamp der Statusänderung in einen überwachungsbezogenen Status.
Ereignistyp
inferred
|
|||
Anleitungen zur Extraktion
Möchten Sie starten?
Bereiten Sie Ihre Daten jetzt vor, um neue Erkenntnisse zu gewinnen und Ihren Qualitätsmanagementprozess zu optimieren. Ihr Weg zu besserer Compliance und höherer operativer Leistungsfähigkeit beginnt hier.
Optimieren Sie Ihr Qualitätsmanagement: Starten Sie heute Ihre kostenlose Testphase
Beseitigen Sie Ineffizienzen, verkürzen Sie die Durchlaufzeiten um 30 % und stärken Sie Ihre Compliance.
Keine Kreditkarte erforderlich. Beginnen Sie innerhalb weniger Minuten mit der Optimierung.