Szablon danych dla procesu Purchase to Pay: zapotrzebowania

Coupa
Szablon danych dla procesu Purchase to Pay: zapotrzebowania

Szablon danych dla procesu Purchase to Pay: zapotrzebowania

Ten szablon porządkuje zbieranie danych potrzebnych do analizy procesu Purchase to Pay: zapotrzebowania. Zawiera listę atrybutów i aktywności wymaganych do przygotowania rzetelnego dziennika zdarzeń. Znajdą tu Państwo również wskazówki, jak skutecznie wyeksportować te dane z systemu Coupa.
  • Zalecane atrybuty do szczegółowej analizy
  • Najważniejsze aktywności procesu do śledzenia
  • Praktyczne wskazówki dotyczące eksportu danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu Purchase to Pay: zapotrzebowania

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby szczegółowo analizować proces Purchase to Pay: zapotrzebowania.
5 Wymagane 5 Zalecane 11 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładna data i godzina wystąpienia czynności.
Opis

Czas zdarzenia, czyli znacznik czasu, wskazuje dokładny moment zarejestrowania czynności dotyczącej zapotrzebowania zakupowego. Dane te są niezbędne do uporządkowania zdarzeń chronologicznie i odtworzenia przebiegu procesu. Stanowią podstawę analiz czasowych, w tym obliczania czasu realizacji, wykrywania wąskich gardeł przez pomiar odstępów między czynnościami oraz oceny wyników procesu w różnych okresach. Rzetelna analiza wymaga dokładnych znaczników czasu.

Dlaczego to ważne

Ten znacznik czasu pozwala prawidłowo uporządkować zdarzenia i obliczyć wszystkie miary czasu, takie jak czas realizacji i czas trwania wąskich gardeł.

Skąd pobrać

Informacje te są zapisywane w ścieżce audytu lub historii każdego zapotrzebowania w systemie Coupa, często w polu „created_at” lub „updated_at” dla danej czynności.

Przykłady
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
Identyfikator zapotrzebowania zakupowego
PurchaseRequisitionId
Unikalny identyfikator każdego zapotrzebowania zakupowego, używany jako główny identyfikator sprawy w procesie.
Opis

Identyfikator zapotrzebowania zakupowego to główny klucz łączący wszystkie czynności dotyczące jednego wniosku o towary lub usługi. Każde zapotrzebowanie otrzymuje unikalny identyfikator podczas tworzenia, który pozostaje niezmienny przez cały cykl życia sprawy. Umożliwia to śledzenie zapotrzebowania od utworzenia i przesłania, przez kolejne etapy zatwierdzania lub odrzucenia, aż po przekazanie do pozyskania ofert i zamknięcie. W process mining każdy wpis w dzienniku zdarzeń jest powiązany z tym identyfikatorem, co pozwala odtworzyć pełny przebieg każdej sprawy.

Dlaczego to ważne

To podstawowy identyfikator sprawy, który łączy wszystkie etapy procesu i umożliwia pełną analizę cyklu życia zapotrzebowania.

Skąd pobrać

To pole klucza głównego w module Requisitions systemu Coupa oraz powiązanych eksportach danych.

Przykłady
PR-102934PR-102935PR-102936
Nazwa czynności
ActivityName
Nazwa konkretnej czynności biznesowej lub zdarzenia, które miało miejsce w określonym czasie w ramach obsługi zapotrzebowania.
Opis

Ten atrybut zapisuje poszczególne etapy cyklu życia zapotrzebowania zakupowego. Przykłady to „Utworzono zapotrzebowanie”, „Zatwierdzono etap” i „Przekazano zapotrzebowanie do pozyskania ofert”. Każda czynność oznacza konkretny etap lub działanie dotyczące zapotrzebowania. Analiza kolejności i częstotliwości tych czynności jest podstawą process mining. Pozwala wizualizować mapy procesów, wskazywać typowe ścieżki i wykrywać odstępstwa od standardowej procedury.

Dlaczego to ważne

Określa etapy na mapie procesu, dzięki czemu można wizualizować i analizować przebieg obsługi zapotrzebowań.

Skąd pobrać

Dane pochodzą zwykle z dzienników zdarzeń, zapisów zmian statusu lub ścieżek audytu w systemie Coupa. Może być konieczne mapowanie pól statusu lub kodów czynności.

