Szablon danych dla procesu od zakupu do płatności: zapotrzebowanie
Szablon danych dla procesu od zakupu do płatności: zapotrzebowanie
To ogólny szablon danych do process mining dla procesu Purchase to Pay: zapotrzebowania. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.
Wybierz konkretny system- Ujednolicone pola danych ułatwiające spójną analizę w różnych systemach.
- Lista najważniejszych czynności, które warto śledzić, aby uzyskać pełny obraz procesu.
- Elastyczna podstawa, którą można dostosować do specyfiki workflow obsługi zapotrzebowań w procesie od zakupu do płatności.
Atrybuty procesu od zakupu do płatności: zapotrzebowanie
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładna data i godzina wystąpienia działania. To podstawowy timestamp służący do ustalania kolejności zdarzeń. | ||
| Opis Czas zdarzenia, nazywany też timestampem, wskazuje dokładny moment wykonania działania. Te dane są niezbędne do prawidłowego uporządkowania zdarzeń i wszystkich analiz czasowych procesu, w tym obliczania czasu realizacji, wykrywania wąskich gardeł i monitorowania wyników. W process mining timestampy służą do porządkowania działań w każdym case i mierzenia czasu między poszczególnymi krokami. Analiza tych okresów pomaga wykrywać opóźnienia, ustalać przyczyny długiego czasu realizacji i sprawdzać, czy dotrzymywane są uzgodnione poziomy usług. Rzetelna analiza wyników wymaga dokładnych i kompletnych danych o czasie. Dlaczego to ważne Ten timestamp jest niezbędny do ustalania kolejności zdarzeń, obliczania czasu realizacji oraz analizy wyników procesu i wąskich gardeł. Skąd pobrać Zwykle jest zapisywany w ścieżkach audytowych systemu, dziennikach zdarzeń albo jako data utworzenia lub zmiany rekordu transakcji. Przykłady 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| Identyfikator wniosku zakupowego PurchaseRequisitionId | Unikalny identyfikator każdego wniosku zakupowego. Służy jako główny identyfikator case w procesie. | ||
| Opis Identyfikator wniosku zakupowego to unikalny klucz przypisywany każdemu dokumentowi w chwili jego utworzenia. Stanowi główny punkt odniesienia dla wszystkich działań, zmian i akceptacji dotyczących danego wniosku, od rozpoczęcia do zakończenia. W process mining ten identyfikator jest niezbędny do powiązania zdarzeń z case. Pozwala odtworzyć pełny przebieg każdego wniosku i połączyć odrębne zdarzenia, takie jak „Utworzenie wniosku zakupowego”, „Akceptacja etapu” i „Utworzenie zamówienia zakupu”, w spójny przepływ procesu. Bez stałego, unikalnego identyfikatora case nie można analizować wariantów procesu, czasu realizacji ani wyników. Dlaczego to ważne To niezbędny klucz do śledzenia całego cyklu życia wniosku i łączenia wszystkich powiązanych zdarzeń w jedną instancję procesu. Skąd pobrać Zwykle znajduje się w danych nagłówka transakcji wniosku zakupowego lub w tabeli dokumentów. Przykłady PR-100567REQ00043218000123987 | |||
| Nazwa działania ActivityName | Nazwa konkretnego działania biznesowego lub zdarzenia, które miało miejsce w danym momencie obsługi wniosku zakupowego. | ||
| Opis Nazwa działania opisuje pojedynczy krok lub zmianę statusu w cyklu życia wniosku zakupowego. Jest czytelną dla użytkownika etykietą zdarzeń, takich jak „Przesłanie wniosku zakupowego”, „Rozpoczęcie etapu akceptacji” czy „Odrzucenie wniosku zakupowego”. Z takich zdarzeń składa się mapa procesu. Ten atrybut stanowi podstawę odkrywania i analizy procesu. Po uporządkowaniu działań process mining pozwala zwizualizować rzeczywisty przebieg procesu, wykryć odstępstwa od standardowej procedury oraz wskazać wąskie gardła i pętle ponownej pracy. Spójne i zrozumiałe nazwy działań ułatwiają tworzenie czytelnego modelu procesu, na podstawie którego można podejmować działania. Dlaczego to ważne Określa poszczególne kroki procesu, niezbędne do przedstawienia mapy procesu i analizy jego przebiegu. Skąd pobrać Często pochodzi z dzienników zdarzeń, tabel zmian statusu lub kodów transakcji powiązanych z dokumentem wniosku zakupowego. Przykłady Utworzenie zapotrzebowaniaAkceptacja etapuUtworzenie zamówienia zakupu | |||
| Ostatnia aktualizacja danych LastDataUpdate | Timestamp wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone lub pobrane z systemu źródłowego. | ||
| Opis Timestamp ostatniej aktualizacji danych informuje, jak aktualne są analizowane dane. Wskazuje, kiedy rekord został ostatnio pobrany z systemu źródłowego i załadowany do środowiska process mining. Ten atrybut jest niezbędny do monitorowania operacji i sprawdzania, czy analizy opierają się na aktualnych informacjach. Pozwala ocenić opóźnienie między zdarzeniami w rzeczywistym procesie a ich odzwierciedleniem w modelu procesu. Dashboardy i KPI monitorujące bieżące operacje wykorzystują tę informację, aby dostarczać aktualne i przydatne dane. Dlaczego to ważne Informuje o aktualności danych, co pozwala ocenić, czy analizy są miarodajne i oparte na najnowszych informacjach. Skąd pobrać Zwykle dodaje go narzędzie integracji danych lub ETL (Extract, Transform, Load) podczas ładowania danych. Przykłady 2024-05-20T02:00:00Z2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| System źródłowy SourceSystem | Wskazuje system informatyczny, z którego pobrano dane, na przykład ERP lub platformę zakupową. | ||
| Opis Atrybut „System źródłowy” określa pochodzenie danych o procesie. W organizacjach korzystających z wielu systemów, na przykład centralnego ERP i specjalistycznego narzędzia e-procurement, pole to pozwala odróżnić dane z poszczególnych źródeł. Informacja ta pomaga weryfikować dane, rozwiązywać problemy i rozumieć różnice w przebiegu procesu wynikające z używanego systemu. Na przykład wnioski z jednego systemu mogą przechodzić inną ścieżkę akceptacji lub być realizowane szybciej niż wnioski z innego. Analiza według systemu źródłowego może ujawnić problemy z integracją lub możliwości konsolidacji systemów. Dlaczego to ważne Informacja o pochodzeniu danych jest niezbędna do ich weryfikacji i analizy różnic w przebiegu procesu między systemami. Skąd pobrać Często jest to stała wartość dodawana podczas ekstrakcji danych albo informacja z pól metadanych technicznych. Przykłady SAP S/4HANAOracle FusionCoupa | |||
| Dział Department | Dział biznesowy, centrum kosztów lub jednostka organizacyjna, na którą przypisano koszt wniosku. | ||
| Opis Atrybut „Dział” określa jednostkę organizacyjną odpowiedzialną za zakup, na przykład „Marketing”, „IT” lub „Finanse”. To ważna informacja finansowa i organizacyjna wykorzystywana przy budżetowaniu i alokacji kosztów. W process mining często analizuje się dane według działu. Pozwala to porównywać wyniki różnych jednostek biznesowych i ustalić, które działają najsprawniej, a które mogą potrzebować wsparcia. Analiza może ujawnić różnice w czasie realizacji, odsetku akceptacji lub zgodności, wynikające ze specyfiki zakupów albo procesów wewnętrznych danego działu. Dlaczego to ważne Umożliwia porównywanie wyników i analizę kosztów w różnych jednostkach biznesowych, ujawniając różnice w przebiegu procesu zależne od działu. Skąd pobrać Zwykle jest dostępny w danych nagłówka lub pozycji wniosku zakupowego i powiązany ze strukturą organizacyjną firmy. Przykłady MarketingTechnologie informatyczneFinanseOperacje | |||
| Identyfikator zamówienia zakupu PurchaseOrderId | Identyfikator zamówienia zakupu utworzonego na podstawie zaakceptowanego wniosku. | ||
| Opis Identyfikator zamówienia zakupu to unikalny numer dokumentu zamówienia utworzonego na podstawie zaakceptowanego wniosku. To pole łączy proces obsługi wniosku z kolejnymi etapami zakupów i płatności. Ten atrybut jest niezbędny do analizy sprawności przekształcania wniosków w zamówienia zakupu. Potwierdza, że wniosek doprowadził do utworzenia zamówienia, i pozwala zmierzyć czas tej konwersji. Analiza wniosków powiązanych z zamówieniami pozwala ocenić skuteczność etapu poprzedzającego zakup i wykryć wnioski zaakceptowane, ale niezrealizowane. Dlaczego to ważne Łączy wniosek z kolejnym etapem procesu zakupowego, umożliwiając analizę odsetka i czasu przekształcania wniosków w zamówienia zakupu. Skąd pobrać Po utworzeniu zamówienia zakupu identyfikator często znajduje się w danych dokumentu wniosku, a czasem w tabeli powiązanych dokumentów lub przepływu dokumentów. Przykłady PO-4500012345ORD7890016000054321 | |||
| Imię i nazwisko wnioskodawcy RequesterName | Imię i nazwisko pracownika lub użytkownika, który utworzył i przesłał wniosek zakupowy. | ||
| Opis Imię i nazwisko wnioskodawcy wskazuje osobę, która rozpoczęła proces zakupu. Zwykle jest to użytkownik biznesowy potrzebujący towarów lub usług. Analiza procesu według wnioskodawcy może ujawnić wzorce dotyczące konkretnych osób lub grup. Można na przykład sprawdzić, czy niektórzy wnioskodawcy często składają niekompletne wnioski lub wnioski niezgodne z wymaganiami, które trzeba poprawiać. Te informacje można wykorzystać do zaplanowania szkoleń dla konkretnych osób lub uproszczenia procesu dla grup, które często składają wnioski. W efekcie wzrasta sprawność i zgodność procesu. Dlaczego to ważne Pomaga wykrywać zachowania charakterystyczne dla poszczególnych użytkowników, co ułatwia kierowanie szkoleń i usprawnień procesu do konkretnych osób lub zespołów. Skąd pobrać Znajduje się w danych nagłówka wniosku zakupowego i często jest powiązane z danymi podstawowymi pracownika. Przykłady John SmithJane DoeMaria Garcia | |||
| Kwota wniosku zakupowego RequisitionAmount | Łączna wartość pieniężna wniosku zakupowego. | ||
| Opis Kwota wniosku zakupowego to łączna wartość wszystkich towarów i usług ujętych we wniosku. Jest to ważna miara finansowa wykorzystywana w całym procesie zakupowym. W analizie procesu ten atrybut umożliwia filtrowanie i analizę według wartości. Pozwala podzielić wnioski na kategorie, na przykład o wysokiej i niskiej wartości, które często podlegają różnym workflow akceptacji i wiążą się z innym poziomem ryzyka. Analiza czasu realizacji lub odsetka odrzuceń według kwoty może pokazać, że akceptacja wniosków o wysokiej wartości trwa znacznie dłużej lub są one częściej odrzucane. To dobry punkt wyjścia do usprawnienia procesu. Dlaczego to ważne Umożliwia analizę według wartości, pomaga ustalać priorytety dla wniosków o wysokiej wartości i sprawdzać, jak kwota wpływa na przebieg procesu. Skąd pobrać Zwykle znajduje się w danych nagłówka transakcji wniosku zakupowego lub w tabeli dokumentów. Przykłady 500.0012500.7599.95 | |||
| Status wniosku zakupowego RequisitionStatus | Bieżący lub końcowy status wniosku zakupowego w jego cyklu życia. | ||
| Opis Status wniosku zakupowego wskazuje jego stan w danym momencie lub końcowy wynik. Typowe statusy to „W toku”, „Oczekuje na akceptację”, „Zaakceptowany”, „Odrzucony” i „Zamknięty”. Ten atrybut jest niezbędny do analizy wyników i monitorowania operacji. Analitycy mogą filtrować wnioski według końcowego statusu i obliczać takie miary jak odsetek odrzuceń czy konwersji na zamówienia zakupu. W codziennej pracy status pomaga zespołom ocenić bieżące obciążenie, na przykład liczbę wniosków oczekujących na akceptację, ustalać priorytety i efektywnie zarządzać zasobami. Dlaczego to ważne Pokazuje wyniki obsługi wniosków, umożliwia obliczanie miar, takich jak odsetek odrzuceń, i pomaga zarządzać bieżącym obciążeniem. Skąd pobrać Zwykle znajduje się w polu statusu nagłówka dokumentu wniosku zakupowego. Przykłady ZaakceptowanyOdrzuconyOczekuje na akceptacjęWycofany | |||
| Typ wniosku zakupowego RequisitionType | Kategoria lub typ wniosku, na przykład wniosek o towary, usługi lub wydatki inwestycyjne. | ||
| Opis Typ wniosku zakupowego określa jego kategorię na podstawie charakteru lub celu zakupu. Przykłady obejmują standardowe materiały, usługi, wydatki inwestycyjne lub pozycje z określonego katalogu. Ta klasyfikacja często wpływa na workflow akceptacji i sposób księgowania. Analiza procesu według typu wniosku pozwala sprawdzić, czy różne rodzaje wniosków przebiegają innymi ścieżkami lub różnią się sprawnością. Na przykład wnioski o wydatki inwestycyjne mogą mieć dłuższy czas realizacji ze względu na dodatkowe etapy akceptacji, a wnioski o standardowe pozycje katalogowe mogą być w dużym stopniu zautomatyzowane. Analiza pomaga projektować i usprawniać warianty procesu dla poszczególnych typów. Dlaczego to ważne Pozwala analizować różne ścieżki procesu, ponieważ typ wniosku często określa wymagany workflow akceptacji i poziom złożoności. Skąd pobrać Informacja ta jest zwykle zapisana w danych nagłówka wniosku jako typ dokumentu lub kod kategorii. Przykłady Wydatek inwestycyjnyWydatek operacyjnyWniosek o usługęWniosek o materiały | |||
| Waluta Currency | Kod waluty, na przykład USD lub EUR, w której podano łączną kwotę wniosku. | ||
| Opis Atrybut „Waluta” określa jednostkę pieniężną dla kwoty wniosku zakupowego. W organizacjach międzynarodowych wnioski mogą być składane w różnych walutach, zależnie od lokalizacji wnioskodawcy lub dostawcy. To pole jest niezbędne do prawidłowego raportowania i analizy finansowej. Pozwala właściwie interpretować wartości pieniężne i przeliczać je podczas agregowania danych z różnych regionów. Każda analiza wartości wniosków musi uwzględniać walutę, aby nie porównywać bezpośrednio różnych jednostek pieniężnych. Dlaczego to ważne Zapewnia kontekst niezbędny do prawidłowej interpretacji danych finansowych i agregowania wartości wniosków z różnych regionów. Skąd pobrać Zwykle znajduje się w danych nagłówka transakcji wniosku zakupowego, obok pól kwoty. Przykłady USDEURGBP | |||
| Imię i nazwisko osoby zatwierdzającej ApproverName | Imię i nazwisko użytkownika lub nazwa grupy odpowiedzialnej za akceptację albo odrzucenie. | ||
| Opis Imię i nazwisko osoby zatwierdzającej wskazuje osobę, rolę lub grupę, która zaakceptowała albo odrzuciła wniosek na danym etapie workflow. To inna osoba niż wnioskodawca lub użytkownik wykonujący pozostałe działania. Ten atrybut pozwala analizować sam proces akceptacji. Ułatwia pomiar wyników osób zatwierdzających, na przykład średniego czasu podejmowania decyzji. Może też ujawnić nierównomierny rozkład obciążenia i wskazać osoby, które tworzą wąskie gardła. Analiza wspiera lepszy podział zasobów i zarządzanie wynikami w łańcuchu akceptacji. Dlaczego to ważne Umożliwia szczegółową analizę workflow akceptacji, w tym obciążenia i wyników osób zatwierdzających oraz wąskich gardeł. Skąd pobrać Jest zapisywane w dzienniku zdarzeń lub dzienniku audytowym dla działań związanych z akceptacją. Może wymagać połączenia z danymi podstawowymi pracowników. Przykłady Alice JohnsonBob WilliamsGrupa akceptująca z działu finansów | |||
| Nazwa użytkownika UserName | Nazwa użytkownika, który wykonał określone działanie, na przykład utworzył, edytował lub zaakceptował wniosek. | ||
| Opis Nazwa użytkownika wskazuje osobę odpowiedzialną za daną czynność w dzienniku procesu. To ogólny atrybut, który może określać osobę zgłaszającą zapotrzebowanie, edytora, zatwierdzającego lub inną osobę uczestniczącą w obsłudze zapotrzebowania. Atrybut ten ma podstawowe znaczenie przy analizie zasobów i automatyzacji. Pomaga sprawdzić, czy przestrzegana jest zasada „czterech oczu”, czyli czy kolejne czynności wykonują różni użytkownicy. Można go też wykorzystać do obliczenia poziomu automatyzacji, identyfikując czynności wykonywane przez użytkowników systemowych lub konta wsadowe. Analiza czynności według użytkownika pokazuje, jak poszczególne role uczestniczą w procesie. Dlaczego to ważne Atrybut ten pomaga analizować przekazywanie zadań między użytkownikami i poziom automatyzacji, a także przypisywać poszczególne etapy procesu właściwym osobom. Skąd pobrać Informacje te znajdują się w ścieżce audytu lub danych dziennika zdarzeń dla każdej transakcji. Często są zapisane jako identyfikator użytkownika. Przykłady asmithjdoeUŻYTKOWNIK_WSADOWY | |||
| Poziom pilności UrgencyLevel | Klasyfikacja określająca priorytet lub pilność wniosku, na przykład „Wysoki”, „Średni” lub „Niski”. | ||
| Opis Poziom pilności, nazywany też priorytetem, to pole, w którym wnioskodawca określa, jak szybko potrzebne są zamówione towary lub usługi. Klasyfikacja może wpływać na sposób kierowania wniosku i ustalania jego priorytetu przez zespół zakupów oraz osoby zatwierdzające. Analiza wyników procesu według poziomu pilności pozwala sprawdzić, czy proces odpowiada na potrzeby biznesowe. Można na przykład zweryfikować, czy wnioski oznaczone jako „Wysoki” są realizowane szybciej niż te z poziomem „Niski”. Jeśli tak nie jest, może to wskazywać na wąskie gardło lub nieskuteczny mechanizm ustalania priorytetów, który wymaga poprawy. Dlaczego to ważne Pomaga ocenić, czy proces nadaje pilnym wnioskom odpowiedni priorytet i czy deklarowana pilność odpowiada rzeczywistemu tempu obsługi. Skąd pobrać Zwykle jest to pole opcjonalne lub obowiązkowe w formularzu tworzenia wniosku, zapisywane w jego nagłówku. Przykłady WysokiŚredniNiskiPilny | |||
| Przyczyna odrzucenia RejectionReason | Przyczyna podana przez osobę zatwierdzającą przy odrzuceniu wniosku lub etapu akceptacji. | ||
| Opis Przyczyna odrzucenia to pole tekstowe lub kod wyjaśniający, dlaczego wniosek został odrzucony. Osoba zatwierdzająca podaje tę informację, aby przekazać wnioskodawcy uwagi. Wnioskodawca może wtedy poprawić i ponownie przesłać wniosek. Ten atrybut jest bardzo przydatny przy analizie przyczyn źródłowych niepowodzeń procesu. Klasyfikacja i analiza przyczyn odrzucenia pozwala wykryć częste problemy, takie jak „Nieprawidłowy kod księgowy”, „Przekroczony budżet” czy „Dostawca niezgodny z wymaganiami”. Na tej podstawie można zaplanować konkretne usprawnienia, na przykład szkolenia dla wnioskodawców, jaśniejsze zasady lub zmiany w systemie zapobiegające typowym błędom. Dlaczego to ważne Pokazuje bezpośrednio, dlaczego wnioski są odrzucane. Analiza przyczyn źródłowych pomaga ograniczyć ponowną pracę i zwiększyć odsetek wniosków akceptowanych za pierwszym razem. Skąd pobrać Zwykle jest zapisywana w polu komentarza lub notatki powiązanym z działaniem „Odrzucony” albo zmianą statusu. Przykłady Przekroczony budżetNieprawidłowe centrum kosztówZduplikowany wniosekNaruszenie zasad | |||
| Wymagana data dostawy RequiredByDate | Data, do której osoba zgłaszająca zapotrzebowanie potrzebuje dostawy towarów lub usług. | ||
| Opis Osoba zgłaszająca zapotrzebowanie podaje wymaganą datę dostawy, aby określić termin realizacji. Jest to termin docelowy dla całego procesu zakupowego, od zatwierdzenia zapotrzebowania po dostawę. Atrybut ten pozwala ocenić terminowość procesu i sprawdzić, czy odpowiada on potrzebom firmy. Porównując wymaganą datę dostawy z datą utworzenia zamówienia zakupu lub faktycznej dostawy, można zmierzyć, jak często udaje się dotrzymać wewnętrznych uzgodnionych poziomów obsługi. Dzięki temu można sprawdzić, czy proces zakupowy przebiega wystarczająco szybko, by spełnić wymagania biznesowe. Dlaczego to ważne Pozwala ocenić wyniki procesu względem terminów biznesowych i sprawdzić, czy zamówienia są realizowane na czas. Skąd pobrać Użytkownik zwykle podaje tę datę podczas tworzenia zapotrzebowania. Jest ona zapisywana w nagłówku zapotrzebowania lub w szczegółach pozycji. Przykłady 2024-06-302024-07-152024-08-01 | |||
Czynności w procesie od zakupu do płatności: zapotrzebowanie
| Działanie | Opis | ||
|---|---|---|---|
| Akceptacja wniosku zakupowego | Wniosek zakupowy pomyślnie przeszedł wszystkie wymagane etapy workflow akceptacji. Od tej chwili można rozpocząć wybór dostawcy lub przekształcić wniosek w zamówienie zakupu. | ||
| Dlaczego to ważne To ważny etap potwierdzający pomyślny wynik. Czas potrzebny na jego osiągnięcie jest podstawową miarą sprawności procesu obsługi wniosków zakupowych. Skąd pobrać Zdarzenie można wywnioskować ze zmiany ogólnego statusu nagłówka wniosku na „Zaakceptowany” lub podobny końcowy status akceptacji w dzienniku workflow. Rejestrowanie Zapisz timestamp pierwszej zmiany ogólnego statusu wniosku na „Zaakceptowany” lub jego odpowiednik. Typ zdarzenia inferred | |||
| Odrzucenie wniosku zakupowego | Wniosek zostaje ostatecznie odrzucony w trakcie akceptacji i nie zostanie przekształcony w zamówienie zakupu. Oznacza to negatywne zakończenie obsługi wniosku. | ||
| Dlaczego to ważne To ważny etap oznaczający niepowodzenie. Analiza przyczyn ostatecznych odrzuceń może pomóc usprawnić działania poprzedzające złożenie wniosku i szkolenia dla wnioskodawców. Skąd pobrać Zdarzenie można wywnioskować ze zmiany ogólnego statusu nagłówka wniosku na „Odrzucony”, „Odmowa” lub podobny końcowy status odrzucenia. Rejestrowanie Zapisz timestamp pierwszej zmiany ogólnego statusu wniosku na „Odrzucony”, „Odmowa” lub jego odpowiednik. Typ zdarzenia inferred | |||
| Przesłanie zapotrzebowania | Zgłaszający formalnie przesyła wypełnione zapotrzebowanie do workflow akceptacji. Zmienia to jego status z roboczego na aktywny, oczekujący na weryfikację i akceptację. | ||
| Dlaczego to ważne To zdarzenie rozpoczyna formalny proces akceptacji. Czas od przesłania zapotrzebowania do jego końcowej akceptacji jest ważną częścią całkowitego czasu realizacji. Skąd pobrać Zdarzenie jest zwykle rejestrowane jako zmiana statusu, działanie użytkownika lub wpis w dzienniku silnika workflow wskazujący rozpoczęcie procesu akceptacji. Rejestrowanie Zapisz znacznik czasu zmiany statusu zapotrzebowania z roboczego na oczekujące na akceptację. Typ zdarzenia explicit | |||
| Utworzenie zamówienia zakupu | Na podstawie danych z jednej lub kilku zaakceptowanych pozycji wniosku generowany jest formalny dokument zamówienia zakupu. To zdarzenie oznacza przekazanie sprawy z wewnętrznego procesu wnioskowania do procesu zakupów zewnętrznych. | ||
| Dlaczego to ważne To podstawowy pozytywny wynik procesu obsługi wniosków zakupowych. Czas od ostatecznej akceptacji do utworzenia zamówienia zakupu pokazuje sprawność działu zakupów. Skąd pobrać Zdarzenie można wywnioskować dla wniosku, znajdując powiązany dokument zamówienia zakupu, który zawiera identyfikator wniosku. Rejestrowanie Ustal timestamp utworzenia zamówienia zakupu zawierającego identyfikator wniosku. Typ zdarzenia inferred | |||
| Utworzenie zapotrzebowania | Użytkownik rozpoczyna zgłoszenie zapotrzebowania na towary lub usługi, tworząc nowy dokument zapotrzebowania zakupowego. To zdarzenie rozpoczyna cykl życia zapotrzebowania. Dokument zwykle ma najpierw status roboczy lub niekompletny, zanim zostanie formalnie przesłany. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Analiza czasu od utworzenia do przesłania zapotrzebowania może ujawnić opóźnienia w przygotowaniu zgłoszenia lub niepewność użytkowników. Skąd pobrać Zdarzenie to jest zwykle rejestrowane na podstawie znacznika czasu utworzenia w głównym rekordzie lub tabeli nagłówka zapotrzebowania zakupowego. Rejestrowanie Ustal znacznik czasu utworzenia początkowego rekordu nagłówka zapotrzebowania zakupowego. Typ zdarzenia explicit | |||
| Zamknięcie wniosku zakupowego | Wniosek zostaje zamknięty administracyjnie, co oznacza, że nie będą już podejmowane dalsze działania. Zwykle następuje to po przekształceniu wszystkich jego pozycji w zamówienia zakupu lub ich anulowaniu. | ||
| Dlaczego to ważne To końcowe zdarzenie potwierdza zakończenie cyklu życia wniosku. Dzięki temu stare wnioski nie pozostają otwarte bezterminowo. Skąd pobrać Zdarzenie można wywnioskować z końcowej zmiany statusu nagłówka wniosku lub oznaczenia wszystkich powiązanych pozycji jako w pełni zamówionych albo zamkniętych. Rejestrowanie Zapisz timestamp ustawienia końcowego statusu wniosku na „Zamknięty” lub „Zakończony”. Typ zdarzenia inferred | |||
| Zmiana zapotrzebowania | Użytkownik zmienia zapotrzebowanie po jego przesłaniu, zwykle po to, by poprawić informacje lub odpowiedzieć na odrzucenie. Zmiany mogą obejmować ilości, ceny lub pozycje i mogą wymagać ponownego rozpoczęcia procesu akceptacji. | ||
| Dlaczego to ważne Śledzenie zmian jest niezbędne do wykrywania ponownej pracy, nieefektywności procesu i niejasnych wymagań początkowych. Częste zmiany mogą znacznie wydłużyć czas realizacji. Skąd pobrać Informacje można pozyskać z systemowych ścieżek audytu, dzienników zmian lub na podstawie utworzenia nowej wersji dokumentu zapotrzebowania. Rejestrowanie W dziennikach zmian lub audytu znajdź zdarzenia odpowiadające edycji ważnych pól zapotrzebowania po jego pierwszym przesłaniu. Typ zdarzenia explicit | |||
| Akceptacja etapu | Osoba akceptująca zatwierdza zapotrzebowanie na przypisanym jej etapie workflow. Dzięki temu przechodzi ono do kolejnego etapu lub zbliża się do końcowej akceptacji. | ||
| Dlaczego to ważne Analiza czasu od rozpoczęcia do zakończenia etapu akceptacji pokazuje wydajność poszczególnych osób zatwierdzających i rozkład ich obciążenia. Skąd pobrać Rejestrowane na podstawie jawnego działania użytkownika zapisanego w historii akceptacji lub danych transakcyjnych workflow. Rejestrowanie Wyodrębnij zdarzenia akceptacji z historii akceptacji lub dziennika workflow, wraz z osobą zatwierdzającą i timestampem. Typ zdarzenia explicit | |||
| Odrzucenie na etapie akceptacji | Osoba zatwierdzająca odrzuca wniosek zakupowy na przypisanym jej etapie, zwykle odsyłając go wnioskodawcy do poprawy. To działanie zatrzymuje dalszy przebieg workflow akceptacji. | ||
| Dlaczego to ważne To zdarzenie często prowadzi do ponownej pracy. Śledzenie odrzuceń pomaga ustalić najczęstsze przyczyny, potrzeby szkoleniowe i problematyczne etapy akceptacji. Skąd pobrać Rejestrowane na podstawie jawnego działania użytkownika zapisanego w historii akceptacji lub danych transakcyjnych workflow. Rejestrowanie Wyodrębnij zdarzenia odrzucenia z historii akceptacji lub dziennika workflow, wraz z osobą zatwierdzającą i timestampem. Typ zdarzenia explicit | |||
| Ponowne uruchomienie akceptacji | Cały workflow akceptacji wniosku zakupowego zostaje zresetowany i rozpoczyna się od początku. Zwykle dzieje się tak po istotnej zmianie wniosku, który jest już w trakcie realizacji. | ||
| Dlaczego to ważne Ponowne uruchomienia akceptacji znacznie wydłużają czas realizacji. Analiza ich częstotliwości i przyczyn może wskazać problemy z polityką lub procesem wprowadzania zmian. Skąd pobrać Wnioskuje się o tym na podstawie wyczyszczenia statusu akceptacji lub jego powrotu do pierwszego etapu, mimo że wcześniej przypisano go osobie zatwierdzającej na dalszym etapie. Rejestrowanie Ustal, kiedy status workflow akceptacji wraca do stanu początkowego po przejściu do kolejnych etapów. Typ zdarzenia inferred | |||
| Przypisanie źródła dostaw | Kupiec lub specjalista ds. zakupów przypisuje do zaakceptowanej pozycji wniosku konkretnego dostawcę, umowę lub uzgodnione warunki cenowe. To etap przygotowujący do utworzenia zamówienia zakupu. | ||
| Dlaczego to ważne To działanie pozwala ocenić sprawność zespołu zakupów operacyjnych. Opóźnienia mogą tworzyć wąskie gardło między akceptacją wniosku a złożeniem zamówienia. Skąd pobrać Zdarzenie można wykryć na podstawie zmian pól dostawcy lub źródła dostaw w pozycji wniosku po jej zaakceptowaniu. Rejestrowanie Ustal timestamp pierwszego uzupełnienia identyfikatora dostawcy lub umowy w zaakceptowanej pozycji wniosku. Typ zdarzenia explicit | |||
| Rozpoczęcie etapu akceptacji | W ramach wieloetapowego workflow zapotrzebowanie zostaje przypisane do konkretnej osoby lub grupy akceptującej. To działanie rozpoczyna czas oczekiwania na akceptację na danym etapie. | ||
| Dlaczego to ważne To zdarzenie umożliwia szczegółową analizę wąskich gardeł w ścieżce akceptacji i wskazanie osób lub etapów powodujących opóźnienia. Skąd pobrać Zdarzenie można ustalić na podstawie dzienników silnika workflow, gdy nowe zadanie akceptacji zostaje utworzone i przypisane do użytkownika lub roli. Rejestrowanie Zapisz znacznik czasu utworzenia zadania akceptacji lub moment, w którym status zapotrzebowania wskazuje oczekiwanie na konkretną osobę akceptującą. Typ zdarzenia inferred | |||
| Wycofanie wniosku zakupowego | Wnioskodawca lub upoważniony użytkownik anuluje wniosek przed uzyskaniem ostatecznej akceptacji lub przekształceniem go w zamówienie. W ten sposób proces dla danego wniosku zostaje zakończony. | ||
| Dlaczego to ważne To zdarzenie końcowe zamyka proces bez jednoznacznego wyniku pozytywnego ani negatywnego. Wysoki odsetek wycofanych wniosków może wskazywać na zmianę potrzeb biznesowych lub składanie wniosków zbyt wcześnie. Skąd pobrać Zwykle jest rejestrowane jako jawne działanie użytkownika, które zmienia status na „Wycofany” lub „Anulowany”, albo ustawia znacznik usunięcia. Rejestrowanie Zapisz timestamp zmiany statusu wniosku na „Wycofany” lub „Anulowany” albo ustawienia znacznika usunięcia. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Metody ekstrakcji zależą od systemu. Szczegółowe instrukcje znajdą Państwo w
naszym przewodniku ETL lub wybierz konkretny proces i system.
Od czego zacząć?
Aby dostosować sposób zbierania danych, można skorzystać z instrukcji ekstrakcji dla konkretnego systemu. Można też użyć tego ogólnego szablonu jako elastycznej podstawy do rozpoczęcia analizy obsługi zapotrzebowań w procesie od zakupu do płatności.
Usprawnij obsługę zapotrzebowań P2P i zwiększ efektywność
Znajdź wąskie gardła, popraw zgodność i ogranicz koszty w procesie P2P.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.