Szablon danych dla procesu od zamówienia do płatności: obsługa zamówień sprzedaży
Szablon danych dla procesu od zamówienia do płatności: obsługa zamówień sprzedaży
To ogólny szablon danych do process mining dla procesu Order to Cash: obsługa zleceń sprzedaży. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.
Wybierz konkretny system- Wskazuje niezbędne atrybuty danych potrzebne do utworzenia kompletnego dziennika zdarzeń.
- Przedstawia najważniejsze czynności i kamienie milowe procesu.
- Uniwersalny punkt wyjścia do process mining, który można dostosować do dowolnego systemu.
Atrybuty procesu od zamówienia do płatności: obsługa zamówień sprzedaży
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładna data i godzina wystąpienia konkretnego działania lub zdarzenia. | ||
| Opis Czas zdarzenia to znacznik czasu wskazujący dokładny moment wykonania działania. Zapewnia kontekst czasowy procesu i pozwala uporządkować chronologicznie wszystkie zdarzenia związane z zamówieniem sprzedaży. Ten atrybut jest niezbędny w każdej analizie opartej na czasie. Służy do obliczania czasu między dowolnymi działaniami, ustalania czasu trwania poszczególnych etapów oraz wykrywania opóźnień i wąskich gardeł. Na przykład KPI „Czas realizacji zamówienia” oblicza się jako różnicę między czasem zdarzenia końcowego etapu dostawy a czasem początkowego utworzenia zamówienia. Dashboardy takie jak „Przegląd czasu realizacji zamówień sprzedaży” w całości opierają się na tym atrybucie. Dlaczego to ważne Ten znacznik czasu jest niezbędny do obliczania wskaźników efektywności, takich jak czas realizacji i czas trwania, które pomagają wykrywać wąskie gardła. Skąd pobrać Zwykle znajduje się przy każdym zapisie transakcji lub zmiany statusu. Może być opisany jako data utworzenia, zmiany lub księgowania. Przykłady 2023-03-15T09:30:00Z2023-04-01T14:05:10Z2023-04-10T11:00:00Z | |||
| Identyfikator zamówienia sprzedaży SalesOrderId | Unikalny identyfikator zamówienia sprzedaży, który służy jako główny identyfikator case w procesie Order to Cash. | ||
| Opis Identyfikator zamówienia sprzedaży jest podstawą process mining w procesie Order to Cash. Jednoznacznie wskazuje każdą instancję procesu od utworzenia do zamknięcia. Pełni funkcję klucza głównego, który łączy powiązane działania, zdarzenia i dane, tworząc pełny przebieg realizacji pojedynczego zamówienia. W analizie ten atrybut pozwala odtworzyć cykl życia każdego zamówienia sprzedaży. Służy do śledzenia kolejności zdarzeń, mierzenia czasu między działaniami i agregowania wskaźników na poziomie zamówienia. Na przykład obliczenie KPI „Czas realizacji zamówienia” wymaga pogrupowania wszystkich działań według identyfikatora zamówienia sprzedaży i ustalenia różnicy czasu między pierwszym a ostatnim zdarzeniem. Dlaczego to ważne Ten identyfikator jest niezbędny do śledzenia poszczególnych zamówień w procesie oraz analizy czasu realizacji, wąskich gardeł i odchyleń na poziomie case. Skąd pobrać Zwykle znajduje się w tabeli nagłówków dokumentów zamówień sprzedaży w źródłowym systemie ERP lub CRM. Przykłady SO-001234598004567ORD-2023-54321 | |||
| Nazwa działania ActivityName | Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w określonym momencie procesu obsługi zamówienia sprzedaży. | ||
| Opis Nazwa działania opisuje etap lub kamień milowy w cyklu życia zamówienia sprzedaży, na przykład „Utworzenie zamówienia sprzedaży”, „Przeprowadzenie weryfikacji zdolności kredytowej” lub „Wysłanie towaru”. Każde działanie oznacza odrębną czynność wykonaną w ramach zamówienia i stanowi element mapy procesu. Analiza tego atrybutu pozwala wizualizować przebieg procesu, wykrywać typowe ścieżki i znajdować odstępstwa od standardowej procedury. Analizując kolejność działań, można wskazać wąskie gardła, pętle poprawek, na przykład powtarzające się działania „Zmiana zamówienia sprzedaży”, oraz warianty niezgodne z procedurami. Atrybut ten jest podstawą dashboardów takich jak „Zgodność procesu i odchylenia” oraz KPI, na przykład „Wskaźnik poprawek w zamówieniach sprzedaży”. Dlaczego to ważne Określa etapy procesu, dzięki czemu można wizualizować jego mapę i przebieg oraz wykrywać poprawki i odchylenia. Skąd pobrać Często jest ustalana na podstawie zmian statusu dokumentu, dzienników zdarzeń lub kodów transakcji w modułach sprzedaży, dostaw i fakturowania systemu źródłowego. Przykłady Utworzono zamówienie sprzedażyWysłano towaryOtrzymanie płatnościAnulowanie zamówienia sprzedaży | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane zostały ostatnio odświeżone lub pobrane z systemu źródłowego. | ||
| Opis Ten atrybut wskazuje, kiedy dane zostały ostatnio załadowane do środowiska process mining. Informuje o aktualności analizowanych danych i różni się od czasu zdarzenia, który określa, kiedy faktycznie wystąpiło działanie biznesowe. Zwykle nie służy bezpośrednio do analizy przebiegu procesu, ale ma duże znaczenie dla zarządzania danymi i wiarygodności wyników. Pozwala analitykom i użytkownikom biznesowym ocenić, na ile aktualne są uzyskane wnioski. Jeśli na przykład dane zaktualizowano tydzień temu, wnioski dotyczące bieżącej efektywności należy interpretować z uwzględnieniem tego faktu. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu można ocenić, czy analiza opiera się na najnowszych informacjach i czy wnioski pozostają miarodajne. Skąd pobrać Zwykle generuje ją i zapisuje narzędzie do ekstrakcji danych (ETL) lub platforma process mining podczas wczytywania danych. Przykłady 2023-10-27T02:00:00Z2023-10-26T02:00:00Z2023-10-25T02:00:00Z | |||
| System źródłowy SourceSystem | Wskazuje system informatyczny, z którego pochodzą dane, na przykład ERP, CRM lub starsza platforma. | ||
| Opis Atrybut „System źródłowy” wskazuje system, w którym wygenerowano dane o zdarzeniu. W nowoczesnych firmach proces od Order to Cash często obejmuje wiele aplikacji, na przykład CRM do tworzenia zamówień oraz ERP do ich realizacji i fakturowania. W analizie ten atrybut pomaga zrozumieć środowisko technologiczne procesu. Ułatwia identyfikację punktów integracji i potencjalnych problemów ze spójnością danych między systemami. Analiza działań według systemu źródłowego może wykazać, czy poszczególne etapy przebiegają inaczej lub trwają dłużej w zależności od używanego systemu. Dlaczego to ważne Informacja o pochodzeniu danych jest niezbędna w środowiskach z wieloma systemami. Pozwala prześledzić ich przepływ i wykryć różnice w przebiegu procesu zależne od systemu. Skąd pobrać Informacja ta jest często dodawana podczas ekstrakcji danych (ETL) lub dostępna jako standardowe pole w hurtowni danych. Przykłady SAP S/4HANASalesforce Sales CloudOracle NetSuite | |||
| Identyfikator klienta CustomerIdentifier | Unikalny identyfikator lub nazwa klienta, który złożył zamówienie sprzedaży. | ||
| Opis Ten atrybut wskazuje podmiot zewnętrzny, na rzecz którego realizowane jest zamówienie sprzedaży. Może to być unikalny numer klienta, nazwa firmy lub inny identyfikator odróżniający go od pozostałych klientów. W process mining identyfikator klienta pozwala dzielić dane na segmenty. Analitycy mogą filtrować mapę procesu, aby sprawdzić jego przebieg dla konkretnego klienta, lub porównywać ścieżki różnych grup, na przykład klientów strategicznych i okazjonalnych. Dzięki temu można wykryć procesy dostosowane do konkretnych klientów albo wskazać klientów, którzy często powodują odchylenia lub opóźnienia. Takie informacje pomagają zarządzać relacjami z klientami. Dlaczego to ważne Pozwala filtrować i porównywać procesy dla różnych klientów lub grup klientów, aby wykrywać procesy dostosowane do ich potrzeb i problematyczne konta. Skąd pobrać Znajduje się w danych nagłówka zamówienia sprzedaży i jest powiązany z danymi podstawowymi klienta w źródłowym systemie ERP lub CRM. Przykłady KLIENT-10023Global Corp Inc.758991 | |||
| Identyfikator produktu ProductIdentifier | Unikalny kod lub nazwa głównego produktu albo usługi w zamówieniu sprzedaży. | ||
| Opis Identyfikator produktu, na przykład numer materiału lub SKU, określa, co jest sprzedawane. Zamówienie sprzedaży może obejmować wiele produktów, ale ten atrybut często wskazuje produkt główny lub kategorię produktu używaną w analizie ogólnej. Atrybut ten pozwala analizować proces Order to Cash z perspektywy produktów. Analiza może wykazać, czy określone produkty wiążą się z dłuższym czasem realizacji, częstszymi problemami z dostawą lub większą liczbą anulowań. Takie informacje są przydatne przy planowaniu łańcucha dostaw, zarządzaniu zapasami i kształtowaniu oferty produktowej. Na przykład wykrycie powtarzających się opóźnień dla określonej linii produktów na etapie „Zwolnienie do magazynu” może skłonić do sprawdzenia poziomu zapasów lub rozmieszczenia towaru w magazynie. Dlaczego to ważne Umożliwia analizę efektywności procesu dla różnych produktów lub ich grup, pomagając wykrywać problemy i wąskie gardła dotyczące konkretnych produktów. Skąd pobrać Znajduje się na poziomie pozycji zamówienia sprzedaży. W analizie na poziomie case może oznaczać najważniejszą pozycję lub wyprowadzoną kategorię produktu. Przykłady PROD-5540-XLMAT-009871USŁ-KONSULT-GODZ | |||
| Kanał sprzedaży SalesChannel | Kanał, którym wpłynęło zamówienie sprzedaży, na przykład internet, sprzedaż bezpośrednia lub partner. | ||
| Opis Kanał sprzedaży wskazuje źródło lub sposób złożenia zamówienia. Może to być portal internetowy, zespół sprzedaży bezpośredniej, połączenie EDI z partnerem lub sklep stacjonarny. Analiza procesu według kanału sprzedaży może ujawnić znaczne różnice w efektywności i zgodności. Zamówienia internetowe mogą być w dużym stopniu zautomatyzowane i szybko realizowane, podczas gdy zamówienia z kanału sprzedaży bezpośredniej mogą wymagać więcej ręcznych zmian i dłuższego zatwierdzania. Taka analiza pomaga usprawnić przebieg procesu w każdym kanale i lepiej przydzielać zasoby. Kanał sprzedaży jest ważnym wymiarem dashboardów, takich jak „Wąskie gardła w realizacji zamówień”. Dlaczego to ważne Pozwala porównywać efektywność procesu w różnych kanałach i wykrywać różnice w sprawności, automatyzacji oraz zgodności. Skąd pobrać Informacja ta jest zwykle zapisana w danych nagłówka zamówienia sprzedaży i często jest wymagana podczas jego wprowadzania. Przykłady Portal internetowySprzedaż bezpośredniaEDISieć partnerów | |||
| Nazwa użytkownika UserName | Nazwa lub identyfikator użytkownika, pracownika albo agenta systemowego, który wykonał działanie. | ||
| Opis Atrybut „Nazwa użytkownika” wskazuje osobę lub agenta automatycznego odpowiedzialnego za wykonanie danego działania. Może to być przedstawiciel handlowy, który utworzył zamówienie, menedżer ds. kredytowych, który je zatwierdził, albo użytkownik systemowy, który automatycznie zaksięgował płatność. Atrybut ten pozwala analizować proces z perspektywy osób zaangażowanych w jego realizację. Służy do badania rozkładu obciążenia pracą, porównywania wyników zespołów lub poszczególnych osób oraz wskazywania potrzeb szkoleniowych. Ma też znaczenie dla zgodności i ścieżki audytu. Analiza działań według użytkownika pomaga ustalić, kto uczestniczy w pętlach poprawek lub postępuje niezgodnie z procedurami. Jest również podstawą do obliczenia KPI „Wskaźnik ręcznej interwencji”. Dlaczego to ważne Wskazuje osobę lub system wykonujący działanie, co pozwala analizować obciążenie pracą, wyniki zespołów, poziom automatyzacji i zgodność. Skąd pobrać Zwykle znajduje się w dziennikach transakcji lub historii zmian dokumentu, często pod nazwą „Utworzył” lub „Zmienił”. Przykłady Jan.KowalskiUŻYTKOWNIK_WSADOWYAnna.NowakUŻYTKOWNIK_API | |||
| Wartość zamówienia OrderValue | Łączna wartość pieniężna zamówienia sprzedaży, zwykle wyrażona w walucie dokumentu. | ||
| Opis Wartość zamówienia określa łączną wartość finansową zamówienia sprzedaży. To ważny wskaźnik finansowy, który pokazuje skalę każdej instancji case. Atrybut ten jest przydatny w analizie procesu według wartości. Pozwala ustalać priorytety problemów, koncentrując się na zamówieniach o wysokiej wartości. Analitycy mogą na przykład sprawdzić, czy ich realizacja trwa dłużej lub wymaga więcej poprawek niż w przypadku zamówień o niższej wartości. Atrybut służy też do obliczania finansowego wpływu nieefektywności procesu, na przykład łącznej wartości zamówień opóźnionych przez konkretne wąskie gardło. Takie dane pomagają uzasadnić działania usprawniające proces. Dlaczego to ważne Umożliwia analizę według wartości, co pomaga ustalać priorytety usprawnień przez skupienie się na zamówieniach o wysokiej wartości i określenie finansowego wpływu opóźnień. Skąd pobrać Dostępna w danych nagłówka zamówienia sprzedaży. Często jest obliczana jako suma wartości netto wszystkich pozycji. Przykłady 15200.50500.00125000.75 | |||
| Czy zautomatyzowane IsAutomated | Wskaźnik określający, czy czynność wykonał automatycznie system, czy ręcznie użytkownik. | ||
| Opis Ten atrybut logiczny odróżnia zadania wykonywane przez użytkowników od tych realizowanych automatycznie przez system, na przykład w ramach zadań w tle, przez API lub boty RPA. Przykładowo sprawdzenie zdolności kredytowej może odbywać się automatycznie, natomiast rozwiązanie blokady kredytowej zwykle wymaga ręcznej interwencji. Analiza procesu pod kątem automatyzacji ma duże znaczenie dla inicjatyw transformacji cyfrowej. Ten wskaźnik jest podstawą do obliczenia KPI „Odsetek ręcznych interwencji”. Pokazuje, które części procesu są w dużym stopniu zautomatyzowane, a które nadal wymagają pracy ręcznej. Dzięki temu można wskazać dalsze możliwości automatyzacji, ograniczyć koszty i liczbę błędów oraz skrócić czas realizacji. Dlaczego to ważne Pozwala odróżnić zadania ręczne od zautomatyzowanych, co pomaga mierzyć poziom automatyzacji i wskazywać możliwości usprawnienia procesu. Skąd pobrać Informację tę można wywnioskować z atrybutu „Nazwa użytkownika” (na przykład rozpoznając konta systemowe, takie jak „BATCH_USER”) albo odczytać z pól dziennika zdarzeń, które rejestrują kontekst wykonania. Przykłady truefalse | |||
| Faktyczna data dostawy ActualDeliveryDate | Data faktycznego dostarczenia towaru klientowi, oznaczająca zakończenie etapu realizacji zamówienia. | ||
| Opis Faktyczna data dostawy to znacznik czasu potwierdzający dostarczenie towaru klientowi. Często jest ustalana na podstawie potwierdzenia dostawy od przewoźnika. To ostateczna miara skuteczności realizacji zamówienia. Służy do obliczenia „Wskaźnika terminowości dostaw” przez porównanie z oczekiwaną i potwierdzoną datą dostawy. Analiza czasu między działaniem „Wysłanie towaru” a faktyczną datą dostawy może też dostarczyć informacji o efektywności partnerów logistycznych i metod wysyłki. Dlaczego to ważne To ostateczne potwierdzenie realizacji zamówienia, niezbędne do dokładnego obliczenia wskaźnika terminowości dostaw i łącznego czasu realizacji zamówienia. Skąd pobrać Często pochodzi z zewnętrznego systemu logistycznego lub wysyłkowego i jest przekazywana do systemu ERP. Może być ustalana na podstawie znacznika czasu działania „Dostarczenie towaru”. Przykłady 2023-11-172023-12-022024-01-14 | |||
| Oczekiwana data dostawy RequestedDeliveryDate | Data dostawy zamówienia wskazana przez klienta. | ||
| Opis Ta data określa oczekiwany przez klienta termin dostawy. Jest ważną informacją rejestrowaną na początku procesu i stanowi podstawę oceny terminowości dostawy z perspektywy klienta. W analizie procesu oczekiwaną datę dostawy porównuje się z innymi ważnymi datami, takimi jak data potwierdzona i faktyczna, aby mierzyć poziom obsługi. Jest jednym z głównych danych wejściowych dashboardu „Terminowość dostaw” i służy do ustalenia, czy dostawa dotarła na czas z punktu widzenia klienta. Różnice między oczekiwaną a potwierdzoną datą mogą też wskazywać problemy z planowaniem i harmonogramowaniem. Dlaczego to ważne Określa oczekiwania klienta dotyczące dostawy i stanowi punkt odniesienia przy pomiarze terminowości dostaw oraz zadowolenia klienta. Skąd pobrać Zwykle znajduje się w nagłówku zamówienia sprzedaży lub szczegółach jego pozycji i jest wprowadzana podczas tworzenia zamówienia. Przykłady 2023-11-152023-12-012024-01-10 | |||
| Potwierdzona data dostawy ConfirmedDeliveryDate | Data dostawy potwierdzona przez firmę i zadeklarowana klientowi. | ||
| Opis Po sprawdzeniu zapasów i harmonogramów produkcji firma podaje potwierdzoną datę dostawy. Jest to zobowiązanie firmy wobec klienta i wewnętrzny punkt odniesienia przy pomiarze efektywności realizacji zamówień. Atrybut ten jest ważny przy ocenie wewnętrznej sprawności operacyjnej. Służy do obliczania KPI „Wskaźnik terminowości dostaw”, w którym porównuje się go z faktyczną datą dostawy, aby sprawdzić, czy firma dotrzymała zobowiązania. Znaczne rozbieżności między oczekiwanymi a potwierdzonymi datami dostaw w wielu zamówieniach mogą wskazywać na systemowe problemy z obliczaniem dostępności do obietnicy (ATP) lub planowaniem zdolności produkcyjnych. Dlaczego to ważne Określa zobowiązanie firmy wobec klienta i stanowi wewnętrzny punkt odniesienia przy pomiarze terminowości dostaw oraz niezawodności realizacji zamówień. Skąd pobrać Znajduje się w danych pozycji harmonogramu zamówienia sprzedaży i jest często aktualizowana po sprawdzeniu dostępności lub uruchomieniu planowania produkcji. Przykłady 2023-11-182023-12-012024-01-15 | |||
| Powód odrzucenia RejectionReason | Kod lub opis wyjaśniający, dlaczego zamówienie sprzedaży albo jego pozycja zostały anulowane lub odrzucone. | ||
| Opis Gdy zamówienie sprzedaży zostaje anulowane lub pozycja odrzucona, powód odrzucenia wyjaśnia przyczyny takiego wyniku. Może to być na przykład „Anulowanie przez klienta”, „Nieprawidłowa cena” lub „Brak towaru w magazynie”. Ten atrybut pomaga ustalić źródłowe przyczyny problemów w procesie. Analiza częstotliwości poszczególnych powodów odrzucenia pozwala wykryć problemy systemowe. Na przykład częste anulowanie zamówień z powodu „Nieprawidłowej ceny” może wskazywać na problemy z przygotowywaniem ofert lub danymi podstawowymi. Takie ustalenia pomagają zwiększyć wskaźnik „Poprawnie za pierwszym razem” i ograniczyć straty w procesie. Dlaczego to ważne Wyjaśnia, dlaczego zamówienia nie są realizowane, i pomaga ustalić źródłowe przyczyny problemów z cenami, zapasami lub komunikacją z klientami. Skąd pobrać Zwykle jest przypisany do pozycji zamówienia sprzedaży i wybierany z wcześniej zdefiniowanej listy kodów podczas anulowania pozycji. Przykłady Żądanie klientaProdukt wycofany ze sprzedażyBłąd w ceniePrzekroczony limit kredytowy | |||
| Status zamówienia OrderStatus | Status zamówienia sprzedaży w chwili wystąpienia zdarzenia, na przykład „Otwarte”, „W toku” lub „Zakończone”. | ||
| Opis Status zamówienia pokazuje, na jakim etapie cyklu życia znajduje się zamówienie sprzedaży w danym momencie. Jest to kategoria podsumowująca jego bieżący stan. Kolejność działań przedstawia szczegółową mapę procesu, natomiast atrybut statusu zamówienia przydaje się do tworzenia uproszczonego obrazu procesu na wysokim poziomie. Można go użyć do filtrowania zamówień o określonym statusie, na przykład wszystkich zamówień „Zablokowanych z powodu kontroli kredytowej”. Analiza czasu spędzonego w poszczególnych statusach może też ujawnić wąskie gardła, na przykład zamówienia zbyt długo oczekujące na zatwierdzenie. Dlaczego to ważne Zapewnia ogólny obraz stanu zamówienia. Ułatwia filtrowanie, analizę statusów i wykrywanie zamówień, które utknęły na danym etapie. Skąd pobrać To standardowe pole w nagłówku większości dokumentów zamówień sprzedaży w systemach ERP i CRM. Przykłady OtwarteW tokuBlokada kredytowaZakończoneAnulowane | |||
| Termin płatności PaymentDueDate | Data, do której klient ma zapłacić za fakturę. | ||
| Opis Termin płatności jest obliczany na podstawie daty faktury i uzgodnionych warunków płatności klienta. Wyznacza datę graniczną terminowej płatności i jest ważnym elementem procesu obsługi należności. Atrybut ten ma podstawowe znaczenie przy analizie finansowej części cyklu Order to Cash. Stanowi punkt odniesienia przy ustalaniu, czy płatność wpłynęła na czas, i jest bezpośrednio wykorzystywany do obliczenia KPI „Wskaźnik terminowych płatności”. Dashboard „Cykl od faktury do płatności” w dużej mierze opiera się na tej dacie, aby analizować zachowania płatnicze i skutecznie zarządzać kapitałem obrotowym. Porównanie opóźnień między wystawieniem faktury a otrzymaniem płatności z terminem płatności pomaga wskazać klientów, którzy płacą z opóźnieniem. Dlaczego to ważne Ta data jest ważna w analizie finansowej. Stanowi punkt odniesienia przy obliczaniu wskaźnika terminowych płatności i zarządzaniu należnościami. Skąd pobrać Zwykle znajduje się na fakturze klienta i jest wyliczana na podstawie daty faktury oraz warunków płatności określonych w danych podstawowych klienta lub zamówieniu sprzedaży. Przykłady 2023-12-152024-01-302024-02-28 | |||
Czynności w procesie od zamówienia do płatności: obsługa zamówień sprzedaży
| Działanie | Opis | ||
|---|---|---|---|
| Anulowanie zamówienia sprzedaży | To zdarzenie oznacza anulowanie zamówienia sprzedaży przed jego pełną wysyłką i zafakturowaniem. Jest to alternatywne, niepomyślne zakończenie procesu, które może nastąpić na różnych etapach. | ||
| Dlaczego to ważne To niepomyślny wynik procesu. Analiza tego, kiedy i dlaczego zamówienia są anulowane, może ujawnić problemy z zadowoleniem klientów, dostępnością zapasów lub błędami przy wprowadzaniu danych. Skąd pobrać Zwykle jest rejestrowane przez przypisanie statusu „Anulowane” lub „Odrzucone” do nagłówka zamówienia sprzedaży albo jego pozycji. Rejestrowanie Zapisz znacznik czasu przypisania przyczyny anulowania lub końcowego statusu „Anulowane” do dokumentu zamówienia sprzedaży. Typ zdarzenia inferred | |||
| Otrzymanie płatności | To zdarzenie oznacza, że płatność klienta za fakturę została otrzymana, przetworzona i rozliczona. Zwykle jest rejestrowane w module należności i zamyka otwartą pozycję finansową. | ||
| Dlaczego to ważne To ostatni etap procesu, który przynosi przychód. Pomiar czasu od wystawienia faktury do otrzymania płatności ma zasadnicze znaczenie przy analizie wskaźnika Days Sales Outstanding i efektywności cyklu konwersji gotówki. Skąd pobrać To jawne zdarzenie księgowe, rejestrowane na podstawie daty rozliczenia dokumentu należności lub utworzenia zapisu rozliczenia płatności. Rejestrowanie Użyj daty księgowania lub rozliczenia dokumentu finansowego, który zamyka otwartą kwotę faktury. Typ zdarzenia explicit | |||
| Utworzenie faktury | To zdarzenie oznacza wystawienie faktury klientowi za wysłane towary lub usługi. Jest to podstawowa operacja finansowa, która formalnie rejestruje należność od klienta i rozpoczyna cykl płatności. | ||
| Dlaczego to ważne Czas między wysyłką a wystawieniem faktury, określany jako opóźnienie „bill-to-cash”, bezpośrednio wpływa na przepływy pieniężne. Analiza tego czasu pomaga wykryć opóźnienia w fakturowaniu. Skąd pobrać To jawne zdarzenie, rejestrowane na podstawie znacznika czasu utworzenia faktury lub dokumentu rozliczeniowego w module finansowym. Rejestrowanie Użyj daty i godziny utworzenia dokumentu faktury z tabel należności lub fakturowania. Typ zdarzenia explicit | |||
| Utworzono zamówienie sprzedaży | To działanie oznacza utworzenie zamówienia sprzedaży w systemie. Rejestruje formalne przyjęcie zamówienia klienta na towary lub usługi i rozpoczyna proces Order to Cash. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Pomiar czasu od tego momentu pozwala ocenić całkowity czas realizacji zamówienia i sprawność początkowego wprowadzania danych. Skąd pobrać To zdarzenie jest zwykle rejestrowane na podstawie znacznika czasu utworzenia głównego rekordu nagłówka zamówienia sprzedaży lub powiązanego dziennika transakcji. Rejestrowanie Ustal pierwszy znacznik czasu powiązany z utworzeniem nowego identyfikatora zamówienia sprzedaży w tabeli nagłówków zamówień lub dokumencie systemowym. Typ zdarzenia explicit | |||
| Wysłano towary | To ważne zdarzenie oznacza, że zapakowane towary zostały wysłane i fizycznie opuściły magazyn. Jest to istotny moment logistyczny i finansowy, który często uruchamia proces fakturowania. | ||
| Dlaczego to ważne To podstawowy etap pomiaru terminowości dostaw i czasu realizacji zamówienia. Czas od utworzenia zamówienia do wysyłki jest ważnym KPI. Skąd pobrać Zdarzenie jest zwykle jawnie rejestrowane w modułach wysyłki lub logistyki pod nazwą „Post Goods Issue” albo „Ship Confirmation”. Rejestrowanie Wykorzystaj znacznik czasu potwierdzenia wysyłki lub transakcji wydania towarów, zwykle zapisany w dokumencie dostawy albo realizacji. Typ zdarzenia explicit | |||
| Zamknięcie zamówienia sprzedaży | To ostatnie zdarzenie w przypadku pomyślnie zrealizowanego zamówienia. Oznacza, że zamówienie zostało w całości wysłane, zafakturowane i opłacone. Ten status wskazuje, że nie są już oczekiwane żadne dalsze transakcje dotyczące zamówienia. | ||
| Dlaczego to ważne To zdarzenie oznacza pomyślne zakończenie procesu. Łączny czas od utworzenia do zamknięcia zamówienia to pełny czas realizacji zamówienia bez zakłóceń. Skąd pobrać Zwykle można je ustalić na podstawie końcowego statusu nagłówka zamówienia sprzedaży, na przykład „Zamknięte” lub „Zrealizowane”, po zakończeniu wszystkich powiązanych transakcji. Rejestrowanie Ustal znacznik czasu zmiany ogólnego statusu nagłówka zamówienia sprzedaży na końcowy, oznaczający zakończenie. Typ zdarzenia inferred | |||
| Zatwierdzono zamówienie sprzedaży | Ten etap oznacza, że zamówienie sprzedaży przeszło wszystkie wymagane kontrole wewnętrzne, takie jak weryfikacja zdolności kredytowej i konfiguracji, i zostało formalnie zatwierdzone do realizacji. Zwykle wiąże się z wyraźną decyzją o zatwierdzeniu lub zmianą statusu. | ||
| Dlaczego to ważne To ważny punkt kontrolny, który warunkuje rozpoczęcie realizacji zamówienia. Analiza czasu do zatwierdzenia pomaga wykryć opóźnienia w weryfikacji i przeglądzie zamówienia. Skąd pobrać Zdarzenie jest zwykle rejestrowane jako status „Approved”, „Confirmed” lub „Booked” w polu statusu zamówienia sprzedaży albo w historii workflow. Rejestrowanie Ustal znacznik czasu zmiany statusu zamówienia sprzedaży na stan oznaczający gotowość do realizacji, na przykład „Approved” lub „Booked”. Typ zdarzenia inferred | |||
| Dostarczono towary | To działanie oznacza, że przesyłka została dostarczona pod wskazany przez klienta adres. Informacje o dostawie są często aktualizowane na podstawie danych od zewnętrznego przewoźnika lub ręcznego potwierdzenia. | ||
| Dlaczego to ważne Śledzenie dostawy daje pełny obraz doświadczeń klienta i pozwala dokładnie zmierzyć łączny czas realizacji zamówienia. Skąd pobrać Dane pochodzą zwykle od zewnętrznego przewoźnika i są przekazywane do systemu głównego albo z potwierdzenia „Proof of Delivery”. Rejestrowanie Zapisz znacznik czasu potwierdzenia dostawy przekazany przez przewoźnika lub znacznik czasu ręcznie wprowadzonego potwierdzenia „Proof of Delivery”. Typ zdarzenia explicit | |||
| Przekazano do magazynu | To działanie oznacza formalne przekazanie zamówienia sprzedaży do magazynu w celu jego fizycznej obsługi. Uruchamia pracę zespołu magazynowego nad kompletowaniem i pakowaniem. | ||
| Dlaczego to ważne To ważny punkt przekazania pracy między działami. Analiza czasu potrzebnego na ten etap może ujawnić problemy z komunikacją między sprzedażą a logistyką. Skąd pobrać Zdarzenie jest często rejestrowane w chwili wygenerowania listy kompletacyjnej lub zmiany statusu zamówienia na „Ready to Pick” albo „Released”. Rejestrowanie Ustal znacznik czasu zmiany statusu pozycji zamówienia sprzedaży na stan oznaczający gotowość do obsługi magazynowej. Typ zdarzenia inferred | |||
| Przeprowadzono weryfikację zdolności kredytowej | To działanie oznacza przeprowadzenie weryfikacji zdolności kredytowej klienta powiązanego z zamówieniem. Może to być automatyczna kontrola systemowa lub ręczna analiza, która często powoduje aktualizację statusu kredytowego zamówienia. | ||
| Dlaczego to ważne Ten etap często stanowi wąskie gardło. Pomiar jego czasu trwania i wyników pomaga ocenić efektywność zarządzania kredytowego oraz wpływ tego etapu na całkowity czas realizacji zamówienia. Skąd pobrać Zdarzenie często można wywnioskować ze zmiany statusu zamówienia sprzedaży, zwolnienia blokady kredytowej lub wpisu w dzienniku zarządzania kredytowego. Rejestrowanie Zapisz znacznik czasu aktualizacji pola statusu kredytowego zamówienia na „Approved” lub „Checked” albo usunięcia blokady związanej z kredytem. Typ zdarzenia inferred | |||
| Skompletowano towary | To działanie oznacza zakończenie fizycznego kompletowania wszystkich pozycji zamówienia z lokalizacji magazynowych. Zwykle jest rejestrowane, gdy pracownik magazynu potwierdzi wykonanie zadania. | ||
| Dlaczego to ważne Pomiar czasu kompletowania jest niezbędny do analizy efektywności magazynu i wykrywania wąskich gardeł w fizycznej realizacji zamówień. Skąd pobrać Zdarzenie jest zwykle rejestrowane w module Warehouse Management System lub można je wywnioskować ze zmiany statusu dokumentu dostawy albo realizacji. Rejestrowanie Zapisz znacznik czasu zmiany statusu powiązanej listy kompletacyjnej lub dokumentu realizacji na „Picked” albo „Completed”. Typ zdarzenia inferred | |||
| Spakowano towary | To działanie oznacza zakończenie pakowania. Skompletowane towary są łączone, pakowane i przygotowywane do wysyłki. Często obejmuje to wygenerowanie dokumentu pakowania i uzupełnienie szczegółów wysyłki. | ||
| Dlaczego to ważne Analiza czasu między kompletowaniem a pakowaniem może pomóc usprawnić układ stanowisk i procedury pakowania. To ważny etap weryfikacji poprawności zamówienia przed wysyłką. Skąd pobrać Zdarzenie może być zapisane jako osobny status w systemie WMS lub można je wywnioskować z czasu utworzenia dokumentu pakowania. Rejestrowanie Ustal znacznik czasu zmiany statusu dokumentu realizacji na „Packed” albo wykorzystaj znacznik czasu utworzenia dokumentu pakowania. Typ zdarzenia inferred | |||
| Utworzenie faktury korygującej | To zdarzenie występuje, gdy klient otrzymuje fakturę korygującą, zwykle z powodu zwrotu produktu, sporu dotyczącego ceny lub innej korekty. Oznacza anulowanie lub zmniejszenie wcześniej zafakturowanej kwoty. | ||
| Dlaczego to ważne Analiza częstotliwości wystawiania faktur korygujących i ich przyczyn pomaga wykryć powtarzające się problemy z jakością produktów, poprawnością wysyłek lub błędami cenowymi. To ważny wskaźnik nieprawidłowości w procesie. Skąd pobrać To jawne zdarzenie finansowe, rejestrowane na podstawie znacznika czasu utworzenia faktury korygującej w module fakturowania lub należności. Rejestrowanie Użyj daty i godziny utworzenia faktury korygującej, która zwykle jest powiązana z pierwotnym zamówieniem sprzedaży lub fakturą. Typ zdarzenia explicit | |||
| Wysłanie faktury do klienta | Oznacza moment przekazania wystawionej faktury klientowi do zapłaty. Może to nastąpić różnymi kanałami, na przykład pocztą elektroniczną, przez elektroniczną wymianę danych lub pocztą tradycyjną. | ||
| Dlaczego to ważne To oficjalny początek biegu terminu płatności klienta. Opóźnienie między wystawieniem a wysłaniem faktury może wydłużyć cykl konwersji gotówki. Skąd pobrać Dane pochodzą z dzienników zarządzania wydrukami, rejestrów komunikacji lub konkretnej zmiany statusu dokumentu faktury. Rejestrowanie Zapisz znacznik czasu z dziennika wyjściowego systemu, który potwierdza pomyślne wysłanie dokumentu faktury. Typ zdarzenia inferred | |||
| Zarezerwowano zapasy | To działanie oznacza przydzielenie lub zarezerwowanie zapasów wymaganych dla pozycji zamówienia sprzedaży. Dzięki temu towary są dostępne i przypisane do konkretnego zamówienia, więc nie można ich sprzedać innemu klientowi. | ||
| Dlaczego to ważne Śledzenie rezerwacji zapasów pomaga analizować dostępność materiałów i możliwe opóźnienia związane z zapasami. Czas między zatwierdzeniem zamówienia a rezerwacją może wskazywać problemy z zaopatrzeniem. Skąd pobrać Często jest to automatyczne zdarzenie systemowe, zapisywane w tabelach transakcji magazynowych lub widoczne jako zmiana statusu pozycji zamówienia sprzedaży. Rejestrowanie Zapisz znacznik czasu z dziennika transakcji magazynowych, który odpowiada rezerwacji zapasów dla konkretnej pozycji zamówienia sprzedaży. Typ zdarzenia explicit | |||
| Zmieniono zamówienie sprzedaży | To działanie oznacza każdą istotną zmianę w zamówieniu sprzedaży po jego utworzeniu, na przykład zmianę ilości, pozycji, cen lub wymaganych terminów. Zwykle wykrywa się je, śledząc aktualizacje w ścieżkach audytu systemu lub dziennikach zmian. | ||
| Dlaczego to ważne Śledzenie zmian w zamówieniach pomaga wykrywać poprawki w procesie, ustalać źródła nieefektywności i mierzyć odsetek zamówień poprawnych za pierwszym razem. Częste zmiany mogą wskazywać na problemy z dokładnością zamówień przy ich wprowadzaniu. Skąd pobrać Dane pochodzą z tabel dziennika zmian systemu, ścieżek audytu lub porównania różnych wersji dokumentu zamówienia sprzedaży. Rejestrowanie Przefiltruj dzienniki zmian systemu, aby znaleźć aktualizacje ważnych pól w nagłówku zamówienia sprzedaży lub jego pozycjach. Jako czas zdarzenia wykorzystaj znacznik czasu zmiany. 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.
Gotowi do rozpoczęcia?
Niezależnie od tego, czy wybiorą Państwo instrukcję dla konkretnego systemu, czy dostosują uniwersalny szablon, mogą już rozpocząć usprawnianie obsługi zamówień sprzedaży w procesie od zamówienia do płatności.
Zacznij usprawniać obsługę zamówień sprzedaży
Szybko uzyskaj konkretne informacje, ogranicz opóźnienia i popraw przepływy pieniężne.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.