Przykłady
Utworzenie zgłoszenia zakupowegoWysłanie zgłoszenia zakupowegoZatwierdzenie etapu akceptacjiOdrzucono zapotrzebowanieUtworzono zamówienie zakupu
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane z systemu źródłowego.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z systemu Coupa. Informuje, jak aktualne są analizowane dane. Dzięki temu użytkownicy mogą ocenić, czy wyniki odzwierciedlają bieżący stan operacji, czy wcześniejszy okres. Ma to szczególne znaczenie w dashboardach monitorujących bieżące operacje.

Dlaczego to ważne

Informuje użytkowników o aktualności danych, dzięki czemu mogą uwzględnić okres objęty analizą i podejmować decyzje na podstawie aktualnych informacji.

Skąd pobrać

Ten znacznik czasu jest generowany i dodawany przez potok danych lub narzędzie ETL po pomyślnym zakończeniu pobierania danych.

Przykłady
2024-05-21T02:00:00Z
System źródłowy
SourceSystem
Wskazuje system, z którego pobrano dane.
Opis

Ten atrybut wskazuje system, w którym powstały analizowane dane procesowe. W tej analizie jego wartością będzie zawsze „Coupa”. Warto uwzględniać to pole, zwłaszcza gdy dane pochodzą z kilku systemów. Informacja o źródle danych ułatwia śledzenie ich pochodzenia oraz zarządzanie zasadami ładu i jakości danych.

Dlaczego to ważne

Ułatwia śledzenie pochodzenia danych, co ma znaczenie dla ładu danych i łączenia informacji z wielu systemów firmowych.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas pobierania i przekształcania danych w celu oznaczenia źródła zbioru.

Przykłady
Coupa
Dział
Department
Dział firmy lub centrum kosztów, na które przypisano zapotrzebowanie.
Opis

Atrybut Dział łączy każde zapotrzebowanie z konkretną jednostką organizacyjną lub centrum kosztów. Umożliwia porównywanie wyników między działami. Dashboardy i KPI można filtrować oraz dzielić według działu, aby porównywać czas zatwierdzania, odsetek odrzuceń i zgodność w różnych częściach organizacji. Ułatwia to wykrywanie problemów i dobrych praktyk charakterystycznych dla poszczególnych działów.

Dlaczego to ważne

Umożliwia porównywanie KPI procesu, takich jak czas realizacji i odsetek odrzuceń, między jednostkami biznesowymi oraz wskazywanie obszarów do poprawy.

Skąd pobrać

To standardowe pole obiektu Requisition w systemie Coupa, często powiązane z profilem wnioskodawcy lub określone na poziomie pozycji zapotrzebowania.

Przykłady
MarketingOperacje ITAdministracja obiektamiBadania i rozwój
Łączna kwota
TotalAmount
Łączna wartość pieniężna zapotrzebowania zakupowego.
Opis

Ten atrybut określa łączny koszt wszystkich towarów i usług ujętych w zapotrzebowaniu. Kwota ma znaczenie dla analizy procesu, ponieważ często wpływa na złożoność workflow zatwierdzania. Zapotrzebowania o wyższej wartości zwykle wymagają większej liczby etapów zatwierdzania. Analiza miar procesu według przedziałów kwotowych, na przykład poniżej 1 000 USD lub od 1 000 do 10 000 USD, pokazuje, jak obsługiwane są zapotrzebowania o różnej wartości.

Dlaczego to ważne

Pomaga analizować różnice w obsłudze zapotrzebowań o różnych wartościach, ponieważ wyższe kwoty często uruchamiają bardziej złożone workflow zatwierdzania.

Skąd pobrać

To standardowe pole w nagłówku obiektu Requisition w systemie Coupa, zwykle nazwane „total” lub „total_amount”.

Przykłady
500.0012550.7599.99
Osoba zatwierdzająca
Approver
Użytkownik lub grupa odpowiedzialna za zatwierdzenie.
Opis

Ten atrybut wskazuje konkretną osobę lub grupę przypisaną do etapu zatwierdzania. Jest wypełniany dla czynności takich jak „Rozpoczęto etap zatwierdzania”, „Zatwierdzono etap” i „Odrzucono etap”. Analiza danych według osób zatwierdzających pozwala przygotować dashboard „Wyniki i obciążenie osób zatwierdzających”. Ułatwia pomiar czasu zatwierdzania, wykrywanie wąskich gardeł powodowanych przez konkretne osoby oraz ocenę rozkładu obciążenia.

Dlaczego to ważne

Pomaga analizować pracę osób zatwierdzających, równoważyć obciążenie i wykrywać wąskie gardła związane z konkretnymi osobami lub grupami.

Skąd pobrać

