Szablon danych dotyczących zapotrzebowań w cyklu Purchase-to-Pay
Szablon danych dotyczących zapotrzebowań w cyklu Purchase-to-Pay
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pobierania danych
Atrybuty zapotrzebowań w cyklu Purchase-to-Pay
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Dokładny timestamp wystąpienia danej czynności lub zdarzenia. | ||
|
Opis
Czas zdarzenia, czyli timestamp, określa datę i godzinę zapisania zdarzenia biznesowego w systemie. Stanowi podstawę wszystkich analiz procesu opartych na czasie. Ten atrybut jest niezbędny do obliczania czasu cyklu, czasu trwania i czasu oczekiwania między czynnościami. Umożliwia analizę wyników procesu, wykrywanie wąskich gardeł i monitorowanie zgodności z SLA. Dokładne timestampy są warunkiem wiarygodnej analizy process mining.
Dlaczego to ważne
Pozwala ustalić chronologiczną kolejność zdarzeń, niezbędną do obliczania czasu trwania procesu, wykrywania wąskich gardeł i analizy wyników w czasie.
Skąd pobrać
Można go znaleźć w historii workflow lub tabelach dzienników dokumentów, często w polu 'CreatedDateTime' lub 'ModifiedDateTime' powiązanym ze zmianą statusu albo rekordem zdarzenia.
Przykłady
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
|
|||
|
Nazwa czynności
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub kroku, który wystąpił w procesie obsługi zapotrzebowania. | ||
|
Opis
Ten atrybut zapisuje nazwę każdej czynności wykonanej w cyklu życia zapotrzebowania zakupowego. Przykłady to „Utworzenie zapotrzebowania”, „Akceptacja na etapie procesu” i „Utworzenie zamówienia zakupu”. Czynności te tworzą węzły na odkrytej mapie procesu. Analiza kolejności, częstotliwości i czasu trwania czynności stanowi podstawę process mining. Pomaga wykrywać wąskie gardła, powtarzające się pętle poprawek i odstępstwa od standardowego przebiegu procesu, ujawniając nieefektywne działania operacyjne.
Dlaczego to ważne
Ten atrybut określa kroki na mapie procesu, umożliwiając wizualizację, analizę i zrozumienie workflow obsługi zapotrzebowań.
Skąd pobrać
Zwykle jest ustalany na podstawie dzienników zmian statusu, tabel historii workflow lub tabel zdarzeń w Microsoft Dynamics 365, takich jak WorkflowTrackingStatusTable.
Przykłady
Przekazanie zapotrzebowania do akceptacjiAkceptacja na etapie procesuZmiana zapotrzebowania
|
|||
|
Purchase Requisition ID
PurchaseRequisitionId
|
Unikatowy identyfikator zapotrzebowania zakupowego, używany jako główny identyfikator sprawy. | ||
|
Opis
Purchase Requisition ID to główny identyfikator łączący wszystkie czynności związane z pojedynczym zapotrzebowaniem na towary lub usługi. Cały proces, od utworzenia zapotrzebowania po jego ostateczną akceptację i zamknięcie, jest śledzony pod tym unikatowym identyfikatorem. W process mining ten atrybut jest niezbędny do odtworzenia pełnego przebiegu każdego zapotrzebowania. Umożliwia analizę wariantów procesu, czasu cyklu i zgodności dla poszczególnych spraw, zapewniając pełny obraz cyklu życia zapotrzebowania.
Dlaczego to ważne
Atrybut ten jest niezbędny do grupowania wszystkich powiązanych zdarzeń w jedną instancję procesu i przeprowadzenia pełnej analizy cyklu życia każdego zapotrzebowania.
Skąd pobrać
Zwykle jest to klucz główny w głównej tabeli nagłówków zapotrzebowań zakupowych, takiej jak PurchReqTable w Microsoft Dynamics 365.
Przykłady
PR-001254PR-001255PR-001256
|
|||
|
Data ostatniej aktualizacji danych
LastDataIngestionTimestamp
|
Timestamp ostatniej ekstrakcji danych i wczytania ich do narzędzia process mining. | ||
|
Opis
Ten atrybut informuje o aktualności analizowanych danych. Pokazuje datę i godzinę ostatniego odświeżenia danych z systemu źródłowego. Nie jest to pole z samego Dynamics 365, lecz metadane dodawane podczas wczytywania danych. Timestamp pomaga ocenić, jak aktualne są wnioski. Pozwala ustalić, czy analiza dotyczy danych bieżących, czy migawki z określonego momentu, co wpływa na trafność wyciąganych wniosków.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu wiadomo, jakiego okresu dotyczy analiza i na ile wnioski są przydatne.
Skąd pobrać
Ta wartość jest generowana i dodawana do zbioru danych podczas wczytywania danych lub procesu ETL.
Przykłady
2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
|
|||
|
System źródłowy
SourceSystemId
|
System, z którego wyodrębniono dane. | ||
|
Opis
Ten atrybut wskazuje system źródłowy, z którego pochodzą dane o zdarzeniach. W tym przypadku będzie to 'Microsoft Dynamics 365'. W środowiskach z wieloma zintegrowanymi systemami pole to ma istotne znaczenie dla śledzenia pochodzenia danych i ich kontekstu. W analizie pomaga rozróżnić procesy obejmujące kilka systemów lub potwierdzić, że dane pochodzą z jednego wiarygodnego źródła. Ułatwia to weryfikację danych i upewnienie się, że analiza opiera się na właściwym zbiorze.
Dlaczego to ważne
Informuje o pochodzeniu danych, co ma znaczenie dla zarządzania danymi, ich weryfikacji i pracy w środowiskach zintegrowanych z wieloma systemami.
Skąd pobrać
To stała wartość 'Microsoft Dynamics 365', dodawana podczas ekstrakcji i transformacji danych.
Przykłady
Microsoft Dynamics 365 F&OD365MSD365
|
|||
|
Dział
Department
|
Dział osoby zgłaszającej lub centrum kosztów powiązane z zapotrzebowaniem. | ||
|
Opis
Ten atrybut określa dział firmy lub centrum kosztów, z którego pochodzi zapotrzebowanie zakupowe, na przykład „Marketing”, „IT” lub „Operacje”. Informacje te zwykle znajdują się w nagłówku zapotrzebowania. Podział procesu według działów jest ważny w analizie porównawczej. Pozwala sprawdzić, które działy mają najdłuższy czas cyklu, najwyższy odsetek odrzuceń lub najczęściej wprowadzają zmiany. Dzięki tym informacjom można dopasować usprawnienia do potrzeb poszczególnych działów.
Dlaczego to ważne
Pozwala filtrować i porównywać wyniki procesu w różnych jednostkach firmy oraz wykrywać charakterystyczne dla poszczególnych działów wzorce, wąskie gardła i nieefektywne działania.
Skąd pobrać
Te informacje są często przechowywane w nagłówku zapotrzebowania zakupu (PurchReqTable) i powiązane z konfiguracją wymiarów finansowych w Dynamics 365.
Przykłady
Dział ITFinanseOperacje
|
|||
|
Etap zatwierdzania
ApprovalStep
|
Nazwa lub etap konkretnego kroku zatwierdzania w workflow. | ||
|
Opis
Ten atrybut wskazuje konkretny etap workflow zatwierdzania, na przykład „Zatwierdzenie przez kierownika” lub „Zatwierdzenie przez dział finansowy”. Zapewnia dokładniejsze informacje niż ogólna nazwa działania. Atrybut ten jest niezbędny do analizy wąskich gardeł na etapach zatwierdzania. Śledząc czas spędzony na każdym z nich, można dokładnie ustalić, które etapy opóźniają cały proces. Ułatwia to podjęcie działań ukierunkowanych na usprawnienie workflow.
Dlaczego to ważne
Umożliwia szczegółową analizę workflow zatwierdzania i wskazanie konkretnych etapów powodujących wąskie gardła.
Skąd pobrać
Informacje te znajdują się w tabelach historii workflow, takich jak WorkflowTrackingStatusTable, które zawierają szczegóły poszczególnych kroków skonfigurowanego workflow.
Przykłady
Zatwierdzenie przez kierownikaZatwierdzenie przez kierownika działuWeryfikacja przez dział finansowy
|
|||
|
Łączna kwota zapotrzebowania
RequisitionTotalAmount
|
Łączna wartość pieniężna zapotrzebowania zakupu. | ||
|
Opis
Ten atrybut zawiera łączną wartość wszystkich pozycji zapotrzebowania zakupu. Kwota często wpływa na złożoność workflow zatwierdzania. Zapotrzebowania o wyższej wartości mogą wymagać większej liczby etapów zatwierdzania. W analizie procesu atrybut ten jest niezbędny do filtrowania i analizy według wartości. Pozwala odpowiedzieć na pytania takie jak: „Czy zatwierdzanie zapotrzebowań o wysokiej wartości trwa dłużej?” lub „Jaka jest wartość zapotrzebowań, które utknęły w procesie?”. Dzięki temu można uwzględnić kontekst finansowy przy ocenie przebiegu procesu.
Dlaczego to ważne
Uwzględnia wymiar finansowy w analizie, co pozwala nadawać priorytet sprawom o wysokiej wartości i sprawdzać, jak kwota wpływa na przebieg procesu.
Skąd pobrać
Wartość ta znajduje się zwykle w tabeli nagłówków zapotrzebowań zakupu albo jest obliczana jako suma kwot pozycji z tabeli wierszy zapotrzebowania zakupu (PurchReqLine).
Przykłady
1500.0025000.50500.75
|
|||
|
Poziom pilności
UrgencyLevel
|
Klasyfikacja pilności zapotrzebowania, na przykład „Wysoka”, „Średnia” lub „Niska”. | ||
|
Opis
Poziom pilności, czyli priorytet, określa, jak szybko potrzebne są zamówione towary lub usługi. Atrybut ten często wpływa na ścieżkę zatwierdzania lub kolejność pracy osób zatwierdzających. Analiza tego atrybutu pozwala sprawdzić, czy system priorytetów działa skutecznie. Można na przykład porównać czas realizacji zapotrzebowań o „Wysokim” i „Niskim” poziomie pilności. Jeśli różnica jest niewielka, może to oznaczać, że pole priorytetu jest ignorowane lub używane niezgodnie z przeznaczeniem. Takie informacje można analizować na dashboardzie „Wpływ poziomu pilności”.
Dlaczego to ważne
Pozwala ocenić, czy ustawienia priorytetów przyspieszają obsługę pilnych zapotrzebowań, i wykryć niewłaściwe użycie klasyfikacji pilności.
Skąd pobrać
Może to być standardowe lub niestandardowe pole w tabeli PurchReqTable. Jego dostępność i nazwa zależą od konfiguracji systemu.
Przykłady
WysokaŚredniaNiska
|
|||
|
Status zapotrzebowania
RequisitionStatus
|
Bieżący lub końcowy status zapotrzebowania zakupu. | ||
|
Opis
Ten atrybut określa ogólny status zapotrzebowania zakupu w danym momencie, na przykład „W trakcie weryfikacji”, „Zatwierdzone”, „Odrzucone” lub „Zamknięte”. Często jest to atrybut na poziomie sprawy, który wskazuje jej końcowy wynik. Analiza końcowego statusu pozwala ocenić ogólne wyniki procesu. Duża liczba zapotrzebowań ze statusem „Odrzucone” lub „Wycofane” może wskazywać na problemy na etapie składania wniosku albo uciążliwy proces zatwierdzania. Status ten pozwala mierzyć odsetek zatwierdzeń i efektywność procesu.
Dlaczego to ważne
Wskazuje wynik każdej sprawy, dzięki czemu można analizować odsetek zatwierdzeń, odrzuceń i wycofań. Są to ważne KPI.
Skąd pobrać
Pole statusu znajduje się zwykle w tabeli nagłówków zapotrzebowań zakupu PurchReqTable i często nosi nazwę „Status” lub „PurchReqStatus”.
Przykłady
ZatwierdzoneW trakcie weryfikacjiOdrzuconeWersja robocza
|
|||
|
Użytkownik
User
|
Identyfikator lub nazwa użytkownika, który wykonał daną czynność. | ||
|
Opis
Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za wykonanie konkretnego kroku procesu, na przykład przesłanie zapotrzebowania lub zaakceptowanie zgłoszenia. Może to być identyfikator użytkownika, imię i nazwisko lub adres e-mail. Analiza czynności według użytkownika pomaga określić potrzeby szkoleniowe, wskazać osoby lub zespoły osiągające dobre wyniki oraz ocenić rozkład obciążenia pracą. Jest też niezbędna do analizy zgodności, na przykład rozdziału obowiązków, i zrozumienia, jak różne role użytkowników współpracują w procesie.
Dlaczego to ważne
Umożliwia analizę zachowań, obciążenia pracą i wyników poszczególnych użytkowników, co pomaga zarządzać zasobami i wskazywać potrzeby szkoleniowe.
Skąd pobrać
Zwykle można go znaleźć w tabelach historii workflow, np. WorkflowTrackingStatusTable, lub tabelach transakcji, np. PurchReqTable, powiązanych z tabelą użytkowników, np. UserInfo.
Przykłady
j.smitha.joness.patel
|
|||
|
Grupa zatwierdzająca
ApproverGroup
|
Grupa użytkowników lub rola odpowiedzialna za zatwierdzenie danego etapu. | ||
|
Opis
Ten atrybut wskazuje grupę, rolę lub kolejkę przypisaną do konkretnego zadania zatwierdzania, na przykład „Osoby zatwierdzające w dziale finansowym” lub „Kierownicy IT”. Analiza wyników procesu według grup zatwierdzających pozwala zrozumieć rozkład obciążenia i wskazać grupy, którym może brakować zasobów lub które potrzebują dodatkowego szkolenia. Umożliwia też analizę dashboardu „Analiza wąskich gardeł na etapach zatwierdzania” według zespołów odpowiedzialnych za zatwierdzanie.
Dlaczego to ważne
Pomaga porównać wyniki zespołów zatwierdzających i wskazać potencjalne braki zasobów lub potrzeby szkoleniowe w poszczególnych grupach.
Skąd pobrać
Informacje te są częścią historii workflow, na przykład tabeli WorkflowTrackingStatusTable, która zapisuje przypisanego użytkownika lub grupę użytkowników dla każdego zadania.
Przykłady
Osoby zatwierdzające w dziale finansowymKierownicy ITKadra kierownicza wyższego szczebla
|
|||
|
Liczba zmian zapotrzebowania
AmendmentCount
|
Łączna liczba zmian wprowadzonych w zapotrzebowaniu. | ||
|
Opis
To obliczany atrybut liczbowy, który zlicza wystąpienia działania „Zmieniono zapotrzebowanie” dla każdej sprawy dotyczącej zapotrzebowania zakupu. Atrybut ten jest niezbędny do dashboardu „Częstotliwość zmian zapotrzebowań” i KPI „Odsetek zmienionych zapotrzebowań”. Określa liczbę poprawek w każdej sprawie, ułatwiając wskazanie zapotrzebowań, działów lub użytkowników powiązanych z częstymi zmianami i niską efektywnością. Pozwala to ukierunkować działania na poprawę jakości składanych zapotrzebowań.
Dlaczego to ważne
Określa liczbę poprawek w sprawie, ułatwiając pomiar i analizę częstotliwości zmian oraz ich wpływu na efektywność procesu.
Skąd pobrać
To obliczany atrybut. Wylicza się go podczas transformacji danych, zliczając działania „Zmieniono zapotrzebowanie” dla każdego unikatowego PurchaseRequisitionId.
Przykłady
013
|
|||
|
Numer zamówienia zakupu
PurchaseOrderNumber
|
Identyfikator zamówienia zakupu utworzonego na podstawie zapotrzebowania. | ||
|
Opis
Ten atrybut przechowuje unikatowy identyfikator zamówienia zakupu utworzonego na podstawie zatwierdzonego zapotrzebowania. Łączy proces obsługi zapotrzebowania z kolejnym etapem procesu zakupowego. Śledzenie tego numeru jest niezbędne do analizy czasu przekształcenia zapotrzebowania w zamówienie zakupu (PO). Potwierdza, że zapotrzebowanie przeszło do kolejnego etapu cyklu Purchase-to-Pay, i umożliwia analizę całego procesu, obejmującą zarówno zapotrzebowania, jak i zamówienia zakupu.
Dlaczego to ważne
Łączy zapotrzebowanie z utworzonym na jego podstawie zamówieniem zakupu. Umożliwia analizę przekształcenia zapotrzebowania w PO i powiązanie różnych etapów procesu P2P.
Skąd pobrać
Po utworzeniu PO informacja ta znajduje się zwykle w tabeli wierszy zapotrzebowania zakupu (PurchReqLine), skąd prowadzi do tabeli PurchTable.
Przykłady
PO-000987PO-000988PO-000989
|
|||
|
Ścieżka zatwierdzania
ApprovalWorkflowPath
|
Przebieg kolejnych etapów zatwierdzania. | ||
|
Opis
Ten atrybut jest polem pochodnym, które łączy w kolejności etapy zatwierdzania danego zapotrzebowania, na przykład „Zatwierdzenie przez kierownika -> Zatwierdzenie przez kierownika działu -> Zatwierdzenie przez dział finansowy”. Podsumowuje wariant procesu dla podprocesu zatwierdzania. Atrybut ten jest niezbędny do działania dashboardu „Monitorowanie odstępstw od zasad”. Porównanie rzeczywistej ścieżki workflow ze zdefiniowanym standardem lub oczekiwanym przebiegiem pozwala łatwo wykryć niezgodne z zasadami lub nietypowe przepływy, które mogą wskazywać na naruszenie polityki albo ryzyko operacyjne.
Dlaczego to ważne
Ułatwia analizę zgodności, przedstawiając wariant procesu w postaci czytelnego ciągu, w którym łatwo zauważyć odstępstwa od standardowych procedur.
Skąd pobrać
To pole nie jest standardowe. Należy je wyliczyć podczas transformacji danych, łącząc wartości „ApprovalStep” w kolejności chronologicznej dla każdej sprawy.
Przykłady
Kierownik -> DyrektorKierownik -> Dyrektor -> Wiceprezes ds. finansówKierownik -> Zatwierdzenie automatyczne
|
|||
|
Waluta
Currency
|
Kod waluty, w której podano kwotę zapotrzebowania. | ||
|
Opis
Ten atrybut określa walutę, na przykład USD, EUR lub GBP, w której wyrażono łączną kwotę zapotrzebowania. Ma duże znaczenie w analizie finansowej, zwłaszcza w międzynarodowych organizacjach korzystających z wielu walut. Atrybut waluty pozwala prawidłowo przetwarzać i agregować dane finansowe. Dzięki niemu wartości pieniężne są poprawnie interpretowane, a dane można przeliczać na wspólną walutę, aby rzetelnie raportować i porównywać wyniki w różnych regionach lub jednostkach biznesowych.
Dlaczego to ważne
Zapewnia kontekst niezbędny do interpretacji atrybutów finansowych i prawidłowego agregowania wartości pieniężnych w środowisku wielowalutowym.
Skąd pobrać
To pole znajduje się zwykle w tabeli nagłówków zapotrzebowań zakupu PurchReqTable, obok pól z kwotami.
Przykłady
USDEURGBP
|
|||
|
Zatwierdzone za pierwszym razem
IsFirstPass
|
Flaga wskazująca, czy zapotrzebowanie zatwierdzono bez wcześniejszych zmian lub odrzuceń. | ||
|
Opis
To obliczany atrybut logiczny. Przyjmuje wartość „true”, jeśli na ścieżce do zatwierdzenia zapotrzebowania nie wystąpiły działania „Zmieniono zapotrzebowanie” ani „Odrzucono etap zatwierdzania”. W przeciwnym razie przyjmuje wartość „false”. Atrybut ten bezpośrednio wspiera KPI „Odsetek zapotrzebowań zatwierdzonych za pierwszym razem”. Ułatwia analizę efektywności procesu, wskazując na poziomie sprawy, czy konieczne były poprawki. Niski odsetek zatwierdzeń za pierwszym razem może świadczyć o niskiej jakości danych początkowych lub niejasnych wymaganiach, a tym samym wskazywać możliwość usprawnienia procesu.
Dlaczego to ważne
Bezpośrednio mierzy jakość i efektywność procesu, wskazując sprawy wymagające poprawek, i wspiera KPI dotyczące poprawnego wykonania za pierwszym razem.
Skąd pobrać
To obliczany atrybut. Podczas transformacji danych należy przeanalizować pełną sekwencję działań dla każdej sprawy i sprawdzić, czy przed zatwierdzeniem nie wystąpiły działania związane z poprawkami.
Przykłady
truefalse
|
|||
Działania w procesie obsługi zapotrzebowań w cyklu Purchase-to-Pay
| Działanie | Opis | ||
|---|---|---|---|
|
Akceptacja na etapie procesu
|
Osoba akceptująca wykonuje przypisane zadanie i akceptuje zapotrzebowanie na danym etapie procesu. Zapotrzebowanie przechodzi wtedy do kolejnego etapu lub do końcowej akceptacji. | ||
|
Dlaczego to ważne
Pozwala zmierzyć czas realizacji każdego etapu akceptacji i wskazać sprawnie działające części workflow. Jest też ważnym elementem analizy wariantów procesu.
Skąd pobrać
Zdarzenie jest jawnie rejestrowane w tabeli 'WorkflowTrackingStatusTable', gdy użytkownik kończy zadanie z wynikiem 'Approve'.
Rejestrowanie
W historii workflow wyszukaj zdarzenia 'WorkItemCompleted' z wynikiem 'Approve'.
Typ zdarzenia
explicit
|
|||
|
Akceptacja zapotrzebowania
|
Zapotrzebowanie przeszło wszystkie wymagane etapy akceptacji w workflow. Zdarzenie jest rejestrowane po zakończeniu instancji workflow ze statusem końcowym „Approved”. | ||
|
Dlaczego to ważne
To ważny etap, który kończy cykl akceptacji i rozpoczyna fazę zakupów. Jest zdarzeniem końcowym dla KPI „Czas cyklu akceptacji zapotrzebowania”.
Skąd pobrać
Zdarzenie jest jawnie rejestrowane w tabeli 'WorkflowTrackingStatusTable' po zakończeniu workflow. Aktualizuje też pole 'Status' w tabeli 'PurchReqTable' na 'Approved'.
Rejestrowanie
Wyszukaj zdarzenia 'Completion' workflow ze statusem 'Approved' lub śledź zmianę statusu w tabeli PurchReqTable.
Typ zdarzenia
explicit
|
|||
|
Odrzucenie zapotrzebowania
|
Zapotrzebowanie zostało odrzucone w trakcie workflow akceptacji i nie będzie dalej obsługiwane. Jest to końcowy status niepowodzenia dla danego zapotrzebowania. | ||
|
Dlaczego to ważne
To zdarzenie końcowe jest niezbędne do analizy ogólnego odsetka odrzuceń oraz oceny finansowych i operacyjnych skutków niezaakceptowanych zapotrzebowań.
Skąd pobrać
Zdarzenie jest jawnie rejestrowane w tabeli 'WorkflowTrackingStatusTable' po zakończeniu workflow ze statusem 'Rejected'. Aktualizuje ono pole statusu w tabeli 'PurchReqTable'.
Rejestrowanie
Wyszukaj zdarzenia 'Completion' workflow ze statusem 'Rejected' lub śledź zmianę statusu w tabeli PurchReqTable.
Typ zdarzenia
explicit
|
|||
|
Przekazanie zapotrzebowania do akceptacji
|
Użytkownik przesyła wypełnione zapotrzebowanie, rozpoczynając formalny workflow akceptacji. System rejestruje tę czynność jako jawne zdarzenie w silniku workflow. | ||
|
Dlaczego to ważne
To ważny etap, który rozpoczyna cykl akceptacji. Stanowi punkt początkowy do pomiaru KPI „Czas cyklu akceptacji zapotrzebowania” i „Odsetek akceptacji za pierwszym razem”.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli 'WorkflowTrackingStatusTable' lub podobnej tabeli historii workflow, gdzie dla zapotrzebowania zapisywane jest zdarzenie 'Submission'.
Rejestrowanie
W historii workflow wyszukaj zdarzenia typu 'Submission' lub 'Start' powiązane z zapotrzebowaniem.
Typ zdarzenia
explicit
|
|||
|
Utworzenie zamówienia zakupu
|
Zaakceptowana pozycja zapotrzebowania zakupowego zostaje przekształcona w pozycję zamówienia zakupu, co oznacza przekazanie sprawy do zespołu zakupowego. Zdarzenie można wykryć, łącząc pozycję zapotrzebowania z pozycją zamówienia zakupu. | ||
|
Dlaczego to ważne
To ważny etap łączący zapotrzebowanie z dalszym procesem zakupowym. Jest niezbędny do pomiaru KPI „Czas od zapotrzebowania do zamówienia zakupu”.
Skąd pobrać
Zdarzenie można wywnioskować, znajdując w tabeli 'PurchLine' rekord odwołujący się do identyfikatora 'PurchReqLine' powiązanego z daną sprawą zapotrzebowania.
Rejestrowanie
Połącz tabele PurchReqLine i PurchLine za pomocą pola referencyjnego, np. PurchReqLineRefId.
Typ zdarzenia
inferred
|
|||
|
Utworzenie zapotrzebowania
|
To zdarzenie oznacza utworzenie rekordu zapotrzebowania zakupowego w wersji roboczej. Jest rejestrowane na podstawie timestampu utworzenia nagłówka zapotrzebowania. | ||
|
Dlaczego to ważne
Jako początek procesu ta czynność jest niezbędna do pomiaru całkowitego czasu obsługi zapotrzebowania i analizy dziennej liczby obsługiwanych zapotrzebowań.
Skąd pobrać
Czynność jest określana na podstawie pola 'createdDateTime' w tabeli 'PurchReqTable' dla każdego nowego Purchase Requisition ID.
Rejestrowanie
Użyj timestampu utworzenia rekordu w tabeli PurchReqTable.
Typ zdarzenia
inferred
|
|||
|
Zamknięcie zapotrzebowania
|
Całe zapotrzebowanie zakupowe uznaje się za zakończone, gdy wszystkie jego pozycje zostały przekształcone w zamówienia zakupu lub anulowane. Jest to końcowy status pomyślnej realizacji. | ||
|
Dlaczego to ważne
Ta czynność oznacza pomyślne zakończenie cyklu życia zapotrzebowania. Stanowi końcowy punkt pomiaru całkowitego czasu procesu.
Skąd pobrać
Ten status jest zwykle obliczany lub wywnioskowany. Występuje, gdy wszystkie powiązane rekordy 'PurchReqLine' osiągną status końcowy, na przykład 'Closed' lub 'Cancelled'.
Rejestrowanie
Ustal to zdarzenie, sprawdzając, czy wszystkie podrzędne rekordy PurchReqLine dla danego PurchReqTable mają status końcowy.
Typ zdarzenia
calculated
|
|||
|
Odrzucenie na etapie akceptacji
|
Osoba akceptująca odrzuca przypisane zadanie, zwykle odsyłając zapotrzebowanie do zgłaszającego w celu poprawy. Silnik workflow rejestruje tę czynność jako jawne zdarzenie. | ||
|
Dlaczego to ważne
Ta czynność jest niezbędna do obliczenia odsetka odrzuconych zapotrzebowań i ustalenia, na których etapach najczęściej dochodzi do odrzucenia. Wskazuje też obszary wymagające usprawnienia.
Skąd pobrać
Zdarzenie jest jawnie rejestrowane w tabeli 'WorkflowTrackingStatusTable', gdy użytkownik kończy zadanie z wynikiem 'Reject'.
Rejestrowanie
W historii workflow wyszukaj zdarzenia 'WorkItemCompleted' z wynikiem 'Reject'.
Typ zdarzenia
explicit
|
|||
|
Rozpoczęcie etapu akceptacji
|
W ramach workflow zadanie akceptacji zostaje przypisane konkretnej osobie lub grupie. Oznacza to początek czasu oczekiwania lub realizacji dla danego akceptującego. | ||
|
Dlaczego to ważne
Ta czynność jest niezbędna do analizy wąskich gardeł na etapach akceptacji, ponieważ pozwala mierzyć czas oczekiwania w kolejce na poszczególnych etapach.
Skąd pobrać
Zdarzenie jest rejestrowane w tabeli 'WorkflowTrackingStatusTable', gdy dla instancji workflow danego zapotrzebowania zostaje utworzone i przypisane nowe zadanie.
Rejestrowanie
W historii workflow danego zapotrzebowania wyszukaj zdarzenia 'WorkItemCreated' lub podobne.
Typ zdarzenia
explicit
|
|||
|
Wycofanie zapotrzebowania
|
Osoba zgłaszająca lub upoważniony użytkownik anuluje zapotrzebowanie po jego przesłaniu. Ta czynność kończy workflow i zamyka zgłoszenie. | ||
|
Dlaczego to ważne
Śledzenie wycofań pomaga wykrywać problemy z planowaniem popytu lub nadmiernie złożony proces. Dane te są wykorzystywane w dashboardzie „Analiza wycofanych zapotrzebowań”.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu w tabeli 'PurchReqTable' na 'Cancelled' lub ze zdarzenia 'Cancel' w tabeli 'WorkflowTrackingStatusTable'.
Rejestrowanie
Wykryj zmianę statusu na 'Cancelled' w tabeli PurchReqTable lub zdarzenie anulowania workflow.
Typ zdarzenia
inferred
|
|||
|
Zamknięcie pozycji zapotrzebowania
|
Pojedyncza pozycja zapotrzebowania zakupowego została w pełni obsłużona. Zwykle następuje to po jej całkowitym przekształceniu w zamówienie zakupu. | ||
|
Dlaczego to ważne
Szczegółowe informacje o realizacji zapotrzebowania pomagają ustalić, czy pozycje zostały przekształcone w zamówienia zakupu częściowo, czy w całości.
Skąd pobrać
Zdarzenie można wywnioskować z pola statusu w tabeli 'PurchReqLine' dla danej pozycji. Status wskazujący na zamówienie lub odbiór oznacza zamknięcie pozycji.
Rejestrowanie
Monitoruj pole statusu w tabeli PurchReqLine i wyszukuj wartości końcowe, takie jak 'Invoiced' lub 'Closed'.
Typ zdarzenia
inferred
|
|||
|
Zmiana zapotrzebowania
|
To zdarzenie występuje, gdy użytkownik wycofuje przesłane zapotrzebowanie z workflow, aby je zmienić. Zwykle można je wykryć, identyfikując czynność wycofania, po której następuje ponowne przesłanie. | ||
|
Dlaczego to ważne
Śledzenie zmian pomaga wykrywać konieczność ponownej pracy, niejasne zgłoszenia i nieefektywne działania w procesie. Dane te są bezpośrednio wykorzystywane w dashboardzie „Częstotliwość zmian zapotrzebowań”.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii workflow ('WorkflowTrackingStatusTable'), wykrywając czynność 'Recall' lub 'RequestChange'. Można je też wywnioskować ze zmian pola 'modifiedDateTime' w tabeli 'PurchReqTable' po przesłaniu zapotrzebowania.
Rejestrowanie
Wykryj zdarzenia wycofania z workflow lub zmiany wersji rekordu między kolejnymi przesłaniami.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Ten szablon zawiera wszystko, czego potrzeba, aby rozpocząć optymalizację procesu obsługi zapotrzebowań w cyklu Purchase-to-Pay. Już dziś można zacząć odkrywać przydatne informacje.
Usprawnij proces Purchase to Pay - Requisition i przyspiesz akceptacje
Ogranicz opóźnienia i skróć czas realizacji procesu w Dynamics 365 o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.