> Ciągłe doskonalenie procesów > Zarządzanie jakością > Zarządzanie jakością w Oracle > Szablon danych

Szablon danych do zarządzania jakością

Zarządzanie jakością w Oracle

← Wróć do przewodnika ulepszania procesów

Atrybuty zarządzania jakością(20) Czynności w zarządzaniu jakością(14) Instrukcje ekstrakcji danych(3)

Szablon danych do zarządzania jakością

Szablon zawiera wskazówki dotyczące atrybutów danych i czynności procesowych potrzebnych do skutecznej analizy zarządzania jakością. Podpowiada również, jak wyodrębnić te informacje z systemu Oracle Quality Management. Dzięki niemu można zebrać dane potrzebne do szczegółowej analizy i optymalizacji procesów.

Zalecane atrybuty do zebrania
Najważniejsze czynności do śledzenia
Wskazówki dotyczące ekstrakcji danych

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty zarządzania jakością

Poniżej przedstawiono zalecane pola danych i informacje kontekstowe, które warto uwzględnić w dzienniku zdarzeń, aby uzyskać pełny obraz zarządzania jakością.

3 Wymagane 7 Zalecane 10 Opcjonalne

	Nazwa	Opis
	Czas rozpoczęcia zdarzenia EventStartTime	Znacznik czasu wskazujący, kiedy rozpoczęło się działanie lub zdarzenie.
Opis Ten atrybut określa dokładną datę i godzinę rozpoczęcia konkretnego etapu procesu. Jest podstawą chronologicznego porządkowania zdarzeń i odtworzenia kolejności działań dla każdej sprawy jakościowej. W analizie czas rozpoczęcia zdarzenia jest niezbędny do obliczania czasu cyklu, czasu trwania i czasu oczekiwania między działaniami. Pomaga wykrywać wąskie gardła, wskazując długie przerwy między kolejnymi etapami. Służy też do monitorowania wyników względem KPI opartych na czasie, takich jak czas do analizy przyczyny źródłowej. Dlaczego to ważne Ten znacznik czasu stanowi podstawę analizy procesu. Umożliwia wszystkie obliczenia oparte na czasie i prawidłowe uporządkowanie działań. Skąd pobrać Znacznik czasu znajduje się zwykle w dziennikach transakcji lub tabelach historii powiązanych z działaniami jakościowymi i planami pobierania próbek. Pole może nazywać się CREATION_DATE lub podobnie. Przykłady 2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
	Nazwa działania ActivityName	Nazwa konkretnego zadania lub etapu, który wystąpił w procesie zarządzania jakością.
Opis Ten atrybut opisuje pojedyncze zdarzenie lub działanie w ramach obsługi zdarzenia jakościowego. Kolejność tych działań, ustalona na podstawie znaczników czasu, wyznacza przebieg procesu dla każdej sprawy. Analiza nazwy działania jest podstawą process mining. Umożliwia odkrycie rzeczywistego modelu procesu, porównanie go z modelem docelowym w ramach kontroli zgodności oraz wykrywanie wąskich gardeł i pętli poprawek między konkretnymi działaniami. Pozwala na przykład zmierzyć czas między etapami „Rozpoczęto dochodzenie” i „Przeprowadzono analizę przyczyny źródłowej”. Dlaczego to ważne Ten atrybut jest niezbędny do mapowania przebiegu procesu, wykrywania odstępstw i zrozumienia, jak faktycznie wykonywana jest praca. Skąd pobrać Informacje te pochodzą zwykle z dzienników zdarzeń, rekordów zmian statusu lub tabel historii działań w module Oracle Quality Management. Przykłady Zidentyfikowano problem jakościowyRozpoczęto dochodzenieZatwierdzono plan działań korygującychKońcowy przegląd i zamknięcie
	Zdarzenie jakościowe QualityEventId	Unikalny identyfikator pojedynczego zdarzenia jakościowego, takiego jak niezgodność, reklamacja lub odstępstwo.
Opis Identyfikator Quality Event ID jest głównym identyfikatorem sprawy. Łączy wszystkie powiązane działania, od pierwszego zgłoszenia do ostatecznego zamknięcia. Każdemu zdarzeniu jakościowemu przypisuje się unikalny identyfikator, który pozwala zachować pełną historię dochodzenia i rozwiązania problemu. W analizie process mining ten atrybut jest podstawą odtworzenia pełnego przebiegu każdego zdarzenia jakościowego. Umożliwia obliczanie całkowitego czasu cyklu, wykrywanie wariantów procesu i analizę sposobu obsługi różnych rodzajów zdarzeń. Powiązanie każdego wpisu aktywności z konkretnym identyfikatorem Quality Event ID pozwala analitykom zobaczyć cały przebieg procesu i wykryć problemy systemowe, takie jak wąskie gardła lub niezgodności. Dlaczego to ważne Ten identyfikator wyznacza zakres pojedynczej sprawy. Umożliwia dokładne śledzenie zdarzeń jakościowych i obliczanie wskaźników efektywności dla całego procesu. Skąd pobrać Zwykle jest to klucz główny w głównych tabelach zdarzeń jakościowych lub planów pobierania próbek w Oracle Quality Management, na przykład QA_RESULTS. Przykłady NC-2023-00123CAPA-45892QE-500-A
	Bieżący status CurrentStatus	Bieżący status sprawy dotyczącej zdarzenia jakościowego.
Opis Ten atrybut wskazuje aktualny etap zdarzenia jakościowego, na przykład „Otwarte”, „W trakcie dochodzenia”, „Oczekuje na zatwierdzenie” lub „Zamknięte”. Pokazuje stan sprawy w chwili pobrania danych. To ważny atrybut do monitorowania operacyjnego. Wspiera dashboard „Otwarte zdarzenia jakościowe i przegląd statusów”, który pozwala kierownikom szybko sprawdzić bieżące sprawy i ustalić priorytety przydziału zasobów. W process mining filtrowanie według statusu końcowego pomaga analizować wyniki różnych ścieżek procesu. Dlaczego to ważne Zapewnia bieżący obraz spraw związanych ze zdarzeniami jakościowymi, ułatwiając zarządzanie operacyjne i ustalanie priorytetów aktywnych spraw. Skąd pobrać Informacje te są zwykle dostępne w głównej tabeli nagłówkowej zdarzeń jakościowych i odzwierciedlają ostatni znany stan zdarzenia. Przykłady OtwarteW tokuOczekuje na zatwierdzenieZamknięte
	Czas zakończenia zdarzenia EventEndTime	Znacznik czasu wskazujący, kiedy zakończyło się działanie lub zdarzenie.
Opis Czas zakończenia zdarzenia wskazuje, kiedy zakończyło się konkretne działanie. W połączeniu z czasem rozpoczęcia określa czas jego realizacji. W niektórych systemach działanie może być natychmiastowe, a wtedy czas rozpoczęcia i zakończenia jest taki sam. Ten atrybut jest niezbędny do szczegółowej analizy czasu trwania. Pozwala odróżnić aktywny czas realizacji, czyli czas od rozpoczęcia do zakończenia działania, od czasu oczekiwania, czyli przerwy między zakończeniem jednego działania a rozpoczęciem następnego. Dzięki temu można ustalić, kiedy zasoby są zaangażowane w pracę, a kiedy przekazywanie zadań powoduje opóźnienia. Dlaczego to ważne Umożliwia dokładne obliczenie czasu realizacji działań, co pomaga odróżnić nieefektywne zadania od długiego oczekiwania. Skąd pobrać Może być dostępny w tych samych tabelach transakcji lub historii co czas rozpoczęcia, czasem jako LAST_UPDATE_DATE albo osobny znacznik czasu zakończenia. Można go też ustalić na podstawie czasu rozpoczęcia kolejnego zdarzenia. Przykłady 2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
	Docelowa data rozwiązania TargetResolutionDate	Planowana lub przewidywana data ostatecznego zamknięcia zdarzenia jakościowego.