Informacje te znajdują się w szczegółach ścieżki zatwierdzania powiązanej z każdym zapotrzebowaniem w systemie Coupa. Może być konieczne połączenie z danymi użytkowników.

Przykłady
David MillerGrupa zatwierdzająca: finanse, poziom 2Susan Chen
Status zapotrzebowania
RequisitionStatus
Bieżący lub końcowy status zapotrzebowania zakupowego.
Opis

Ten atrybut wskazuje ogólny stan zapotrzebowania w chwili pobrania danych albo jego końcowy wynik. Typowe statusy to „Oczekuje na zatwierdzenie”, „Zatwierdzono”, „Odrzucono”, „Wycofano” i „Zamknięto”. To ważny wymiar filtrowania i analizy. Pozwala obliczać odsetek zatwierdzeń i odrzuceń, monitorować bieżące obciążenie otwartymi zapotrzebowaniami oraz sprawdzać, jak zakończyły się poszczególne sprawy.

Dlaczego to ważne

Pomaga oceniać wyniki obsługi zapotrzebowań, obliczać odsetek zatwierdzeń i odrzuceń oraz monitorować bieżący stan spraw w toku.

Skąd pobrać

To standardowe pole obiektu Purchase Requisition w systemie Coupa, często nazwane „status” lub „state”.

Przykłady
Oczekuje na zatwierdzenieZatwierdzonoOdrzuconoWycofanoZamknięto
Wnioskodawca
Requester
Pracownik, który utworzył i przesłał zapotrzebowanie zakupowe.
Opis

Ten atrybut wskazuje osobę, która zainicjowała wniosek. Analiza danych według wnioskodawcy pomaga wykrywać wzorce dotyczące konkretnych użytkowników, na przykład częste poprawki lub odrzucenia, które mogą wskazywać na potrzebę dodatkowego szkolenia. Umożliwia też analizę liczby zapotrzebowań i przebiegu procesu dla poszczególnych użytkowników lub grup.

Dlaczego to ważne

Umożliwia analizę przebiegu procesu według użytkownika, co pomaga określić potrzeby szkoleniowe i zrozumieć, jak poszczególne osoby korzystają z procesu.

Skąd pobrać

To standardowe pole obiektu Requisition w systemie Coupa, często powiązane z obiektem User i nazwane „requester” lub „created_by”.

Przykłady
Alice JohnsonBob SmithCharlie Brown
Czas trwania etapu zatwierdzania
ApprovalStepDuration
Czas oczekiwania zapotrzebowania na pojedynczym etapie zatwierdzania.
Opis

Ta obliczana miara określa czas między czynnością „Rozpoczęto etap zatwierdzania” a odpowiadającą jej czynnością „Zatwierdzono etap” lub „Odrzucono etap”. Pokazuje czas oczekiwania na każdym etapie ścieżki zatwierdzania. Jest potrzebna do dashboardu „Wąskie gardła na etapach zatwierdzania”, ponieważ wskazuje, które osoby lub etapy powodują największe opóźnienia w całym procesie.

Dlaczego to ważne

Wskazuje konkretne wąskie gardła w workflow zatwierdzania, mierząc czas oczekiwania na każdym etapie, a nie tylko łączny czas realizacji.

Skąd pobrać

Wartość oblicza się w narzędziu process mining, mierząc różnicę czasu między zdarzeniami „Rozpoczęto etap zatwierdzania” i następującym po nim końcowym zdarzeniem zatwierdzenia („Zatwierdzono” lub „Odrzucono”).

Przykłady
1,2 dnia4 godziny3,8 dnia
Czy wprowadzono poprawki
IsAmended
Wartość logiczna ustawiona na true, jeśli po pierwszym przesłaniu zapotrzebowanie poprawiono co najmniej raz.
Opis

Ten obliczany atrybut to prosta flaga (True/False), która wskazuje, czy w danej sprawie wystąpiła czynność „Poprawiono zapotrzebowanie”. Ułatwia analizę i filtrowanie, pozwalając szybko wyodrębnić zapotrzebowania wymagające zmian. Służy do obliczania KPI odsetka zapotrzebowań wymagających poprawek oraz zasilania dashboardu „Liczba zapotrzebowań wymagających poprawek”. Pomaga ustalić przyczyny ponownej pracy i poprawić jakość za pierwszym razem.

Dlaczego to ważne

Ułatwia obliczanie KPI dotyczącego odsetka poprawek i dzielenie spraw na wymagające ponownej pracy oraz niewymagające zmian.

Skąd pobrać

Wartość oblicza się w narzędziu process mining, sprawdzając, czy w dzienniku zdarzeń danej sprawy występuje czynność „Poprawiono zapotrzebowanie”.

