Szablon danych dla procesu Purchase to Pay: zapotrzebowanie

SAP S/4HANA
Szablon danych dla procesu Purchase to Pay: zapotrzebowanie

Szablon danych dla procesu Purchase to Pay: zapotrzebowanie

Ten szablon zawiera wskazówki dotyczące zbierania danych potrzebnych do analizy procesu Purchase to Pay: zapotrzebowanie. Opisuje atrybuty i działania, które warto śledzić, oraz praktyczne sposoby ekstrakcji danych z SAP S/4HANA. Skorzystaj z niego, aby przygotować dziennik zdarzeń do analizy process mining.
  • Zalecane atrybuty do szczegółowej analizy
  • Działania, które warto śledzić podczas odkrywania procesu
  • Wskazówki dotyczące ekstrakcji danych z SAP S/4HANA
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu Purchase to Pay: zapotrzebowanie

Poniżej przedstawiono zalecane pola danych do uwzględnienia w dzienniku zdarzeń na potrzeby analizy procesu Purchase to Pay: zapotrzebowanie.
3 Wymagane 6 Zalecane 11 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładna data i godzina wystąpienia danego działania.
Opis

Czas zdarzenia to znacznik czasu wskazujący, kiedy miało miejsce dane działanie. Jest niezbędny do chronologicznego uporządkowania zdarzeń w ramach sprawy i stanowi podstawę obliczania czasu trwania oraz wyników w process mining. Na przykład różnica między zdarzeniami „Przekazano zapotrzebowanie do akceptacji” i „Zaakceptowano zapotrzebowanie” określa czas akceptacji.

Dokładne znaczniki czasu są niezbędne do analizy wyników procesu, wykrywania opóźnień i monitorowania dotrzymywania uzgodnionych poziomów usług. Ten atrybut umożliwia tworzenie dashboardów, które pokazują czas realizacji, wskazują zapotrzebowania oczekujące na obsługę i porównują wyniki w różnych okresach.

Dlaczego to ważne

Znacznik czasu pozwala uporządkować zdarzenia, obliczać czas realizacji oraz analizować wyniki procesu i wąskie gardła.

Skąd pobrać

Znaczniki czasu pochodzą zwykle z nagłówków dokumentów zmian (CDHDR-UDATE, CDHDR-UTIME) lub dzienników zdarzeń workflow.

Przykłady
2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z
Identyfikator zapotrzebowania zakupowego
PurchaseRequisitionId
Unikalny identyfikator dokumentu zapotrzebowania zakupowego.
Opis

Identyfikator zapotrzebowania zakupowego to klucz główny, który jednoznacznie wskazuje każde zapotrzebowanie na towary lub usługi w SAP S/4HANA. Jest centralnym identyfikatorem sprawy, który łączy wszystkie działania i zmiany dotyczące danego zapotrzebowania, od jego utworzenia po stan końcowy, taki jak akceptacja, odrzucenie lub przekształcenie w zamówienie zakupu.

W process mining ten atrybut jest niezbędny do odtworzenia pełnego cyklu życia każdego zapotrzebowania. Grupowanie powiązanych zdarzeń pod jednym identyfikatorem pozwala dokładnie mierzyć czas realizacji, śledzić zmiany statusu i analizować różne ścieżki procesu akceptacji.

Dlaczego to ważne

To podstawowy identyfikator sprawy, który łączy wszystkie powiązane etapy procesu i pozwala uzyskać pełny, spójny obraz cyklu życia zapotrzebowania.

Skąd pobrać

To numer zapotrzebowania zakupowego z pola BANFN w tabeli EBAN.

Przykłady
100178901001789110017892
Nazwa działania
ActivityName
Nazwa działania biznesowego, które miało miejsce na danym etapie procesu obsługi zapotrzebowania.
Opis

Nazwa działania opisuje konkretne zdarzenie lub zadanie w cyklu życia zapotrzebowania zakupowego. Działania są wyznaczane na podstawie dzienników systemowych, takich jak dokumenty zmian i historia workflow. Obejmują ważne etapy procesu, na przykład „Utworzono zapotrzebowanie”, „Rozpoczęto etap akceptacji” lub „Utworzono zamówienie zakupu”.

Analiza działań pozwala zobrazować przebieg procesu, wskazać wąskie gardła i zmierzyć czas spędzony na poszczególnych etapach. Znajomość kolejności i częstotliwości działań, takich jak „Zmieniono zapotrzebowanie” lub „Odrzucono zapotrzebowanie”, pomaga wykrywać nieefektywne etapy i obszary wymagające usprawnienia.

Dlaczego to ważne

Określa etapy procesu i stanowi podstawę mapy procesu. Umożliwia analizę przebiegu, wariantów i wąskich gardeł.

Skąd pobrać

To atrybut pochodny, zwykle tworzony na podstawie interpretacji danych z tabel dokumentów zmian (CDHDR, CDPOS) i dzienników workflow (np. SWWLOGHIST).