Opis Ten atrybut określa termin, do którego zdarzenie jakościowe powinno zostać w pełni rozwiązane. Jest to termin wynikający z umowy o gwarantowanym poziomie usług (SLA) lub cel wewnętrzny, często ustalany na podstawie wagi albo rodzaju zdarzenia. Data ta ma podstawowe znaczenie przy monitorowaniu wyników i jest bezpośrednio wykorzystywana do obliczania KPI „Terminowość wdrożenia CAPA”. Porównując rzeczywiste daty zakończenia działań z wyznaczonym terminem, analitycy mogą ocenić terminowość, wskazać zdarzenia zagrożone opóźnieniem i śledzić zmiany wyników w czasie. Pomaga to skrócić czas rozwiązywania problemów. Dlaczego to ważne Stanowi punkt odniesienia przy ocenie terminowości. Jest też niezbędna do obliczania KPI dotyczących terminowości i zarządzania SLA. Skąd pobrać Informacje można znaleźć w dokumentacji Oracle Quality Management. Może to być standardowe pole daty lub pole zdefiniowane przez użytkownika w planie zbierania danych dotyczących jakości. Przykłady 2023-05-302023-06-152024-01-10
	Kategoria przyczyny źródłowej RootCauseCategory	Klasyfikacja ustalonej przyczyny źródłowej problemu jakościowego.
Opis Po przeprowadzeniu analizy przyczyny źródłowej jej wyniki często przypisuje się do wcześniej określonych kategorii, takich jak „Awaria sprzętu”, „Błąd człowieka” lub „Wada projektu”. Ten atrybut przechowuje końcową klasyfikację. Analiza procesu według kategorii przyczyny źródłowej pomaga odejść od usuwania pojedynczych objawów i skupić się na problemach systemowych. Na przykład duża liczba zdarzeń, których przyczyną jest „Problem ze szkoleniem”, może wskazywać na potrzebę lepszego przygotowania pracowników. To jeden z celów działań zapobiegawczych. Dlaczego to ważne Atrybut ten pomaga przejść od reaktywnego do proaktywnego zarządzania jakością, ponieważ umożliwia analizę podstawowych przyczyn niepowodzeń. Skąd pobrać Informacje można znaleźć w dokumentacji Oracle Quality Management. Prawdopodobnie jest to pole zdefiniowane przez użytkownika w planie zbierania danych, uzupełniane po działaniu „Przeprowadzono analizę przyczyny źródłowej”. Przykłady Awaria sprzętuWada materiałuBłąd człowiekaNieprzestrzeganie procedury
	Odpowiedzialny dział ResponsibleDepartment	Dział lub obszar funkcjonalny odpowiedzialny za zdarzenie jakościowe albo bieżące działanie.
Opis Ten atrybut wskazuje zespół lub dział odpowiedzialny za obsługę zdarzenia jakościowego. Może to być dział zapewnienia jakości, inżynierii, produkcji lub inna jednostka. Odpowiedzialność może się zmieniać w miarę przechodzenia zdarzenia przez kolejne etapy. Analiza według odpowiedzialnego działu pomaga zrozumieć rozkład obciążenia, wykrywać wąskie gardła w poszczególnych działach i porównywać wyniki zespołów. Wspiera dashboard „Przydział zasobów w obsłudze zdarzeń jakościowych”, pokazując, które działy uczestniczą w poszczególnych działaniach i ułatwiając planowanie zasobów. Dlaczego to ważne Umożliwia analizę obciążenia, wyników i wąskich gardeł w poszczególnych działach, co pomaga planować zasoby i usprawniać organizację. Skąd pobrać Informacje można znaleźć w dokumentacji Oracle Quality Management. Mogą być zapisane w tabelach dotyczących działań jakościowych lub przypisań powiązanych ze zdarzeniem jakościowym. Przykłady Inżynieria jakościOperacje produkcyjneJakość dostawcówInżynieria projektowa
	Poziom dotkliwości SeverityLevel	Klasyfikacja wpływu zdarzenia jakościowego, na przykład jako krytycznego, poważnego lub niewielkiego.
Opis Poziom dotkliwości to ocena, zwykle przeprowadzana podczas wstępnej oceny, potencjalnego wpływu problemu jakościowego na klientów, zgodność lub operacje biznesowe. Klasyfikacja pomaga ustalać priorytety przydziału zasobów i pilność wymaganej reakcji. W process mining ten atrybut umożliwia podział danych na segmenty. Analitycy mogą porównywać przebieg procesu, czasy cyklu i wyniki dla zdarzeń o wysokiej i niskiej dotkliwości. Wspiera dashboard „Spójność wstępnej oceny zdarzeń jakościowych” i KPI „Wskaźnik rozwiązywania problemów według dotkliwości”, pokazując, czy problemy krytyczne są obsługiwane szybciej i skuteczniej. Dlaczego to ważne Ułatwia ustalanie priorytetów i podział analizy na segmenty, dzięki czemu zdarzenia jakościowe o dużym wpływie można skutecznie obsługiwać. Skąd pobrać Informacje można znaleźć w dokumentacji Oracle Quality Management. Często jest to element konfigurowany w planie zbierania danych dotyczących jakości. Przykłady 1 - Krytyczny2 - Poważny3 - Drobny4 - Informacyjny
	Przypisany użytkownik AssignedUser	Użytkownik przypisany do wykonania działania lub odpowiedzialny za zdarzenie jakościowe.
Opis Ten atrybut wskazuje osobę odpowiedzialną za konkretne zadanie lub całościową obsługę zdarzenia jakościowego. Zapewnia bardziej szczegółowe informacje niż odpowiedzialny dział. Analiza według użytkownika pomaga ocenić indywidualne obciążenie pracą, określić potrzeby szkoleniowe i rozpoznać osoby osiągające najlepsze wyniki. Może też ujawnić powtarzające się przekazywanie pracy lub zadania, które zatrzymują się u konkretnych osób. Taki poziom szczegółowości przydaje się w zarządzaniu wynikami i optymalizacji zasobów. Dlaczego to ważne Umożliwia szczegółową analizę obciążenia i wyników poszczególnych osób, pomagając wykryć ograniczenia zasobów i potrzeby szkoleniowe. Skąd pobrać Informacje można znaleźć w dokumentacji Oracle Quality Management. Dane o przypisaniu użytkowników są zwykle przechowywane w tabelach działań lub workflow powiązanych ze zdarzeniem jakościowym. Przykłady j.smitha.jonesr.williams
	Całkowity czas cyklu TotalCycleTime	Łączny czas od wykrycia problemu jakościowego do jego ostatecznego zamknięcia.
Opis Ten atrybut mierzy całkowity czas obsługi pojedynczej sprawy dotyczącej zdarzenia jakościowego, od początku do końca. Oblicza się go jako różnicę między znacznikiem czasu pierwszego działania („Zidentyfikowano problem jakościowy”) a znacznikiem czasu ostatniego działania („Końcowy przegląd i zamknięcie”). To jeden z podstawowych KPI efektywności całego procesu zarządzania jakością. Jest główną miarą na dashboardzie „Całkowity czas obsługi zdarzenia jakościowego”. Śledzenie tego wskaźnika w czasie i podział wyników według takich atrybutów jak waga lub kategoria problemu pozwalają ocenić stan procesu oraz wpływ działań usprawniających. Dlaczego to ważne To ważny KPI, który mierzy szybkość i efektywność całego procesu zarządzania jakością, od początku do końca. Skąd pobrać Wartość oblicza się dla każdej sprawy podczas przygotowywania danych do process mining. Potrzebny jest czas rozpoczęcia pierwszego zdarzenia i czas zakończenia ostatniego zdarzenia dla każdego QualityEventId. Przykłady P30DT12HP15DP92D
	Czy ponowne wykonanie IsRework	Flaga informująca, czy działanie jest powtórzeniem lub ponownym wykonaniem wcześniejszego kroku w tej samej sprawie.