Przykłady
truefalse
Identyfikator zamówienia zakupu
PurchaseOrderId
Identyfikator zamówienia zakupu utworzonego na podstawie zatwierdzonego zapotrzebowania.
Opis

Po pełnym zatwierdzeniu zapotrzebowania i zakończeniu pozyskiwania ofert zwykle tworzone jest zamówienie zakupu. Ten atrybut przechowuje identyfikator utworzonego zamówienia. Łączy wcześniejszy proces obsługi zapotrzebowania z dalszym procesem obsługi zamówienia zakupu. Umożliwia obliczenie KPI „Czas od zatwierdzenia zapotrzebowania do utworzenia zamówienia zakupu” oraz szerszą analizę całego cyklu Purchase-to-Pay.

Dlaczego to ważne

Łączy zapotrzebowanie z późniejszym zamówieniem zakupu, umożliwiając analizę czasu przekazania sprawy i szerszą analizę całego procesu P2P.

Skąd pobrać

To standardowe pole obiektu Requisition w systemie Coupa, wypełniane po utworzeniu zamówienia zakupu.

Przykłady
PO-45000123PO-45000124PO-45000125
Kategoria zakupowa
Commodity
Ogólna kategoria zamawianych towarów lub usług.
Opis

Atrybut Kategoria zakupowa przypisuje pozycjom zapotrzebowania ujednoliconą klasyfikację, na przykład „Artykuły biurowe”, „Sprzęt komputerowy” lub „Usługi marketingowe”. Umożliwia analizę wzorców zakupowych i różnic w przebiegu procesu zależnie od przedmiotu zakupu. Niektóre kategorie mogą wymagać specjalnych zatwierdzeń lub strategii pozyskiwania ofert. Analiza procesu według kategorii pomaga usprawniać zakupy w różnych grupach wydatków.

Dlaczego to ważne

Pomaga analizować kategorie wydatków i sprawdzać, czy przebieg procesu, na przykład czas zatwierdzania, zależy od rodzaju kupowanych towarów lub usług.

Skąd pobrać

To standardowe pole w systemie Coupa, zwykle dostępne na poziomie pozycji zapotrzebowania. Może być konieczne zagregowanie danych do poziomu nagłówka.

Przykłady
Artykuły biuroweSprzęt komputerowyUsługi marketingowePodróże służbowe
Liczba etapów zatwierdzania
ApprovalStepCount
Łączna liczba etapów zatwierdzania, przez które przeszło zapotrzebowanie.
Opis

Ten obliczany atrybut zlicza odrębne wystąpienia aktywności „Zatwierdzono etap zatwierdzania” dla każdego zapotrzebowania. Pozwala określić złożoność workflow zatwierdzania poszczególnych spraw. Na tej podstawie obliczany jest KPI „Średnia liczba etapów zatwierdzania”. Atrybut pomaga też wykrywać zapotrzebowania przechodzące nietypowo długą lub złożoną ścieżkę zatwierdzania, co może wskazywać na potrzebę uproszczenia workflow.

Dlaczego to ważne

Określa złożoność workflow zatwierdzania poszczególnych zapotrzebowań i pomaga wykrywać nadmiernie złożone ścieżki, które warto uprościć.

Skąd pobrać

Wartość oblicza się w narzędziu process mining, zliczając wystąpienia aktywności „Zatwierdzono etap zatwierdzania” dla każdego identyfikatora sprawy.

Przykłady
253
Nazwa dostawcy
SupplierName
Nazwa dostawcy wybranego dla zapotrzebowania.
Opis

Ten atrybut wskazuje dostawcę wybranego dla zamawianych towarów lub usług. Dostawcę może wskazać wnioskodawca albo można go dodać później, podczas pozyskiwania ofert. Analiza miar procesu według dostawcy pomaga ocenić jego wyniki i sprawdzić, czy współpraca z niektórymi dostawcami wydłuża czas realizacji lub powoduje inne problemy. Dostarcza też informacji przydatnych przy planowaniu zakupów i zarządzaniu relacjami z dostawcami.

Dlaczego to ważne

Umożliwia analizę wyników procesu według wybranego dostawcy, co może pomóc w planowaniu pozyskiwania ofert i zarządzaniu dostawcami.

Skąd pobrać

Informacje te są dostępne w obiekcie Requisition Line w systemie Coupa, często w polu „supplier” lub „vendor”.