Przykłady
Utworzono zapotrzebowanieZakończono etap akceptacjiZaakceptowano zapotrzebowanieUtworzono zamówienie zakupu
Dział
Department
Dział lub centrum kosztów, na które przypisywane są koszty zapotrzebowania.
Opis

Atrybut działu, często reprezentowany w SAP przez centrum kosztów, wskazuje jednostkę biznesową odpowiedzialną za zakup. To ważna informacja finansowa i organizacyjna przypisywana na poziomie pozycji zapotrzebowania.

W process mining atrybut ten jest niezbędny do analizy wyników poszczególnych działów. Umożliwia tworzenie dashboardów porównujących takie wskaźniki jak czas realizacji, częstotliwość zmian i odsetek odrzuceń. Dzięki temu można wskazać działy osiągające dobre wyniki, których praktyki warto wdrożyć w innych jednostkach, oraz te, które potrzebują dodatkowych szkoleń lub wsparcia w obsłudze procesu.

Dlaczego to ważne

Umożliwia porównanie wyników jednostek biznesowych. Różnice w czasie realizacji lub odsetku odrzuceń pomagają wskazać dobre praktyki i obszary wymagające usprawnienia.

Skąd pobrać

To centrum kosztów, zwykle zapisane w polu KOSTL tabeli przypisań kont EBKN.

Przykłady
FIN-1001IT-2005MKT-3010
Identyfikator osoby akceptującej
ApproverId
Identyfikator użytkownika, który zaakceptował lub odrzucił zapotrzebowanie na danym etapie.
Opis

Identyfikator osoby akceptującej wskazuje użytkownika, który zaakceptował lub odrzucił zapotrzebowanie. W odróżnieniu od ogólnego identyfikatora użytkownika dotyczy wyłącznie osób podejmujących decyzje w workflow akceptacji. Rejestrowanie tych informacji jest niezbędne do szczegółowej analizy procesu akceptacji.

Atrybut ten pozwala analizować sposób podejmowania decyzji, na przykład wskazać kierowników, którzy długo akceptują zapotrzebowania lub często je odrzucają. Jest podstawą dashboardów pokazujących czas poszczególnych etapów akceptacji i wąskie gardła workflow. Pomaga ustalić, które osoby lub role powodują opóźnienia.

Dlaczego to ważne

Wskazuje osobę podejmującą decyzję na danym etapie akceptacji. Umożliwia szczegółową analizę czasu akceptacji i wąskich gardeł według osoby lub roli.

Skąd pobrać

Informacje te są zwykle pobierane z tabel SAP Business Workflow, takich jak SWW_WI2OBJ i SWWLOGHIST, które łączą elementy pracy z użytkownikiem kończącym zadanie.

Przykłady
MJOHNSONCWILLIAMSLBLACK
Identyfikator użytkownika
UserId
Identyfikator użytkownika, który utworzył zapotrzebowanie lub wykonał określone działanie.
Opis

Identyfikator użytkownika wskazuje pracownika lub użytkownika systemu odpowiedzialnego za dane zdarzenie w cyklu życia zapotrzebowania. Może to być osoba, która utworzyła zapotrzebowanie, kierownik, który je zaakceptował, lub pracownik, który je zmienił. W przypadku kroków zautomatyzowanych może to być identyfikator użytkownika systemowego lub wsadowego.

Analiza według identyfikatora użytkownika pomaga zrozumieć sposób pracy poszczególnych osób, rozkład obciążenia i zgodność z procedurami. Ułatwia wskazanie potrzeb szkoleniowych, rozpoznanie osób osiągających dobre wyniki i ustalenie odpowiedzialności w procesie. W połączeniu z danymi podstawowymi użytkowników wspiera też analizę wyników poszczególnych działów.

Dlaczego to ważne

Umożliwia analizę wyników pracy użytkowników, rozkładu obciążenia i zgodności z procedurami. Pomaga wskazać potrzeby szkoleniowe i wąskie gardła związane z zasobami.

Skąd pobrać

Identyfikator twórcy znajduje się w polu EBAN-ERNAM. W przypadku późniejszych zmian jest zapisany w CDHDR-USERNAME, a w przypadku akceptacji w dziennikach workflow.

Przykłady
JSMITHRROEWF-BATCH
Status zapotrzebowania
RequisitionStatus
Bieżący status przetwarzania lub akceptacji zapotrzebowania zakupowego.
Opis

Status zapotrzebowania wskazuje jego bieżący etap cyklu życia. W SAP często określa go wskaźnik zwalniania, który informuje, czy zapotrzebowanie jest zablokowane, w trakcie akceptacji, częściowo zaakceptowane czy w pełni zaakceptowane. Status zmienia się w miarę przechodzenia zapotrzebowania przez workflow.

Śledzenie statusu w czasie pozwala zrozumieć przebieg procesu i ustalić, gdzie oraz jak długo zapotrzebowania oczekują na obsługę. Analiza przejść między statusami pokazuje szczegółowo przebieg akceptacji i jego warianty.