Opis Ten atrybut logiczny przyjmuje wartość prawda, jeśli określone działanie, na przykład „Zaproponowano plan działań korygujących”, występuje więcej niż raz w ramach jednej sprawy dotyczącej zdarzenia jakościowego. Oznacza to pętlę lub korektę w procesie, czyli konieczność ponownego wykonania wcześniej zakończonego kroku. Wykrywanie ponownego wykonywania działań to jedna z możliwości process mining. Flaga ułatwia pomiar takich nieefektywności i bezpośrednio wspiera KPI „Częstotliwość ponownego wykonywania działań”. Analiza kroków najczęściej wykonywanych ponownie oraz okoliczności, w których do tego dochodzi, może ujawnić problemy ze szkoleniami, jakością danych lub kryteriami akceptacji. Wskazuje też możliwości usprawnienia procesu. Dlaczego to ważne Wskazuje nieefektywności i pętle w procesie, pomagając mierzyć straty i ustalać przyczyny ponownego wykonywania działań. Skąd pobrać Wartość oblicza się podczas przygotowywania danych, używając funkcji okienkowych lub analizy sekwencyjnej dziennika zdarzeń. Pozwala to wykryć, że ta sama nazwa działania występuje wielokrotnie w ramach jednej sprawy. Przykłady truefalse
	Czy w terminie IsOnTime	Flaga informująca, czy działanie korygujące wdrożono do docelowej daty rozwiązania.
Opis Ten atrybut logiczny jest wyznaczany przez porównanie znacznika czasu zakończenia działania „Wdrożono działanie korygujące” z docelową datą rozwiązania sprawy. Przyjmuje wartość prawda, jeśli działanie zakończono w wyznaczonym terminie lub wcześniej, a w przeciwnym razie wartość fałsz. Atrybut ten bezpośrednio wspiera KPI „Terminowość wdrożenia CAPA”. Ułatwia analizę i tworzenie dashboardów, ponieważ jasno klasyfikuje terminowość każdej sprawy. Pozwala łatwo filtrować i agregować dane, monitorować dotrzymywanie poziomów usług oraz ustalać przyczyny opóźnień. Dlaczego to ważne Ułatwia monitorowanie realizacji celów w terminie oraz pomiar i raportowanie tego KPI. Skąd pobrać To flaga wyliczana podczas przekształcania danych. Do jej obliczenia potrzebne są TargetResolutionDate i znacznik czasu odpowiedniego działania kończącego. Przykłady truefalse
	Identyfikator planu działań korygujących CorrectiveActionPlanId	Unikalny identyfikator planu działań korygujących (CAPA) utworzonego w celu rozwiązania zdarzenia jakościowego.
Opis Ten atrybut bezpośrednio łączy zdarzenie jakościowe z konkretnym planem działań korygujących i zapobiegawczych, który ma rozwiązać problem. Plan jest często osobnym obiektem w systemie i ma własny cykl życia. Podczas analizy identyfikator ten pozwala połączyć dane z procesu obsługi zdarzeń jakościowych z danymi z procesu zarządzania CAPA, zapewniając pełniejszy obraz. Ułatwia sprawdzenie, czy do każdego zdarzenia wymagającego CAPA przypisano plan, oraz ocenę skuteczności podjętych działań. Dlaczego to ważne Łączy problem, czyli zdarzenie jakościowe, z rozwiązaniem w postaci CAPA. Umożliwia pełniejszą analizę systemu zarządzania jakością od początku do końca. Skąd pobrać To pole referencyjne w rekordzie zdarzenia jakościowego, które wskazuje rekord w tabeli lub module przeznaczonym do obsługi CAPA. Przykłady CAPA-2023-088CAPA-2023-091
	Identyfikator produktu ProductIdentifier	Identyfikator produktu powiązanego ze zdarzeniem jakościowym.
Opis Ten atrybut łączy zdarzenie jakościowe z konkretnym produktem, materiałem lub usługą. Może to być kod produktu, SKU albo numer części. Powiązanie to ma duże znaczenie w analizie jakości produktów. process mining pozwala porównywać procesy zarządzania jakością dla różnych linii produktów i wskazywać produkty często powiązane z problemami jakościowymi. Dzięki temu można skupić działania inżynieryjne lub produkcyjne na obszarach, które najbardziej tego wymagają. Dlaczego to ważne Łączy zdarzenia jakościowe z konkretnymi produktami, co pozwala analizować trendy dotyczące jakości produktów i różnice w przebiegu procesów. Skąd pobrać Informacja ta jest przechowywana w polu planu zbierania danych dotyczących jakości, często powiązanym z kartoteką pozycji Oracle Inventory. Przykłady SKU-100-A-REDPN-987654CHEM-X2
	Jednostka biznesowa BusinessUnit	Jednostka biznesowa lub dział organizacji, w którym wystąpiło zdarzenie jakościowe albo w którym jest ono obsługiwane.
Opis Ten atrybut przypisuje zdarzenie jakościowe do określonej części struktury firmy. Ułatwia analizę i porównywanie wyników w zakresie jakości między jednostkami organizacyjnymi. Duże przedsiębiorstwa często analizują procesy osobno dla każdej jednostki biznesowej. Pozwala to tworzyć dashboardy dla poszczególnych jednostek i sprawdzać, czy niektóre z nich mają sprawniejsze procesy zarządzania jakością lub mierzą się z odrębnymi problemami. Takie podejście wspiera nadzór na poziomie całej firmy i wymianę dobrych praktyk. Dlaczego to ważne Umożliwia porównywanie wyników i analizę różnych części organizacji, wspierając zarządzanie jakością w całej firmie. Skąd pobrać Zazwyczaj jest to część danych o strukturze organizacyjnej powiązanych z transakcją. Dane te często pochodzą z kartoteki użytkowników lub działów. Przykłady Wyroby medyczneElektronika użytkowaCzęści samochodowe
	Kategoria problemu IssueCategory	Kategoria lub rodzaj problemu jakościowego, na przykład „Wada produktu” lub „Odchylenie od procesu”.
Opis Ten atrybut klasyfikuje zdarzenie jakościowe i ułatwia grupowanie podobnych problemów na potrzeby analizy. Kategorie są zwykle definiowane przez organizację, tak aby odpowiadały jej specyfice operacyjnej. Analiza procesu według kategorii problemu pozwala wykrywać prawidłowości związane z konkretnymi rodzajami problemów. Może na przykład wykazać, że problemy z materiałami od dostawców trwają znacznie dłużej niż problemy wewnętrzne. Taki podział pomaga lepiej ukierunkować działania usprawniające proces. Dlaczego to ważne Kategoryzacja problemów pozwala analizować konkretne obszary, wykrywać trendy i ustalać przyczyny źródłowe. Skąd pobrać Informacje można znaleźć w dokumentacji Oracle Quality Management. Prawdopodobnie jest to pole zdefiniowane przez użytkownika w planie zbierania danych dotyczących jakości. Przykłady Wada produktuOdchylenie od procesuMateriał od dostawcyReklamacja klienta
	Kod zamknięcia ClosureCode	Kod określający przyczynę lub wynik zamknięcia zdarzenia jakościowego.