Przykłady
StaplesDell TechnologiesAccentureCDW
Poziom pilności
UrgencyLevel
Klasyfikacja określająca pilność zapotrzebowania, na przykład „Wysoka”, „Średnia” lub „Niska”.
Opis

Poziom pilności, często przypisany do pola priorytetu, pozwala wnioskodawcom oznaczać sprawy wymagające szybszej obsługi. Ten atrybut jest potrzebny do dashboardu „Czas obsługi pilnych zapotrzebowań”. Porównanie czasu realizacji pilnych zapotrzebowań ze standardowymi pozwala ocenić skuteczność ustalania priorytetów i sprawdzić, czy pilne potrzeby biznesowe są zaspokajane na czas.

Dlaczego to ważne

Pozwala sprawdzić, czy pilne wnioski są obsługiwane szybciej niż standardowe, i ocenić skuteczność zasad ustalania priorytetów.

Skąd pobrać

Może to być standardowe lub niestandardowe pole obiektu Requisition w systemie Coupa. Szczegóły można sprawdzić w dokumentacji Coupa lub konfiguracji systemu.

Przykłady
WysokaŚredniaNiska
Przyczyna odrzucenia
RejectionReason
Powód podany przez osobę zatwierdzającą przy odrzuceniu zapotrzebowania lub etapu zatwierdzania.
Opis

Osoba zatwierdzająca często podaje powód odrzucenia zapotrzebowania. Ten atrybut zapisuje wyjaśnienie. Analiza przyczyn odrzuceń dostarcza bezpośrednich informacji o tym, dlaczego zapotrzebowania nie przechodzą procesu. Pomaga ustalić źródłowe przyczyny, takie jak błędne przypisanie kosztów, brak budżetu lub niewystarczające uzasadnienie. Można je następnie ograniczać przez szkolenia lub usprawnienia procesu.

Dlaczego to ważne

Pomaga ustalić źródłowe przyczyny niepowodzeń procesu i wskazać obszary wymagające szkoleń użytkowników lub doprecyzowania procedur.

Skąd pobrać

Informacje te są zwykle zapisywane w polu komentarzy lub notatek powiązanym ze zmianą statusu na „Odrzucono” w historii zatwierdzania zapotrzebowania.

Przykłady
Nieprawidłowe centrum kosztówPrzekroczono budżet na ten kwartałDuplikat wnioskuBrak wystarczającego uzasadnienia
Ścieżka workflow zatwierdzania
ApprovalWorkflowPath
Identyfikator konkretnej ścieżki zatwierdzania lub szablonu workflow przypisanego do zapotrzebowania.
Opis

Ten atrybut wskazuje z góry określoną kolejność osób zatwierdzających, którą powinno przejść zapotrzebowanie. Wyznaczają ją reguły biznesowe, często na podstawie takich czynników jak kwota, dział i typ zapotrzebowania. Analiza tego atrybutu jest podstawą dashboardu „Zgodność zapotrzebowań z zasadami”. Porównanie rzeczywistej kolejności zatwierdzania z przypisaną ścieżką workflow pozwala wykrywać odstępstwa, mierzyć zgodność i identyfikować wyjątki, które nie są odpowiednio zarządzane.

Dlaczego to ważne

Umożliwia analizę zgodności przez porównanie oczekiwanych i rzeczywistych etapów zatwierdzania oraz wskazanie odstępstw od procesu.

Skąd pobrać

Należy sprawdzić dokumentację Coupa. Informację można uzyskać z nazwy ścieżki zatwierdzania lub reguły workflow uruchomionej dla zapotrzebowania.

Przykłady
Standardowe zatwierdzanie poniżej 5 000 USDZatwierdzanie sprzętu IT powyżej 10 000 USDPrzegląd nakładów inwestycyjnych przez dyrektora finansowego
Typ zapotrzebowania
RequisitionType
Kategoria lub typ zapotrzebowania, na przykład „Nakłady inwestycyjne”, „Koszty operacyjne” lub „Oprogramowanie”.
Opis

Typ zapotrzebowania to klasyfikacja, która grupuje zapotrzebowania według celu biznesowego lub rodzaju zakupu. Atrybut ten przydaje się w analizie zgodności i pozwala sprawdzić, jak różne rodzaje wniosków przechodzą przez proces. Na przykład wnioski dotyczące nakładów inwestycyjnych mogą wymagać bardziej rygorystycznej i dłuższej ścieżki zatwierdzania niż standardowe wnioski operacyjne. Analiza procesu według typu zapotrzebowania może wskazać możliwości jego usprawnienia.

Dlaczego to ważne