Dlaczego to ważne

Wskazuje bieżący stan zapotrzebowania. Pozwala śledzić postęp, wykrywać wąskie gardła i analizować przebieg procesu.

Skąd pobrać

Status zwalniania jest często określany przez wskaźnik zwalniania, zapisany w polu FRGZU tabeli EBAN.

Przykłady
B1S
Typ zapotrzebowania
RequisitionType
Kod klasyfikujący zapotrzebowanie zakupowe, na przykład jako zapotrzebowanie na standardowe materiały, usługi lub wydatki inwestycyjne.
Opis

Typ zapotrzebowania, nazywany w SAP również typem dokumentu, to pole konfiguracyjne służące do klasyfikowania zapotrzebowań zakupowych. Różne typy mogą uruchamiać inne workflow akceptacji, mieć odrębne ustawienia pól i odpowiadać różnym celom biznesowym, takim jak zakup standardowych materiałów magazynowych, usług zewnętrznych lub środków trwałych.

Analiza procesu według typu zapotrzebowania pozwala sprawdzić, jak obsługiwane są różne rodzaje wniosków. Umożliwia porównanie wyników, czasu realizacji i ścieżek akceptacji między kategoriami. Dzięki temu można ustalić, które typy zapotrzebowań są obsługiwane mniej sprawnie i gdzie warto wprowadzić usprawnienia.

Dlaczego to ważne

Klasyfikuje zapotrzebowania i umożliwia ich porównywanie. Pomaga sprawdzić, czy różne typy wniosków mają odmienne przebiegi procesu, wąskie gardła lub czas realizacji.

Skąd pobrać

To pole typu dokumentu BSART w tabeli EBAN.

Przykłady
NBFORV
Wartość zapotrzebowania
RequisitionAmount
Łączna wartość pieniężna zapotrzebowania zakupowego.
Opis

Wartość zapotrzebowania oznacza łączny szacowany koszt zamawianych towarów lub usług. Często wpływa na złożoność i długość workflow akceptacji. Zapotrzebowania o wyższej wartości zwykle wymagają akceptacji na większej liczbie poziomów.

Analiza tego atrybutu pozwala podzielić proces według wartości. Ułatwia odpowiedź na pytania, takie jak: „Czy akceptacja zapotrzebowań o wysokiej wartości trwa dłużej?” lub „Jaka jest wartość zapotrzebowań często odrzucanych?”. To ważny wymiar analizy finansowego wpływu nieefektywności procesu.

Dlaczego to ważne

Pozwala podzielić proces według wpływu finansowego. Wartość często wiąże się ze złożonością akceptacji i czasem realizacji, dlatego jest ważnym wymiarem analizy procesu.

Skąd pobrać

Łączna wartość znajduje się w polu GFWERT tabeli EBAN. Wartość pozycji jest zapisana w polu EBAN-PREIS.

Przykłady
1500.0075000.50250.75
Czas zakończenia
EndTime
Dokładna data i godzina zakończenia danego działania.
Opis

EndTime to znacznik czasu określający, kiedy zakończyło się działanie. Wiele zdarzeń generowanych przez system jest natychmiastowych, więc StartTime i EndTime mają tę samą wartość. Zadania wykonywane przez ludzi, takie jak zatwierdzanie, mogą mieć różne godziny rozpoczęcia i zakończenia. EndTime wskazuje moment zakończenia pracy.

Oddzielny EndTime pozwala dokładniej mierzyć czas aktywnej pracy i czas oczekiwania. W połączeniu ze StartTime służy do obliczania miary ProcessingTime. Taka szczegółowość ułatwia analizę wykorzystania zasobów i efektywności zadań wykonywanych ręcznie.

Dlaczego to ważne

Oznacza moment zakończenia działania. Pozwala obliczyć czas aktywnej pracy i dokładniej określić czas trwania zadania.

Skąd pobrać

Wartość pochodzi z dzienników workflow, które mogą rejestrować zarówno utworzenie elementu pracy (StartTime), jak i jego zakończenie (EndTime).

Przykłady
2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z
Czy ponowne przetwarzanie
IsRework
Flaga wskazująca, czy działanie oznacza ponowne przetwarzanie, na przykład zmianę zapotrzebowania po jego przesłaniu.
Opis

Is Rework to obliczana flaga logiczna, która wskazuje działania oznaczające pracę bez wartości dodanej lub powtarzanie czynności. Typowym przykładem w tym procesie jest zdarzenie „Zmieniono zapotrzebowanie” po przesłaniu go do zatwierdzenia. W takiej sytuacji proces zatwierdzania trzeba rozpocząć ponownie.

Atrybut ten pozwala zmierzyć skalę ponownego przetwarzania i jego wpływ na całkowity czas realizacji. Dashboard Requisition Amendment and Rework Rate wykorzystuje tę flagę do wskazywania nieefektywności procesu. Ograniczenie ponownego przetwarzania często jest jednym z głównych celów inicjatyw usprawniających procesy, ponieważ pozwala bezpośrednio zaoszczędzić czas i nakład pracy.

