Szablon danych dla procesu Purchase to Pay: zapotrzebowania
Szablon danych dla procesu Purchase to Pay: zapotrzebowania
- Zalecane atrybuty do szczegółowej analizy
- Najważniejsze aktywności procesu do śledzenia
- Praktyczne wskazówki dotyczące eksportu danych
Atrybuty procesu Purchase to Pay: zapotrzebowania
| 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
|
|||
Aktywności w procesie Purchase to Pay: zapotrzebowania
| 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
|
|||
Instrukcje eksportu danych
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%.
Nie trzeba podawać danych karty płatniczej. Usprawnienia można wprowadzić w kilka minut.