Pozwala dzielić analizę według celu biznesowego wniosku, ponieważ różne typy mogą podlegać innym ścieżkom procesu i zasadom.

Skąd pobrać

To prawdopodobnie standardowe lub niestandardowe pole klasyfikacji obiektu Requisition w systemie Coupa.

Przykłady
Nakłady inwestycyjneKoszty operacyjneSprzęt ITUsługi profesjonalne
Waluta
Currency
Kod waluty, w której podano łączną kwotę zapotrzebowania.
Opis

Ten atrybut określa walutę, na przykład USD, EUR lub GBP, w której podano łączną kwotę zapotrzebowania. Jest niezbędny do analiz finansowych, zwłaszcza w organizacjach międzynarodowych korzystających z wielu walut. Pozwala prawidłowo interpretować kwoty oraz przeliczać je i agregować w raportach finansowych i dashboardach.

Dlaczego to ważne

Uzupełnia atrybut „Łączna kwota” o kontekst walutowy, co pozwala rzetelnie analizować finanse w środowisku wielowalutowym.

Skąd pobrać

To standardowe pole obiektu Requisition w systemie Coupa, zwykle nazwane „currency_code” lub podobnie.

Przykłady
USDEURGBP
Wymagane Zalecane Opcjonalne

Aktywności w procesie Purchase to Pay: zapotrzebowania

Poniżej przedstawiono najważniejsze etapy i punkty kontrolne, które należy uwzględnić w dzienniku zdarzeń, aby prawidłowo odkryć przebieg workflow zapotrzebowań w procesie Purchase to Pay.
6 Zalecane 6 Opcjonalne
Działanie Opis
Odrzucono zapotrzebowanie
Zapotrzebowanie zostaje ostatecznie odrzucone w trakcie zatwierdzania i nie zostanie przekształcone w zamówienie zakupu. Zdarzenie można wywnioskować ze zmiany ogólnego statusu nagłówka zapotrzebowania na „rejected”.
Dlaczego to ważne

Ta czynność oznacza niepowodzenie i koniec procesu. Analiza takich zdarzeń pomaga obniżyć „odsetek odrzuconych zapotrzebowań” oraz ustalić przyczyny, takie jak naruszenie zasad lub problemy budżetowe.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu w tabeli „requisition_headers”, gdy pole „status” przyjmuje wartość „rejected”. Znacznik czasu jest zapisany w powiązanej ścieżce audytu.

Rejestrowanie

Należy ustalić znacznik czasu zmiany ogólnego statusu zapotrzebowania na „rejected”.

Typ zdarzenia inferred
Utworzenie zgłoszenia zakupowego
Użytkownik rozpoczyna nowe zgłoszenie zakupowe i zapisuje je jako wersję roboczą. To początek każdego przypadku obsługi zgłoszenia. Zdarzenie można zwykle ustalić na podstawie znacznika czasu utworzenia rekordu zgłoszenia.
Dlaczego to ważne

To zdarzenie rozpoczyna cykl życia zgłoszenia. Analiza czasu od utworzenia do wysłania może ujawnić opóźnienia wynikające z niepewności użytkownika lub złożoności systemu.

Skąd pobrać

Zdarzenie jest rejestrowane na podstawie znacznika czasu „created-at” w tabeli „requisition_headers” dla danego identyfikatora zgłoszenia zakupowego.

Rejestrowanie

Użyj znacznika czasu utworzenia rekordu nagłówka zgłoszenia.

Typ zdarzenia inferred
Utworzono zamówienie zakupu
Na podstawie zatwierdzonego zapotrzebowania utworzono zamówienie zakupu (PO). Zdarzenie można wywnioskować z utworzenia rekordu PO zawierającego identyfikator zapotrzebowania źródłowego.
Dlaczego to ważne

To główny pomyślny rezultat procesu obsługi zapotrzebowania i moment przekazania sprawy do kolejnego etapu procesu Purchase-to-Pay. Analiza czasu od „Zatwierdzono zapotrzebowanie” do tego zdarzenia pozwala wykryć opóźnienia w realizacji.

Skąd pobrać

Zdarzenie można wywnioskować z utworzenia rekordu w tabeli „purchase_orders”, który zawiera odwołanie do identyfikatora źródłowego rekordu „requisition_headers” lub „requisition_lines”.

Rejestrowanie

Należy użyć znacznika czasu „created-at” rekordu PO powiązanego z identyfikatorem zapotrzebowania.