Dlaczego to ważne

Oznacza działania będące stratą czasu lub powtarzaniem pracy. Pozwala bezpośrednio mierzyć skalę ponownego przetwarzania i jego wpływ na efektywność procesu.

Skąd pobrać

Jest to atrybut obliczany. Zwykle oznacza jako ponowne przetwarzanie każde zdarzenie „Zmieniono zapotrzebowanie”, które wystąpiło po pierwszym zdarzeniu „Przesłano zapotrzebowanie do zatwierdzenia”.

Przykłady
truefalse
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych z systemu źródłowego. To ważna metadana, która informuje o aktualności analizowanych danych. Analitycy i użytkownicy biznesowi mogą sprawdzić, czy dane o procesie odzwierciedlają bieżący stan operacji.

Przy analizie procesu aktualność danych ma podstawowe znaczenie dla podejmowania świadomych decyzji. Atrybut ten pomaga ustalić, jak aktualnych danych można oczekiwać, i upewnić się, że wnioski opierają się na danych wystarczająco aktualnych dla danej analizy.

Dlaczego to ważne

Informuje o aktualności danych, co pozwala ocenić wiarygodność analizy i podejmować decyzje biznesowe we właściwym czasie.

Skąd pobrać

Znacznik czasu jest generowany i dodawany podczas procesu ekstrakcji, transformacji i ładowania danych (ETL).

Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Nazwa etapu zatwierdzania
ApprovalStepName
Nazwa lub opis konkretnego etapu zatwierdzania w workflow.
Opis

Nazwa etapu zatwierdzania to czytelny dla użytkownika opis konkretnego etapu workflow, na przykład „Zatwierdzenie przez kierownika” lub „Zatwierdzenie przez wiceprezesa ds. finansów”. Jest bardziej szczegółowa niż ogólne zdarzenie „Zakończono etap zatwierdzania”.

Atrybut ten jest niezbędny w dashboardach Approval Step Cycle Time i Workflow Bottleneck Analysis. Pozwala szczegółowo przeanalizować proces zatwierdzania, wskazać etapy powodujące największe opóźnienia i ustalić, gdzie gromadzą się zadania. Taki poziom szczegółowości ułatwia podjęcie działań w konkretnych miejscach i usprawnienie ścieżki zatwierdzania.

Dlaczego to ważne

Dostarcza szczegółowych informacji o etapach zatwierdzania, dzięki czemu można precyzyjnie wskazać wąskie gardła w wielopoziomowym workflow zatwierdzania.

Skąd pobrać

Informacja pochodzi z opisu zadania workflow. Można go znaleźć, łącząc dziennik workflow z tabelami definicji zadań, takimi jak T528T.

Przykłady
Zatwierdzenie przez kierownikaZatwierdzenie przez dyrektoraZatwierdzenie przez wiceprezesa ds. finansów
Numer zamówienia zakupu
PurchaseOrderNumber
Numer zamówienia zakupu utworzonego na podstawie zapotrzebowania.
Opis

Numer zamówienia zakupu identyfikuje oficjalny dokument zakupowy utworzony na podstawie zaakceptowanego zapotrzebowania. Utworzenie zamówienia zakupu jest często pomyślnym zakończeniem obsługi zapotrzebowania. Oznacza, że wniosek przekształcono w formalne zamówienie u dostawcy.

Ten atrybut jest niezbędny do pomiaru KPI czasu od zapotrzebowania do zamówienia zakupu oraz ogólnego współczynnika konwersji. Łączy proces zgłaszania zapotrzebowania z dalszym procesem zakupowym, umożliwiając analizę całego cyklu Purchase-to-Pay.

Dlaczego to ważne

Łączy zapotrzebowanie z kolejnym dokumentem zakupowym i umożliwia pomiar współczynnika konwersji oraz czasu od zapotrzebowania do zamówienia zakupu.

Skąd pobrać

Po utworzeniu zamówienia zakupu na podstawie pozycji zapotrzebowania jego numer znajduje się w polu EBELN tabeli EBAN.

Przykłady
450001789045000178914500017892
Poziom pilności
UrgencyLevel
Klasyfikacja pilności zapotrzebowania, która może wpływać na priorytet jego obsługi.
Opis

Poziom pilności określa priorytet zapotrzebowania na zakup. Nie ma do tego standardowego, dedykowanego pola, ale niektóre organizacje wykorzystują na przykład numer śledzenia zapotrzebowania. Dzięki temu wnioskodawcy mogą oznaczać pilne potrzeby wymagające szybszej obsługi.

