Szablon danych do zarządzania jakością
Szablon danych do zarządzania jakością
- Zalecane atrybuty do gromadzenia danych
- Najważniejsze czynności do śledzenia przebiegu procesu
- Instrukcja eksportu danych z ETQ Reliance
Atrybuty zarządzania jakością
| Nazwa | Opis | ||
|---|---|---|---|
|
Nazwa czynności
ActivityName
|
Nazwa konkretnego zadania lub zdarzenia, które wystąpiło w procesie zarządzania jakością. | ||
|
Opis
Ten atrybut opisuje pojedynczy etap lub kamień milowy w cyklu obsługi zdarzenia jakościowego, na przykład „Sklasyfikowano i ustalono priorytet zgłoszenia” lub „Przeprowadzono analizę przyczyny źródłowej”. Każda czynność oznacza konkretne działanie przybliżające rozwiązanie problemu. Analiza czynności stanowi podstawę process mining. Ten atrybut służy do tworzenia mapy procesu, która pokazuje przebieg pracy. Pozwala wykrywać wąskie gardła, odstępstwa od standardowego przebiegu i pętle poprawek, co ma istotne znaczenie dla usprawniania procesów.
Dlaczego to ważne
Określa etapy procesu. Jest niezbędny do wizualizacji jego przebiegu, wykrywania wąskich gardeł i analizy odstępstw.
Skąd pobrać
Informacje te pochodzą zwykle z dzienników zdarzeń, zmian statusu workflow lub rejestrów audytowych w modułach ETQ Reliance.
Przykłady
Rozpoczęto dochodzeniePrzeprowadzono analizę przyczyny źródłowejZatwierdzono plan działań korygujących
|
|||
|
Zdarzenie jakościowe
QualityEvent
|
Unikalny identyfikator pojedynczego zdarzenia jakościowego, który łączy wszystkie powiązane czynności od jego wykrycia do zamknięcia. | ||
|
Opis
Zdarzenie jakościowe jest głównym identyfikatorem sprawy w procesie zarządzania jakością. Oznacza pojedynczy, odrębny problem jakościowy, taki jak niezgodność, skarga klienta lub odchylenie, który przechodzi przez etapy dochodzenia i rozwiązania. W analizie process mining ten atrybut jest niezbędny do odtworzenia pełnego przebiegu każdego zdarzenia jakościowego. Pozwala analitykom wizualizować mapy procesów, mierzyć czas cyklu od początku do końca i analizować warianty, aby sprawdzić, jak obsługiwane są różne zdarzenia. Wszystkie czynności i punkty danych są grupowane według tego identyfikatora, co zapewnia pełny obraz sprawy.
Dlaczego to ważne
To podstawowy atrybut w process mining. Łączy powiązane etapy procesu w jedną sprawę, umożliwiając analizę całego cyklu obsługi problemu jakościowego.
Skąd pobrać
To klucz główny w głównym module Quality Event lub Non-conformance w ETQ Reliance. Dokładną nazwę tabeli i pola można znaleźć w dokumentacji ETQ Reliance.
Przykłady
QE-2023-00123NC-2023-0456CAPA-2023-7890
|
|||
|
Znacznik czasu zdarzenia
EventTimestamp
|
Dokładna data i godzina wystąpienia konkretnej czynności. | ||
|
Opis
Znacznik czasu zdarzenia wskazuje dokładny moment zarejestrowania czynności w systemie. Każda czynność w cyklu obsługi zdarzenia jakościowego ma własny znacznik czasu, dzięki czemu można odtworzyć chronologiczną sekwencję zdarzeń. Ten atrybut jest podstawą wszystkich analiz czasowych w process mining. Służy do obliczania czasu między czynnościami, wykrywania czasu oczekiwania i wąskich gardeł oraz mierzenia całkowitego czasu obsługi zdarzenia jakościowego. Umożliwia też analizę zmian wyników w czasie.
Dlaczego to ważne
Ten atrybut jest niezbędny do obliczania czasu trwania, porządkowania zdarzeń chronologicznie i prowadzenia analiz czasowych, na przykład wykrywania wąskich gardeł.
Skąd pobrać
Zwykle znajduje się w tabelach rejestru audytowego lub w polu daty „Ostatnia modyfikacja” albo „Zmiana statusu”, powiązanym z daną czynnością lub etapem workflow w ETQ Reliance.
Przykłady
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
|
|||
|
Czas zakończenia zdarzenia
EventEndTime
|
Data i godzina zakończenia działania, wykorzystywane do obliczenia czasu jego realizacji. | ||
|
Opis
Czas zakończenia zdarzenia wskazuje, kiedy dane działanie dobiegło końca. W połączeniu ze znacznikiem czasu zdarzenia (czasem rozpoczęcia) określa czas trwania pojedynczego kroku procesu. Nie każdy system zapisuje czas zakończenia każdego zdarzenia. W takim przypadku można go wyznaczyć na podstawie czasu rozpoczęcia kolejnego zdarzenia. Atrybut ten pozwala obliczyć czas realizacji poszczególnych działań, odrębny od czasu oczekiwania między nimi. Dzięki temu można wskazać konkretne zadania, które zajmują najwięcej czasu, i zaplanować ukierunkowane usprawnienia procesu.
Dlaczego to ważne
Pozwala obliczyć czas realizacji poszczególnych działań i odróżnić czas aktywnej pracy od czasu oczekiwania.
Skąd pobrać
Niektóre moduły ETQ Reliance mogą zapisywać czas rozpoczęcia i zakończenia wybranych zadań. Jeśli tych danych brakuje, można je wyznaczyć podczas przygotowania danych.
Przykłady
2023-10-26T11:30:00Z2023-10-27T15:00:10Z2023-11-05T10:00:00Z
|
|||
|
Kategoria przyczyny źródłowej
RootCauseCategory
|
Klasyfikacja ustalonej przyczyny źródłowej zdarzenia jakościowego. | ||
|
Opis
Po analizie przyczyny źródłowej problem jest zwykle przypisywany do kategorii. Przykłady to awaria sprzętu, błąd ludzki, niedoskonałość procesu lub problem z dostawcą. Atrybut ten jest podstawą dashboardu pokazującego trendy według kategorii przyczyn źródłowych. Analiza częstotliwości występowania poszczególnych kategorii w czasie pozwala wykryć problemy systemowe i skupić działania usprawniające na najczęstszych źródłach problemów jakościowych. Ułatwia przejście od reagowania na problemy do zapobiegania im.
Dlaczego to ważne
Umożliwia analizę powtarzających się problemów, wykrywanie przyczyn systemowych i ustalanie priorytetów dla długofalowych działań korygujących i zapobiegawczych.
Skąd pobrać
Zazwyczaj jest to pole uzupełniane na etapie analizy przyczyny źródłowej w workflow ETQ Reliance.
Przykłady
Niedoskonałość procesuWada materiałuBłąd ludzkiAwaria sprzętu
|
|||
|
Odpowiedzialny dział
ResponsibleDepartment
|
Dział lub obszar funkcjonalny odpowiedzialny za zdarzenie jakościowe albo konkretne działanie. | ||
|
Opis
Ten atrybut wskazuje jednostkę organizacyjną, której powierzono obsługę zdarzenia jakościowego lub wykonanie określonych kroków, na przykład dział zapewnienia jakości, inżynierię lub produkcję. Można go przypisać do całej sprawy albo zmieniać w miarę przekazywania jej między działami. Atrybut ten służy do analizy wyników poszczególnych działów na dashboardzie. Umożliwia filtrowanie i porównywanie takich miar jak czas realizacji i liczba zdarzeń. Dzięki temu można wykryć wąskie gardła, ograniczenia zasobów lub obszary osiągające dobre wyniki.
Dlaczego to ważne
Pozwala porównywać wyniki i analizować wąskie gardła w różnych jednostkach biznesowych, co pomaga lepiej przydzielać zasoby.
Skąd pobrać
Zazwyczaj jest to pole w głównym formularzu zdarzenia jakościowego w ETQ Reliance, wskazujące właściciela sprawy lub odpowiedzialną grupę.
Przykłady
Zapewnienie jakościProdukcjaBadania i rozwój
|
|||
|
Osoba wykonująca działanie
ActionPerformedBy
|
Użytkownik lub zasób, który wykonał dane działanie. | ||
|
Opis
Ten atrybut wskazuje osobę lub użytkownika systemu odpowiedzialnego za wykonanie zadania w cyklu życia zdarzenia jakościowego. Łączy działania w procesie z osobami lub zespołami, które je wykonują. Analiza wyników według użytkownika pomaga ocenić rozkład obciążenia pracą, wskazać potrzeby szkoleniowe oraz wyróżnić osoby i zespoły osiągające dobre wyniki. Jest też przydatna przy kontroli zgodności i audytach, ponieważ pozwala ustalić, kto wykonał poszczególne działania.
Dlaczego to ważne
Atrybut ten pozwala analizować wyniki pracy zasobów, równoważyć obciążenie i wskazywać potrzeby szkoleniowe.
Skąd pobrać
Informacje te są zwykle przechowywane w dziennikach ścieżki audytu lub szczegółach transakcji, często w polu identyfikatora użytkownika w ETQ Reliance.
Przykłady
j.doeasmithqa_manager
|
|||
|
Poziom dotkliwości
SeverityLevel
|
Klasyfikacja wpływu zdarzenia jakościowego, na przykład jako krytycznego, poważnego lub niewielkiego. | ||
|
Opis
Poziom dotkliwości określa potencjalny wpływ problemu jakościowego na klientów, produkty lub zgodność z przepisami. Służy do ustalania priorytetów przydziału zasobów i pilności reakcji. Atrybut ten jest używany na dashboardach dotyczących wstępnej oceny i priorytetyzacji problemów oraz rozwiązywania zdarzeń o wysokim poziomie dotkliwości. Pozwala podzielić zdarzenia jakościowe na kategorie i sprawdzić, czy poważne problemy są rozwiązywane szybciej niż te o mniejszym znaczeniu. Pomaga też zapewnić szybką reakcję na problemy krytyczne.
Dlaczego to ważne
Pozwala ustalać priorytety i dzielić sprawy na kategorie, aby najpoważniejsze problemy jakościowe były rozwiązywane z odpowiednią pilnością.
Skąd pobrać
To standardowe pole w większości modułów zarządzania jakością w ETQ Reliance, często dostępne w formularzu zgłoszenia problemu.
Przykłady
KrytycznyPoważnyNiewielki
|
|||
|
Wynik weryfikacji
EffectivenessVerificationOutcome
|
Wynik sprawdzenia skuteczności działania korygującego. | ||
|
Opis
Po wdrożeniu działania korygującego często przeprowadza się weryfikację, aby potwierdzić, że problem został rozwiązany. Ten atrybut zapisuje jej wynik, zwykle jako „Skuteczne” lub „Nieskuteczne”. Atrybut ten jest podstawą dashboardu skuteczności działań korygujących i KPI dotyczącego odsetka skutecznie zweryfikowanych działań CAPA. Bezpośrednio mierzy skuteczność procesu rozwiązywania problemów, pomagając wykrywać ich nawroty i poprawiać jakość planów działań korygujących.
Dlaczego to ważne
Bezpośrednio mierzy skuteczność działań korygujących, co pomaga ograniczyć ponowne wykonywanie pracy i zapobiegać nawrotom problemów jakościowych.
Skąd pobrać
To pole w sekcji weryfikacji skuteczności modułu CAPA lub zdarzeń jakościowych w ETQ Reliance.
Przykłady
SkuteczneNieskuteczneOczekuje
|
|||
|
Czas analizy przyczyny źródłowej
RootCauseAnalysisDuration
|
Czas od rozpoczęcia dochodzenia do zakończenia analizy przyczyny źródłowej. | ||
|
Opis
Ta miara określa czas trwania konkretnego etapu procesu jakościowego. Oblicza się ją jako różnicę między działaniami „Rozpoczęto dochodzenie” i „Przeprowadzono analizę przyczyny źródłowej”. Atrybut ten służy do obliczania KPI „Średni czas analizy przyczyny źródłowej” oraz do dashboardu wąskich gardeł w analizie przyczyn źródłowych. Pomaga wskazać opóźnienia na etapie analizy, które często znacząco wydłużają cały proces.
Dlaczego to ważne
Pozwala osobno ocenić wyniki ważnego podprocesu oraz wykrywać i usuwać opóźnienia w analizie problemów i dochodzeniu.
Skąd pobrać
Atrybutu tego nie ma w systemie źródłowym. Oblicza się go podczas transformacji danych, wyznaczając różnicę między znacznikami czasu wybranych działań.
Przykłady
8640001209600432000
|
|||
|
Czas realizacji zdarzenia jakościowego
QualityEventCycleTime
|
Łączny czas od wykrycia problemu jakościowego do jego ostatecznego zamknięcia. | ||
|
Opis
To obliczana miara czasu trwania całego procesu obsługi pojedynczego zdarzenia jakościowego. Wyznacza się ją, obliczając różnicę między znacznikiem czasu pierwszego działania, na przykład „Zidentyfikowano problem jakościowy”, a znacznikiem czasu ostatniego działania, na przykład „Zamknięto zdarzenie jakościowe”. Atrybut ten służy do obliczania KPI „Średni czas realizacji zdarzenia jakościowego” i jest jedną z podstawowych miar ogólnej sprawności procesu. Dashboardy wykorzystują go do śledzenia postępów w realizacji celów skrócenia czasu oraz porównywania czasu obsługi różnych kategorii zdarzeń.
Dlaczego to ważne
Ten KPI mierzy ogólną sprawność procesu zarządzania jakością od początku do końca.
Skąd pobrać
Atrybut ten nie jest bezpośrednio dostępny w ETQ Reliance. Oblicza się go w narzędziu process mining lub podczas ETL, odejmując znacznik czasu pierwszego zdarzenia od znacznika czasu ostatniego zdarzenia w każdej sprawie.
Przykłady
25920006048008640000
|
|||
|
Czy ponownie wykonano pracę
IsRework
|
Flaga wskazująca, czy działanie lub sekwencja działań oznacza ponowne wykonanie pracy. | ||
|
Opis
Ten atrybut logiczny jest wyliczany w celu wykrycia pętli w procesie, na przykład gdy nieudana weryfikacja skuteczności prowadzi do ponownego dochodzenia albo odrzucony plan działań korygujących wraca do poprawy. Oznacza działania powtarzające wcześniejsze kroki. Atrybut ten służy do obliczania KPI dotyczącego odsetka ponownie wykonywanej pracy przy działaniach korygujących. Wykrywanie takich przypadków pomaga zrozumieć nieefektywność procesu, ponieważ ponowne wykonywanie pracy zużywa zasoby i wydłuża czas realizacji, nie przybliżając sprawy do rozwiązania.
Dlaczego to ważne
Pozwala mierzyć nieefektywność procesu przez oznaczanie powtarzanej pracy, co pomaga ustalić przyczyny niepowodzeń i ograniczyć straty.
Skąd pobrać
Atrybutu tego nie ma w systemie źródłowym. Oblicza się go podczas transformacji danych na podstawie sekwencji działań w ramach sprawy.
Przykłady
truefalse
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy dane dotyczące procesu zostały ostatnio odświeżone. | ||
|
Opis
Ten atrybut zapisuje datę i godzinę ostatniej ekstrakcji danych z systemu źródłowego. Jest to pole metadanych dotyczące całego zbioru danych, a nie poszczególnych zdarzeń. W analizie procesu ważne jest, aby wiedzieć, jak aktualne są dane. Atrybut ten pozwala ocenić aktualność analizy, podejmować decyzje na podstawie bieżących informacji i uwzględniać opóźnienia w dostępności danych.
Dlaczego to ważne
Informuje o aktualności danych, co pozwala ocenić, na ile analiza i uzyskane wnioski odzwierciedlają bieżącą sytuację.
Skąd pobrać
Wartość ta jest generowana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL) i zapisuje znacznik czasu uruchomienia zadania.
Przykłady
2024-05-20T08:00:00Z
|
|||
|
Dotknięty produkt
AffectedProduct
|
Produkt, materiał lub komponent, którego dotyczy zdarzenie jakościowe. | ||
|
Opis
Ten atrybut wskazuje konkretny produkt lub numer części powiązany z problemem jakościowym. Łączy dane procesowe z danymi podstawowymi produktów. Analiza zdarzeń jakościowych według produktów pozwala ustalić, czy problemy częściej dotyczą określonych produktów, co może wskazywać na problemy projektowe lub produkcyjne. Dzięki temu działania usprawniające można skupić na produktach, które najbardziej ich potrzebują.
Dlaczego to ważne
Łączy proces jakościowy z konkretnymi produktami, co pozwala sprawdzić, które z nich są najbardziej podatne na problemy.
Skąd pobrać
Zazwyczaj jest to ważne pole w formularzu zdarzenia jakościowego, powiązane z tabelą danych podstawowych produktów w ETQ Reliance lub zintegrowanym systemie ERP.
Przykłady
PROD-1001-APROD-2050-BRAW-MAT-55
|
|||
|
Identyfikator działania zapobiegawczego
PreventiveActionId
|
Unikalny identyfikator działania zapobiegawczego utworzonego w odpowiedzi na zdarzenie jakościowe. | ||
|
Opis
Ten atrybut łączy zdarzenie jakościowe z jednym lub większą liczbą działań zapobiegawczych podjętych w celu usunięcia przyczyny źródłowej i zapobieżenia podobnym problemom w innych obszarach. Jedno zdarzenie jakościowe może prowadzić do kilku działań zapobiegawczych. Identyfikator ten jest przydatny na dashboardzie zarządzania działaniami zapobiegawczymi. Pomaga śledzić wdrażanie zaplanowanych działań i wykrywać powielające się lub zbędne inicjatywy, dzięki czemu usprawnienia można sprawnie koordynować.
Dlaczego to ważne
Łączy zdarzenia jakościowe wymagające reakcji z działaniami zapobiegawczymi, co pozwala ocenić, jak skutecznie organizacja zapobiega przyszłym problemom.
Skąd pobrać
To powiązany rekord lub pole w sekcji działań zapobiegawczych modułu CAPA w ETQ Reliance.
Przykłady
PA-2023-0088PA-2023-0089PA-2023-0090
|
|||
|
Jednostka biznesowa
BusinessUnit
|
Większy dział lub jednostka biznesowa, w której wystąpiło zdarzenie jakościowe. | ||
|
Opis
Ten atrybut przypisuje zdarzenie jakościowe do konkretnej jednostki biznesowej w organizacji, na przykład elektroniki użytkowej lub urządzeń medycznych. Zapewnia szerszy kontekst organizacyjny niż informacja o dziale. Umożliwia porównywanie wyników na poziomie całej firmy. Kierownictwo może dzięki temu ustalić, które jednostki biznesowe mierzą się z największymi problemami jakościowymi, i odpowiednio przydzielić zasoby.
Dlaczego to ważne
Umożliwia porównanie wyników procesów jakościowych między różnymi działami firmy na wysokim poziomie.
Skąd pobrać
Informacja ta może być polem w formularzu zdarzenia jakościowego lub wynikać z innych atrybutów, takich jak odpowiedzialny dział albo produkt.
Przykłady
Urządzenia medyczneCzęści samochodoweRozwiązania przemysłowe
|
|||
|
Opis problemu
IssueDescription
|
Opis zidentyfikowanego problemu jakościowego w formie tekstu. | ||
|
Opis
Ten atrybut zawiera szczegółowy opis problemu jakościowego. Dostarcza kontekstu, którego nie da się ująć w ustrukturyzowanych polach danych. Opis problemu zwykle nie służy bezpośrednio do wizualizacji przebiegu procesu, ale jest bardzo przydatny podczas szczegółowego przeglądu spraw. Można go też analizować metodami eksploracji tekstu, aby wykrywać powtarzające się tematy lub słowa kluczowe związane z określonymi odstępstwami od procesu albo opóźnieniami.
Dlaczego to ważne
Dostarcza kontekstu jakościowego potrzebnego do zrozumienia szczegółów zdarzenia jakościowego i przydaje się przy analizie pojedynczych spraw.
Skąd pobrać
To standardowe pole tekstowe lub pole notatki w formularzu zgłoszenia zdarzenia jakościowego w ETQ Reliance.
Przykłady
Komponent XYZ nie przeszedł testu wytrzymałościowego na stanowisku 4.Klient zgłosił wadę kosmetyczną w partii 789.Wykryto nieprawidłowe ustawienia kalibracji maszyny A.
|
|||
|
Powiązane przepisy lub norma
AssociatedRegulationStandard
|
Przepis lub norma jakościowa powiązana ze zdarzeniem jakościowym. | ||
|
Opis
Ten atrybut łączy zdarzenie jakościowe z konkretnym wymogiem regulacyjnym lub normą branżową, na przykład ISO 9001, FDA 21 CFR Part 820 albo wewnętrznymi zasadami firmy. Ma to szczególne znaczenie w branżach podlegających regulacjom. Atrybut ten jest podstawą dashboardu przeglądu zgodności w obszarze jakości. Analiza zdarzeń według powiązanej normy pomaga monitorować zgodność, wykrywać obszary, w których często dochodzi do odstępstw, i sprawdzać, czy wymogi regulacyjne są spełniane na czas.
Dlaczego to ważne
Pozwala analizować zdarzenia jakościowe pod kątem zgodności z konkretnymi przepisami i normami branżowymi.
Skąd pobrać
W ETQ Reliance może to być osobne pole lub lista wyboru w formularzu zdarzenia jakościowego, zwłaszcza w modułach związanych ze zgodnością.
Przykłady
ISO 9001:201521 CFR Part 820IATF 16949
|
|||
|
Status planu działań korygujących
CorrectiveActionPlanStatus
|
Status planu działań korygujących, na przykład proponowany, zatwierdzony lub odrzucony. | ||
|
Opis
Ten atrybut śledzi status samego planu działań korygujących (CAP), który jest ważnym etapem obsługi zdarzenia jakościowego. Pokazuje, czy proponowane rozwiązanie zostało sprawdzone i zaakceptowane. Analiza tego atrybutu może ujawnić wąskie gardła w procesie zatwierdzania. Duża liczba odrzuconych planów lub długie opóźnienia między statusami „Proponowany” i „Zatwierdzony” mogą wskazywać na problemy z jakością analizy przyczyny źródłowej lub brak porozumienia między interesariuszami.
Dlaczego to ważne
Pomaga wykrywać opóźnienia i nieefektywność w cyklu zatwierdzania działań korygujących, który często stanowi wąskie gardło w zarządzaniu jakością.
Skąd pobrać
To pole statusu w sekcji lub module działań korygujących i zapobiegawczych (CAPA) w ETQ Reliance.
Przykłady
ProponowanyZatwierdzonyOdrzuconyOczekuje na wdrożenie
|
|||
|
Status SLA
SLAState
|
Informuje, czy zdarzenie jakościowe mieści się w ustalonym SLA, jest zagrożone przekroczeniem terminu czy już go przekroczyło. | ||
|
Opis
To obliczane pole porównuje bieżący lub całkowity czas realizacji zdarzenia jakościowego z ustalonymi limitami. Na przykład dla problemu krytycznego SLA może określać termin rozwiązania wynoszący 15 dni. Status może mieć wartość „Zgodnie z planem”, „Zagrożone” lub „Przekroczone”. Atrybut ten przydaje się na dashboardzie przeglądu zgodności w obszarze jakości, ponieważ od razu pokazuje, czy sprawy są obsługiwane w terminie. Pomaga kierownikom zareagować, zanim upłynie termin dla zagrożonych spraw, zamiast podejmować działania dopiero po jego przekroczeniu.
Dlaczego to ważne
Zapewnia czytelny podgląd wyników względem terminów i pozwala z wyprzedzeniem zarządzać sprawami zagrożonymi opóźnieniem.
Skąd pobrać
Atrybut ten oblicza się podczas transformacji danych, porównując czas trwania sprawy z regułami biznesowymi SLA, które mogą uwzględniać takie atrybuty jak poziom dotkliwości.
Przykłady
Zgodnie z planemZagrożonePrzekroczone
|
|||
|
Status zdarzenia jakościowego
QualityEventStatus
|
Bieżący status zdarzenia jakościowego, na przykład otwarte, zamknięte lub anulowane. | ||
|
Opis
Ten atrybut pokazuje ogólny etap cyklu życia zdarzenia jakościowego. Informuje, czy sprawa jest w trakcie obsługi, została rozwiązana czy anulowano ją z innego powodu. W analizie procesu służy do filtrowania spraw aktywnych i zakończonych. Jest niezbędny do obliczania liczby otwartych zdarzeń jakościowych oraz do tego, by czas realizacji analizować tylko dla spraw, które osiągnęły końcowy status.
Dlaczego to ważne
Pozwala filtrować sprawy otwarte i zamknięte, co jest niezbędne do obliczania zaległości i rzetelnej analizy zakończonych przebiegów procesu.
Skąd pobrać
To podstawowe pole statusu głównego obiektu zdarzenia jakościowego w ETQ Reliance.
Przykłady
OtwarteZamknięteAnulowaneOczekuje na zatwierdzenie
|
|||
|
System źródłowy
SourceSystem
|
System, z którego pobrano dane. | ||
|
Opis
Ten atrybut wskazuje źródło danych dotyczących zarządzania jakością. W tym widoku procesu jego wartość będzie stała i będzie wskazywać ETQ Reliance. Choć wartość może się nie zmieniać w obrębie jednego zbioru danych, atrybut ten ma znaczenie dla zarządzania danymi oraz łączenia danych z wielu systemów. Ułatwia ustalenie pochodzenia danych i zarządzanie ich integracją.
Dlaczego to ważne
Informacja ta wyjaśnia pochodzenie danych, co ma znaczenie dla zarządzania nimi, ich weryfikacji i integracji z innymi systemami.
Skąd pobrać
Zazwyczaj jest to stała wartość dodawana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL), która wskazuje ich źródło.
Przykłady
ETQ Reliance
|
|||
Czynności w zarządzaniu jakością
| Działanie | Opis | ||
|---|---|---|---|
|
Potwierdzono skuteczność działania
|
Ta czynność potwierdza, że wdrożone działanie korygujące usunęło przyczynę źródłową i zapobiegło jej ponownemu wystąpieniu. Jest to formalny etap weryfikacji, często przeprowadzany po ustalonym okresie monitorowania. | ||
|
Dlaczego to ważne
To ważny etap zamykający cykl działań jakościowych, bezpośrednio powiązany ze wskaźnikami KPI skuteczności CAPA. Pozwala potwierdzić, że rozwiązania są trwałe i skuteczne.
Skąd pobrać
Dane pochodzą z daty zakończenia etapu workflow lub sekcji formularza „Weryfikacja skuteczności”. Często jest to osobna czynność ze znacznikiem czasu.
Rejestrowanie
Na podstawie daty zakończenia formularza lub zadania „Weryfikacja skuteczności”.
Typ zdarzenia
inferred
|
|||
|
Przeprowadzono analizę przyczyny źródłowej
|
Oznacza zakończenie dochodzenia, podczas którego ustalono i udokumentowano przyczynę lub przyczyny źródłowe. Zdarzenie jest zwykle rejestrowane po wypełnieniu i zapisaniu sekcji formularza RCA. | ||
|
Dlaczego to ważne
Oznacza koniec etapu dochodzenia. Czas między rozpoczęciem dochodzenia a tą czynnością jest ważnym wskaźnikiem przy wykrywaniu wąskich gardeł w analizie.
Skąd pobrać
Ustalane na podstawie daty uzupełnienia pola „Kategoria przyczyny źródłowej” lub znacznika czasu zakończenia etapu RCA w rejestrze audytowym.
Rejestrowanie
Ustalane na podstawie uzupełnienia pól „Przyczyna źródłowa” lub zmiany statusu na „RCA zakończone”.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęto dochodzenie
|
Oznacza formalne rozpoczęcie etapu dochodzenia, którego celem jest ustalenie przyczyny źródłowej problemu jakościowego. Zwykle można je rozpoznać po zmianie statusu na „W trakcie dochodzenia” lub przypisaniu osoby prowadzącej dochodzenie. | ||
|
Dlaczego to ważne
To ważny etap, od którego liczy się czas analizy przyczyny źródłowej. Pozwala wykryć opóźnienia między oceną zgłoszenia a rozpoczęciem formalnego dochodzenia.
Skąd pobrać
Ustalane na podstawie znacznika czasu zmiany statusu na „Dochodzenie” w historii zdarzenia lub daty przypisania osoby prowadzącej dochodzenie.
Rejestrowanie
Ustalane na podstawie zmiany statusu na „W trakcie dochodzenia”.
Typ zdarzenia
inferred
|
|||
|
Wdrożono działanie korygujące
|
Oznacza zakończenie zadań określonych w zatwierdzonym planie działań korygujących. Zwykle jest rejestrowane, gdy osoba realizująca oznaczy przypisane działania jako zakończone. | ||
|
Dlaczego to ważne
Pozwala zmierzyć czas realizacji działań i wykryć ograniczenia zasobów lub praktyczne trudności we wdrażaniu działań korygujących.
Skąd pobrać
Ustalane na podstawie daty zakończenia ostatniego powiązanego zadania dotyczącego działań korygujących lub ręcznej zmiany statusu na „Działania wdrożone”.
Rejestrowanie
Ustalane na podstawie daty zakończenia ostatniego powiązanego zadania CAPA.
Typ zdarzenia
inferred
|
|||
|
Zamknięto zdarzenie jakościowe
|
Ostatnia czynność, która oznacza pomyślne rozwiązanie problemu i administracyjne zamknięcie rekordu zdarzenia jakościowego. To główny punkt końcowy procesu. | ||
|
Dlaczego to ważne
Wyznacza koniec procesu na potrzeby obliczenia całkowitego czasu cyklu. Analiza zamkniętych zdarzeń pozwala mierzyć przepustowość i ogólną skuteczność procesu.
Skąd pobrać
Ustalane na podstawie zmiany statusu na „Zamknięte” lub „Zakończone” w historii zdarzenia. Zmianie tej niemal zawsze towarzyszy znacznik czasu.
Rejestrowanie
Ustalane na podstawie znacznika czasu zmiany statusu na „Zamknięte”.
Typ zdarzenia
inferred
|
|||
|
Zatwierdzono plan działań korygujących
|
Oznacza formalne zatwierdzenie proponowanego planu działań korygujących przez wyznaczoną osobę, co pozwala rozpocząć jego realizację. Zwykle jest to jawna czynność zatwierdzenia ze znacznikiem czasu w workflow. | ||
|
Dlaczego to ważne
To ważny etap i punkt kontroli zatwierdzenia. Opóźnienia na tym etapie mogą znacznie wydłużyć cały cykl rozwiązania problemu.
Skąd pobrać
Dane pochodzą ze znacznika czasu zatwierdzenia w historii podpisu elektronicznego zdarzenia lub w historii workflow. ETQ Reliance szeroko wykorzystuje workflow zatwierdzania.
Rejestrowanie
Na podstawie znacznika czasu etapu zatwierdzenia w historii workflow.
Typ zdarzenia
explicit
|
|||
|
Zidentyfikowano problem jakościowy
|
Oznacza utworzenie nowego rekordu zdarzenia jakościowego, czyli początek procesu. Zwykle następuje to, gdy użytkownik przesyła w ETQ Reliance formularz zgłoszenia problemu jakościowego. | ||
|
Dlaczego to ważne
Pozwala ustalić czas rozpoczęcia sprawy, niezbędny do obliczenia całkowitego czasu cyklu i analizy napływu nowych zdarzeń jakościowych.
Skąd pobrać
Zwykle ustalany na podstawie znacznika czasu utworzenia rekordu zdarzenia jakościowego w głównej tabeli Quality Event lub w powiązanym rejestrze audytowym.
Rejestrowanie
Na podstawie znacznika czasu utworzenia rekordu zdarzenia jakościowego.
Typ zdarzenia
explicit
|
|||
|
Anulowano zdarzenie jakościowe
|
Alternatywny punkt końcowy. Zdarzenie jakościowe zostaje zakończone bez pełnego rozwiązania, na przykład dlatego, że jest duplikatem lub zgłoszenie jest niezasadne. | ||
|
Dlaczego to ważne
Pozwala odróżnić sprawy rozwiązane od tych, które zakończono przedwcześnie. Analiza anulowanych zdarzeń może ujawnić problemy na etapie zgłaszania i wstępnej oceny.
Skąd pobrać
Ustalane na podstawie zmiany statusu na „Anulowane”, „Unieważnione” lub „Wycofane” w historii zdarzenia.
Rejestrowanie
Ustalane na podstawie znacznika czasu zmiany statusu na „Anulowane”.
Typ zdarzenia
inferred
|
|||
|
Odrzucono plan działań korygujących
|
Oznacza, że proponowany plan działań korygujących został sprawdzony i odrzucony, więc trzeba go poprawić i ponownie przesłać. Ta czynność tworzy w procesie pętlę poprawek. | ||
|
Dlaczego to ważne
Ta czynność pomaga wykrywać pętle poprawek, poznawać przyczyny odrzuceń i mierzyć skuteczność planowania za pierwszym razem.
Skąd pobrać
Dane pochodzą ze znacznika czasu odrzucenia w historii workflow. Jest to odpowiednik zatwierdzenia w workflow.
Rejestrowanie
Na podstawie znacznika czasu odrzucenia w historii workflow.
Typ zdarzenia
explicit
|
|||
|
Powiadomiono zainteresowane strony
|
Oznacza formalne poinformowanie zainteresowanych stron o rozwiązaniu zdarzenia jakościowego. Można to śledzić za pomocą osobnego etapu workflow lub zarejestrowanej komunikacji. | ||
|
Dlaczego to ważne
Ten etap pozwala mierzyć sprawność komunikacji i wspiera dashboard „Terminowość powiadamiania zainteresowanych stron”. Opóźnienia mogą negatywnie wpłynąć na zadowolenie klientów.
Skąd pobrać
Wymaga analizy systemu, ponieważ często jest to czynność ręczna. Jeśli skonfigurowano odpowiednie zadanie, można ją ustalić na podstawie zakończenia zadania „Powiadom zainteresowane strony”.
Rejestrowanie
Ustalane na podstawie daty zakończenia ręcznego zadania „Powiadom zainteresowane strony”.
Typ zdarzenia
inferred
|
|||
|
Przedstawiono plan działań korygujących
|
Ta czynność następuje po udokumentowaniu formalnego planu usunięcia przyczyny źródłowej i przekazaniu go do zatwierdzenia. Zwykle można ją rozpoznać po wypełnieniu sekcji planu działań korygujących w formularzu i zmianie statusu. | ||
|
Dlaczego to ważne
Analiza czasu od zakończenia RCA do tego etapu pozwala wykryć opóźnienia w planowaniu działań korygujących, które często stanowią wąskie gardło w procesach jakościowych.
Skąd pobrać
Ustalane na podstawie zmiany statusu na „Oczekuje na zatwierdzenie CAPA” lub znacznika czasu przesłania formularza planu działań korygujących w rekordzie zdarzenia jakościowego.
Rejestrowanie
Ustalane na podstawie zmiany statusu na „Oczekuje na zatwierdzenie” lub daty przesłania planu CAPA.
Typ zdarzenia
inferred
|
|||
|
Przeprowadzono przegląd końcowy
|
Końcowa kontrola całego rekordu zdarzenia jakościowego, która pozwala sprawdzić, czy dokumentacja jest kompletna i czy wykonano wszystkie wymagane czynności przed zamknięciem sprawy. Często jest to osobny etap zatwierdzenia. | ||
|
Dlaczego to ważne
To ostatni punkt kontroli jakości przed zakończeniem procesu. Pozwala zadbać o zgodność i integralność danych. Wąskie gardła na tym etapie mogą opóźnić zamknięcie sprawy.
Skąd pobrać
Dane pochodzą ze znacznika czasu zatwierdzenia etapu „Przegląd końcowy” lub „Gotowe do zamknięcia” w historii workflow.
Rejestrowanie
Na podstawie znacznika czasu zatwierdzenia etapu „Przegląd końcowy” w workflow.
Typ zdarzenia
explicit
|
|||
|
Przeprowadzono wstępną ocenę
|
Oznacza wstępny przegląd lub ocenę nowo zgłoszonego problemu jakościowego, której celem jest zebranie podstawowych informacji i ustalenie zasadności zgłoszenia. Zdarzenie można rozpoznać po wypełnieniu sekcji wstępnej oceny formularza lub zmianie statusu z „Nowe” na „W trakcie oceny”. | ||
|
Dlaczego to ważne
Pozwala ocenić sprawność wstępnej selekcji zgłoszeń i zmierzyć czas od zgłoszenia problemu do rozpoczęcia jego oceny.
Skąd pobrać
Ustalane na podstawie zmiany statusu, na przykład z „Nowe” na „W trakcie oceny”, lub daty zakończenia zadania wstępnej oceny w dzienniku workflow zdarzenia.
Rejestrowanie
Ustalane na podstawie zmiany statusu na „W trakcie oceny” lub „W trakcie wstępnej selekcji”.
Typ zdarzenia
inferred
|
|||
|
Sklasyfikowano i ustalono priorytet zgłoszenia
|
Oznacza moment, w którym zgłoszenie zostaje sklasyfikowane według rodzaju i wagi oraz otrzymuje priorytet. Często od tego zależy dalszy przebieg workflow. Zdarzenie można rozpoznać po uzupełnieniu pól kategorii i priorytetu oraz zapisaniu rekordu. | ||
|
Dlaczego to ważne
To ważny punkt decyzyjny. Czas do jego osiągnięcia ma istotne znaczenie dla dashboardu „Wstępna ocena i ustalanie priorytetów zgłoszeń” oraz analizy kierowania spraw do dalszej obsługi.
Skąd pobrać
Ustalane na podstawie znacznika czasu pierwszego uzupełnienia wymaganych pól, takich jak „Poziom wagi” i „Rodzaj zdarzenia jakościowego”, widocznego w rejestrze audytowym systemu.
Rejestrowanie
Ustalane na podstawie znacznika czasu pierwszego uzupełnienia pola „Waga” lub „Priorytet”.
Typ zdarzenia
inferred
|
|||
|
Wdrożono działanie zapobiegawcze
|
Oznacza zakończenie zadań związanych ze zidentyfikowanym działaniem zapobiegawczym, czyli wdrożenie środków zapobiegawczych. | ||
|
Dlaczego to ważne
Ta czynność pozwala mierzyć wskaźnik KPI „Odsetek wdrożonych działań zapobiegawczych” i sprawdzić, czy zaplanowane usprawnienia jakościowe są rzeczywiście realizowane.
Skąd pobrać
Wymaga analizy systemu. Prawdopodobnie można ją ustalić na podstawie daty zakończenia powiązanego rekordu działania zapobiegawczego lub jego zadań.
Rejestrowanie
Na podstawie daty zakończenia powiązanego rekordu działania zapobiegawczego.
Typ zdarzenia
inferred
|
|||
|
Weryfikacja skuteczności zakończona niepowodzeniem
|
Oznacza, że wdrożone działanie korygujące nie rozwiązało problemu, co często prowadzi do ponownego dochodzenia lub rozpoczęcia kolejnego cyklu CAPA. To poważne niepowodzenie procesu i początek pętli poprawek. | ||
|
Dlaczego to ważne
Wskazuje nieskuteczne rozwiązania i bezpośrednio wpływa na liczbę poprawek oraz koszty. Analiza takich przypadków pomaga usprawnić analizę przyczyn źródłowych i planowanie CAPA.
Skąd pobrać
Ustalane na podstawie zmiany statusu na „Weryfikacja skuteczności nie powiodła się” lub utworzenia powiązanego zdarzenia jakościowego dotyczącego dalszych działań.
Rejestrowanie
Ustalane na podstawie zmiany statusu, na przykład na „Weryfikacja nie powiodła się”, lub oznaczenia w rekordzie weryfikacji.
Typ zdarzenia
inferred
|
|||
|
Zidentyfikowano działanie zapobiegawcze
|
Oznacza zidentyfikowanie działania zapobiegawczego (PA), którego celem jest wyeliminowanie przyczyny potencjalnej niezgodności. Może być ono zarządzane w osobnym rekordzie powiązanym z pierwotnym zdarzeniem jakościowym. | ||
|
Dlaczego to ważne
Ten etap pomaga ocenić, jak proaktywnie organizacja zarządza jakością. Wspiera też dashboard „Zarządzanie działaniami zapobiegawczymi”, pokazując, kiedy rozpoczęto takie działania.
Skąd pobrać
Wymaga analizy systemu. Prawdopodobnie można go ustalić na podstawie daty utworzenia rekordu działania zapobiegawczego powiązanego z pierwotnym rekordem zdarzenia jakościowego.
Rejestrowanie
Na podstawie daty utworzenia powiązanego rekordu działania zapobiegawczego.
Typ zdarzenia
inferred
|
|||
Instrukcje eksportu danych
Gotowi do rozpoczęcia?
Skorzystajcie z tego szablonu, aby sprawnie przygotować dane dotyczące zarządzania jakością i rozpocząć analizę procesu. Od tego można zacząć usprawnianie operacji.
Usprawnijcie zarządzanie jakością i skróćcie czas realizacji
Wskażcie i usuńcie wąskie gardła, aby dążyć do skrócenia czasu realizacji o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.