Typ zdarzenia inferred
Wysłanie zgłoszenia zakupowego
Osoba składająca zgłoszenie formalnie wysyła je do workflow akceptacji. Zdarzenie można ustalić na podstawie zmiany statusu zgłoszenia z „draft” na „pending_approval” w dzienniku audytowym lub tabelach historii systemu.
Dlaczego to ważne

Wysłanie zgłoszenia rozpoczyna proces akceptacji i stanowi ważny punkt pomiaru KPI „średni czas akceptacji zgłoszenia zakupowego”. Opóźnienia przed tym etapem wynikają z działań użytkownika, a po nim z przebiegu procesu.

Skąd pobrać

Zdarzenie można ustalić na podstawie zmiany statusu w tabeli „requisition_headers”, gdy pole „status” przyjmuje wartość „pending_approval”. Znacznik czasu tej zmiany znajduje się w powiązanym dzienniku audytowym.

Rejestrowanie

Ustal znacznik czasu pierwszej zmiany statusu zgłoszenia na „pending_approval”.

Typ zdarzenia inferred
Zamknięto zapotrzebowanie
Zapotrzebowanie zostaje formalnie zamknięte, co oznacza, że nie będą już podejmowane żadne działania w tej sprawie. Może do tego dojść po utworzeniu i realizacji zamówienia zakupu albo po anulowaniu zapotrzebowania po zatwierdzeniu, ale przed złożeniem zamówienia.
Dlaczego to ważne

Ta czynność jednoznacznie kończy cykl życia zapotrzebowania. Dzięki niej sprawy mają wyraźny koniec i nie pozostają bezterminowo oznaczone jako „aktywne” w analizie procesu.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu w tabeli „requisition_headers”, gdy pole „status” przyjmuje wartość „closed”. Znacznik czasu jest zapisany w powiązanej ścieżce audytu.

Rejestrowanie

Należy ustalić znacznik czasu zmiany ogólnego statusu zapotrzebowania na „closed”.

Typ zdarzenia inferred
Zatwierdzono zapotrzebowanie
Zapotrzebowanie przeszło wszystkie wymagane etapy workflow zatwierdzania. Zdarzenie można wywnioskować ze zmiany ogólnego statusu nagłówka zapotrzebowania na „approved”.
Dlaczego to ważne

To ważny etap potwierdzający pomyślne zakończenie cyklu zatwierdzania. Czas do jego osiągnięcia jest jednym z głównych KPI, a samo zatwierdzenie uruchamia dalsze działania zakupowe.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu w tabeli „requisition_headers”, gdy pole „status” przyjmuje wartość „approved”. Znacznik czasu jest zapisany w powiązanej ścieżce audytu.

Rejestrowanie

Należy ustalić znacznik czasu zmiany ogólnego statusu zapotrzebowania na „approved”.

Typ zdarzenia inferred
Odrzucono etap zatwierdzania
Osoba zatwierdzająca odrzuca zapotrzebowanie na swoim etapie workflow. Zwykle odsyła je do wnioskodawcy w celu wprowadzenia poprawek. Coupa rejestruje tę jawną czynność.
Dlaczego to ważne

Odrzucenie na dowolnym etapie powoduje konieczność ponownej pracy i wydłuża czas realizacji. Analiza miejsca i przyczyn odrzuceń pomaga ulepszać proces i planować szkolenia użytkowników.

Skąd pobrać

Dane pochodzą z jawnej czynności „reject”, zapisanej w tabeli „approvals” lub jej ścieżce audytu i powiązanej z konkretnym zapotrzebowaniem oraz osobą zatwierdzającą.

Rejestrowanie

W historii zatwierdzania zapotrzebowania należy wyszukać zdarzenia „reject”.

Typ zdarzenia explicit
Przekazano zapotrzebowanie do pozyskania ofert
Zatwierdzone zapotrzebowanie trafia do procesu pozyskiwania ofert, na przykład zapytania ofertowego (RFQ) lub aukcji, zamiast od razu zostać przekształcone w zamówienie zakupu. Zdarzenie można wywnioskować z powiązania zapotrzebowania z obiektem procesu pozyskiwania ofert.
Dlaczego to ważne

Ta czynność pokazuje istotną alternatywną ścieżkę w procesie zakupowym. Pozwala odróżnić proste zakupy od bardziej złożonych, strategicznych działań związanych z pozyskiwaniem ofert i dokładniej analizować czas realizacji.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu na „sourcing” lub utworzenia powiązania między tabelą „requisition_lines” a tabelą zdarzeń związanych z pozyskiwaniem ofert.

Rejestrowanie

Należy sprawdzić, czy status zmienił się na „sourcing” lub czy utworzono powiązanie z identyfikatorem zdarzenia związanego z pozyskiwaniem ofert.