Opis Po zamknięciu zdarzenia jakościowego często przypisuje się kod klasyfikujący końcowy wynik. Przykłady to „Działanie skuteczne”, „Nie wymagano działania” lub „Problem zduplikowany”. Atrybut ten jest przydatny przy analizie wyników. Filtrując dane według kodów zamknięcia, analitycy mogą porównywać ścieżki procesu prowadzące do skutecznego rozwiązania z tymi, które go nie przynoszą. Można na przykład sprawdzić, jak przebiega obsługa problemów zamkniętych jako duplikaty, i wykryć nieefektywności w procesie wstępnej oceny. Dlaczego to ważne Dostarcza informacji o wyniku sprawy i pozwala analizować, które ścieżki procesu prowadzą do skutecznego rozwiązania. Skąd pobrać Informacje można znaleźć w dokumentacji Oracle Quality Management. Pole to jest prawdopodobnie uzupełniane podczas końcowego działania zamykającego sprawę. Przykłady SKUTECZNEBRAK_DZIAŁANIADUPLIKATRYZYKO_AKCEPTOWANE
	Ostatnia aktualizacja danych LastDataUpdate	Znacznik czasu ostatniego odświeżenia lub aktualizacji danych z systemu źródłowego.
Opis Ten atrybut wskazuje, kiedy ostatnio zaktualizowano dane o zdarzeniu w zbiorze danych do process mining. Informuje o aktualności danych i pomaga ocenić, na ile bieżąca jest analiza. W dashboardach i raportach ten znacznik czasu zapewnia użytkownikom ważny kontekst. Pokazuje, czy analizowane są dane bieżące, czy migawka z określonego momentu. Dzięki temu można podejmować decyzje operacyjne na podstawie aktualnych informacji i sprawdzić, jak świeże są dane. Dlaczego to ważne Ten znacznik czasu informuje o aktualności danych, dzięki czemu wiadomo, jak bieżąca jest analiza procesu. Skąd pobrać Wartość jest generowana i zapisywana podczas procesu ETL, zwykle jako znacznik czasu ostatniego pomyślnego uruchomienia potoku danych. Przykłady 2023-10-27T04:00:00Z2023-10-26T04:00:00Z
	System źródłowy SourceSystem	Wskazuje system źródłowy, z którego pobrano dane.
Opis Ten atrybut wskazuje aplikację lub system, z którego pochodzą dane o zdarzeniu. W organizacji dane o zdarzeniach jakościowych mogą pochodzić z wielu źródeł, na przykład z głównego modułu Oracle Quality, osobnego systemu CAPA lub portalu reklamacji klientów. W analizie pole to pomaga ustalić pochodzenie danych i umożliwia podział procesu według systemu źródłowego. Jest ważne dla zarządzania danymi i diagnozowania problemów z integracją, a także pozwala sprawdzić, czy widok procesu prawidłowo łączy dane z różnych źródeł. Dlaczego to ważne Informacja o pochodzeniu danych jest ważna przy ich weryfikacji i zarządzaniu oraz podczas analizy różnic w przebiegu procesu między systemami. Skąd pobrać Zwykle jest to stała wartość dodawana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL), która oznacza źródło zbioru danych. Przykłady Oracle Quality Management R12Oracle EBS QualityQM-PROD

Wymagane Zalecane Opcjonalne

Czynności w zarządzaniu jakością

Poniżej przedstawiono najważniejsze kroki procesu i istotne etapy, które warto zapisać w dzienniku zdarzeń, aby dokładnie odtworzyć przebieg procesu i ocenić jego wyniki.

6 Zalecane 8 Opcjonalne

	Działanie	Opis
	Końcowy przegląd i zamknięcie	Ostatni etap, na którym potwierdza się wykonanie wszystkich powiązanych działań i formalnie zamyka nadrzędny problem jakościowy. Zdarzenie jest rejestrowane jako końcowa zmiana statusu głównego rekordu na „Closed” lub „Resolved”.
Dlaczego to ważne To główne zdarzenie końcowe procesu. Jest niezbędne do obliczenia KPI „Średni czas obsługi zdarzenia” i pomiaru ogólnej przepustowości procesu. Skąd pobrać Ustalane na podstawie końcowej zmiany statusu nadrzędnego rekordu Quality Issue na „Closed”. Znacznik czasu tej zmiany jest czasem zdarzenia. Rejestrowanie Ustalane na podstawie zmiany statusu głównego rekordu Quality Issue na „Closed”. Typ zdarzenia inferred
	Potwierdzono skuteczność działania	Potwierdza, że wdrożone działanie korygujące usunęło przyczynę źródłową i zapobiegło ponownemu wystąpieniu problemu. Zdarzenie jest rejestrowane, gdy użytkownik kończy weryfikację i aktualizuje status rekordu.
Dlaczego to ważne To ważny etap potwierdzający osiągnięty rezultat i podstawa KPI „Wskaźnik potwierdzonej skuteczności”. Zamyka cykl działań korygujących i pozwala sprawdzić, czy problem został rzeczywiście rozwiązany. Skąd pobrać Ustalane na podstawie zmiany statusu rekordu CAPA na „Verification Complete” lub „Effective”. Może też wymagać uzupełnienia określonych pól z wynikami weryfikacji. Rejestrowanie Ustalane na podstawie zmiany statusu na „Verification Complete” lub „Effective”. Typ zdarzenia inferred
	Rozpoczęto dochodzenie	Oznacza formalne rozpoczęcie dochodzenia mającego ustalić przyczynę źródłową problemu jakościowego. Zwykle odpowiada mu zmiana statusu w systemie, na przykład na „Under Investigation”.
Dlaczego to ważne To punkt początkowy pomiaru KPI „Czas do analizy przyczyny źródłowej”. Pozwala też ustalić, jak długo problemy czekają na rozpoczęcie formalnego dochodzenia. Skąd pobrać Ustalane na podstawie zmiany statusu rekordu Quality Issue lub powiązanego rekordu Quality Action na „Investigation”. Znacznikiem czasu zdarzenia jest czas tej zmiany. Rejestrowanie Ustalane na podstawie zmiany statusu na „Under Investigation” lub podobny. Typ zdarzenia inferred
	Sklasyfikowano i ustalono priorytet problemu	To działanie następuje po wstępnej ocenie przeprowadzonej przez analityka, który określa między innymi dotkliwość, priorytet i rodzaj problemu. Zwykle można je rozpoznać po zmianie statusu z „New” na „Assessed” lub „In Triage”.
Dlaczego to ważne Ten etap jest istotny dla KPI „Średni czas wstępnej oceny”. Opóźnienia mogą spowolnić cały proces rozwiązywania problemu, zwłaszcza w przypadku spraw krytycznych. Skąd pobrać Ustalane na podstawie zmiany statusu rekordu Quality Issue, na przykład z „New” na „Under Assessment”, albo pierwszego uzupełnienia pól „Severity” lub „Priority”. Rejestrowanie Ustalane na podstawie zmiany statusu lub pierwszego uzupełnienia pól „Severity” albo „Priority”. Typ zdarzenia inferred
	Zatwierdzono plan działań korygujących	Oznacza formalne zatwierdzenie proponowanego planu działań korygujących przez wyznaczoną osobę lub jednostkę. To ważny punkt kontroli, zwykle rejestrowany jako jawna decyzja zatwierdzająca lub zmiana statusu na „Approved”.
Dlaczego to ważne Zatwierdzenie jest ważnym etapem i często stanowi wąskie gardło. Analiza czasu zatwierdzania pomaga usprawnić proces i zapewnić zgodność z procedurami. Skąd pobrać Ustalane na podstawie zmiany statusu rekordu Quality Action lub CAPA na „Approved”. Systemy Oracle z workflow zatwierdzania często jawnie rejestrują tę zmianę w tabelach audytowych. Rejestrowanie Ustalane na podstawie zmiany statusu na „Approved”. Typ zdarzenia inferred
	Zidentyfikowano problem jakościowy	To działanie oznacza utworzenie nowego rekordu zdarzenia jakościowego, na przykład niezgodności, odstępstwa lub reklamacji klienta. Zdarzenie jest rejestrowane w chwili, gdy użytkownik tworzy w Oracle rekord Quality Issue lub Quality Action.