Analiza wpływu pilności pozwala ocenić, czy proces rzeczywiście nadaje priorytet krytycznym zapotrzebowaniom. Dashboard Urgency Level Impact Analysis wykorzystuje ten atrybut do porównania czasu realizacji i wskaźników zatwierdzeń dla zapotrzebowań pilnych i standardowych. Ułatwia to sprawdzenie, czy obsługa priorytetowa działa zgodnie z założeniami.

Dlaczego to ważne

Pozwala analizować różnice w wynikach procesu dla zapotrzebowań o wysokim priorytecie i sprawdzić, czy pilne sprawy są rzeczywiście obsługiwane szybciej.

Skąd pobrać

Nie ma standardowego pola określającego pilność. Niektóre firmy wykorzystują w tym celu numer śledzenia zapotrzebowania (EBAN-BEDAR). Informacja może też znajdować się w polu niestandardowym.

Przykłady
WysokiŚredniNiski
Przyczyna odrzucenia
RejectionReason
Powód podany przy odrzuceniu zapotrzebowania zakupowego.
Opis

Przyczyna odrzucenia wyjaśnia, dlaczego osoba akceptująca odrzuciła zapotrzebowanie zakupowe. Powodem może być przekroczenie budżetu, nieprawidłowe informacje, niezgodność z zasadami lub powielenie innego wniosku. Informacja ta pomaga zrozumieć, dlaczego proces się nie powiódł.

Analiza przyczyn odrzuceń pozwala ustalić źródła nieefektywności i poprawek. Jeśli na przykład częstym powodem jest „Nieprawidłowe centrum kosztów”, może to wskazywać na potrzebę lepszego przeszkolenia użytkowników lub walidacji w systemie. Atrybut ten stanowi podstawę dashboardu analizy odrzuceń zapotrzebowań i pomaga precyzyjnie zaplanować usprawnienia procesu.

Dlaczego to ważne

Wskazuje przyczyny niepowodzeń procesu i pozwala ograniczyć poprawki oraz zwiększyć odsetek zapotrzebowań poprawnych za pierwszym razem.

Skąd pobrać

Często nie jest to standardowe pole. Informacja może być zapisana w elementach kontenera workflow, długim opisie zapotrzebowania lub polach niestandardowych.

Przykłady
Przekroczono budżetNieprawidłowy dostawcaPowielony wniosek
System źródłowy
SourceSystem
Wskazuje konkretną instancję SAP S/4HANA, z której wyodrębniono dane.
Opis

Atrybut systemu źródłowego wskazuje system, w którym powstały dane o procesie. W organizacjach korzystających z wielu instancji SAP, na przykład osobnych systemów do rozwoju, zapewniania jakości i produkcji albo systemów dla różnych regionów, pole to zapewnia niezbędny kontekst i wspiera zarządzanie danymi.

Pozwala odróżniać dane z różnych źródeł, zapobiega błędnemu łączeniu ich w zestawieniach i umożliwia analizę poszczególnych systemów. Jest wymagany do zachowania pochodzenia danych i możliwości ich śledzenia.

Dlaczego to ważne

Dostarcza informacji o pochodzeniu danych i wspiera zarządzanie nimi. Ma to szczególne znaczenie w środowiskach z wieloma systemami, gdzie trzeba zapewnić możliwość śledzenia danych.

Skąd pobrać

Zwykle jest to identyfikator systemu SAP (SID), który można pobrać ze zmiennych systemowych lub tabel konfiguracyjnych.

Przykłady
S4PECCS4H_PROD_01
Waluta
Currency
Kod waluty, w której podano wartość zapotrzebowania.
Opis

Ten atrybut określa walutę, w której wyrażono wartość zapotrzebowania, na przykład USD, EUR lub JPY. Dostarcza kontekstu niezbędnego do interpretacji wartości, szczególnie w międzynarodowych organizacjach korzystających z wielu walut.

Dokładna analiza finansowa i raportowanie wymagają uwzględnienia waluty. Przed zsumowaniem lub porównaniem wartości zapotrzebowań należy przeliczyć je na wspólną walutę. Ten atrybut jest niezbędny do wykonania takiego przeliczenia.

Dlaczego to ważne

Uzupełnia informację o wartości zapotrzebowania i umożliwia dokładną analizę finansową oraz porównania w środowiskach wielowalutowych.

Skąd pobrać

To pole WAERS w tabeli EBAN.

Przykłady
USDEURGBP
Wykonane automatycznie
IsAutomated
Wskaźnik informujący, czy działanie wykonał użytkownik systemowy, a nie człowiek.
Opis

Atrybut Is Automated to flaga logiczna, która przyjmuje wartość true, jeśli działanie wykonał użytkownik systemowy lub użytkownik wsadowy, na przykład „WF-BATCH” w przypadku działań workflow. Pozwala odróżnić kroki wykonywane ręcznie od tych realizowanych automatycznie.

Atrybut ten jest niezbędny do pomiaru poziomu automatyzacji procesu obsługi zapotrzebowań oraz obliczania KPI „Automated Approval Rate”. Analitycy mogą filtrować kroki ręczne i automatyczne, porównywać ich efektywność oraz wskazywać możliwości dalszej automatyzacji, która ograniczy czas przetwarzania i nakład pracy ręcznej.

