Szablon danych do zarządzania jakością
Szablon danych do zarządzania jakością
- Zalecane atrybuty do zebrania na potrzeby szczegółowej analizy
- Najważniejsze działania w zarządzaniu jakością do monitorowania
- Wskazówki dotyczące ekstrakcji danych z zarządzania jakością w SAP S/4HANA
Atrybuty zarządzania jakością
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas rozpoczęcia
EventTimestamp
|
Dokładna data i godzina wystąpienia danego działania lub zdarzenia. | ||
|
Opis
Czas rozpoczęcia, czyli znacznik czasu zdarzenia, wskazuje dokładny moment wykonania działania. Jest niezbędny do chronologicznego uporządkowania zdarzeń i obliczania czasu między nimi. Pozwala na przykład ustalić, kiedy utworzono zgłoszenie, zakończono zadanie lub zmieniono status. W analizie process mining ten atrybut służy do obliczania wszystkich miar opartych na czasie, takich jak czas cyklu, czas przetwarzania i czas oczekiwania. Ułatwia wykrywanie wąskich gardeł, analizę przepustowości oraz monitorowanie wyników względem SLA i celów czasowych. Dokładne znaczniki czasu są niezbędne, aby model procesu prawidłowo odzwierciedlał jego przebieg.
Dlaczego to ważne
Ten znacznik czasu pozwala uporządkować zdarzenia, obliczać miary efektywności, takie jak czas cyklu i czas oczekiwania, oraz analizować przebieg procesu.
Skąd pobrać
Zwykle pochodzi z pól daty i godziny powiązanych ze zmianą statusu lub utworzeniem dokumentu. Przykłady to ERDAT/ERZEIT (data/godzina utworzenia) w QMEL oraz znaczniki czasu zmian w CDHDR.
Przykłady
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-01T11:21:45Z
|
|||
|
Działanie
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w procesie zarządzania jakością. | ||
|
Opis
Ten atrybut opisuje pojedynczy krok lub etap w cyklu życia zdarzenia jakościowego, na przykład „Utworzono zgłoszenie”, „Zakończono analizę przyczyny źródłowej” lub „Podjęto decyzję o wykorzystaniu”. Działania są ustalane na podstawie zmian statusu w systemie, utworzenia powiązanych dokumentów lub czynności użytkowników zapisanych w dziennikach zmian. Analiza kolejności i czasu trwania tych działań stanowi podstawę process mining. Pozwala odkryć rzeczywisty przebieg procesu, wykryć wąskie gardła między krokami i zmierzyć zgodność ze standardowymi procedurami operacyjnymi. Szczegółowość działań wpływa na poziom dokładności analizy procesu.
Dlaczego to ważne
Ten atrybut określa kroki procesu. Dzięki niemu można zwizualizować i przeanalizować jego przebieg, wykryć odstępstwa oraz zmierzyć czas między działaniami.
Skąd pobrać
Dane pochodzą ze zmian statusu w tabelach JEST i JSTO lub z zapisów działań w tabelach takich jak QMSM (Tasks). Dziennik zdarzeń można też utworzyć na podstawie tabel dokumentów zmian CDHDR i CDPOS.
Przykłady
Utworzenie zgłoszenia jakościowegoPrzydzielenie zadania dochodzeniowegoDziałanie korygujące wdrożoneZgłoszenie zamknięte
|
|||
|
Zdarzenie jakościowe
QualityEvent
|
Unikalny identyfikator zgłoszenia jakościowego, używany jako główny identyfikator sprawy do śledzenia problemu jakościowego od jego zgłoszenia do zamknięcia. | ||
|
Opis
Zdarzenie jakościowe to główny identyfikator sprawy, który łączy wszystkie działania, zadania i decyzje dotyczące jednego problemu jakościowego. W SAP odpowiada mu zwykle numer zgłoszenia jakościowego (QMNUM). W process mining analiza zdarzeń według tego identyfikatora pozwala odtworzyć przebieg każdej sprawy jakościowej od początku do końca. Umożliwia wizualizację przepływu procesu, obliczanie czasu realizacji całej sprawy oraz wykrywanie typowych i nietypowych ścieżek jej rozwiązywania. Identyfikator ten stanowi podstawę większości analiz zarządzania jakością.
Dlaczego to ważne
To niezbędny identyfikator, który łączy powiązane działania w jedną instancję procesu i umożliwia analizę obsługi problemów jakościowych od początku do końca.
Skąd pobrać
To numer zgłoszenia jakościowego z pola QMNUM w tabeli QMEL.
Przykłady
200000018200000019200000020
|
|||
|
Docelowa data rozwiązania
TargetResolutionDate
|
Planowana lub wymagana data zakończenia obsługi zdarzenia jakościowego. | ||
|
Opis
Ta data określa termin, do którego zdarzenie jakościowe powinno zostać w pełni rozwiązane i zamknięte. Często służy jako punkt odniesienia przy ocenie wyników i zgodności z umowami SLA. Atrybut ten pozwala obliczać odsetek spraw zakończonych w terminie i wykrywać sprawy przeterminowane. Dashboard „Terminowe zakończenie zdarzeń jakościowych” i KPI „Odsetek działań jakościowych zakończonych w terminie” opierają się na porównaniu rzeczywistej daty zakończenia z datą docelową. Informacja ta pomaga ustalać priorytety i efektywnie zarządzać zasobami.
Dlaczego to ważne
Stanowi punkt odniesienia przy ocenie terminowości, ważnym KPI służącym do pomiaru sprawności procesu i zgodności z SLA.
Skąd pobrać
Data znajduje się w QMEL-QMDAT (wymagana data zakończenia) lub na poziomie zadania w QMSM-PSTER.
Przykłady
2023-05-302023-06-152023-07-01
|
|||
|
Odpowiedzialny dział
ResponsibleDepartment
|
Dział lub obszar funkcjonalny odpowiedzialny za wykonanie konkretnego zadania lub obsługę zdarzenia jakościowego. | ||
|
Opis
Ten atrybut wskazuje jednostkę organizacyjną przypisaną do działania lub całego zdarzenia jakościowego. Może to być zespół zapewnienia jakości, dział inżynieryjny lub jednostka produkcyjna. Pozwala analizować współpracę między działami i przekazywanie zadań. Pomaga wykrywać opóźnienia przy zmianie odpowiedzialności między działami, co można analizować na dashboardzie „Opóźnienia przy przekazywaniu zadań między działami”. Umożliwia też filtrowanie widoku procesu, aby sprawdzić sposób pracy poszczególnych działów.
Dlaczego to ważne
Ułatwia analizę przekazywania zadań między działami, wykrywanie wąskich gardeł w organizacji i ocenę wkładu poszczególnych zespołów w proces.
Skąd pobrać
Informacje można często uzyskać z funkcji partnerów przypisanych do zgłoszenia lub zadania albo z danych o przypisaniu użytkownika do jednostki organizacyjnej w systemie HR. Mogą nie być dostępne w jednym polu.
Przykłady
Zapewnienie jakościLinia produkcyjna 3Inżynieria jakości dostawców
|
|||
|
Priorytet
NotificationPriority
|
Poziom priorytetu przypisany do zgłoszenia jakościowego, określający pilność jego obsługi. | ||
|
Opis
Priorytet określa, jak pilnie należy zająć się zdarzeniem jakościowym. Pomaga zespołom organizować pracę i w pierwszej kolejności obsługiwać najpoważniejsze problemy. W SAP można skonfigurować różne typy priorytetów, które mogą wpływać na docelowy czas reakcji. Analiza tego atrybutu pozwala sprawdzić, czy sprawy o wysokim priorytecie są rzeczywiście obsługiwane szybciej niż te o niskim priorytecie. Może ujawnić nieefektywność, na przykład sytuacje, w których pilne sprawy utknęły w procesie. Priorytet można wykorzystać jako wymiar na dashboardach, takich jak „Analiza przepustowości zdarzeń jakościowych”.
Dlaczego to ważne
Pomaga sprawdzić, czy wyniki procesu odpowiadają pilności biznesowej i czy problemy o wysokim priorytecie są rozwiązywane szybciej.
Skąd pobrać
Pole QMPRI w tabeli QMEL. Opis znajduje się w tabeli TQ05.
Przykłady
1234
|
|||
|
Produkt
MaterialNumber
|
Unikalny identyfikator produktu lub materiału, którego dotyczy zdarzenie jakościowe. | ||
|
Opis
Ten atrybut łączy zdarzenie jakościowe z konkretnym produktem lub materiałem. Ma to duże znaczenie dla zapewnienia jakości, ponieważ pomaga wykrywać produkty, w których problemy powtarzają się lub występuje wysoki odsetek wad. Analiza według produktu pozwala wykrywać zależności, na przykład ustalić, czy rozwiązanie problemów dotyczących określonych produktów trwa dłużej lub wiąże się z konkretnymi przyczynami źródłowymi. Na dashboardzie „Wykrywanie powtarzających się problemów” można zestawić produkty z problemami jakościowymi, co pomaga lepiej ukierunkować działania doskonalące.
Dlaczego to ważne
Łączy problemy jakościowe z konkretnymi produktami i umożliwia analizę odsetka wad, przyczyn źródłowych oraz sposobów rozwiązywania problemów dla poszczególnych produktów.
Skąd pobrać
Pole MATNR w tabeli pozycji zgłoszenia jakościowego QMFE.
Przykłady
FIN-1001RAW-205ASEMI-303B
|
|||
|
Przyczyna źródłowa
RootCauseCode
|
Kod lub opis wskazujący ustaloną przyczynę źródłową problemu jakościowego. | ||
|
Opis
Atrybut „Przyczyna źródłowa” określa podstawową przyczynę wady jakościowej lub niezgodności. Jej prawidłowe ustalenie jest ważnym etapem zarządzania jakością, ponieważ stanowi podstawę do określenia skutecznych działań korygujących i zapobiegawczych. Ten atrybut jest niezbędny na dashboardach „Czas cyklu analizy przyczyny źródłowej” i „Wykrywanie powtarzających się problemów”. Analiza według przyczyny źródłowej pomaga wykrywać problemy systemowe. Na przykład po odfiltrowaniu mapy procesu według konkretnej przyczyny można sprawdzić, czy wiąże się ona z odmiennymi ścieżkami procesu lub dłuższym czasem rozwiązania problemu.
Dlaczego to ważne
Pozwala analizować problemy systemowe przez zestawienie przyczyn źródłowych z produktami, działami i nieefektywnością procesu, co pomaga zaplanować działania zapobiegawcze.
Skąd pobrać
Zwykle przechowywana w tabeli QMUR (Notification Causes), w polu URCOD.
Przykłady
OPERATOR_ERRORDEFECTIVE_MATERIALMACHINE_MALFUNCTION
|
|||
|
Typ zgłoszenia jakościowego
QualityNotificationType
|
Klasyfikacja zgłoszenia jakościowego, na przykład reklamacja klienta, problem wewnętrzny lub wada dostawcy. | ||
|
Opis
Ten atrybut klasyfikuje zdarzenie jakościowe według jego źródła i charakteru. Standardowe typy SAP obejmują reklamacje klientów, zgłoszenia problemów wewnętrznych i wady związane z dostawcami. Klasyfikacja określa dalszy przebieg procesu i wymaganą dokumentację. Analiza procesu według typu zgłoszenia pozwala sprawdzić, czy różne problemy są obsługiwane w odmienny sposób lub z różną sprawnością. Umożliwia filtrowanie i porównywanie czasu cyklu oraz ścieżek procesu dla poszczególnych kategorii problemów, na przykład na dashboardzie „Analiza przepustowości zdarzeń jakościowych”.
Dlaczego to ważne
Pozwala podzielić proces na kategorie i sprawdzić, czy różne problemy jakościowe przebiegają innymi ścieżkami lub mają odmienne wyniki.
Skąd pobrać
Pole QMART w tabeli QMEL.
Przykłady
Q1Q2F2
|
|||
|
Użytkownik
ChangedBy
|
Identyfikator użytkownika, który wykonał działanie lub wprowadził ostatnią zmianę. | ||
|
Opis
Ten atrybut wskazuje użytkownika odpowiedzialnego za wykonanie danego kroku procesu. W SAP odpowiadają mu często pola „Changed By” (AENAM) lub „Created By” (ERNAM). Analiza według użytkownika pomaga ocenić rozkład obciążenia, określić potrzeby szkoleniowe i wykryć odstępstwa charakterystyczne dla konkretnych osób. Jest podstawą analizy wykorzystania zasobów, na przykład przy badaniu, dlaczego niektóre osoby przetwarzają sprawy dłużej lub częściej korzystają ze ścieżek niestandardowych.
Dlaczego to ważne
Umożliwia analizę wyników pracy użytkowników, rozkładu obciążenia i zgodności ze standardowymi procedurami, co pomaga lepiej wykorzystywać zasoby.
Skąd pobrać
Dane znajdują się w tabelach nagłówków i pozycji, na przykład w QMEL-ERNAM (utworzył), lub można je uzyskać z dzienników zmian (CDHDR-USERNAME).
Przykłady
SMITHJWILSONAPROCESS_AUTOMATION_BOT
|
|||
|
Czy wymaga ponownego wykonania
IsRework
|
Wartość logiczna wskazująca, czy działanie lub sekwencja działań oznacza ponowne wykonanie pracy. | ||
|
Opis
Flaga ma wartość true, jeśli w danym przypadku powtarzają się określone kroki, co wskazuje, że początkowe działania nie przyniosły wystarczającego rezultatu. Na przykład jeśli po działaniu „Analiza przyczyny źródłowej” w tym samym przypadku ponownie zostanie przypisane zadanie „Przydzielenie zadania dochodzeniowego”, oznacza to pętlę ponownej pracy. Ten atrybut bezpośrednio wspiera KPI „Odsetek ponownie wykonywanych działań korygujących”. Wykrywanie i mierzenie ponownej pracy to jeden z głównych celów process mining, ponieważ oznacza ona zmarnowany wysiłek i nieefektywność procesu. Zaznaczenie takich pętli na mapie procesu może wskazać istotne możliwości poprawy jakości i wydajności.
Dlaczego to ważne
Pozwala mierzyć nieefektywność procesu przez wykrywanie powtarzających się kroków. Wskazuje zmarnowany wysiłek i możliwości zwiększenia odsetka spraw załatwianych prawidłowo za pierwszym razem.
Skąd pobrać
Atrybut obliczany podczas analizy process mining przez wykrywanie powtarzających się sekwencji działań w ramach jednego przypadku.
Przykłady
truefalse
|
|||
|
Klient
CustomerNumber
|
Identyfikator klienta powiązanego ze zdarzeniem jakościowym, jeśli dotyczy. | ||
|
Opis
Ten atrybut łączy zdarzenie jakościowe z konkretnym klientem. Ma największe znaczenie w przypadku typów zgłoszeń takich jak „Customer Complaint”. Śledzenie tej informacji jest ważne dla zarządzania relacjami z klientami i oceny wpływu problemów jakościowych na klientów. Analiza według klienta pozwala ustalić, czy niektórzy klienci zgłaszają więcej problemów jakościowych niż inni lub czy czas ich rozwiązania różni się w zależności od klienta. Dodanie wymiaru klienta do analizy wpływu umożliwia wykorzystanie tego atrybutu na dashboardzie „Zdarzenia jakościowe według wagi i wpływu”.
Dlaczego to ważne
Łączy zdarzenia jakościowe z klientami, umożliwiając analizę problemów dotyczących poszczególnych klientów i priorytetową obsługę klientów o dużym znaczeniu dla firmy.
Skąd pobrać
Zwykle znajduje się w funkcjach partnerów zgłoszenia. Może też być zapisany w QMEL-KUNUM, jeśli reklamacja dotyczy zamówienia sprzedaży.
Przykłady
CUST-10045CUST-20399CUST-80110
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego. | ||
|
Opis
Ten atrybut zawiera znacznik czasu ostatniego pobrania lub aktualizacji danych z systemu źródłowego. Informuje użytkowników, jak aktualne są analizowane dane. W dashboardzie lub raporcie analitycznym warto wyświetlać tę informację, aby jasno określić aktualność danych. Pomaga ona odróżnić niedawne zmiany w procesie od efektów analizy nieaktualnych danych.
Dlaczego to ważne
Informuje o aktualności danych, co pozwala podejmować na czas trafne decyzje na podstawie analizy process mining.
Skąd pobrać
To pole metadanych, które narzędzie lub potok do pobierania danych wypełnia podczas ich odświeżania.
Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Skuteczność działania
EffectivenessEvaluation
|
Wynik weryfikacji określającej, czy wdrożone działanie było skuteczne. | ||
|
Opis
Ten atrybut zapisuje wynik weryfikacji skuteczności, czyli ważnego, końcowego etapu zarządzania jakością. Potwierdza, czy podjęte działania korygujące lub zapobiegawcze usunęły przyczynę źródłową i zapobiegły nawrotowi problemu. To podstawowy atrybut dashboardu „Weryfikacja skuteczności działań” i KPI „Odsetek zweryfikowanych skutecznych działań”. Pokazuje bezpośrednio, jak dobrze przebiega rozwiązywanie problemów. Wysoki odsetek nieskutecznych działań wskazuje na potrzebę poprawy analizy przyczyn źródłowych lub planowania działań.
Dlaczego to ważne
Bezpośrednio mierzy skuteczność rozwiązywania problemów i wskazuje, czy podjęte działania rzeczywiście zapobiegają ich nawrotom.
Skąd pobrać
Informacje te są często przechowywane w działaniach następczych lub statusach konkretnych zadań w zgłoszeniu jakościowym. Mogą znajdować się w polu niestandardowym lub wynikać z określonego kodu statusu.
Przykłady
SkuteczneNieskuteczneWymagane monitorowanie
|
|||
|
Status zgłoszenia
SystemStatus
|
Bieżący status obsługi zgłoszenia jakościowego, na przykład „Outstanding” lub „Completed”. | ||
|
Opis
Status systemowy wskazuje bieżący etap cyklu życia zdarzenia jakościowego. W SAP statusy takie jak OSNO (Outstanding Notification), NOPR (Notification in Process) i NOCO (Notification Completed) odzwierciedlają postęp obsługi. Ten atrybut często służy do ustalania działań w dzienniku zdarzeń. Przydaje się też do filtrowania spraw, na przykład w celu analizy tylko otwartych lub niedawno zamkniętych zdarzeń jakościowych. Zrozumienie zmian statusu jest niezbędne do zbudowania dokładnego modelu procesu.
Dlaczego to ważne
Wskazuje bieżący stan sprawy, umożliwia filtrowanie spraw aktywnych i zamkniętych oraz pomaga ustalić działania procesu.
Skąd pobrać
Dane pochodzą z tabel JEST i JSTO, w których przechowywane są informacje o statusach różnych obiektów SAP. Powiązanie prowadzi przez QMEL-OBJNR.
Przykłady
OSNO NOPRNOCOTSCO
|
|||
|
System źródłowy
SourceSystem
|
Wskazuje system, z którego pobrano dane, na przykład konkretną instancję SAP S/4HANA. | ||
|
Opis
Ten atrybut określa źródło danych dotyczących zarządzania jakością. W środowisku z wieloma systemami ERP lub systemami zintegrowanymi pozwala rozróżniać źródła danych i dbać o ich spójność. Umożliwia filtrowanie procesów lub porównywanie ich między systemami i jednostkami organizacyjnymi. Dla danego zbioru danych często ma stałą wartość, ale jest niezbędny do zarządzania danymi i właściwej interpretacji wyników.
Dlaczego to ważne
Informuje o pochodzeniu danych, co ma znaczenie dla zarządzania danymi, zwłaszcza w środowiskach z wieloma połączonymi systemami.
Skąd pobrać
Zwykle jest to stała wartość dodawana podczas pobierania danych, która identyfikuje klienta i identyfikator systemu SAP S/4HANA.
Przykłady
S4H_PROD_100SAP_QM_EUS4HANA_QAS_200
|
|||
|
Terminowa realizacja
IsOnTimeCompletion
|
Wartość logiczna wskazująca, czy zdarzenie jakościowe zakończono do wyznaczonego terminu. | ||
|
Opis
Ta obliczana flaga porównuje rzeczywisty znacznik czasu zakończenia zdarzenia jakościowego z jego „Docelową datą rozwiązania”. Ma wartość true, jeśli zdarzenie zamknięto w wyznaczonym terminie lub wcześniej, a w przeciwnym razie wartość false. Atrybut ten zapewnia prosty, bezpośredni pomiar do monitorowania wyników. Jest podstawą dashboardu „Terminowa realizacja zdarzeń jakościowych” oraz KPI „Odsetek działań jakościowych zrealizowanych w terminie”. Ułatwia filtrowanie i agregowanie danych, dzięki czemu można analizować terminowość według różnych wymiarów, takich jak dział, produkt czy typ zgłoszenia.
Dlaczego to ważne
Zapewnia jednoznaczny wynik do monitorowania realizacji terminów, ułatwiając pomiar i raportowanie zgodności z SLA.
Skąd pobrać
Atrybut obliczany przez porównanie znacznika czasu ostatniego działania zamykającego z atrybutem „TargetResolutionDate”.
Przykłady
truefalse
|
|||
|
Zakład
Plant
|
Zakład produkcyjny lub lokalizacja, w której wystąpiło zdarzenie jakościowe albo w której jest ono obsługiwane. | ||
|
Opis
Atrybut „Zakład” określa fizyczną lokalizację, na przykład fabrykę lub magazyn, powiązaną ze zdarzeniem jakościowym. Wskazuje kontekst geograficzny lub organizacyjny występowania problemów jakościowych. Umożliwia porównywanie wyników. Kierownictwo może filtrować lub grupować dane według zakładu, aby porównać wyniki różnych lokalizacji, wykryć problemy charakterystyczne dla danego zakładu i upowszechniać dobre praktyki z zakładów osiągających lepsze wyniki. Pozwala odpowiedzieć na pytania takie jak: „W którym zakładzie analiza przyczyny źródłowej trwa najdłużej?”.
Dlaczego to ważne
Umożliwia porównywanie wyników różnych lokalizacji operacyjnych, wykrywanie problemów charakterystycznych dla danego zakładu i wskazywanie dobrych praktyk.
Skąd pobrać
Zakład powiązany z nagłówkiem zgłoszenia znajduje się w QMEL-WERKS. Jeśli zgłoszenie dotyczy konkretnego materiału, informacja może być też dostępna na poziomie pozycji.
Przykłady
100017102000
|
|||
Działania w zarządzaniu jakością
| Działanie | Opis | ||
|---|---|---|---|
|
Działanie korygujące wdrożone
|
Oznacza zakończenie prac określonych w planie działań korygujących. Zdarzenie to jest zwykle rejestrowane, gdy zadanie dotyczące działania korygującego w zgłoszeniu jakościowym zostaje oznaczone jako zakończone. | ||
|
Dlaczego to ważne
To ważny etap, który potwierdza podjęcie działań w celu rozwiązania problemu jakościowego. Pozwala mierzyć odsetek działań zakończonych w terminie oraz ogólną sprawność etapu rozwiązywania problemu.
Skąd pobrać
Zdarzenie można wywnioskować z zakończenia zadania dotyczącego działania korygującego w tabeli QMSM. Data zakończenia jest zapisywana w polu ERLDT lub wynika ze zmiany statusu na „Completed” w tabelach JEST/JCDS.
Rejestrowanie
Ustal znacznik czasu zakończenia (ERLDT) zadania dotyczącego działania korygującego w tabeli QMSM.
Typ zdarzenia
inferred
|
|||
|
Podjęcie decyzji o wykorzystaniu
|
Oznacza formalną decyzję o jakości towarów z partii kontrolnej, na przykład o ich przyjęciu lub odrzuceniu. Jest to odrębne zdarzenie w przypadku problemów jakościowych wykrytych podczas kontroli. Rejestruje się je w chwili zapisania decyzji o wykorzystaniu. | ||
|
Dlaczego to ważne
W procesach opartych na kontroli jest to ważny etap, który wyznacza dalsze działania, takie jak blokada lub zwolnienie materiału. Analiza czasu podjęcia decyzji i jej wyniku pomaga ocenić efektywność kontroli jakości produktów.
Skąd pobrać
Jest to jawne zdarzenie rejestrowane w tabeli decyzji o wykorzystaniu QAVE. Czynność tę oznacza znacznik czasu utworzenia rekordu powiązanego z partią kontrolną (PRUEFLOS).
Rejestrowanie
Użyj znacznika czasu utworzenia dla odpowiedniej partii kontrolnej w tabeli QAVE.
Typ zdarzenia
explicit
|
|||
|
Skuteczność działania potwierdzona
|
Potwierdza, że wdrożone działanie korygujące lub zapobiegawcze przyniosło oczekiwany rezultat, a problem jakościowy został rozwiązany i nie powrócił. Zdarzenie jest rejestrowane po zakończeniu zadania weryfikującego skuteczność lub końcowym przeglądzie jakości. | ||
|
Dlaczego to ważne
To ważny etap potwierdzający skuteczność całego procesu rozwiązywania problemu. Wysoki odsetek pomyślnych weryfikacji świadczy o sprawnym zarządzaniu jakością i pomaga ograniczyć nawroty problemów.
Skąd pobrać
Zdarzenie zwykle można wywnioskować z zakończenia zadania „Effectiveness Check” w tabeli QMSM, korzystając z daty zakończenia ERLDT.
Rejestrowanie
Ustal znacznik czasu zakończenia zadania weryfikującego skuteczność w tabeli QMSM.
Typ zdarzenia
inferred
|
|||
|
Utworzenie zgłoszenia jakościowego
|
Ta czynność rozpoczyna proces zarządzania jakością. Problem, wada lub reklamacja związana z jakością zostaje formalnie zarejestrowana. Utworzenie zgłoszenia jakościowego w SAP S/4HANA zapisuje wstępne informacje, przypisuje unikalny identyfikator i rozpoczyna obsługę sprawy. | ||
|
Dlaczego to ważne
Jako główne zdarzenie początkowe ta czynność jest niezbędna do pomiaru czasu realizacji procesu rozwiązywania problemów jakościowych od początku do końca. Stanowi punkt odniesienia przy pomiarze czasu potrzebnego na obsługę i zamknięcie zdarzeń jakościowych.
Skąd pobrać
Jest to jawne zdarzenie rejestrowane w tabeli nagłówków zgłoszeń jakościowych QMEL. Znacznik czasu utworzenia znajduje się zwykle w polu ERDAT dla danego numeru zgłoszenia QMNUM.
Rejestrowanie
Użyj znacznika czasu utworzenia (ERDAT) z tabeli QMEL dla danego zgłoszenia.
Typ zdarzenia
explicit
|
|||
|
Zakończenie analizy przyczyn źródłowych
|
Oznacza zakończenie etapu dochodzenia, podczas którego ustalono przyczynę źródłową problemu jakościowego. Zdarzenie to jest zwykle wywnioskowane z zakończenia zadania „Root Cause Analysis” w ramach zgłoszenia. | ||
|
Dlaczego to ważne
To ważny etap przy pomiarze czasu i efektywności dochodzenia. Wykrycie opóźnień przed tym etapem pomaga wskazać wąskie gardła w analizie problemu i podejmowaniu decyzji.
Skąd pobrać
Zdarzenie wywnioskowane z zakończenia zadania dochodzeniowego lub zadania dotyczącego analizy przyczyn źródłowych w tabeli QMSM. Zakończenie można rozpoznać po zmianie statusu lub wypełnieniu pola daty zakończenia zadania (ERLDT).
Rejestrowanie
Ustal znacznik czasu zakończenia (ERLDT) odpowiedniego zadania analizy przyczyn źródłowych w tabeli QMSM.
Typ zdarzenia
inferred
|
|||
|
Zgłoszenie zakończone
|
Oznacza biznesowe zakończenie obsługi zgłoszenia jakościowego. Potwierdza, że wykonano wymagane działania i problem został rozwiązany z punktu widzenia operacyjnego. W systemie odpowiada temu formalna zmiana statusu. | ||
|
Dlaczego to ważne
To główny punkt końcowy przy pomiarze czasu rozwiązania problemu. Potwierdza, że z perspektywy właściciela procesu sprawa jest zakończona, nawet jeśli zamknięcie techniczne jeszcze nie nastąpiło.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu obiektu zgłoszenia jakościowego. Ustal znacznik czasu ustawienia statusu takiego jak „NOCO” (Notification completed) w tabeli JCDS.
Rejestrowanie
Ustal znacznik czasu ustawienia statusu „Notification completed” w tabeli JCDS.
Typ zdarzenia
inferred
|
|||
|
Działanie zapobiegawcze wdrożone
|
Oznacza pomyślną realizację zaplanowanego działania zapobiegawczego. Zdarzenie jest rejestrowane po odnotowaniu zakończenia odpowiedniego zadania w systemie. | ||
|
Dlaczego to ważne
Zakończenie działań zapobiegawczych to ważny etap dojrzałego zarządzania jakością. Śledzenie tego zdarzenia pomaga ocenić, czy organizacja zapobiega przyszłym problemom i ogranicza ich nawroty.
Skąd pobrać
Zdarzenie można wywnioskować z zakończenia zadania dotyczącego działania zapobiegawczego w tabeli QMSM. Wskazuje na nie pole ERLDT lub zmiana statusu na „Completed”.
Rejestrowanie
Ustal znacznik czasu zakończenia (ERLDT) zadania dotyczącego działania zapobiegawczego w tabeli QMSM.
Typ zdarzenia
inferred
|
|||
|
Działanie zapobiegawcze zaproponowane
|
To działanie ma miejsce, gdy powstaje plan zapobiegania ponownemu wystąpieniu problemu jakościowego. Podobnie jak działania korygujące, często jest rejestrowane przez utworzenie zadania typu „Preventive Action”. | ||
|
Dlaczego to ważne
To zdarzenie pozwala ocenić, czy organizacja koncentruje się na proaktywnym doskonaleniu jakości, a nie tylko na reagowaniu na problemy. Oznacza początek długofalowych działań naprawczych.
Skąd pobrać
Zdarzenie jest rejestrowane po utworzeniu zadania z kodem „Preventive Action” w tabeli QMSM dla danego zgłoszenia jakościowego.
Rejestrowanie
Dla zadań dotyczących działań zapobiegawczych użyj znacznika czasu utworzenia (ERDAT) z tabeli QMSM.
Typ zdarzenia
explicit
|
|||
|
Powiadomiono interesariuszy
|
Oznacza przekazanie informacji o rozwiązaniu problemu odpowiednim osobom, na przykład klientom lub działom wewnętrznym. Rzadko jest to zdarzenie rejestrowane automatycznie, często wymaga ręcznego wykonania. | ||
|
Dlaczego to ważne
Terminowe informowanie interesariuszy wpływa na zadowolenie klientów i przejrzystość działań. Pomiar czasu od zamknięcia sprawy do wysłania powiadomienia pomaga wykryć luki w komunikacji.
Skąd pobrać
Tego działania trudno szukać bezpośrednio w SAP. Można je wywnioskować z zakończenia ręcznego zadania „Notify Stakeholder” w QMSM albo przeanalizować dane z systemów zewnętrznych, na przykład dzienniki poczty e-mail.
Rejestrowanie
Ustal, czy zakończono ręczne zadanie komunikacyjne, jeśli jest używane. W przeciwnym razie informacja ta zwykle nie jest dostępna.
Typ zdarzenia
inferred
|
|||
|
Przydzielenie zadania dochodzeniowego
|
To zdarzenie występuje, gdy konkretne zadanie, na przykład analiza przyczyny źródłowej, zostaje formalnie utworzone i przydzielone osobie lub działowi. Jest rejestrowane w momencie utworzenia zadania w ramach zgłoszenia jakościowego. | ||
|
Dlaczego to ważne
Śledzenie przydziału zadań pomaga zrozumieć rozkład obciążenia i wykryć wąskie gardła w przydziale zasobów. Oznacza początek etapu dochodzenia i stanowi ważną informację przy pomiarze czasu analizy przyczyn źródłowych.
Skąd pobrać
Dane pochodzą z tabeli zarządzania zadaniami QMSM powiązanej ze zgłoszeniem jakościowym. Datą tego zdarzenia jest data utworzenia (ERDAT) zadania z odpowiednim kodem, na przykład zadania dochodzeniowego.
Rejestrowanie
Użyj znacznika czasu utworzenia (ERDAT) z tabeli QMSM dla zadań związanych z dochodzeniem.
Typ zdarzenia
explicit
|
|||
|
Rozpoczęcie obsługi zgłoszenia
|
Oznacza moment, w którym zespół ds. jakości rozpoczyna pracę nad nowo utworzonym zgłoszeniem. Zdarzenie to jest zwykle wywnioskowane ze zmiany statusu systemowego wskazującej na rozpoczęcie pracy. | ||
|
Dlaczego to ważne
Ta czynność pozwala odróżnić samo zarejestrowanie problemu od faktycznego rozpoczęcia pracy nad nim. Analiza czasu między utworzeniem zgłoszenia a tym etapem ujawnia możliwe opóźnienia w przyjęciu sprawy i przydzieleniu zasobów.
Skąd pobrać
Zdarzenie wywnioskowane ze zmiany statusu obiektu zgłoszenia jakościowego. Można je śledzić, analizując dzienniki zmian statusu w tabelach JEST i JCDS, na przykład dla statusu „NOPO” (zgłoszenie w trakcie obsługi).
Rejestrowanie
Ustal znacznik czasu ustawienia statusu „w trakcie obsługi” dla zgłoszenia w tabeli JCDS.
Typ zdarzenia
inferred
|
|||
|
Wymagana weryfikacja skuteczności
|
Oznacza konieczność przeprowadzenia weryfikacji, która potwierdzi, że wdrożone działania rozwiązały problem. Może to być określony status zgłoszenia lub utworzenie osobnego zadania weryfikacyjnego. | ||
|
Dlaczego to ważne
Dzięki temu proces zarządzania jakością obejmuje ważny etap sprawdzenia rezultatów. Pozwala odróżnić wdrożenie działania od potwierdzenia jego skuteczności.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu zgłoszenia jakościowego (w tabelach JEST/JCDS) lub z utworzenia zadania „Effectiveness Check” w tabeli QMSM.
Rejestrowanie
Ustal znacznik czasu zmiany statusu lub utworzenia zadania weryfikacyjnego w tabeli QMSM.
Typ zdarzenia
inferred
|
|||
|
Zaproponowanie działania korygującego
|
Ta czynność oznacza moment formalnego udokumentowania planu rozwiązania wykrytego problemu. W SAP jest to często rejestrowane przez utworzenie zadania „Corrective Action” w ramach zgłoszenia jakościowego. | ||
|
Dlaczego to ważne
To zdarzenie rozpoczyna etap rozwiązywania problemu. Pomiar czasu od analizy przyczyn źródłowych do tego etapu może ujawnić opóźnienia w planowaniu działań.
Skąd pobrać
Zdarzenie jest rejestrowane, gdy w tabeli QMSM zostaje utworzone zadanie z kodem „Corrective Action” dla danego zgłoszenia jakościowego.
Rejestrowanie
Użyj znacznika czasu utworzenia (ERDAT) z tabeli QMSM dla zadań dotyczących działań korygujących.
Typ zdarzenia
explicit
|
|||
|
Zatwierdzenie planu działań
|
Oznacza, że proponowany plan działań korygujących lub zapobiegawczych został sprawdzony i zatwierdzony do wdrożenia. Ten krok często nie jest rejestrowany jako osobne zdarzenie. Można go wywnioskować ze zwolnienia zadania do realizacji. | ||
|
Dlaczego to ważne
Długie oczekiwanie na tym etapie zatwierdzania może znacznie wydłużyć cały proces rozwiązywania problemu. Analiza tego czasu pomaga wykryć opóźnienia administracyjne i wskazać, gdzie można usprawnić nadzór.
Skąd pobrać
Zdarzenie to zwykle można wywnioskować ze zmiany statusu zadania w tabeli QMSM, na przykład na „Released”. Znacznik czasu tej zmiany znajduje się w tabeli JCDS, powiązanej z obiektem zadania.
Rejestrowanie
Ustal znacznik czasu ustawienia statusu „Released” dla zadania dotyczącego działań korygujących lub zapobiegawczych.
Typ zdarzenia
inferred
|
|||
|
Zgłoszenie zamknięte
|
Oznacza ostateczne, techniczne zamknięcie zgłoszenia jakościowego w systemie. Po tym etapie nie można już wprowadzać zmian w zgłoszeniu, a jego cykl życia dobiega końca. | ||
|
Dlaczego to ważne
To końcowe zdarzenie procesu. Analiza czasu między „Notification Completed” a „Notification Closed” może ujawnić opóźnienia w administracyjnym zamykaniu zgłoszeń.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu zgłoszenia jakościowego, zwłaszcza po ustawieniu statusu archiwizacji lub ostatecznego zamknięcia. Zmiana jest rejestrowana wraz ze znacznikiem czasu w tabeli JCDS.
Rejestrowanie
Ustal znacznik czasu ustawienia końcowego statusu „Closed” dla zgłoszenia w tabeli JCDS.
Typ zdarzenia
inferred
|
|||
Przewodniki po ekstrakcji danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby szybko przygotować dane i rozpocząć usprawnianie procesów zarządzania jakością. Poznaj dane i zwiększ wydajność w SAP S/4HANA.
Usprawnij zarządzanie jakością: skróć czas cyklu o 30%
Wykryj wąskie gardła w SAP S/4HANA i skróć czas cyklu QM o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.