Dlaczego to ważne Jako zdarzenie początkowe jest niezbędne do obliczenia całkowitego czasu cyklu procesu zarządzania jakością i określenia liczby napływających zdarzeń jakościowych. Skąd pobrać Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia rekordu Quality Issue lub Quality Action. Można go znaleźć między innymi w tabelach QAM_QUALITY_ISSUES lub QAM_QUALITY_ACTIONS. Rejestrowanie Rejestrowane po utworzeniu nowego rekordu Quality Issue lub Quality Action. Typ zdarzenia explicit
	Poinformowano zainteresowane strony o rozwiązaniu problemu	Oznacza przekazanie informacji o rozwiązaniu zdarzenia jakościowego odpowiednim osobom, na przykład zgłaszającemu lub klientom, których dotyczy problem. Trudno je zarejestrować, dlatego może być ustalane na podstawie zmiany statusu po zamknięciu sprawy lub zapisanego komentarza.
Dlaczego to ważne To zdarzenie ma znaczenie dla KPI „Opóźnienie w powiadomieniu zainteresowanych stron”. Terminowa komunikacja wpływa na zadowolenie klientów i przejrzystość wewnętrzną, także po rozwiązaniu problemu. Skąd pobrać Często trudno je automatycznie zarejestrować. Może być ustalane na podstawie statusu „Notification Sent” albo wpisu w polu aktywności lub komentarzy. Wymaga to specjalnej logiki ekstrakcji danych. Rejestrowanie Ustalane na podstawie określonej zmiany statusu lub analizy tekstu w dziennikach aktywności. Typ zdarzenia inferred
	Przedstawiono plan działań korygujących	Zdarzenie następuje po określeniu działań korygujących i powiązaniu ich z problemem jakościowym. Plan opisuje kroki potrzebne do usunięcia problemu. Może mu odpowiadać utworzenie powiązanego rekordu Corrective Action lub zmiana statusu wskazująca, że plan jest gotowy do przeglądu.
Dlaczego to ważne Ten etap pokazuje przejście od analizy problemu do opracowania rozwiązania. Powtarzanie tego kroku, mierzone za pomocą KPI dotyczących poprawek, może wskazywać na niejasne wymagania lub nieskuteczne planowanie. Skąd pobrać Może to być jawne zdarzenie związane z utworzeniem rekordu Corrective Action w obiekcie CAPA albo zdarzenie ustalone na podstawie zmiany statusu na „Plan Proposed” lub „Pending Approval”. Rejestrowanie Ustalane na podstawie zmiany statusu na „Pending Approval” lub utworzenia powiązanego rekordu Corrective Action. Typ zdarzenia inferred
	Przeprowadzono analizę przyczyny źródłowej	Oznacza zakończenie analizy przyczyny źródłowej (RCA) i udokumentowanie ustaleń. Zwykle można je rozpoznać, gdy zespół dochodzeniowy uzupełnia rekord problemu o ustaloną przyczynę źródłową i zmienia jego status.
Dlaczego to ważne To zdarzenie końcowe dla KPI „Czas do analizy przyczyny źródłowej”. Analiza czasu do tego etapu pomaga wskazać wąskie gardła w rozwiązywaniu problemu. Skąd pobrać Ustalane na podstawie zmiany statusu na „RCA Complete” lub uzupełnienia pola kategorii przyczyny źródłowej i zapisania rekordu. Wykorzystywany jest znacznik czasu tej aktualizacji. Rejestrowanie Ustalane na podstawie zmiany statusu na „RCA Complete” lub uzupełnienia pól dotyczących przyczyny źródłowej. Typ zdarzenia inferred
	Przypisano problem do wstępnej oceny	Oznacza przypisanie nowo zgłoszonego problemu jakościowego do konkretnego użytkownika lub zespołu w celu wstępnego przeglądu i oceny. Zdarzenie często można ustalić na podstawie zmian w polu osoby przypisanej lub właściciela rekordu problemu.
Dlaczego to ważne Śledzenie tego pierwszego przekazania pomaga wykryć opóźnienia przed rozpoczęciem oceny. Analiza czasu spędzonego w tym stanie może ujawnić zaległości w kolejce wstępnej oceny. Skąd pobrać Ustalane na podstawie zmian w polu właściciela lub osoby przypisanej w rekordzie Quality Issue. Dane mogą pochodzić z tabel ścieżki audytu lub ze śledzenia zmian statusu związanych z workflow przypisywania. Rejestrowanie Ustalane na podstawie zmiany pola „Assigned To” lub „Owner” w rekordzie Quality Issue. Typ zdarzenia inferred
	Wdrożono działanie korygujące	Oznacza wykonanie zadań określonych w zatwierdzonym planie działań korygujących. Zwykle można je rozpoznać po zmianie statusu rekordu działania korygującego na „Implemented” lub „Completed”.
Dlaczego to ważne To działanie ma znaczenie dla KPI „Terminowość wdrożenia CAPA”, ponieważ potwierdza wykonanie zaplanowanej korekty i umożliwia porównanie daty realizacji z terminem docelowym. Skąd pobrać Zdarzenie ustalane na podstawie zmiany statusu powiązanego rekordu Quality Action lub CAPA na „Implemented” albo „Completed”. Rejestrowanie Ustalane na podstawie zmiany statusu na „Implemented” lub „Completed”. Typ zdarzenia inferred
	Wdrożono działanie zapobiegawcze	Oznacza wykonanie zadań określonych w planie działań zapobiegawczych, które mają ograniczyć ryzyko systemowe. Zdarzenie jest rejestrowane, gdy użytkownik zmienia status rekordu działania zapobiegawczego na „Implemented” lub „Completed”.
Dlaczego to ważne Mierzy zdolność organizacji do wdrażania proaktywnych usprawnień jakości. Opóźnienia mogą wskazywać na trudności z wprowadzaniem zmian systemowych w całej organizacji. Skąd pobrać Ustalane na podstawie zmiany statusu powiązanego rekordu Preventive Action na „Implemented” lub „Completed”, podobnie jak w przypadku śledzenia działań korygujących. Rejestrowanie Ustalane na podstawie zmiany statusu rekordu Preventive Action na „Implemented”. Typ zdarzenia inferred
	Wymagana weryfikacja skuteczności	Oznacza, że system lub użytkownik wskazał konieczność sprawdzenia, czy wdrożone działanie przyniosło oczekiwany efekt. Zwykle jest to automatyczna lub ręczna zmiana statusu po wdrożeniu działania.
Dlaczego to ważne Ten etap rozpoczyna ważną fazę weryfikacji. Czas między wdrożeniem działania a tym zdarzeniem może ujawnić opóźnienia w rozpoczęciu wymaganych kontroli. Skąd pobrać Zdarzenie ustalane na podstawie zmiany statusu rekordu Quality Action na „Pending Effectiveness Check” lub podobny stan w workflow. Rejestrowanie Ustalane na podstawie zmiany statusu na „Pending Effectiveness Check”. Typ zdarzenia inferred
	Zidentyfikowano działanie zapobiegawcze	Oznacza utworzenie działania zapobiegawczego (PA), które ma rozwiązać problemy systemowe i zapobiec podobnym zdarzeniom jakościowym. Zwykle jest rejestrowane jako nowy rekord Preventive Action powiązany z pierwotnym problemem.
Dlaczego to ważne To działanie wskazuje na dojrzały proces jakościowy, który nie ogranicza się do usuwania pojedynczych problemów, lecz zapobiega kolejnym. Śledzenie tego etapu pomaga mierzyć proaktywne usprawnienia jakości. Skąd pobrać Rejestrowane po utworzeniu nowego rekordu Quality Action typu „Preventive Action”, często powiązanego z pierwotnym rekordem Quality Issue lub Corrective Action. Rejestrowanie Rejestrowane po utworzeniu rekordu Quality Action typu „Preventive Action”. Typ zdarzenia explicit

Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Oracle Quality Management