Dlaczego to ważne

Pozwala odróżnić działania wykonywane przez ludzi od działań systemowych. Jest to potrzebne do pomiaru poziomu automatyzacji i wskazywania zadań ręcznych, które można zautomatyzować.

Skąd pobrać

Jest to atrybut pochodny, zwykle wyznaczany na podstawie reguły sprawdzającej, czy identyfikator użytkownika przypisany do zdarzenia znajduje się na liście znanych użytkowników systemowych lub wsadowych.

Przykłady
truefalse
Wymagana data dostawy
RequiredByDate
Data, do której wnioskodawca potrzebuje zamówionych towarów lub usług.
Opis

Wymagana data dostawy, nazywana w SAP datą dostawy, określa, kiedy potrzebne są towary lub usługi z danej pozycji zapotrzebowania. Ustala ją wnioskodawca i stanowi ona termin docelowy dla całego procesu zakupowego.

Ten atrybut jest niezbędny do obliczenia KPI „Odsetek zapotrzebowań zrealizowanych na czas”. Porównanie wymaganej daty dostawy z datą ostatecznej akceptacji lub utworzenia zamówienia zakupu pozwala ocenić, czy organizacja dotrzymuje wewnętrznych poziomów usług i odpowiada na potrzeby biznesowe. Analiza zapotrzebowań, których nie udało się zrealizować w terminie, może ujawnić systemowe opóźnienia w procesie zakupowym.

Dlaczego to ważne

Określa docelowy termin realizacji zapotrzebowania. Umożliwia pomiar terminowości dostaw i zgodności z wewnętrznymi poziomami usług.

Skąd pobrać

To data dostawy na poziomie pozycji, zapisana w polu LFDAT tabeli EBAN.

Przykłady
2023-11-152023-12-012024-01-20
Wymagane Zalecane Opcjonalne

Działania w procesie Purchase to Pay: zapotrzebowanie

Poniżej przedstawiono najważniejsze kroki i punkty kontrolne procesu, które warto rejestrować w dzienniku zdarzeń, aby dokładnie odtworzyć jego przebieg.
6 Zalecane 6 Opcjonalne
Działanie Opis
Odrzucono zapotrzebowanie
Oznacza ostateczne odrzucenie zapotrzebowania zakupowego przez osobę akceptującą, które zatrzymuje proces. Zdarzenie jest rejestrowane przez określoną zmianę statusu wskazującą na odrzucenie.
Dlaczego to ważne

To zdarzenie oznacza niepowodzenie procesu. Analiza częstotliwości i przyczyn odrzuceń oraz etapów, na których do nich dochodzi, pomaga wykryć problemy ze zgodnością z zasadami, budżetem lub jakością wniosków.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany statusu w tabeli EBAN. Status przetwarzania (PROCSTAT) lub wskaźnik zwalniania przyjmuje wartość jednoznacznie oznaczającą „Odrzucono”.

Rejestrowanie

Należy ustalić na podstawie dokumentów zmian znacznik czasu, w którym ogólny status w tabeli EBAN zmienia się na „Odrzucono”.

Typ zdarzenia inferred
Utworzono zamówienie zakupu
Oznacza utworzenie zamówienia zakupu powiązanego z pozycją zapotrzebowania. To jawne zdarzenie systemowe łączy zapotrzebowanie z kolejnym dokumentem zakupowym.
Dlaczego to ważne

To ważny etap i pomyślny rezultat procesu obsługi zapotrzebowania. Czas od akceptacji zapotrzebowania do utworzenia zamówienia zakupu to istotny KPI efektywności zakupów.

Skąd pobrać

Zdarzenie jest rejestrowane bezpośrednio po utworzeniu pozycji zamówienia zakupu. Powiązanie jest zapisane w tabeli EKPO (pozycja zamówienia zakupu), która zawiera numer zapotrzebowania źródłowego (BANFN) i numer jego pozycji (BNFPO).

Rejestrowanie

Należy połączyć tabelę EKPO z tabelą EBAN na podstawie numeru zapotrzebowania i pozycji. Datę utworzenia pozycji zamówienia zakupu należy przyjąć jako moment zdarzenia.

Typ zdarzenia explicit
Utworzono zapotrzebowanie
Oznacza utworzenie dokumentu zapotrzebowania zakupowego w systemie. Zdarzenie jest rejestrowane w chwili pierwszego zapisania nowego zapotrzebowania przez użytkownika, wraz ze znacznikiem czasu utworzenia.
Dlaczego to ważne

To podstawowy punkt początkowy analizy cyklu życia zapotrzebowania. Pozwala mierzyć czas realizacji całego procesu, od rozpoznania potrzeby do ostatecznej akceptacji lub przekształcenia zapotrzebowania w zamówienie zakupu.

Skąd pobrać

