Szablon danych dotyczących zapotrzebowań w cyklu Purchase-to-Pay

Microsoft Dynamics 365
Szablon danych dotyczących zapotrzebowań w cyklu Purchase-to-Pay

Szablon danych dotyczących zapotrzebowań w cyklu Purchase-to-Pay

Szablon przedstawia najważniejsze atrybuty do zebrania i działania do śledzenia, aby szczegółowo przeanalizować proces obsługi zapotrzebowań. Zawiera też praktyczne wskazówki dotyczące pobierania danych, które ułatwią przygotowanie dziennika zdarzeń do szczegółowej analizy.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące pobierania danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zapotrzebowań w cyklu Purchase-to-Pay

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo przeanalizować proces obsługi zapotrzebowań w cyklu Purchase-to-Pay.
5 Wymagane 6 Zalecane 6 Opcjonalne
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
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi zapotrzebowań w cyklu Purchase-to-Pay

To najważniejsze kroki i punkty kontrolne, które należy uwzględnić w dzienniku zdarzeń, aby prawidłowo odkryć i przeanalizować workflow obsługi zapotrzebowań.
7 Zalecane 5 Opcjonalne
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
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Microsoft Dynamics 365

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%.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.