Kroki

Otwórz Oracle BI Publisher: Zaloguj się do instancji Oracle E-Business Suite i przejdź do odpowiedzialności zapewniającej dostęp do BI Publisher, na przykład BI Publisher Administrator lub podobnej odpowiedzialności niestandardowej.
Utwórz nowy model danych: Na stronie głównej BI Publisher wybierz Create, a następnie Data Model. Otworzy się edytor modelu danych.
Zdefiniuj zestaw danych z zapytania SQL: W edytorze modelu danych kliknij ikonę plusa w panelu Data Sets i wybierz SQL Query. Otworzy się okno edytora zapytań SQL.
Skonfiguruj źródło danych: W oknie New Data Set podaj nazwę zestawu danych, na przykład DS_QUALITY_EVENTS. Jako Data Source wybierz odpowiednią bazę danych Oracle EBS.
Wprowadź zapytanie SQL: Skopiuj całe zapytanie SQL z sekcji „query” tego dokumentu i wklej je w polu tekstowym SQL Query.
Zdefiniuj parametry zapytania: W zapytaniu użyto symboli zastępczych :P_START_DATE i :P_END_DATE określających okres raportowania. W modelu danych BI Publisher należy zdefiniować je jako parametry. Dla każdego utwórz nowy parametr, nadaj mu odpowiednią nazwę, na przykład P_START_DATE, ustaw typ danych Date i skonfiguruj czytelny dla użytkownika opis.
Zapisz model danych: Po wklejeniu zapytania i zdefiniowaniu parametrów zapisz model danych. Zaleca się zapisanie go w folderze współdzielonym przeznaczonym na raporty.
Utwórz nowy raport: Wróć na stronę główną BI Publisher, wybierz Create, a następnie Report. Wybierz opcję „Use Data Model” i wskaż zapisany model danych.
Skonfiguruj układ raportu: Kreator raportów przeprowadzi przez konfigurację układu. Na potrzeby ProcessMind wystarczy prosty układ tabeli. Przeciągnij wszystkie kolumny z modelu danych do układu raportu. Upewnij się, że formatem wyjściowym jest CSV.
Ustaw właściwości raportu: We właściwościach raportu zaznacz opcję „Enable CSV Output”. W razie potrzeby można też ustawić domyślne wartości parametrów.
Uruchom i wyeksportuj raport: Zapisz raport, a następnie uruchom go, podając wymagane daty początkową i końcową. Po wygenerowaniu raportu kliknij Export i wybierz format CSV. Plik zostanie pobrany na komputer.
Przygotuj plik do przesłania: Otwórz pobrany plik CSV i sprawdź, czy zawiera oczekiwane dane. Upewnij się, że nagłówki kolumn odpowiadają wymaganiom schematu ProcessMind. Plik jest gotowy do przesłania.

Konfiguracja

Wymagania wstępne: Konto użytkownika z dostępem do Oracle BI Publisher i uprawnieniami do odczytu tabel bazowego modułu Quality, na przykład QA_RESULTS, QA_PLANS, QA_ACTIONS i FND_USER.
Konfiguracja źródła danych: Model danych BI Publisher musi łączyć się z główną bazą aplikacyjną Oracle EBS, czyli schematem APPS.
Parametry zakresu dat: Zapytanie wymaga dwóch parametrów: :P_START_DATE i :P_END_DATE, które ograniczają zakres pobieranych danych. Do wstępnej analizy zaleca się okres od 6 do 12 miesięcy, aby zebrać wystarczającą liczbę kompletnych przypadków. Datę należy podać w formacie 'YYYY-MM-DD'.
Format wyjściowy: Raport musi umożliwiać eksport do CSV. Ten format najlepiej sprawdza się przy wczytywaniu danych do ProcessMind, ponieważ jest prosty, uporządkowany i nie wymaga złożonego przetwarzania.
Harmonogram: Aby stale monitorować proces, zaplanuj cykliczne uruchamianie raportu BI Publisher, na przykład codziennie lub co tydzień. Skonfiguruj dostarczanie pliku na wskazany serwer lub do repozytorium treści, skąd będzie automatycznie pobierany.
Wydajność: Przy dużej liczbie zdarzeń jakościowych wykonanie zapytania może zająć dużo czasu. Ustaw rozsądny zakres dat. Jeśli wydajność budzi obawy, skonsultuj z administratorem bazy danych optymalizację zapytania lub indeksowanie tabel.

Przykładowe zapytanie sql

SELECT
    qr.occurrence AS QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    qr.creation_date AS EventStartTime,
    qr.last_update_date AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate, -- Or a dedicated target date field
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.created_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

-- Activities based on status changes are best captured from an audit table if available. 
-- This example uses LAST_UPDATE_DATE which is an approximation.
SELECT
    qr.occurrence AS QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Assigned', 'In Triage') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Assessed', 'Prioritized') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Investigation Initiated' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Under Investigation' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qpc_rc.char_value IS NOT NULL AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

-- Corrective and Preventive Actions from a table like QA_ACTIONS
SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    qa.creation_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.assignee_id = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.status_code = 'Approved' AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.status_code IN ('Implemented', 'Completed') AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Verification Pending' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Verification Complete' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    qa.creation_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.assignee_id = fu.user_id
WHERE qa.action_code = 'PREVENTIVE_ACTION' AND qa.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'PREVENTIVE_ACTION' AND qa.status_code IN ('Implemented', 'Completed') AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Final Review and Closure' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Closed', 'Resolved') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Notification Sent' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

Kroki

Wymagania wstępne: Przygotuj klienta bazy danych, na przykład SQL Developer lub DBeaver, oraz dane logowania z uprawnieniami tylko do odczytu do bazy Oracle, w której działa moduł Quality Management.
Poznaj schemat: Zapoznaj się z najważniejszymi tabelami Oracle Quality. Zapytanie korzysta głównie z QA_RESULTS, zawierającej nagłówki zdarzeń jakościowych, QA_PLANS z definicjami planów, QA_RESULTS_V, czyli widoku łączącego wyniki z ich wartościami, oraz tabel użytkowników aplikacji, takich jak FND_USER lub PER_ALL_PEOPLE_F.
Zdefiniuj parametry zapytania: Przed uruchomieniem znajdź zmienne zastępcze w klauzuli WHERE. Zastąp :start_date, :end_date i :organization_id wartościami odpowiednimi dla zakresu ekstrakcji. Na przykład ustaw :start_date na '2023-01-01', a :end_date na '2023-06-30'.
Uruchom zapytanie SQL: Skopiuj cały skrypt SQL i uruchom go w kliencie bazy danych. Skrypt używa kilku klauzul UNION ALL, aby zebrać różne zdarzenia w jednym, ujednoliconym formacie dziennika zdarzeń.
Sprawdź surowe dane: Po wykonaniu zapytania przejrzyj wyniki. Każdy wiersz odpowiada jednej czynności w cyklu życia zdarzenia jakościowego. Sprawdź kompletność danych i obecność wartości w najważniejszych kolumnach, takich jak QualityEventId, ActivityName i EventStartTime.
Uwzględnij znaczniki czasu i czas trwania: Zapytanie zwraca EventStartTime. Pole EventEndTime pozostaje celowo ustawione na NULL, ponieważ ustalenie czasu zakończenia zdarzenia często wymaga znajomości czasu rozpoczęcia kolejnego. Takie obliczenie najlepiej wykonać w narzędziu process mining lub skrypcie przetwarzającym dane. ProcessingTime również ma wartość NULL, ponieważ wymaga obliczenia na podstawie czasu rozpoczęcia i zakończenia.
Wyeksportuj dane do CSV: Wyeksportuj cały zestaw wyników z klienta SQL do pliku CSV. Upewnij się, że plik jest zapisany w kodowaniu UTF-8 i zawiera wiersz nagłówkowy z aliasami kolumn z zapytania.
Przygotuj plik do przesłania: Sprawdź, czy nagłówki kolumn w pliku CSV odpowiadają wymaganiom platformy ProcessMind (Case ID, Activity, Start Timestamp). Przed przesłaniem zmień nazwy kolumn QualityEventId, ActivityName i EventStartTime na wymagane.