Typ zdarzenia inferred
Rozpoczęcie etapu akceptacji
Zadanie akceptacji zostaje przypisane konkretnej osobie lub grupie zatwierdzającej, a zgłoszenie oczekuje na ich działanie. Zdarzenie można ustalić, gdy dla zgłoszenia zostaje utworzony rekord akceptacji ze statusem „pending”.
Dlaczego to ważne

To początek czasu oczekiwania na konkretną akceptację. Pomiar czasu między tym zdarzeniem a odpowiadającym mu zdarzeniem „etap akceptacji zatwierdzony/odrzucony” pomaga wykryć wąskie gardła w łańcuchu akceptacji.

Skąd pobrać

Zdarzenie można ustalić na podstawie znacznika czasu utworzenia rekordu w tabeli „approvals” powiązanego ze zgłoszeniem, w którym status działania osoby zatwierdzającej ma wartość „pending” lub równoważną.

Rejestrowanie

Użyj znacznika czasu utworzenia oczekującego rekordu akceptacji danej osoby w łańcuchu akceptacji.

Typ zdarzenia inferred
Wycofano zapotrzebowanie
Wnioskodawca anuluje zapotrzebowanie przed uzyskaniem ostatecznej akceptacji. To jawna czynność użytkownika, która kończy proces dla danego zapotrzebowania.
Dlaczego to ważne

Wycofanie może oznaczać zmianę potrzeb biznesowych, duplikat wniosku lub próbę ominięcia procesu. Śledzenie takich przypadków pomaga ocenić zmienność zapotrzebowania i wykryć problemy z przestrzeganiem procedur.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu w tabeli „requisition_headers” na „withdrawn” lub podobny stan. Zmiana wynika z jawnej czynności użytkownika zapisanej w ścieżce audytu.

Rejestrowanie

Należy ustalić znacznik czasu zmiany statusu zapotrzebowania na „withdrawn”.

Typ zdarzenia inferred
Zatwierdzenie etapu akceptacji
Osoba zatwierdzająca na danym etapie workflow zatwierdza zapotrzebowanie. System rejestruje tę jawną czynność wraz z dokładnym znacznikiem czasu i informacją o użytkowniku.
Dlaczego to ważne

Ta czynność pozwala szczegółowo analizować przebieg procesu zatwierdzania. Zestawienie tych etapów umożliwia obliczenie „średniego czasu oczekiwania na zatwierdzenie na każdym etapie” oraz analizę pracy osób zatwierdzających.

Skąd pobrać

Dane pochodzą z jawnej czynności „approve”, zapisanej w tabeli „approvals” lub jej ścieżce audytu i powiązanej z konkretnym zapotrzebowaniem oraz osobą zatwierdzającą.

Rejestrowanie

W historii zatwierdzania zapotrzebowania należy wyszukać zdarzenia „approve”.

Typ zdarzenia explicit
Zmiana zgłoszenia zakupowego
Po wysłaniu zgłoszenie edytuje osoba składająca je lub inny uprawniony użytkownik. Coupa rejestruje taką zmianę jako nową wersję lub wpis w dzienniku audytowym. Często powoduje to ponowne uruchomienie części lub całości workflow akceptacji.
Dlaczego to ważne

Śledzenie zmian pomaga zrozumieć dodatkową pracę i nieefektywność procesu. Duża liczba zmian może wskazywać na niejasne wymagania początkowe lub złożoną politykę zakupową, co wpływa na KPI „wskaźnik zmian w zgłoszeniach zakupowych”.

Skąd pobrać

Dane pochodzą z tabel dziennika audytowego powiązanych z tabelą „requisition_headers”, w których rejestrowane są zmiany wersji lub konkretne działania „edit”.

Rejestrowanie

Po wysłaniu zgłoszenia poszukaj w jego historii jawnych zdarzeń „edit” lub „update”.

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje eksportu danych

Jak pobrać dane z Coupa

Gotowi do rozpoczęcia?

Zacznij już dziś usprawniać proces Purchase to Pay: zapotrzebowania w Coupa, korzystając z tego szablonu. Uzyskaj przydatne informacje i zwiększ efektywność zakupów.

Usprawnij zapotrzebowania P2P w Coupa i skróć czas realizacji

Wykryj nieefektywności i skróć czas realizacji zapotrzebowań P2P o 30%.

Rozpocznij bezpłatny okres próbny

Nie trzeba podawać danych karty płatniczej. Usprawnienia można wprowadzić w kilka minut.