Szablon danych dla procesu od zapotrzebowania do płatności: zapotrzebowanie
Szablon danych dla procesu od zapotrzebowania do płatności: zapotrzebowanie
- Zalecane atrybuty do zebrania na potrzeby szczegółowej analizy
- Najważniejsze działania i etapy procesu do śledzenia
- Szczegółowe wskazówki dotyczące pobierania danych z systemu
Atrybuty procesu od zapotrzebowania do płatności: zapotrzebowanie
| Nazwa | Opis | ||
|---|---|---|---|
|
Nazwa działania
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego, które miało miejsce w określonym momencie cyklu życia requisition. | ||
|
Opis
Nazwa działania opisuje pojedynczy krok lub etap procesu obsługi requisition, na przykład „Utworzenie requisition”, „Zatwierdzenie etapu akceptacji” lub „Zamknięcie requisition”. Dane te pochodzą zwykle z dzienników zdarzeń, zmian statusu lub zarejestrowanych w SAP Ariba działań użytkowników. Ten atrybut służy do utworzenia mapy procesu, która przedstawia przebieg działań. Analiza ich kolejności i częstotliwości pozwala wykryć typowe ścieżki, wąskie gardła, odstępstwa od standardowej procedury i miejsca wymagające poprawek. To podstawa każdej analizy process mining.
Dlaczego to ważne
Określa kroki procesu, dzięki czemu można zwizualizować i analizować workflow obsługi requisition, w tym wąskie gardła i odstępstwa.
Skąd pobrać
Dane pochodzą z dzienników zdarzeń, ścieżek audytowych lub rejestrów zmian statusu w SAP Ariba. Często są powiązane z tabelami nagłówków requisition i ich pozycji.
Przykłady
Wysłanie requisitionZatwierdzenie etapu akceptacjiZmiana requisitionUtworzenie zamówienia zakupu
|
|||
|
Purchase Requisition ID
PurchaseRequisitionId
|
Unikalny identyfikator dokumentu requisition, używany jako główny identyfikator case w procesie. | ||
|
Opis
Purchase Requisition ID to główny identyfikator łączący wszystkie działania związane z pojedynczym wnioskiem o zakup towarów lub usług. Każde requisition utworzone w SAP Ariba otrzymuje unikalny identyfikator, który pozostaje niezmienny przez cały cykl życia dokumentu, od utworzenia i wysłania po końcową akceptację, odrzucenie lub zamknięcie. W analizie process mining ten atrybut służy do łączenia zdarzeń w ramach jednego case. Pozwala odtworzyć pełny przebieg każdego requisition, dokładnie obliczać czasy cyklu, wykrywać warianty procesu i analizować pętle poprawek. Bez tego identyfikatora nie dałoby się rozróżnić zdarzeń dotyczących różnych requisition.
Dlaczego to ważne
To podstawowy identyfikator case, który łączy wszystkie powiązane działania i pozwala analizować cały proces obsługi każdego requisition.
Skąd pobrać
To pole klucza głównego w głównych tabelach nagłówka requisition w strukturze danych SAP Ariba.
Przykłady
PR-102345PR-102346PR-102347
|
|||
|
Znacznik czasu zdarzenia
EventTimestamp
|
Dokładna data i godzina wystąpienia działania, używana do ustalenia kolejności zdarzeń. | ||
|
Opis
Znacznik czasu zdarzenia zapisuje dokładny moment wykonania działania. Dane o wysokiej precyzji są niezbędne do prawidłowego uporządkowania zdarzeń w każdym case i obliczenia czasu między poszczególnymi krokami procesu. W analizie ten znacznik stanowi podstawę wszystkich obliczeń związanych z czasem, w tym czasu cyklu, oczekiwania i realizacji. Zasila dashboardy do analizy wyników, takie jak „Requisition Approval Cycle Time” i „Approval Path Bottleneck Analysis”. Dokładność tego pola bezpośrednio wpływa na wiarygodność wskaźników efektywności.
Dlaczego to ważne
Ten atrybut określa chronologiczną kolejność zdarzeń i stanowi podstawę obliczeń czasu oraz efektywności, takich jak czas cyklu i wąskie gardła.
Skąd pobrać
Zwykle znajduje się przy rekordach działań lub zmian statusu w ścieżce audytowej SAP Ariba albo w tabelach dziennika transakcji.
Przykłady
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
|
|||
|
Dział wnioskodawcy
RequesterDepartment
|
Dział lub centrum kosztów pracownika, który utworzył requisition. | ||
|
Opis
Ten atrybut pokazuje, która część organizacji zainicjowała wniosek. Zwykle pochodzi z profilu wnioskodawcy lub jest podawany bezpośrednio w formularzu requisition. W analizie umożliwia filtrowanie i porównywanie wyników. Jest wykorzystywany w wielu dashboardach, takich jak „Requisition Approval Cycle Time” i „Requisition Rejection Rate Analysis”, aby zestawiać wskaźniki według działów. Pozwala to wskazać działy z najdłuższym czasem cyklu, największą liczbą zmian lub największym odsetkiem wniosków niezgodnych z zasadami, a następnie zaplanować działania usprawniające.
Dlaczego to ważne
Pozwala porównywać wyniki procesu w różnych częściach organizacji i wykrywać problemy lub dobre praktyki charakterystyczne dla poszczególnych działów.
Skąd pobrać
Należy sprawdzić dokumentację SAP Ariba. Informacja jest zwykle dostępna w danych nagłówka requisition i często pochodzi z profilu wnioskodawcy.
Przykłady
MarketingOperacje ITFinanseBadania i rozwój
|
|||
|
Kategoria pozycji
ItemCategory
|
Klasyfikacja zamawianych towarów lub usług, na przykład „Sprzęt IT”, „Materiały biurowe” lub „Usługi profesjonalne”. | ||
|
Opis
Kategoria pozycji określa, co jest kupowane. Ułatwia analizę wydatków oraz stosowanie strategii i zasad zakupowych właściwych dla danej kategorii. W process mining atrybut ten jest przydatny w dashboardzie „Requisition Amendment Analysis”. Może pokazać, czy w niektórych kategoriach częściej wprowadza się zmiany, co może wskazywać na niejasne specyfikacje lub zmienne ceny. Pozwala też porównywać wyniki procesu, na przykład czas akceptacji, dla różnych rodzajów zakupów i sprawdzić, które kategorie napotykają więcej przeszkód.
Dlaczego to ważne
Pozwala analizować proces według rodzaju kupowanych towarów lub usług i wykrywać wąskie gardła oraz problemy ze zgodnością charakterystyczne dla poszczególnych kategorii.
Skąd pobrać
Należy sprawdzić dokumentację SAP Ariba. Informacja ta znajduje się zwykle na poziomie pozycji requisition.
Przykłady
Sprzęt ITUsługi doradczeMateriały biuroweMateriały marketingowe
|
|||
|
Łączna wartość requisition
TotalRequisitionAmount
|
Łączna wartość pieniężna requisition. | ||
|
Opis
Ten atrybut określa wartość finansową całego wniosku. Dostarcza kontekstu biznesowego, który pomaga kategoryzować i ustalać priorytety requisition. Zestawienie wskaźników procesu z wartością wniosku może ujawnić istotne zależności. Na przykład requisition o wysokiej wartości mogą przechodzić inną, bardziej rygorystyczną ścieżkę akceptacji lub mieć dłuższy czas cyklu. Atrybut ten pomaga ocenić finansowy wpływ nieefektywności i podzielić requisition na przedziały wartości do porównań.
Dlaczego to ważne
Dostarcza kontekstu finansowego i pozwala sprawdzić, jak wartość requisition wpływa na przebieg procesu, na przykład czas akceptacji i złożoność workflow.
Skąd pobrać
Należy sprawdzić dokumentację SAP Ariba. To standardowe pole w nagłówku Purchase Requisition.
Przykłady
1500.0025000.5099.95
|
|||
|
Poziom pilności
UrgencyLevel
|
Wskaźnik priorytetu requisition, na przykład „Normalny”, „Pilny” lub „Krytyczny”. | ||
|
Opis
Poziom pilności, często oznaczany flagą priorytetu, wskazuje potrzebę szybszej obsługi. Zwykle ustala go wnioskodawca, aby pilne potrzeby zostały zrealizowane na czas. Atrybut ten zasila dashboard „Urgent Requisition Process Monitor” i KPI „Urgent Requisition Proc. Time”. Pozwala bezpośrednio porównać czas cyklu pilnych i standardowych requisition oraz sprawdzić, czy obsługa priorytetowa działa. Analiza odstępstw i opóźnień w pilnych wnioskach pomaga zadbać o ciągłość działania firmy.
Dlaczego to ważne
Pozwala ustalać priorytety analizy i sprawdzać, czy requisition o wysokim priorytecie są obsługiwane szybciej, aby zaspokoić pilne potrzeby firmy.
Skąd pobrać
Należy sprawdzić dokumentację SAP Ariba. To pole wyboru jest często dostępne w formularzu tworzenia requisition.
Przykłady
WysokiŚredniNiski
|
|||
|
Przyczyna odrzucenia
RejectionReason
|
Powód podany przez osobę zatwierdzającą przy odrzuceniu requisition lub etapu akceptacji. | ||
|
Opis
Po odrzuceniu requisition osoba zatwierdzająca często podaje przyczynę, wpisując ją w polu tekstowym lub wybierając z listy. Ten atrybut zapisuje tę ważną informację zwrotną. Dane te stanowią podstawę dashboardu „Requisition Rejection Rate Analysis”. Analiza najczęstszych przyczyn odrzucenia pomaga wykryć źródła problemów, takie jak nieprawidłowe kodowanie, niewystarczające uzasadnienie lub problemy z budżetem. Na tej podstawie można lepiej przygotować wnioskodawców i poprawić jakość składanych wniosków, ograniczając liczbę poprawek.
Dlaczego to ważne
Pokazuje, dlaczego requisition są odrzucane. Analiza przyczyn źródłowych pomaga ograniczyć poprawki i zwiększyć odsetek wniosków poprawnych za pierwszym razem.
Skąd pobrać
Należy sprawdzić dokumentację SAP Ariba. Informacja ta jest zwykle zapisywana w komentarzach lub historii powiązanej ze zdarzeniem odrzucenia.
Przykłady
Nieprawidłowe konto księgi głównejPrzekroczony budżetNiewystarczające uzasadnienieZduplikowany wniosek
|
|||
|
Ścieżka workflow akceptacji
ApprovalWorkflowPath
|
Z góry określona kolejność etapów akceptacji, przez które powinno przejść requisition. | ||
|
Opis
Ten atrybut określa standardowy wariant procesu lub macierz akceptacji, której powinno podlegać requisition w zależności od jego cech, takich jak wartość, kategoria pozycji i dział. Opisuje docelowy przebieg procesu. Jest podstawą sprawdzania zgodności i jest wykorzystywany w dashboardzie „Requisition Compliance Overview”. Porównanie rzeczywistej kolejności działań z oczekiwaną ścieżką workflow akceptacji pozwala automatycznie wykrywać naruszenia zasad, nieuprawnione etapy akceptacji i pominięte kontrole. Ma to znaczenie dla audytu wewnętrznego i zarządzania ryzykiem.
Dlaczego to ważne
Określa standardowy przebieg procesu i umożliwia automatyczne wykrywanie odstępstw oraz naruszeń zasad.
Skąd pobrać
Należy sprawdzić dokumentację SAP Ariba. Informację można ustalić na podstawie konfiguracji macierzy akceptacji lub konkretnego pola requisition.
Przykłady
Standardowe IT > 10 000 USDUsługi marketingowe < 5 000 USDNakłady inwestycyjne > 100 000 USD
|
|||
|
Status requisition
RequisitionStatus
|
Bieżący status zapotrzebowania zakupowego w jego cyklu życia. | ||
|
Opis
Ten atrybut pokazuje aktualny status zapotrzebowania, na przykład „W trakcie tworzenia”, „Przesłane”, „Zatwierdzone”, „Odrzucone” lub „Zamknięte”. Informuje, na jakim etapie procesu znajduje się każda sprawa w chwili pobrania danych. Process mining odtwarza przebieg procesu z przeszłości, a ten atrybut służy do bieżącego monitorowania operacji. Jest podstawą dashboardu „Monitor statusu zapotrzebowań”, który pozwala kierownikom sprawdzać aktualne obciążenie i wykrywać zapotrzebowania, które utknęły lub są przetwarzane zbyt długo. Zapewnia bieżący wgląd w zapotrzebowania znajdujące się w toku i ułatwia podjęcie działań.
Dlaczego to ważne
Umożliwia bieżące monitorowanie zapotrzebowań i pomaga wykrywać oraz obsługiwać sprawy, które utknęły lub są przetwarzane zbyt długo, zanim staną się problemem.
Skąd pobrać
Informacje można znaleźć w dokumentacji SAP Ariba. Jest to standardowe pole statusu w nagłówku zapotrzebowania.
Przykłady
ZatwierdzonePrzesłaneOdrzuconeW trakcie zatwierdzania
|
|||
|
Użytkownik wykonujący zdarzenie
EventUser
|
Identyfikator lub nazwa użytkownika, który wykonał działanie, na przykład wnioskodawcy lub osoby zatwierdzającej. | ||
|
Opis
Atrybut użytkownika wykonującego zdarzenie wskazuje osobę odpowiedzialną za dany krok procesu. Może to być pracownik, który wysłał requisition, kierownik, który je zatwierdził, lub pracownik działu zakupów, który je obsłużył. Atrybut ten jest niezbędny do analizy obciążenia pracą i wyników oraz do wykrywania potrzeb szkoleniowych. Zasila dashboard „Approver Workload and Performance”, który pozwala analizować czas akceptacji dla poszczególnych użytkowników. Pomaga też badać przyczyny opóźnień i odstępstw, wskazując konkretne osoby lub zespoły.
Dlaczego to ważne
Umożliwia analizę rozkładu obciążenia, wyników użytkowników i przydziału zasobów. Pomaga wykryć wąskie gardła związane z konkretnymi osobami lub zespołami.
Skąd pobrać
Należy sprawdzić dokumentację SAP Ariba. Dane te są często przechowywane w tabelach ścieżki audytowej lub historii i powiązane z danymi podstawowymi użytkowników.
Przykłady
john.doejane.smithmanager123
|
|||
|
Czy wykonano automatycznie
IsAutomated
|
Wartość logiczna określająca, czy działanie wykonał system, czy użytkownik. | ||
|
Opis
Ten atrybut odróżnia zdarzenia automatyczne, takie jak automatyczne zatwierdzenia lub zmiany statusu inicjowane przez system, od działań wykonywanych ręcznie przez użytkowników. Pozwala ocenić stopień automatyzacji procesu. W analizie pomaga dokładnie mierzyć nakład pracy ludzi i wskazywać możliwości dalszej automatyzacji. Na przykład filtrowanie działań ręcznych pozwala precyzyjnie obliczyć czas przetwarzania z perspektywy użytkownika. Ułatwia też sprawdzenie, czy reguły automatyzacji działają zgodnie z założeniami.
Dlaczego to ważne
Odróżnia działania ludzi od działań systemu, co pozwala mierzyć poziom automatyzacji i wskazywać kolejne możliwości jej zwiększenia.
Skąd pobrać
Zazwyczaj wartość ustala się, sprawdzając, czy atrybut „Użytkownik zdarzenia” wskazuje konto systemowe lub konto użytkownika wsadowego.
Przykłady
truefalse
|
|||
|
Czy wystąpiła ponowna praca
IsRework
|
Wartość logiczna określająca, czy zapotrzebowanie wymagało ponownej pracy, na przykład z powodu odrzucenia lub kilku zmian. | ||
|
Opis
Ten obliczany atrybut szerzej niż „Czy zmieniono” mierzy nieefektywność. Oznacza sprawy, w których wystąpiły istotne pętle ponownej pracy, zwykle zdefiniowane jako co najmniej jedno zdarzenie „Odrzucono krok zatwierdzania” lub kilka zdarzeń „Zmieniono zapotrzebowanie”. Atrybut służy do obliczania KPI „Odsetek zapotrzebowań wymagających ponownej pracy”. Pomaga oszacować ukryte koszty i opóźnienia związane z problemami w procesie. Analiza oznaczonych spraw może ujawnić powiązania z konkretnymi osobami zatwierdzającymi, działami lub rodzajami zapotrzebowań, które utrudniają przebieg procesu.
Dlaczego to ważne
Wskazuje sprawy, w których proces napotkał poważne trudności, na przykład odrzucenie. Ułatwia skupienie analizy na przyczynach nieefektywności i opóźnień.
Skąd pobrać
Przyjmuje wartość prawda, jeśli sprawa zawiera zdarzenie odrzucenia lub więcej niż jedno zdarzenie zmiany.
Przykłady
truefalse
|
|||
|
Czy zmieniono
IsAmended
|
Wartość logiczna określająca, czy zapotrzebowanie zmieniono co najmniej raz po jego pierwszym przesłaniu. | ||
|
Opis
Ten obliczany atrybut wskazuje sprawy, w których wystąpiło co najmniej jedno działanie „Zmieniono zapotrzebowanie”. Ułatwia oznaczanie zapotrzebowań wymagających zmian w trakcie cyklu życia. Atrybut służy do obliczania KPI „Odsetek zmienionych zapotrzebowań”. Zliczając sprawy, dla których ma wartość prawda, analitycy mogą łatwo zmierzyć częstotliwość ponownej pracy i zbadać jej przyczyny, zestawiając wyniki z innymi atrybutami, takimi jak „Imię i nazwisko osoby zgłaszającej” lub „Kategoria pozycji”.
Dlaczego to ważne
Ułatwia obliczenie KPI dotyczącego odsetka zmienionych zapotrzebowań, pomiar ponownej pracy i wskazanie obszarów, w których warto dokładniej określać wymagania już na początku.
Skąd pobrać
Przyjmuje wartość prawda, jeśli sprawa zawiera co najmniej jedno działanie „Zmieniono zapotrzebowanie”, a w przeciwnym razie wartość fałsz.
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 pokazuje datę i godzinę ostatniego pobrania lub aktualizacji danych dla danego zdarzenia. Informuje, jak aktualne są analizowane dane, co jest szczególnie ważne przy monitorowaniu trwających procesów. Analitycy wykorzystują tę informację, aby ocenić aktualność uzyskanych wniosków. W dashboardach takich jak „Live Requisition Status Tracker” pole to informuje użytkowników, kiedy dane były ostatnio aktualizowane. Pomaga też określić, na ile można polegać na aktualności prezentowanych informacji.
Dlaczego to ważne
Informuje o aktualności danych, co pozwala ocenić, czy wnioski z process mining odnoszą się do bieżącej sytuacji.
Skąd pobrać
Ten znacznik czasu jest zwykle generowany i dodawany do każdego rekordu podczas wczytywania danych.
Przykłady
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Identyfikator zamówienia zakupu
PurchaseOrderId
|
Identyfikator zamówienia zakupu utworzonego na podstawie zatwierdzonego zapotrzebowania. | ||
|
Opis
Ten atrybut łączy zapotrzebowanie zakupowe z kolejnym dokumentem w procesie, czyli zamówieniem zakupu (PO). Jego obecność oznacza, że zapotrzebowanie zostało przekształcone w zamówienie. Jest niezbędny do analizy procesu od początku do końca, obejmującej również etapy po złożeniu zapotrzebowania. Pozwala obliczyć KPI „Czas od zapotrzebowania do zamówienia zakupu”, łącząc zdarzenie utworzenia zapotrzebowania ze zdarzeniem utworzenia zamówienia. Dzięki temu można ocenić początkową część cyklu zakupowego jako całość.
Dlaczego to ważne
Łączy zapotrzebowanie z późniejszym zamówieniem zakupu, umożliwiając pomiar czasu całego cyklu od zapotrzebowania do zamówienia.
Skąd pobrać
Informacje można znaleźć w dokumentacji SAP Ariba. Zazwyczaj są przechowywane w danych pozycji zapotrzebowania po wygenerowaniu zamówienia zakupu.
Przykłady
PO-4500012345PO-4500012346PO-4500012347
|
|||
|
Imię i nazwisko osoby zatwierdzającej
ApproverName
|
Imię i nazwisko użytkownika przypisanego do zatwierdzenia danego kroku w workflow. | ||
|
Opis
Ten atrybut wskazuje konkretnego kierownika lub interesariusza odpowiedzialnego za zatwierdzenie. W odróżnieniu od ogólnego atrybutu „Użytkownik zdarzenia” dotyczy bezpośrednio zadań związanych z zatwierdzaniem. Atrybut ten jest podstawą dashboardu „Obciążenie i efektywność osób zatwierdzających”. Pozwala sprawdzić liczbę zapotrzebowań obsłużonych przez każdą osobę oraz średni czas zatwierdzania. Dzięki temu można wykrywać wąskie gardła, równoważyć obciążenie pracą i oceniać wyniki w odniesieniu do założonych celów.
Dlaczego to ważne
Wskazuje osobę odpowiedzialną za zatwierdzenie, co pozwala szczegółowo analizować obciążenie pracą i efektywność oraz lepiej rozdzielać zadania między osoby zatwierdzające.
Skąd pobrać
Informacje można znaleźć w dokumentacji SAP Ariba. Dane te są przechowywane w danych przepływu zatwierdzania powiązanych z zapotrzebowaniem.
Przykłady
Sarah JonesDavid ChenMaria Garcia
|
|||
|
Imię i nazwisko osoby zgłaszającej
RequesterName
|
Imię i nazwisko pracownika, który utworzył zapotrzebowanie zakupowe. | ||
|
Opis
Ten atrybut na poziomie sprawy wskazuje osobę, która utworzyła zapotrzebowanie zakupowe. Informuje, skąd pochodzi wniosek i kto go zgłosił. W analizie atrybut ten służy do filtrowania procesu i badania zachowań poszczególnych osób zgłaszających. Na przykład dashboardy „Analiza zmian w zapotrzebowaniach” i „Analiza odsetka odrzuconych zapotrzebowań” pomagają wskazać osoby, które mogą potrzebować dodatkowego szkolenia ze względu na częste zmiany lub odrzucenia. Ułatwia to dostosowanie informacji zwrotnej i działań usprawniających do konkretnych osób.
Dlaczego to ważne
Wskazuje osobę, która utworzyła zapotrzebowanie, dzięki czemu można analizować przebieg i jakość procesu dla poszczególnych osób zgłaszających.
Skąd pobrać
Informacje można znaleźć w dokumentacji SAP Ariba. Jest to standardowe pole w nagłówku zapotrzebowania, często opisane jako „Utworzone przez” lub „Osoba zgłaszająca”.
Przykłady
Alice WilliamsBob MillerCharles Brown
|
|||
|
System źródłowy
SourceSystem
|
System, z którego pobrano dane. | ||
|
Opis
Ten atrybut wskazuje źródło danych o procesie. W tym widoku jego wartością będzie zawsze „SAP Ariba”. Jeśli dane pochodzą z kilku systemów, pole to pomaga ustalić ich pochodzenie i rozwiązywać problemy. W analizie pozwala potwierdzić źródło danych oraz filtrować lub porównywać procesy obejmujące różne systemy. Ułatwia zrozumienie pochodzenia danych i zwiększa zaufanie do wyników, co ma znaczenie dla akceptacji analizy przez interesariuszy.
Dlaczego to ważne
Wskazuje pochodzenie danych, co pomaga w zarządzaniu danymi, rozwiązywaniu problemów i właściwym zrozumieniu kontekstu analizy.
Skąd pobrać
Zwykle jest to stała wartość dodawana podczas ekstrakcji i transformacji danych, aby oznaczyć źródło zbioru.
Przykłady
SAP AribaSAP_ARIBA_P2PAribaCloud
|
|||
Działania w procesie od zapotrzebowania do płatności: zapotrzebowanie
| Działanie | Opis | ||
|---|---|---|---|
|
Odrzucenie requisition
|
Oznacza ostateczne odrzucenie Purchase Requisition po jego sprawdzeniu. Jest to stan końcowy procesu, rejestrowany przy zmianie statusu na „Denied”. | ||
|
Dlaczego to ważne
To ważny punkt końcowy oznaczający niepowodzenie. Analiza odrzuconych requisition jest niezbędna do obliczenia KPI „Requisition Rejection Rate”, wykrycia powtarzających się przyczyn i poprawy jakości wniosków.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii dokumentu Ariba, w której zapisywana jest końcowa zmiana statusu requisition na „Denied”.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola statusu requisition na „Denied”.
Typ zdarzenia
inferred
|
|||
|
Utworzenie requisition
|
Oznacza utworzenie przez użytkownika dokumentu Purchase Requisition. Zdarzenie jest rejestrowane przy pierwszym zapisaniu requisition w stanie „Composing” lub jako wersji roboczej. | ||
|
Dlaczego to ważne
To początek cyklu życia requisition. Analiza czasu od utworzenia do wysłania pozwala ocenić sprawność użytkowników i określić potrzeby szkoleniowe.
Skąd pobrać
Na podstawie znacznika czasu utworzenia obiektu Purchase Requisition w SAP Ariba. Można go znaleźć w danych nagłówka dokumentu requisition. Oznacza jawne zdarzenie utworzenia.
Rejestrowanie
Należy użyć pola „CreateTime” lub równoważnego znacznika czasu z tabeli nagłówka dokumentu requisition.
Typ zdarzenia
explicit
|
|||
|
Utworzenie zamówienia zakupu
|
Oznacza pomyślne przekształcenie zatwierdzonego Purchase Requisition w Purchase Order. Zdarzenie jest rejestrowane po utworzeniu dokumentu PO, który odwołuje się do requisition. | ||
|
Dlaczego to ważne
To podstawowy wynik potwierdzający pomyślną realizację procesu obsługi requisition. Jest niezbędny do pomiaru KPI „Requisition to PO Lead Time” dla całego procesu.
Skąd pobrać
Jest to jawne zdarzenie. Wykorzystuje się znacznik czasu utworzenia dokumentu Purchase Order, który zawiera bezpośredni odnośnik lub referencję do źródłowego Purchase Requisition ID.
Rejestrowanie
W tabeli nagłówka PO należy znaleźć zamówienie powiązane z requisition i użyć jego znacznika czasu utworzenia.
Typ zdarzenia
explicit
|
|||
|
Wysłanie requisition
|
Oznacza formalne przekazanie przez wnioskodawcę dokumentu Purchase Requisition do workflow akceptacji. Zdarzenie jest rejestrowane przy zmianie statusu z „Composing” na „Submitted”. | ||
|
Dlaczego to ważne
To ważny etap, który rozpoczyna proces akceptacji. Jest niezbędny do obliczenia wskaźników „Requisition Approval Cycle Time” i „Requisition Creation Lead Time”.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii dokumentu lub dziennika audytowego Ariba, w których zapisywana jest zmiana statusu requisition na „Submitted” wraz ze znacznikiem czasu.
Rejestrowanie
Należy ustalić znacznik czasu pierwszej zmiany pola statusu requisition na „Submitted”.
Typ zdarzenia
inferred
|
|||
|
Zamknięcie requisition
|
Oznacza końcowe zamknięcie administracyjne Purchase Requisition po zakończeniu wszystkich powiązanych działań, takich jak zamówienie i odbiór. Jest rejestrowane przy końcowej zmianie statusu na „Closed”. | ||
|
Dlaczego to ważne
Oznacza definitywny koniec całego cyklu życia requisition. Analiza czasu od utworzenia PO do zamknięcia może ujawnić wąskie gardła w dalszych procesach odbioru lub fakturowania.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii dokumentu Ariba, w której zapisywana jest zmiana statusu requisition na „Closed”.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola statusu requisition na „Closed”.
Typ zdarzenia
inferred
|
|||
|
Zatwierdzenie requisition
|
Oznacza końcowe zatwierdzenie Purchase Requisition po pomyślnym przejściu wszystkich etapów workflow. Zdarzenie jest rejestrowane przy zmianie statusu na „Approved”. | ||
|
Dlaczego to ważne
To ważny etap oznaczający koniec fazy akceptacji. Stanowi punkt końcowy pomiaru „Avg Requisition Approval Time” i sygnalizuje gotowość do utworzenia PO.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii dokumentu Ariba, w której zapisywana jest końcowa zmiana statusu requisition na „Approved”.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola statusu requisition na „Approved”.
Typ zdarzenia
inferred
|
|||
|
Odrzucenie etapu akceptacji
|
Oznacza negatywny wynik etapu akceptacji, gdy osoba zatwierdzająca odrzuca requisition, zwykle odsyłając je do poprawy. Zdarzenie jest jawnie rejestrowane jako działanie „Deny”. | ||
|
Dlaczego to ważne
Wskazuje istotne źródło poprawek i opóźnień w procesie. Analiza tych zdarzeń pomaga zrozumieć wskaźnik „Requisition Rework Rate” i przyczyny odrzuceń.
Skąd pobrać
Na podstawie tabel przepływu akceptacji Ariba. Zdarzenie jest rejestrowane ze znacznikiem czasu, gdy osoba zatwierdzająca wybiera działanie „Deny” lub „Reject” dla przypisanego zadania.
Rejestrowanie
Należy użyć znacznika czasu działania „Deny” zapisanego w historii akceptacji dla danego etapu.
Typ zdarzenia
explicit
|
|||
|
Przekazanie requisition do działu zakupów strategicznych
|
Zdarzenie występuje, gdy zatwierdzone requisition zostaje przekazane do działu zakupów strategicznych, który przeprowadza postępowanie, na przykład RFQ, przed utworzeniem PO. Jest rejestrowane przy zmianie statusu, na przykład na „Sourcing”. | ||
|
Dlaczego to ważne
Wskazuje ważną ścieżkę procesu dla pozycji o wysokiej wartości lub niestandardowych. Pomaga ocenić, jak czas pracy działu zakupów strategicznych wpływa na łączny czas realizacji.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu requisition na wartość oznaczającą przekazanie do działu zakupów strategicznych. Jest to częste w Ariba Buying zintegrowanym z Ariba Sourcing.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola statusu requisition na „Sourcing” lub podobny status niestandardowy.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie etapu akceptacji
|
Oznacza przekazanie Purchase Requisition do osoby zatwierdzającej lub kolejki akceptacji, gdzie oczekuje na dalsze działanie. Zdarzenie jest rejestrowane po utworzeniu i przypisaniu prośby o akceptację. | ||
|
Dlaczego to ważne
Zapewnia szczegółowy wgląd w workflow akceptacji. Jest niezbędne do obliczania czasu oczekiwania w kolejce i wskazania etapów stanowiących wąskie gardła w analizie „Approval Path Bottleneck Analysis”.
Skąd pobrać
Na podstawie tabel przepływu akceptacji Ariba, w których rejestrowane jest tworzenie i przypisywanie poszczególnych zadań akceptacyjnych powiązanych z requisition.
Rejestrowanie
Należy użyć znacznika czasu utworzenia rekordu prośby o akceptację powiązanego z requisition i konkretnym etapem akceptacji.
Typ zdarzenia
explicit
|
|||
|
Wycofanie requisition
|
Zdarzenie występuje, gdy pierwotny wnioskodawca anuluje wysłane Purchase Requisition przed zakończeniem akceptacji. Jest rejestrowane przy zmianie statusu na „Withdrawn” lub „Canceled”. | ||
|
Dlaczego to ważne
Oznacza zakończenie procesu z inicjatywy użytkownika. Analiza przyczyn wycofywania requisition może ujawnić problemy związane ze zmianą potrzeb biznesowych lub długim czasem akceptacji.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii dokumentu lub dziennika audytowego Ariba, w których zapisywana jest zmiana statusu requisition na „Withdrawn”.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola statusu requisition na „Withdrawn”.
Typ zdarzenia
inferred
|
|||
|
Zamówienie pozycji requisition
|
Oznacza zmianę statusu pojedynczej pozycji requisition na „Ordered” po dodaniu jej do zamówienia zakupu. Pozwala śledzić proces dokładniej niż samo utworzenie PO na poziomie nagłówka. | ||
|
Dlaczego to ważne
Umożliwia analizę częściowych zamówień i opóźnień dotyczących poszczególnych pozycji, których nie widać na poziomie nagłówka. Jest to przydatne w przypadku requisition z wieloma pozycjami realizowanymi w różnych PO.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu obiektu pozycji requisition. Status pozycji zmienia się na „Ordered” po utworzeniu dla niej PO.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola statusu pozycji requisition na „Ordered”.
Typ zdarzenia
inferred
|
|||
|
Zatwierdzenie etapu akceptacji
|
Oznacza pozytywny wynik etapu akceptacji, czyli zatwierdzenie przez osobę zatwierdzającą przypisanej jej części requisition. Zdarzenie jest jawnie rejestrowane jako działanie akceptacji. | ||
|
Dlaczego to ważne
Pozwala mierzyć czas obsługi poszczególnych osób zatwierdzających. Dane te są niezbędne do obliczenia wskaźnika „Avg Approval Step Duration” i oceny obciążenia pracą.
Skąd pobrać
Na podstawie tabel przepływu akceptacji Ariba. Zdarzenie jest rejestrowane ze znacznikiem czasu, gdy osoba zatwierdzająca wybiera działanie „Approve” dla przypisanego zadania.
Rejestrowanie
Należy użyć znacznika czasu działania „Approve” zapisanego w historii akceptacji dla danego etapu.
Typ zdarzenia
explicit
|
|||
|
Zmiana requisition
|
Zdarzenie występuje, gdy użytkownik modyfikuje Purchase Requisition po jego wysłaniu, często w odpowiedzi na odrzucenie lub pytanie. Jest rejestrowane, gdy dokument zostaje edytowany i wysłany ponownie. | ||
|
Dlaczego to ważne
Pozwala śledzić poprawki i nieefektywności procesu. Częste zmiany mogą wskazywać na niejasne wymagania początkowe lub zasady, co wpływa na KPI „Requisition Amendment Rate”.
Skąd pobrać
Zdarzenie można ustalić na podstawie danych o wersjach w Ariba. Każda zmiana tworzy nową wersję dokumentu requisition. Wersja o numerze większym niż 1 oznacza zmianę.
Rejestrowanie
Należy sprawdzić, czy po pierwszym statusie „Submitted” utworzono nową wersję requisition. Znacznik czasu nowej wersji jest czasem zdarzenia.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Skorzystajcie Państwo z tego szablonu, aby usprawnić przygotowanie danych i uzyskać dokładniejszy obraz procesu od zapotrzebowania do płatności, obejmującego obsługę zapotrzebowań. Już dziś można rozpocząć usprawnianie operacji.
Ogranicz opóźnienia i usprawnij obsługę zapotrzebowań w procesie od zapotrzebowania do płatności
Wskaż nieefektywności w SAP Ariba i skróć czas cyklu o 30%.
Nie trzeba podawać danych karty płatniczej. Konfiguracja jest szybka i prosta.