Konfiguracja

Dostęp do bazy danych: Użytkownik uruchamiający zapytanie musi mieć uprawnienia SELECT do wszystkich tabel użytych w skrypcie. Mogą to być tabele ze schematów APPS, QA, PER i HR.
Najważniejsze filtry zapytania: Zapytanie zawiera symbole zastępcze, które trzeba skonfigurować:
- :start_date: początek okresu raportowania. Zapytanie uwzględnia zdarzenia utworzone tego dnia lub później.
- :end_date: koniec okresu raportowania.
- :organization_id: identyfikator organizacji Oracle, którą Państwo analizują. Plany i wyniki kontroli jakości są często przypisane do konkretnej organizacji.
Zakres dat: Do wstępnej analizy zaleca się dane z okresu od 3 do 6 miesięcy. W dużych systemach o dużym wolumenie danych warto zacząć od krótszego okresu, na przykład jednego miesiąca, aby sprawdzić wydajność zapytania przed pobraniem większej ilości danych.
Wydajność: Zapytanie łączy kilka dużych tabel i scala 14 osobnych zestawów wyników. Może więc mocno obciążać system. Zaplanuj ekstrakcję poza godzinami szczytu, aby ograniczyć wpływ na jego wydajność. Jeśli zapytanie działa wolno, skonsultuj z administratorem bazy danych indeksowanie najważniejszych kolumn, zwłaszcza kolumn z datami i kluczami obcymi.

Przykładowe zapytanie sql

WITH QualityEventBase AS (
    SELECT
        qr.COLLECTION_ID,
        qr.PLAN_ID,
        qp.NAME AS PLAN_NAME,
        qr.ORGANIZATION_ID,
        qr.CREATION_DATE,
        qr.LAST_UPDATE_DATE,
        qr.CREATED_BY,
        qr.LAST_UPDATED_BY,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_STATUS') AS CurrentStatus,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_SEVERITY') AS SeverityLevel,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_ROOT_CAUSE') AS RootCauseCategory,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_DEPT') AS ResponsibleDepartment,
        (SELECT qrv.DATE1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_TARGET_DATE') AS TargetResolutionDate,
        (SELECT fu.USER_NAME FROM FND_USER fu WHERE fu.USER_ID = qr.LAST_UPDATED_BY) AS AssignedUser
    FROM
        QA_RESULTS qr
    JOIN
        QA_PLANS qp ON qr.PLAN_ID = qp.PLAN_ID
    WHERE
        qr.CREATION_DATE BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND qr.ORGANIZATION_ID = :organization_id
)
-- 1. Quality Issue Identified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    qeb.CREATION_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb

UNION ALL

-- 2. Issue Assigned For Triage (Approximation: first update after creation)
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'TRIAGE' AND qeb.LAST_UPDATE_DATE > qeb.CREATION_DATE

UNION ALL

-- 3. Issue Categorized and Prioritized
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'ASSESSED' AND qeb.SeverityLevel IS NOT NULL

UNION ALL

-- 4. Investigation Initiated
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Investigation Initiated' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'UNDER_INVESTIGATION'

UNION ALL

-- 5. Root Cause Analysis Performed
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'RCA_COMPLETE' AND qeb.RootCauseCategory IS NOT NULL

UNION ALL

-- 6. Corrective Action Plan Proposed
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_PROPOSED'

UNION ALL

-- 7. Corrective Action Plan Approved
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_APPROVED'

UNION ALL

-- 8. Corrective Action Implemented
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_IMPLEMENTED'

UNION ALL

-- 9. Effectiveness Check Required
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'EFFECTIVENESS_CHECK'

UNION ALL

-- 10. Effectiveness of Action Verified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'VERIFIED'

UNION ALL

-- 11. Preventive Action Identified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'PAPA_DEFINED'

UNION ALL

-- 12. Preventive Action Implemented
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'PAPA_IMPLEMENTED'

UNION ALL

-- 13. Final Review and Closure
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Final Review and Closure' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CLOSED'

UNION ALL

-- 14. Stakeholders Notified of Resolution (Approximation)
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    qeb.LAST_UPDATE_DATE + interval '1' minute AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CLOSED'

Kroki

Przygotuj środowisko: Upewnij się, że w systemie jest zainstalowany Python 3.6 lub nowszy. Zainstaluj wymagane biblioteki za pomocą pip: pip install pandas oracledb. Są potrzebne do połączenia z bazą Oracle i przetwarzania danych.
Uzyskaj dane logowania do bazy: Przygotuj dane potrzebne do połączenia z bazą Oracle Quality Management: nazwę użytkownika, hasło i Data Source Name (DSN), zwykle w formacie hostname:port/service_name.
Zapisz skrypt ekstrakcji: Skopiuj cały skrypt Python z sekcji „query” i zapisz go w pliku, na przykład extract_quality_events.py.
Skonfiguruj skrypt: Otwórz zapisany plik w edytorze tekstu. W sekcji konfiguracji na początku pliku zastąp wartości zastępcze db_user, db_password, db_dsn, start_date i end_date własnymi danymi.
Dostosuj symbole zastępcze w SQL: Sprawdź zapytanie SQL w skrypcie. Może być konieczna zmiana nazw tabel, takich jak QA_RESULTS, lub wartości statusu, takich jak 'NEW' i 'CLOSED', aby odpowiadały konfiguracji Oracle w Państwa organizacji. W razie wątpliwości skonsultuj się z administratorem systemu Oracle.
Uruchom skrypt: Otwórz wiersz polecenia lub terminal, przejdź do katalogu, w którym zapisano skrypt, i uruchom polecenie: python extract_quality_events.py.
Monitoruj wykonanie: Skrypt połączy się z bazą, wykona zapytanie i przetworzy dane. Zależnie od zakresu dat i ilości danych może to potrwać kilka minut. Sprawdź, czy pojawił się komunikat 'Successfully connected to Oracle Database!', a na końcu 'Event log saved to quality_event_log.csv'.
Odbierz plik wynikowy: Po zakończeniu skryptu w tym samym katalogu pojawi się plik quality_event_log.csv z wyodrębnionym dziennikiem zdarzeń.
Sprawdź dziennik zdarzeń: Otwórz plik quality_event_log.csv w arkuszu kalkulacyjnym i szybko sprawdź jego zawartość. Upewnij się, że zawiera oczekiwane kolumny i poprawnie wypełnione dane dla kilku przykładowych przypadków.
Prześlij dane do narzędzia process mining: Wygenerowany plik CSV jest gotowy do przesłania do aplikacji process mining i analizy.

Konfiguracja

Połączenie z bazą danych: Skrypt wymaga Oracle Data Source Name (DSN), nazwy użytkownika i hasła z uprawnieniami do odczytu wymaganych tabel Quality Management, na przykład QA_RESULTS, QA_PLANS, FND_USER i PER_ALL_PEOPLE_F.
Filtrowanie według zakresu dat: Zmienne start_date i end_date w skrypcie określają ilość pobieranych danych. Zaleca się zacząć od krótszego zakresu, na przykład 3–6 miesięcy, aby sprawdzić wydajność i poprawność wyników przed większą ekstrakcją.
Filtry zależne od systemu: Zapytanie SQL można dostosować do struktury organizacji. Na przykład klauzula WHERE z filtrem ORGANIZATION_ID ograniczy ekstrakcję do wybranego zakładu lub jednostki biznesowej.
Mapowanie kodów statusu: Logika ekstrakcji czynności przypisuje określone wartości statusu, na przykład 'NEW', 'UNDER_INVESTIGATION' i 'CLOSED', do kroków procesu. Wartości te zależą od konfiguracji Oracle i należy je sprawdzić oraz odpowiednio zmienić w zapytaniu SQL.
Zależności Pythona: Skrypt wymaga bibliotek pandas i oracledb. Należy je zainstalować w środowisku Python, w którym będzie uruchamiany skrypt.