Zdarzenie jest rejestrowane bezpośrednio na podstawie tabeli EBAN, z wykorzystaniem pól daty utworzenia (ERDAT) i godziny utworzenia (ERZEIT) dla danego numeru zapotrzebowania zakupowego (BANFN).

Rejestrowanie

Dla każdego zapotrzebowania (BANFN) należy użyć pól znacznika czasu utworzenia (ERDAT, ERZEIT) z tabeli EBAN.

Typ zdarzenia explicit
Zaakceptowano zapotrzebowanie
Oznacza pełną i ostateczną akceptację zapotrzebowania zakupowego, które może zostać przekształcone w zamówienie zakupu. Zdarzenie jest wnioskowane, gdy ogólny status zwalniania osiąga końcowy stan akceptacji.
Dlaczego to ważne

To ważny etap potwierdzający pomyślne zakończenie procesu i częsty punkt końcowy analizy czasu realizacji. Oznacza, że zapotrzebowanie przeszło wszystkie kontrole i dział zakupów może je obsłużyć.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany statusu w tabeli EBAN, w szczególności gdy ogólny wskaźnik zwalniania (FRGZU) lub status przetwarzania (PROCSTAT) zostaje ustawiony na końcową wartość „Zaakceptowano”.

Rejestrowanie

Należy ustalić znacznik czasu zastosowania ostatniego kodu zwalniania lub zmiany ogólnego statusu zapotrzebowania na „Zaakceptowano”.

Typ zdarzenia inferred
Zakończono etap akceptacji
Zdarzenie występuje, gdy osoba akceptująca podejmuje pozytywną decyzję dotyczącą zapotrzebowania, kończąc jeden z etapów wielopoziomowego workflow akceptacji. Jest wnioskowane na podstawie zmiany statusu zwalniania zapotrzebowania.
Dlaczego to ważne

To zdarzenie umożliwia szczegółową analizę workflow akceptacji i pomiar czasu trwania każdego etapu. Pomaga wskazać sprawnie działające osoby akceptujące oraz wąskie gardła procesu.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie dokumentów zmian (CDHDR/CDPOS) dla tabeli EBAN. Zmiana statusu kodu zwalniania (np. w polu FRGZU) z niezwolnionego na zwolniony dla danego kodu oznacza wystąpienie tego zdarzenia.

Rejestrowanie

Należy śledzić zmiany pól statusu zwalniania w tabeli EBAN dla każdego kodu zwalniania określonego w strategii.

Typ zdarzenia inferred
Zamknięto zapotrzebowanie
Oznacza, że pozycja zapotrzebowania została w pełni obsłużona i nie można już utworzyć na jej podstawie kolejnych zamówień zakupu. Status jest zwykle ustawiany automatycznie po zamówieniu całej wymaganej ilości.
Dlaczego to ważne

To zdarzenie oznacza pomyślne zakończenie cyklu życia pozycji zapotrzebowania. Potwierdza, że potrzeba biznesowa została w pełni przełożona na zamówienie zakupu.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie tabeli EBAN. Występuje po ustawieniu wskaźnika „Zamknięto” (EBAKZ), zwykle gdy ilość zamówiona w zamówieniach zakupu jest równa ilości z zapotrzebowania.

Rejestrowanie

Należy znaleźć w dokumentach zmian zdarzenie ustawienia wskaźnika „Zamknięto” (EBAKZ) w tabeli EBAN.

Typ zdarzenia inferred
Przekazano zapotrzebowanie do akceptacji
Oznacza moment formalnego przekazania zapotrzebowania przez wnioskodawcę, co uruchamia workflow akceptacji. Zdarzenie jest zwykle wnioskowane na podstawie ustalenia strategii zwalniania zapotrzebowania i zmiany jego statusu na „W trakcie akceptacji”.
Dlaczego to ważne

To ważny etap, od którego mierzy się KPI czasu akceptacji. Analiza czasu między utworzeniem a przekazaniem zapotrzebowania może ujawnić opóźnienia na etapie jego przygotowania.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie dokumentów zmian (CDHDR/CDPOS) dla tabeli EBAN, w szczególności po uzupełnieniu pól strategii zwalniania (np. FRGST) lub zmianie statusu ogólnego (PROCSTAT) na wskazujący, że trwa akceptacja.

Rejestrowanie

Należy znaleźć pierwszy wpis w dokumentach zmian, który wskazuje na rozpoczęcie workflow akceptacji lub zmianę statusu na „W trakcie akceptacji”.

Typ zdarzenia inferred
Przypisano źródło zaopatrzenia
Oznacza przypisanie przez kupca konkretnego dostawcy, umowy lub rekordu informacyjnego do zaakceptowanej pozycji zapotrzebowania. To ważny etap przygotowania zapotrzebowania do utworzenia zamówienia zakupu.
Dlaczego to ważne

Ten etap łączy akceptację z zamówieniem. Pomiar czasu przypisania źródła zaopatrzenia pomaga wykryć opóźnienia wynikające z obciążenia kupców i ocenić sprawność procesu wyboru źródła.