Przykładowe zapytanie python

import pandas as pd
import oracledb
import sys

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle database credentials and connection details
db_user = class="hl-string">"your_username"
db_password = class="hl-string">"your_password"
class=class="hl-string">"hl-comment"># DSN (Data Source Name) format: hostname:port/service_name
db_dsn = class="hl-string">"your_host:1521/your_service_name"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SQL Query --- 
class=class="hl-string">"hl-comment"># This query extracts events from the Oracle Quality Management module.
class=class="hl-string">"hl-comment"># Each SELECT statement with a UNION ALL corresponds to a specific activity.
sql_query = fclass="hl-string">"""
WITH base_events AS (
    SELECT 
        qr.COLLECTION_ID AS QualityEventId,
        qr.LAST_UPDATE_DATE,
        qr.CREATION_DATE,
        qpc.PROMPT AS StatusPrompt,
        qr.CHARACTER1 AS CurrentStatus,
        qr.CHARACTER2 AS SeverityLevel,
        qr.CHARACTER3 AS RootCauseCategory,
        oap.NAME AS ResponsibleDepartment,
        fu.USER_NAME AS AssignedUser,
        qr.DATE1 AS TargetResolutionDate,
        (qr.LAST_UPDATE_DATE - qr.CREATION_DATE) * 24 * 60 AS ProcessingTime
    FROM 
        QA_RESULTS qr
    JOIN 
        QA_PLANS qp ON qr.PLAN_ID = qp.PLAN_ID
    JOIN 
        QA_PLAN_CHARS qpc ON qp.PLAN_ID = qpc.PLAN_ID AND qpc.PROMPT = 'Status'
    LEFT JOIN 
        FND_USER fu ON qr.LAST_UPDATED_BY = fu.USER_ID
    LEFT JOIN
        HR_ALL_ORGANIZATION_UNITS oap ON qr.ORGANIZATION_ID = oap.ORGANIZATION_ID
    WHERE 
        qr.CREATION_DATE BETWEEN TO_DATE('{start_date}', 'YYYY-MM-DD') AND TO_DATE('{end_date}', 'YYYY-MM-DD')
)
-- 1. Quality Issue Identified
SELECT
    be.QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    be.CREATION_DATE AS EventStartTime,
    be.CREATION_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    'New' AS CurrentStatus, -- Initial status
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be

UNION ALL

-- 2. Issue Assigned For Triage (approximated by first update after creation)
SELECT
    be.QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.LAST_UPDATE_DATE > be.CREATION_DATE AND be.CurrentStatus IN ('Assigned', '[Your Triage Status]')

UNION ALL

-- 3. Issue Categorized and Prioritized
SELECT
    be.QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus IN ('Assessed', 'Prioritized', '[Your Categorized Status]')

UNION ALL

-- 4. Investigation Initiated
SELECT
    be.QualityEventId,
    'Investigation Initiated' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus IN ('Under Investigation', 'Investigation')

UNION ALL

-- 5. Root Cause Analysis Performed
SELECT
    be.QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'RCA Complete' AND be.RootCauseCategory IS NOT NULL

UNION ALL

-- 6. Corrective Action Plan Proposed
SELECT
    be.QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Proposed'

UNION ALL

-- 7. Corrective Action Plan Approved
SELECT
    be.QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Approved'

UNION ALL

-- 8. Corrective Action Implemented
SELECT
    be.QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Implemented'

UNION ALL

-- 9. Effectiveness Check Required
SELECT
    be.QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Verification Pending'

UNION ALL

-- 10. Effectiveness of Action Verified
SELECT
    be.QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Verified Effective'

UNION ALL

-- 11. Preventive Action Identified
SELECT
    be.QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'PA Identified'

UNION ALL

-- 12. Preventive Action Implemented
SELECT
    be.QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'PA Implemented'

UNION ALL

-- 13. Final Review and Closure
SELECT
    be.QualityEventId,
    'Final Review and Closure' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Closed'

UNION ALL

-- 14. Stakeholders Notified of Resolution
SELECT
    be.QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    be.LAST_UPDATE_DATE + interval '1' day AS EventStartTime, -- Approximated as 1 day after closure
    be.LAST_UPDATE_DATE + interval '1' day AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Closed'
"""

class=class="hl-string">"hl-comment"># --- Main Execution Logic ---
try:
    class=class="hl-string">"hl-comment"># Establish the database connection
    with oracledb.connect(user=db_user, password=db_password, dsn=db_dsn) as connection:
        print(class="hl-string">"Successfully connected to Oracle Database!")
        
        class=class="hl-string">"hl-comment"># Execute the query and load data into a pandas DataFrame
        print(class="hl-string">"Executing query... This may take a few minutes.")
        df = pd.read_sql_query(sql_query, connection)
        print(fclass="hl-string">"Query finished. {len(df)} events extracted.")

        class=class="hl-string">"hl-comment"># Data Type Conversion
        df[class="hl-string">'EVENTSTARTTIME'] = pd.to_datetime(df[class="hl-string">'EVENTSTARTTIME'])
        df[class="hl-string">'EVENTENDTIME'] = pd.to_datetime(df[class="hl-string">'EVENTENDTIME'])
        df[class="hl-string">'TARGETRESOLUTIONDATE'] = pd.to_datetime(df[class="hl-string">'TARGETRESOLUTIONDATE'])

        class=class="hl-string">"hl-comment"># Sort the data for chronological order
        df = df.sort_values(by=[class="hl-string">'QUALITYEVENTID', class="hl-string">'EVENTSTARTTIME'], ascending=[True, True])

        class=class="hl-string">"hl-comment"># Save the DataFrame to a CSV file
        output_filename = class="hl-string">'quality_event_log.csv'
        df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
        print(fclass="hl-string">"Event log saved to {output_filename}")

except oracledb.DatabaseError as e:
    error, = e.args
    print(fclass="hl-string">"Database connection or query failed: {error.message}", file=sys.stderr)
    sys.exit(1)
except Exception as e:
    print(fclass="hl-string">"An unexpected error occurred: {e}", file=sys.stderr)
    sys.exit(1)

Gotowi do rozpoczęcia?

Ten szablon ułatwia szybkie przygotowanie danych i rozpoczęcie optymalizacji procesów zarządzania jakością. Już dziś można zacząć szukać sposobów na poprawę efektywności i zgodności.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usprawnij zarządzanie jakością w Oracle i popraw zgodność

Ogranicz nieefektywności i skróć czas cyklu o 30%.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Bezpłatny okres próbny trwa 14 dni.

Szablon danych do zarządzania jakością

Szablon danych do zarządzania jakością

Atrybuty zarządzania jakością

Czynności w zarządzaniu jakością

Instrukcje ekstrakcji danych

Raport Oracle BI Publisher z danymi o zdarzeniach jakościowych

Kroki

Konfiguracja

Przykładowe zapytanie sql

Bezpośrednie zapytanie SQL do tabel Oracle Quality Management

Kroki

Konfiguracja

Przykładowe zapytanie sql

Skrypt ekstrakcji w Pythonie z użyciem łącznika Oracle DB

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Usprawnij zarządzanie jakością w Oracle i popraw zgodność