Skąd pobrać

Zdarzenie jest wnioskowane po wprowadzeniu wartości w polach tabeli EBAN związanych ze źródłem zaopatrzenia, takich jak stały dostawca (LIFNR), rekord informacyjny (INFNR) lub umowa (KONNR).

Rejestrowanie

Należy śledzić uzupełnianie pól takich jak LIFNR, INFNR lub KONNR w tabeli EBAN na podstawie dokumentów zmian.

Typ zdarzenia inferred
Rozpoczęto etap akceptacji
Oznacza, że zapotrzebowanie oczekuje na działanie konkretnej osoby akceptującej lub grupy akceptującej. Zdarzenie jest wnioskowane, gdy status zapotrzebowania wskazuje, że oczekuje ono na określony kod zwalniania.
Dlaczego to ważne

To zdarzenie pomaga wskazać wąskie gardła w łańcuchu akceptacji. Analiza czasu trwania tego stanu pozwala wykryć zapotrzebowania, których obsługa utknęła, oraz przeciążone osoby akceptujące.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie pól statusu zwalniania w tabeli EBAN (np. FRGZU) i konfiguracji strategii zwalniania. Rozpoczyna się, gdy określony kod zwalniania staje się kolejnym kodem do obsłużenia.

Rejestrowanie

Należy ustalić, kiedy zapotrzebowanie przechodzi do stanu oczekiwania na akceptację dla określonego kodu zwalniania, na podstawie dzienników workflow lub pól statusu.

Typ zdarzenia inferred
Wycofano zapotrzebowanie
Zdarzenie występuje, gdy pierwotny wnioskodawca anuluje lub usuwa zapotrzebowanie przed zakończeniem jego obsługi. Zwykle jest to bezpośrednie działanie, które ustawia wskaźnik usunięcia dla pozycji zapotrzebowania.
Dlaczego to ważne

Śledzenie wycofań pomaga zrozumieć zmienność popytu i przyczyny anulowania. Wycofanie kończy cykl życia zapotrzebowania i uniemożliwia jego dalszą obsługę.

Skąd pobrać

Zdarzenie jest rejestrowane bezpośrednio po ustawieniu wskaźnika usunięcia (LOEKZ) dla pozycji zapotrzebowania w tabeli EBAN. Zmiana jest zapisywana w CDHDR/CDPOS.

Rejestrowanie

Należy znaleźć zdarzenie, w którym wskaźnik usunięcia (LOEKZ) w tabeli EBAN przyjmuje wartość „L”.

Typ zdarzenia explicit
Zmieniono zapotrzebowanie
Zdarzenie występuje, gdy po utworzeniu zapotrzebowania użytkownik zmienia istotne pole, na przykład ilość, cenę lub materiał. Zmiana jest rejestrowana bezpośrednio w systemie dokumentów zmian SAP.
Dlaczego to ważne

Śledzenie zmian pozwala wykrywać pętle poprawek i oceniać ich wpływ na czas realizacji. Częste zmiany mogą wskazywać na problemy z jakością danych lub zmieniające się wymagania. Warto uwzględnić te obszary przy ulepszaniu procesów.

Skąd pobrać

Zmiany w tabeli EBAN są rejestrowane bezpośrednio w tabelach dokumentów zmian SAP (CDHDR i CDPOS). Każda zmiana śledzonego pola tworzy wpis.

Rejestrowanie

Należy wyodrębnić zdarzenia zmian z CDHDR/CDPOS, w których klasa obiektu dla zapotrzebowań zakupowych to BANF.

Typ zdarzenia explicit
Zresetowano akceptację
Oznacza zresetowanie całego workflow akceptacji, często z powodu istotnej zmiany zapotrzebowania. Proces akceptacji rozpoczyna się wtedy ponownie od pierwszego poziomu.
Dlaczego to ważne

To zdarzenie wskazuje na poważne poprawki, które znacznie wydłużają czas realizacji. Ustalenie przyczyn resetowania akceptacji pozwala usprawnić proces i ograniczyć opóźnienia.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie dokumentów zmian (CDHDR/CDPOS) dotyczących tabeli EBAN. Wykrywa się je, gdy pola statusu zwalniania, takie jak FRGKZ lub FRGZU, zostają wyczyszczone po częściowym lub pełnym uzupełnieniu.

Rejestrowanie

W dziennikach zmian należy znaleźć przejście statusu zwalniania ze stanu zwolnionego do stanu niezwolnionego.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z SAP S/4HANA

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby przygotować dane i wykorzystać process mining do analizy procesu Purchase to Pay: zapotrzebowanie. Zacznij usprawniać proces już dziś.

Ogranicz opóźnienia w obsłudze zapotrzebowań P2P. Usprawnij workflow.

Usprawnij procesy, skróć czas realizacji i ogranicz czas cyklu o 30%.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje 5 minut.