Szablon danych do procesu od zamówienia do płatności: obsługa zamówień sprzedaży
Szablon danych do procesu od zamówienia do płatności: obsługa zamówień sprzedaży
- Zalecane atrybuty
- Działania do śledzenia
- Wskazówki dotyczące wyodrębniania danych z Salesforce Sales Cloud
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 czynności. | ||
| Opis Czas zdarzenia, czyli znacznik czasu, wskazuje dokładny moment wykonania czynności. Dane te są niezbędne do prawidłowego uporządkowania zdarzeń i obliczenia czasu między czynnościami. Stanowią podstawę wszystkich analiz process mining opartych na czasie. Atrybut służy do porządkowania czynności w ramach każdej sprawy, obliczania czasu realizacji, wykrywania czasu oczekiwania i analizy wyników procesu w różnych okresach. Nieprawidłowe lub brakujące znaczniki czasu mogą znacznie ograniczyć przydatność analizy. Dlaczego to ważne Znaczniki czasu są niezbędne do chronologicznego uporządkowania zdarzeń i obliczania wskaźników efektywności, takich jak czas realizacji i wąskie gardła. Skąd pobrać Odpowiada polom takim jak „CreatedDate” lub „LastModifiedDate” obiektu „Order” albo powiązanych rekordów. W przypadku niektórych zdarzeń może pochodzić z daty zakończenia rekordu „Task”. Przykłady 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
| Nazwa czynności ActivityName | Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w cyklu życia zamówienia sprzedaży. | ||
| Opis Nazwa czynności opisuje etap procesu obsługi zamówienia sprzedaży, na przykład „Utworzenie zamówienia”, „Przeprowadzenie oceny zdolności kredytowej” lub „Wysłanie faktury”. Czynności tworzą mapę procesu i są wyznaczane na podstawie zdarzeń systemowych, zmian statusu lub zakończenia zadań. Analiza czynności pozwala wizualizować przebieg procesu, wykrywać typowe ścieżki (warianty) oraz mierzyć częstotliwość i czas trwania poszczególnych etapów. To podstawa zrozumienia, jak przebiega proces. Dlaczego to ważne Ten atrybut określa etapy widoczne na mapie procesu. Bez niego nie można zwizualizować przebiegu procesu ani przeanalizować rzeczywistej obsługi zamówień sprzedaży. Skąd pobrać Zwykle wyznaczana na podstawie zmian pola „Order.Status”, utworzenia powiązanych rekordów (np. Invoice) lub zakończenia rekordów „Task” albo „Event” powiązanych z zamówieniem. Przykłady Utworzenie zamówieniaZatwierdzenie zamówieniaWysłanie towaruOtrzymanie płatności | |||
| Zamówienie sprzedaży SalesOrderId | Unikalny identyfikator każdego zamówienia sprzedaży, używany jako główny identyfikator sprawy do śledzenia całego procesu od zamówienia do płatności. | ||
| Opis Identyfikator zamówienia sprzedaży (Sales Order ID) stanowi podstawę analizy procesu. Pozwala jednoznacznie rozpoznać każde zamówienie klienta na wszystkich etapach jego realizacji. Łączy powiązane czynności, od utworzenia i zatwierdzenia po realizację i płatność. W process mining każde zdarzenie dotyczące danego zamówienia jest powiązane z tym identyfikatorem. Umożliwia to odtworzenie całej ścieżki zamówienia oraz szczegółową analizę czasu realizacji, wariantów procesu i wąskich gardeł dla poszczególnych zamówień. Dlaczego to ważne Ten atrybut pozwala połączyć wszystkie powiązane zdarzenia w jedną sprawę, a następnie wizualizować i analizować pełny przebieg procesu dla każdego zamówienia sprzedaży. Skąd pobrać To pole „Id” standardowego obiektu Salesforce „Order”. Przykłady 8018d000000XwPBAA08018d000000Y1qCAAS8018d000000Z3kDAB1 | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane zostały ostatnio pobrane lub odświeżone. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z systemu źródłowego. Informuje, jak aktualne są analizowane dane. Analitycy wykorzystują tę informację, aby sprawdzić, czy pracują na najnowszych danych o procesie, i ocenić aktualność wniosków. To ważny element metadanych każdego projektu process mining. Dlaczego to ważne Informuje użytkowników o aktualności danych, dzięki czemu wiedzą, jakiego okresu dotyczy analiza. Skąd pobrać To znacznik czasu generowany i dodawany podczas procesu pobierania, przekształcania i ładowania danych (ETL). Przykłady 2023-11-01T05:00:00Z | |||
| System źródłowy SourceSystem | Wskazuje system, z którego pobrano dane. | ||
| Opis Ten atrybut określa źródło danych o procesie. W tej analizie będzie to zawsze „Salesforce Sales Cloud”. W środowiskach korzystających z wielu systemów pole to ma zasadnicze znaczenie dla śledzenia pochodzenia danych i rozwiązywania problemów. Nawet gdy używany jest tylko jeden system, dostarcza ważnych informacji o źródle danych. Dlaczego to ważne Informuje o pochodzeniu danych, co ma znaczenie dla zarządzania danymi i łączenia danych z wielu systemów źródłowych. Skąd pobrać Zwykle jest to stała wartość dodawana podczas pobierania danych w celu oznaczenia zbioru. Przykłady Salesforce Sales Cloud | |||
| Łączna wartość zamówienia TotalOrderAmount | Łączna wartość pieniężna zamówienia sprzedaży. | ||
| Opis Ten atrybut określa łączną wartość finansową zamówienia klienta. To ważna miara, która pozwala ocenić wpływ sprawności lub nieefektywności procesu na działalność firmy. W analizie łączna wartość zamówienia może służyć do segmentacji spraw, na przykład do sprawdzenia, czy zamówienia o wysokiej wartości są obsługiwane inaczej lub częściej się opóźniają niż zamówienia o niższej wartości. Jest też podstawą do obliczania finansowych KPI i oceny wartości przepływającej przez proces. Dlaczego to ważne Umożliwia analizę finansową procesu, podział zamówień według wartości oraz określenie finansowego wpływu opóźnień i ponownej pracy. Skąd pobrać To pole „TotalAmount” w standardowym obiekcie Salesforce „Order”. Przykłady 5400.50125000.00950.75 | |||
| Łączny czas cyklu CycleTime | Czas od utworzenia zamówienia sprzedaży do jego ostatecznego zamknięcia. | ||
| Opis Łączny czas cyklu to KPI mierzący czas realizacji zamówienia sprzedaży od początku do końca. Oblicza się go jako różnicę między pierwszym zdarzeniem, na przykład „Utworzono zamówienie”, a ostatnim, na przykład „Zamknięto zamówienie”. Ta miara jest głównym elementem dashboardu „Czas realizacji zamówienia sprzedaży od początku do końca”. Analiza czasu cyklu pomaga wykrywać nieefektywności w całym procesie i oceniać wpływ działań usprawniających. Różnice w czasie cyklu można badać, dzieląc dane według innych atrybutów, takich jak kraj lub rodzina produktów. Dlaczego to ważne To podstawowy KPI do pomiaru ogólnej sprawności procesu i wykrywania długo realizowanych zamówień, które mogą wskazywać na problemy systemowe. Skąd pobrać Obliczany podczas transformacji danych przez odjęcie znacznika czasu pierwszego zdarzenia od znacznika czasu ostatniego zdarzenia dla każdego „SalesOrderId”. Przykłady 10 dni 4 godziny25 dni 11 godzin5 dni 2 godziny | |||
| Nazwa konta AccountName | Nazwa klienta lub firmy, która złożyła zamówienie sprzedaży. | ||
| Opis Nazwa konta wskazuje klienta powiązanego z zamówieniem sprzedaży. Dzięki temu można analizować proces z perspektywy klienta. Analitycy mogą używać tego atrybutu do filtrowania procesu dla wybranych klientów, porównywania jego przebiegu w różnych segmentach klientów oraz sprawdzania, czy konkretni klienci regularnie napotykają problemy. Pozwala on bezpośrednio powiązać wyniki procesu z doświadczeniami klientów. Dlaczego to ważne Łączy wyniki procesu z konkretnymi klientami. Umożliwia analizę i segmentację według klientów, aby wykrywać powtarzające się wzorce i problemy. Skąd pobrać Obiekt „Order” zawiera pole odwołania „AccountId”. Aby pobrać pole „Account.Name”, należy połączyć ten identyfikator z obiektem „Account”. Przykłady Global Tech Inc.Innovate Solutions LLCVenture Dynamics | |||
| Status zamówienia OrderStatus | Status zamówienia sprzedaży w chwili wystąpienia zdarzenia. | ||
| Opis Ten atrybut określa stan zamówienia sprzedaży, na przykład „Draft”, „Activated”, „Shipped” lub „Closed”. Zmiany statusu często służą do wyznaczania czynności w dzienniku procesu. Analiza statusu zamówienia dostarcza kontekstu dla każdego zdarzenia i pomaga śledzić postęp realizacji. Ułatwia też ocenę wyniku sprawy, na przykład rozróżnienie zamówień „Cancelled” od tych pomyślnie zamkniętych. Dlaczego to ważne Dostarcza ważnego kontekstu dla każdego zdarzenia i często stanowi podstawę określania czynności. Pomaga też analizować wyniki spraw, takie jak anulowanie zamówień. Skąd pobrać To pole listy wyboru „Status” standardowego obiektu Salesforce „Order”. Przykłady Wersja roboczaAktywowanoWysłanoZamkniętoAnulowane | |||
| Użytkownik wykonujący czynność UserPerformingAction | Nazwa użytkownika lub agenta systemowego, który wykonał czynność. | ||
| Opis Ten atrybut wskazuje osobę odpowiedzialną za wykonanie etapu procesu. Może to być przedstawiciel handlowy, analityk kredytowy lub użytkownik systemowy obsługujący automatyzację. Analiza według użytkownika pomaga zrozumieć rozkład obciążenia pracą, indywidualne wyniki i poziom automatyzacji. Pozwala odpowiedzieć na pytania takie jak: „Którzy użytkownicy najczęściej poprawiają swoją pracę?” lub „Czy niektóre zespoły szybciej zatwierdzają zamówienia?”. Atrybut służy też do analizy sieci współpracy i przekazywania pracy między osobami. Dlaczego to ważne Umożliwia analizę wyników pracy według użytkownika, zespołu lub roli oraz pomaga wykrywać możliwości automatyzacji i potrzeby szkoleniowe. Skąd pobrać Można go znaleźć w polach takich jak „LastModifiedById” obiektu „Order” lub „OwnerId” rekordów „Task”. Aby uzyskać nazwę użytkownika, te identyfikatory trzeba połączyć z obiektem „User”. Przykłady Alice SmithBob JohnsonAutomatyzacja systemowaZespół ds. oceny zdolności kredytowej | |||
| Żądana data dostawy RequestedDeliveryDate | Data dostawy zamówienia wskazana przez klienta. | ||
| Opis Ten atrybut przechowuje datę, w której klient oczekuje dostawy towarów. Stanowi punkt odniesienia przy ocenie terminowości dostaw i zadowolenia klientów. Data jest wykorzystywana bezpośrednio w dashboardzie „Śledzenie zgodności z terminem dostawy” oraz KPI „Odsetek dostaw na czas”. Porównuje się ją z faktyczną datą dostawy, czyli znacznikiem czasu zdarzenia „Dostarczono towary”, aby ustalić, czy zamówienie dostarczono na czas, wcześniej czy z opóźnieniem. Dlaczego to ważne To podstawowy punkt odniesienia przy ocenie terminowości dostaw, która świadczy o zadowoleniu klientów i sprawności operacyjnej. Skąd pobrać Często jest to niestandardowe pole daty w obiekcie „Order”. Jego dokładna nazwa może się różnić. Należy sprawdzić dokumentację lub schemat Salesforce Sales Cloud. Przykłady 2023-11-152023-12-012024-01-10 | |||
| Czas pobrania płatności PaymentCollectionDuration | Czas od wysłania faktury do klienta do otrzymania płatności. | ||
| Opis Ta wyliczana miara określa sprawność końcowego, istotnego etapu procesu od zamówienia do płatności, czyli uzyskania zapłaty. Mierzy czas od działania „Wysłano fakturę do klienta” do działania „Otrzymano płatność”. Atrybut ten bezpośrednio wspiera dashboard „Czas pobrania płatności” oraz KPI „Czas realizacji płatności”. Analiza tego czasu pomaga działowi finansowemu wykrywać wąskie gardła w procesie należności, oceniać skuteczność warunków płatności i znajdować sposoby na szybszy przepływ gotówki. Dlaczego to ważne Mierzy sprawność procesu obsługi należności, który bezpośrednio wpływa na przepływ gotówki w firmie. Skąd pobrać Obliczany podczas transformacji danych przez odjęcie znacznika czasu zdarzenia „Wysłano fakturę do klienta” od znacznika czasu zdarzenia „Otrzymano płatność” dla każdej sprawy. Przykłady 30 dni15 dni 8 godzin45 dni | |||
| Czas zakończenia zdarzenia EventEndTime | Dokładna data i godzina zakończenia czynności. | ||
| Opis Czas zakończenia zdarzenia wskazuje moment ukończenia czynności. Wiele narzędzi process mining wyznacza go na podstawie czasu rozpoczęcia kolejnej czynności, ale jawne zapisanie tej wartości pozwala dokładniej mierzyć czas trwania, zwłaszcza w przypadku zadań długotrwałych. Atrybut służy do precyzyjnego obliczania czasu pracy nad czynnością. Jest szczególnie przydatny przy analizie zadań trwających długo, takich jak „Przeprowadzenie oceny zdolności kredytowej” lub „Przydzielenie zapasów”. Pozwala oddzielić czas aktywnej pracy od czasu oczekiwania. Dlaczego to ważne Umożliwia precyzyjne obliczenie czasu realizacji poszczególnych czynności, co pomaga wykrywać wąskie gardła i etapy wymagające dużych nakładów zasobów. Skąd pobrać Można go wyznaczyć na podstawie pola „StartTime” kolejnego zdarzenia w sekwencji dla danej sprawy. W przypadku niektórych czynności może pochodzić z konkretnego pola, takiego jak „Task.CompletedDateTime”. Przykłady 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Czy dostawa była terminowa IsOnTimeDelivery | Flaga wskazująca, czy towary dostarczono w dniu żądanej dostawy lub wcześniej. | ||
| Opis Ten atrybut logiczny bezpośrednio mierzy terminowość dostawy względem oczekiwań klienta. Oblicza się go przez porównanie znacznika czasu działania „Dostarczono towary” z wartością „RequestedDeliveryDate”. Jest podstawą obliczania KPI „Odsetek dostaw na czas”. Analiza tej flagi pozwala ocenić, czy firma dotrzymuje zobowiązań, co ma duży wpływ na zadowolenie klientów. Połączenie jej z innymi atrybutami może ujawnić, czy wybrane metody wysyłki lub regiony mają niższy odsetek dostaw na czas. Dlaczego to ważne Zapewnia jednoznaczną, binarną miarę realizacji zobowiązań wobec klientów i bezpośrednio wspiera KPI „Odsetek dostaw na czas”. Skąd pobrać Obliczany podczas transformacji danych. Reguła: IF ('Goods Delivered' EventTime <= 'RequestedDeliveryDate') THEN true ELSE false. Przykłady truefalse | |||
| Czy wymaga ponownej pracy IsRework | Flaga wskazująca, czy zamówienie sprzedaży wymagało ponownej pracy, na przykład powtórzenia działania lub przejścia pętlą przez proces. | ||
| Opis Ten wyliczany atrybut wskazuje sprawy, których przebieg odbiega od liniowej ścieżki prowadzącej do przodu. Ponowna praca występuje, gdy działanie trzeba powtórzyć lub proces wraca do wcześniejszego etapu, często z powodu błędów, brakujących informacji albo odrzuconych zatwierdzeń. Flaga służy do obliczania KPI „Odsetek zamówień sprzedaży wymagających ponownej pracy” i zasilania dashboardu „Ponowna praca i błędy w zamówieniach sprzedaży”. Pomaga określić częstotliwość i wpływ nieefektywności oraz wskazać obszary wymagające lepszej kontroli jakości lub doprecyzowania procesu. Dlaczego to ważne Pokazuje nieefektywność procesu, wskazując zamówienia wymagające dodatkowej, nieplanowanej pracy, która bezpośrednio wpływa na koszty i czas cyklu. Skąd pobrać Wartość obliczana przez oprogramowanie process mining lub podczas transformacji danych na podstawie powtarzających się nazw działań albo cofnięć w przebiegu procesu dla danej sprawy. Przykłady truefalse | |||
| Czy zautomatyzowane IsAutomated | Flaga wskazująca, czy działanie wykonał proces systemowy, czy użytkownik. | ||
| Opis Ten atrybut logiczny odróżnia zdarzenia wywołane przez automatyzację systemową, na przykład automatyczną zmianę statusu, od działań wykonanych ręcznie przez użytkownika. Pozwala ocenić poziom automatyzacji procesu. Analiza tego atrybutu pomaga określić wpływ automatyzacji na sprawność i powtarzalność procesu. Umożliwia porównanie ścieżek zautomatyzowanych i ręcznych oraz wskazanie możliwości dalszej automatyzacji, która ograniczy pracę ręczną i ryzyko błędów. Dlaczego to ważne Pozwala odróżnić działania systemu od działań użytkowników, co ułatwia analizę automatyzacji i wskazanie możliwości ograniczenia pracy ręcznej. Skąd pobrać Wartość wyliczana podczas transformacji danych na podstawie tego, czy „UserPerformingAction” jest wskazanym użytkownikiem systemowym, lub reguł opartych na typie działania. Przykłady truefalse | |||
| Identyfikator faktury InvoiceId | Unikalny identyfikator faktury powiązanej z zamówieniem sprzedaży. | ||
| Opis Identyfikator faktury łączy zamówienie sprzedaży z odpowiadającą mu fakturą. Wystawienie i wysłanie faktury to ważne etapy drugiej części procesu od zamówienia do płatności. Atrybut ten pozwala śledzić proces od realizacji zamówienia do otrzymania płatności. Umożliwia dokładny pomiar działań „Wystawiono fakturę” i „Wysłano fakturę do klienta”, potrzebny do obliczenia czasu pobrania płatności. Dlaczego to ważne Łączy zamówienie sprzedaży z podprocesem fakturowania, umożliwiając dokładne śledzenie działań finansowych i czasu cyklu płatności. Skąd pobrać Często jest to niestandardowe pole odwołania w obiekcie „Order”, wskazujące standardowy lub niestandardowy obiekt „Invoice”. Szczegóły zależą od wdrożenia. Przykłady INV-001234INV-001235INV-001236 | |||
| Kanał sprzedaży SalesChannel | Kanał, za pośrednictwem którego złożono zamówienie sprzedaży, na przykład „Internet”, „Sprzedaż bezpośrednia” lub „Partner”. | ||
| Opis Atrybut „Kanał sprzedaży” klasyfikuje zamówienia według źródła ich pochodzenia. Pozwala porównywać wyniki procesu w różnych kanałach. Atrybut jest niezbędny w dashboardzie „Porównanie wyników kanałów sprzedaży”. Filtrowanie i porównywanie danych według kanału pomaga ustalić, które kanały działają najsprawniej, w których najczęściej trzeba ponawiać pracę i gdzie warto ujednolicić sposób działania. Dlaczego to ważne Umożliwia porównanie wyników w różnych kanałach sprzedaży, co pomaga wskazać dobre praktyki i obszary wymagające ujednolicenia procesów. Skąd pobrać Zazwyczaj jest to niestandardowe pole wyboru w obiekcie „Order” lub „Opportunity”. Należy sprawdzić dokumentację lub schemat Salesforce Sales Cloud. Przykłady Sprzedaż bezpośredniaPortal internetowySieć partnerówSprzedaż telefoniczna | |||
| Kraj wysyłki ShippingCountry | Kraj docelowy przesyłki z zamówieniem sprzedaży. | ||
| Opis Ten atrybut określa kraj, do którego wysyłane jest zamówienie. Jest ważnym wymiarem analizy geograficznej procesu od zamówienia do płatności. Analiza według kraju wysyłki może ujawnić regionalne różnice w przebiegu procesu, na przykład dłuższy czas dostawy zamówień międzynarodowych lub różnice w cyklach pobierania płatności. Segmentacja procesu według regionu pomaga zrozumieć i rozwiązywać lokalne problemy. Dlaczego to ważne Umożliwia geograficzną segmentację procesu, która może ujawnić różnice w wynikach między regionami, problemy ze zgodnością lub wyzwania logistyczne. Skąd pobrać To pole „ShippingCountry” w standardowym obiekcie Salesforce „Order”. Przykłady USANiemcyJaponiaBrazylia | |||
| Metoda wysyłki ShippingMethod | Metoda wysyłki towarów, na przykład „Standardowa przesyłka lądowa”, „Ekspresowa” lub „Międzynarodowa”. | ||
| Opis Ten atrybut określa poziom usługi logistycznej wybranej do dostawy zamówienia. Bezpośrednio wpływa na czas i koszt dostawy. W analizie „Efektywność metod wysyłki” służy do porównywania różnych opcji. Pomaga sprawdzić, czy przesyłki ekspresowe docierają w zadeklarowanym terminie oraz jak poszczególne metody wpływają na czas od zdarzenia „Wysłano towary” do „Dostarczono towary”. Dlaczego to ważne Umożliwia analizę wyników logistyki i ocenę kosztów oraz sprawności różnych metod wysyłki. Skąd pobrać Prawdopodobnie jest to niestandardowe pole w obiekcie „Order” lub powiązanym niestandardowym obiekcie „Shipment”. Należy sprawdzić dokumentację lub schemat Salesforce Sales Cloud. Przykłady Standardowa przesyłka lądowaEkspresowa dostawa w 2 dniDostawa lotnicza następnego dniaMiędzynarodowa przesyłka priorytetowa | |||
| Rodzina produktów ProductFamily | Kategoria lub rodzina, do której należą produkty w zamówieniu. | ||
| Opis Rodzina produktów to ogólna klasyfikacja pozycji w zamówieniu sprzedaży. Umożliwia analizę procesu z uwzględnieniem rodzaju sprzedawanego produktu. Atrybut ten pozwala segmentować proces i sprawdzać, czy poszczególne rodziny produktów wiążą się z innymi ścieżkami procesu, dłuższym czasem realizacji lub częstszą ponowną pracą. Na przykład złożone produkty konfigurowalne mogą wymagać bardziej rozbudowanego procesu zatwierdzania i realizacji niż standardowe produkty gotowe. Dlaczego to ważne Umożliwia analizę procesu według kategorii produktu i pokazuje, czy różne rodzaje produktów wpływają na sprawność procesu. Skąd pobrać Dane pochodzą z obiektu „Product2”, połączonego z obiektem „Order” przez obiekt pośredniczący „OrderItem”. Wymaga to połączenia Order -> OrderItem -> PricebookEntry -> Product2. Przykłady SprzętLicencje na oprogramowanieUsługi profesjonalneUmowy serwisowe | |||
| Status weryfikacji zdolności kredytowej CreditCheckStatus | Wynik weryfikacji zdolności kredytowej dla zamówienia. | ||
| Opis Ten atrybut wskazuje wynik oceny zdolności kredytowej klienta, która często stanowi ważny etap procesu obsługi zamówienia. Typowe wartości to „Zatwierdzono”, „Odrzucono” i „Oczekuje”. Atrybut jest niezbędny w dashboardzie „Analiza wąskiego gardła w weryfikacji zdolności kredytowej”. Śledząc moment rozpoczęcia i zakończenia tego etapu oraz jego wynik, można zmierzyć czas jego trwania i wskazać, czy powoduje opóźnienia. Dlaczego to ważne Umożliwia analizę etapu weryfikacji zdolności kredytowej, w tym pomiar jego czasu trwania, skuteczności i wpływu na łączny czas procesu. Skąd pobrać Prawdopodobnie jest to niestandardowe pole w obiekcie „Order” lub „Account”. Należy sprawdzić dokumentację lub schemat Salesforce Sales Cloud. Przykłady ZatwierdzonoOdrzuconoOczekuje na weryfikacjęNie dotyczy | |||
| Właściciel zamówienia OrderOwner | Główny użytkownik odpowiedzialny za obsługę zamówienia sprzedaży. | ||
| Opis Właściciel zamówienia to przedstawiciel handlowy lub opiekun klienta, który odpowiada za dane zamówienie. Nie musi to być osoba wykonująca konkretne działanie. Właściciel odpowiada za cały przebieg sprawy. Analiza według właściciela pomaga ocenić obciążenie pracą i wyniki zespołów lub poszczególnych osób w obsłudze przypisanych im zamówień. Może wskazać właścicieli, których zamówienia często utknęły w procesie lub wymagają ponownej pracy, co może być sygnałem, że warto zapewnić im dodatkowe wsparcie. Dlaczego to ważne Wskazuje osobę odpowiedzialną za pomyślną realizację zamówienia i umożliwia analizę obciążenia pracą oraz wyników na poziomie właściciela. Skąd pobrać To pole „OwnerId” w obiekcie „Order”. Identyfikator można połączyć z obiektem „User”, aby pobrać nazwę właściciela. Przykłady Jane DoeJohn SmithZespół sprzedaży, wschód | |||
Działania w procesie od zamówienia do płatności: obsługa zamówień sprzedaży
| Działanie | Opis | ||
|---|---|---|---|
| Aktywacja zamówienia | Standardowe zdarzenie Salesforce oznaczające sfinalizowanie zamówienia i możliwość przekazania go do realizacji oraz fakturowania. Aktywacja blokuje większość zmian w zamówieniu i jest rejestrowana jako określona zmiana statusu. | ||
| Dlaczego to ważne Aktywacja to ważny, nieodwracalny etap potwierdzający ważność zamówienia. Oznacza formalne przekazanie go ze sprzedaży do operacji i jest istotnym elementem pomiaru czasu realizacji zamówień. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany standardowego pola „Status” obiektu „Order” na „Activated”. Znacznik czasu jest zapisywany w historii zmian pól obiektu „Order”. Rejestrowanie Monitorowanie historii pól obiektu „Order” pod kątem zmiany statusu na „Activated”. Typ zdarzenia inferred | |||
| Dostarczenie towaru | Oznacza, że przesyłka dotarła do klienta. Informacje pochodzą z systemu przewoźnika i są przekazywane z powrotem do Salesforce. | ||
| Dlaczego to ważne To zdarzenie jest niezbędne do obliczenia KPI „On-Time Delivery Rate” i pomiaru rzeczywistego czasu realizacji z perspektywy klienta. Potwierdza zakończenie procesu realizacji zamówienia. Skąd pobrać Zdarzenie można ustalić na podstawie uzupełnienia pola „Delivery Date” w obiekcie „Order” lub niestandardowym obiekcie „Shipment”. Dane są zwykle przekazywane przez integrację z dostawcą usług logistycznych. Rejestrowanie Użycie znacznika czasu z chwili uzupełnienia pola daty dostawy. Typ zdarzenia inferred | |||
| Otrzymanie płatności | Oznacza potwierdzenie otrzymania i uzgodnienia płatności od klienta. Informacja jest przekazywana z systemu finansowego do Salesforce, zwykle jako zmiana statusu. | ||
| Dlaczego to ważne To ostatni etap uzyskania płatności za sprzedaż. Analiza czasu od „Invoice Sent” do tego momentu ma zasadnicze znaczenie dla zarządzania przepływem środków pieniężnych i wskaźnikiem DSO (dniami należności). Skąd pobrać Zdarzenie można ustalić na podstawie zmiany statusu obiektu „Invoice” na „Paid” lub „Closed”. Aktualizacja jest przekazywana przez integrację z systemem księgowym lub systemem obsługi płatności. Rejestrowanie Śledzenie zmian statusu obiektu „Invoice” przekazywanych przez integrację z zewnętrznym systemem finansowym. Typ zdarzenia inferred | |||
| Utworzenie faktury | Oznacza wystawienie faktury za zamówienie sprzedaży. Zdarzenie można zarejestrować jako utworzenie powiązanego obiektu „Invoice”, natywnie w Salesforce Billing lub przez integrację. | ||
| Dlaczego to ważne Ten etap rozpoczyna finansową część procesu, czyli pobieranie płatności. Czas między dostawą a wystawieniem faktury może ujawnić opóźnienia administracyjne wpływające na przepływ środków pieniężnych. Skąd pobrać Zdarzenie można ustalić na podstawie daty utworzenia standardowego lub niestandardowego obiektu „Invoice” powiązanego z obiektem „Order”. Rejestrowanie Użycie pola „CreatedDate” powiązanego rekordu Invoice. Typ zdarzenia inferred | |||
| Utworzenie zamówienia | Oznacza utworzenie rekordu zamówienia sprzedaży w systemie. Zdarzenie jest rejestrowane w chwili pierwszego zapisania nowego obiektu „Order” w Salesforce. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające proces od zamówienia do płatności. Analiza czasu od tego momentu do kolejnych czynności pozwala zrozumieć łączny czas realizacji. Skąd pobrać Zdarzenie utworzenia obiektu „Order”. Znacznik czasu pochodzi ze standardowego pola „CreatedDate” rekordu Order. Rejestrowanie Bezpośrednio ze znacznika czasu „CreatedDate” obiektu „Order”. Typ zdarzenia explicit | |||
| Wysłanie towaru | Oznacza moment fizycznego wysłania zamówienia z magazynu do klienta. Zdarzenie jest niemal zawsze rejestrowane na podstawie aktualizacji przekazanej do Salesforce przez zewnętrzny system wysyłkowy lub ERP. | ||
| Dlaczego to ważne To ważny etap przy pomiarze KPI „On-Time Shipping Rate” i ogólnej sprawności realizacji zamówień. Rozpoczyna etap dostawy w ścieżce klienta. Skąd pobrać Zdarzenie można ustalić na podstawie uzupełnienia pola „Shipped Date” lub „Tracking Number” w obiekcie „Order” albo powiązanym obiekcie niestandardowym „Shipment”. Dane pochodzą z systemu realizacji zamówień. Rejestrowanie Użycie znacznika czasu z chwili pierwszego uzupełnienia pola daty wysyłki lub numeru śledzenia. Typ zdarzenia inferred | |||
| Zamknięcie zamówienia | Oznacza pomyślne zakończenie i ostateczne zamknięcie zamówienia sprzedaży w systemie. Zdarzenie można ustalić na podstawie końcowej aktualizacji statusu zamówienia, która wskazuje, że nie są już potrzebne żadne działania. | ||
| Dlaczego to ważne To główne zdarzenie kończące standardową, pomyślną ścieżkę procesu. Pomiar łącznego czasu do tego etapu pozwala obliczyć KPI „Average Order to Close Time”. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany pola „Status” obiektu „Order” na końcową wartość, taką jak „Closed”, „Completed” lub „Fulfilled”. Znacznik czasu jest dostępny w historii zmian pól. Rejestrowanie Monitorowanie historii pól obiektu „Order” pod kątem zmiany statusu na końcowy, oznaczający zakończenie. Typ zdarzenia inferred | |||
| Anulowanie zamówienia | Oznacza anulowanie zamówienia przed zakończeniem jego realizacji. Zdarzenie jest rejestrowane jako końcowa zmiana statusu rekordu zamówienia. | ||
| Dlaczego to ważne To ważne zdarzenie wyjątkowe i kończące proces. Analiza przyczyn i momentu anulowania zamówień może ujawnić problemy w procesie sprzedaży, dostępności produktów lub ocenie zdolności kredytowej klienta. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany pola „Status” obiektu „Order” na „Cancelled”. Znacznik czasu można znaleźć w historii zmian pola „Status”. Rejestrowanie Monitorowanie historii pól obiektu „Order” pod kątem zmiany statusu na „Cancelled”. Typ zdarzenia inferred | |||
| Przekazanie zamówienia do realizacji | Oznacza przekazanie aktywowanego zamówienia do magazynu lub systemu realizacji, aby można było skompletować i zapakować produkty. Zdarzenie jest zwykle rejestrowane jako zmiana statusu zamówienia wywołana przez integrację. | ||
| Dlaczego to ważne To zdarzenie oddziela handlową i logistyczną część procesu. Pomiar czasu od aktywacji do tego momentu pomaga odróżnić opóźnienia administracyjne od opóźnień w pracy magazynu. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany statusu obiektu „Order” na wartość taką jak „Sent to Fulfillment” lub „Awaiting Shipment”. Zmiana statusu jest często wywoływana przez integrację z systemem ERP lub WMS. Rejestrowanie Monitorowanie pola „Status” obiektu „Order” pod kątem wartości wskazujących na przekazanie zamówienia do realizacji. Typ zdarzenia inferred | |||
| Przekazanie zamówienia do zatwierdzenia | Oznacza przekazanie wersji roboczej zamówienia do formalnego workflow zatwierdzania. Zdarzenie jest zwykle ustalane na podstawie zmiany statusu zamówienia lub utworzenia rekordu w historii procesu zatwierdzania Salesforce. | ||
| Dlaczego to ważne Śledzenie przekazania zamówień do zatwierdzenia pozwala zmierzyć czas oczekiwania na decyzję i sprawność samego procesu weryfikacji. Ujawnia też wąskie gardła przed zatwierdzeniem. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany statusu obiektu „Order” (np. z „Draft” na „Submitted for Approval”) lub daty przekazania zapisanej w obiekcie „ProcessInstance” powiązanym z zamówieniem. Rejestrowanie Śledzenie zmian pola statusu lub odpytywanie obiektu „ProcessInstance”. Typ zdarzenia inferred | |||
| Przeprowadzenie oceny zdolności kredytowej | Oznacza zakończenie oceny zdolności kredytowej klienta powiązanego z zamówieniem. Często jest to zdarzenie wywnioskowane na podstawie zmiany pola niestandardowego, takiego jak „Credit Check Status”, na „Passed” lub „Completed”. | ||
| Dlaczego to ważne Ten etap często powoduje znaczne opóźnienia. Pomiar czasu jego trwania i oczekiwania jest niezbędny do analizy dashboardu „Credit Check Bottleneck Analysis” i usprawnienia przepływu środków pieniężnych. Skąd pobrać Zdarzenie można ustalić na podstawie znacznika czasu lub zmiany statusu w polu niestandardowym obiektu „Order” albo powiązanego obiektu „Account”, na przykład „Credit_Check_Date__c” lub „Credit_Status__c”. Rejestrowanie Śledzenie zmian pól niestandardowych wskazujących na zakończenie oceny zdolności kredytowej. Typ zdarzenia inferred | |||
| Przydzielenie zapasów | Oznacza zarezerwowanie produktów z zamówienia w systemie magazynowym. Zdarzenie zwykle pochodzi z zewnętrznego systemu ERP lub systemu zarządzania zapasami, który aktualizuje Salesforce. Jest rejestrowane jako zmiana pola. | ||
| Dlaczego to ważne Ten etap ma zasadnicze znaczenie dla analizy KPI „Inventory Allocation Lead Time”. Opóźnienia bezpośrednio utrudniają terminową wysyłkę zamówień. Skąd pobrać Wymaga analizy systemu. Zdarzenie często można ustalić na podstawie zmiany statusu obiektu „Order” lub „OrderItem” albo uzupełnienia pola niestandardowego „Allocation_Date__c” przez integrację. Rejestrowanie Śledzenie zmian pól statusu lub daty w obiektach Order lub OrderItem, wprowadzanych przez integrację z ERP. Typ zdarzenia inferred | |||
| Wysłanie faktury do klienta | Oznacza wysłanie faktury do klienta z prośbą o płatność. Zdarzenie jest zwykle rejestrowane jako zmiana statusu rekordu faktury. | ||
| Dlaczego to ważne To zdarzenie rozpoczyna pomiar KPI „Payment Realization Time”. Każde opóźnienie między wystawieniem a wysłaniem faktury przesuwa początek terminu płatności. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany statusu obiektu „Invoice” na „Sent” lub podobną wartość. Można też wykorzystać wpis w dzienniku aktywności dotyczący wysłania wiadomości e-mail. Rejestrowanie Monitorowanie pola „Status” powiązanego obiektu „Invoice” lub wyszukiwanie aktywności dotyczących wysłanych wiadomości e-mail. Typ zdarzenia inferred | |||
| Zatwierdzenie zamówienia | Oznacza formalne zatwierdzenie zamówienia sprzedaży przez wszystkie wymagane osoby. Zamówienie może wtedy przejść do kolejnego etapu. Zdarzenie można wykryć, obserwując ostatni krok zatwierdzania w workflow lub odpowiadającą mu zmianę statusu. | ||
| Dlaczego to ważne To ważny etap, który umożliwia rozpoczęcie realizacji zamówienia. Opóźnienia w zatwierdzaniu mogą znacząco wydłużyć cały proces od zamówienia do płatności. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany pola statusu obiektu „Order” na wartość taką jak „Approved”. Można je też wywnioskować z daty zakończenia powiązanego rekordu „ProcessInstance”. Rejestrowanie Monitorowanie pola „Status” obiektu „Order” lub zakończenia procesu zatwierdzania w historii. Typ zdarzenia inferred | |||
Instrukcje wyodrębniania danych
Kroki
- Wymaganie wstępne: skonfiguruj śledzenie historii pól: Przed utworzeniem raportów administrator Salesforce musi włączyć śledzenie historii pól dla obiektu Order. Należy śledzić pole Status oraz wszystkie pola niestandardowe używane do oznaczania zdarzeń, takie jak Credit_Check_Status__c lub Fulfillment_Status__c. Można to skonfigurować w Setup > Object Manager > Order > Fields & Relationships > Set History Tracking.
- Utwórz niestandardowy typ raportu: Aby wyświetlać historię zmian pól razem ze szczegółami zamówień, utwórz niestandardowy typ raportu. Przejdź do Setup > Report Types. Utwórz nowy typ raportu, wybierając Orders jako obiekt główny. Następnie dodaj Order History jako obiekt powiązany. Ustaw relację tak, aby rekordy „A” mogły mieć powiązane rekordy „B”, ale nie musiały. Dzięki temu raport obejmie wszystkie zamówienia, również te bez historii. Zapisz typ raportu jako „Orders with History”.
- Utwórz główny raport „Events”: Przejdź do karty Reports i kliknij New Report. Wybierz typ raportu „Orders with History”. Raport będzie zawierał wszystkie działania wynikające ze zmian pól.
- Skonfiguruj kolumny raportu „Events”: Dodaj następujące kolumny: Order: Order Number (dla SalesOrderId), Edit Date (dla EventTime), User (dla UserPerformingAction), Field/Event (zmienione pole), Original Value i New Value. Dodaj też kolumny z nadrzędnego obiektu Order, takie jak Order: Total Amount, Account: Account Name oraz Order: Company Authorized By Date (w razie potrzeby jako przybliżenie RequestedDeliveryDate).
- Ustaw filtry raportu „Events”: W filtrze Show Me wybierz All orders, a w polu Date Field ustaw Created Date i określ zakres, na przykład Last 3 Months. Dodaj filtr dla kolumny Field/Event, aby uwzględnić tylko zmiany pól odpowiadające śledzonym działaniom, na przykład Status lub Credit_Check_Status__c.
- Utwórz raport „Order Created”: Utwórz drugi, prostszy raport, korzystając ze standardowego typu raportu Orders. Ma on zawierać wyłącznie zdarzenia utworzenia zamówienia. Dodaj kolumny Order Number, Created Date, Created By, Status, Total Amount i Account Name. Ustaw filtr Created Date dla wybranego zakresu.
- Wyeksportuj oba raporty: Uruchom raporty i wybierz opcję Export. Wybierz format Details Only oraz Comma Delimited .csv.
- Połącz i przekształć dane: Otwórz wyeksportowane pliki CSV w arkuszu kalkulacyjnym, takim jak Microsoft Excel, albo użyj języka skryptowego, na przykład Python.
- W raporcie „Events” utwórz kolumnę ActivityName. Za pomocą formuł lub skryptu przypisz zmianom pól odpowiednie nazwy działań. Na przykład, jeśli Field/Event ma wartość „Status”, a New Value ma wartość „Activated”, ustaw ActivityName na „Order Activated”.
- W raporcie „Order Created” dodaj kolumnę ActivityName i ustaw jej wartość na „Order Created” we wszystkich wierszach. Zmień nazwy kolumn tak, aby odpowiadały schematowi dziennika zdarzeń, na przykład Order Number → SalesOrderId, Created Date → EventTime.
- Połącz dane w jeden dziennik zdarzeń: Dodaj wiersze z przekształconego raportu „Order Created” do przekształconych danych z raportu „Events”. W ten sposób powstanie jedna lista wszystkich działań.
- Przygotuj plik do przesłania: Dodaj pozostałe wymagane kolumny: SourceSystem (ze stałą wartością „Salesforce Sales Cloud”) oraz LastDataUpdate (z bieżącym znacznikiem czasu). Sprawdź nagłówki kolumn i formaty danych, a następnie zapisz plik jako CSV gotowy do przesłania.
Konfiguracja
- Typy raportów: Niestandardowy typ raportu łączący Orders i Order History jest niezbędny do rejestrowania zmian statusu i innych aktualizacji pól jako osobnych zdarzeń.
- Śledzenie historii pól: Ta metoda wymaga włączenia śledzenia historii pól dla obiektu Order przed rozpoczęciem wyodrębniania danych. Należy śledzić ważne pola, takie jak Status, oraz pola niestandardowe opisujące etapy procesu.
- Filtry zakresu dat: Użyj pola Created Date w obiekcie Order jako głównego filtra, aby analizować spójną grupę zamówień. Na początek zalecany jest zakres od 3 do 6 miesięcy.
- Usługa eksportu danych: W środowiskach z dużą ilością danych można zaplanować eksport za pomocą Data Export Service, na przykład co tydzień lub co miesiąc. Usługa wyeksportuje wszystkie dane z wybranych obiektów (Order, OrderHistory, Account). Surowe dane wymagają bardziej zaawansowanego przetwarzania i łączenia poza Salesforce, ale pozwalają uniknąć przekroczenia limitu czasu i limitu wierszy w interaktywnym narzędziu Report Builder.
- Uprawnienia: Osoby wykonujące eksport potrzebują uprawnień do uruchamiania i eksportowania raportów oraz dostępu View All Data do obiektów Order i Account. Konfiguracja Data Export Service wymaga uprawnień administratora systemu.
- Struktura raportu: Aby ułatwić eksport i przetwarzanie, ustaw format raportu Tabular. Nie używaj formatów podsumowania ani macierzy.
Przykładowe zapytanie sql
/*
Salesforce Reports are configured through the user interface. This section describes the configuration of the necessary reports and the logic for post-processing. It is not an executable script.
*/
// ======== REPORT 1: Order Creation Events ========
{
"ReportName": "O2C - Order Created",
"ReportType": "Orders",
"Format": "Tabular",
"Filters": [
{
"Field": "Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
}
],
"Columns": [
{"SourceField": "Order Number", "OutputAs": "SalesOrderId"},
{"StaticValue": "Order Created", "OutputAs": "ActivityName"},
{"SourceField": 'Created Date', "OutputAs": "EventTime"},
{"SourceField": "Last Modified By: Full Name", "OutputAs": "UserPerformingAction"},
{"SourceField": "Status", "OutputAs": "OrderStatus"},
{"SourceField": "Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"},
{"SourceField": "[Your Requested Delivery Date Field]", "OutputAs": "RequestedDeliveryDate"}
]
}
// ======== REPORT 2: Order Field Change Events ========
{
"ReportName": "O2C - Order History Events",
"ReportType": "Orders with History (Custom)",
"Format": "Tabular",
"Filters": [
{
"Field": "Order: Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
},
{
"Field": "Field/Event",
"Operator": "in",
"Value": ["Status", "[Credit Check Status Field]", "[Inventory Status Field]", "[Fulfillment Status Field]", "[Shipping Status Field]", "[Delivery Status Field]", "[Invoice Status Field]", "[Payment Status Field]"]
}
],
"Columns": [
{"SourceField": "Order: Order Number", "OutputAs": "SalesOrderId"},
{"SourceField": "Edit Date", "OutputAs": "EventTime"},
{"SourceField": "User", "OutputAs": "UserPerformingAction"},
{"SourceField": "Field/Event", "OutputAs": "SourceFieldForActivity"},
{"SourceField": "New Value", "OutputAs": "SourceValueForActivity"},
{"SourceField": "Order: Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"}
]
}
// ======== EXTERNAL TRANSFORMATION LOGIC (to be applied after export) ========
/*
- Combine the two exported files.
- For the 'Order History Events' data, create the 'ActivityName' and 'OrderStatus' columns based on the following mapping logic:
CASE
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Submitted' THEN 'Order Submitted for Approval'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Approved' THEN 'Order Approved'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Activated' THEN 'Order Activated'
WHEN SourceFieldForActivity = '[Fulfillment Status Field]' AND SourceValueForActivity = 'Sent to Fulfillment' THEN 'Order Sent to Fulfillment'
WHEN SourceFieldForActivity = '[Shipping Status Field]' AND SourceValueForActivity = 'Shipped' THEN 'Goods Shipped'
WHEN SourceFieldForActivity = '[Delivery Status Field]' AND SourceValueForActivity = 'Delivered' THEN 'Goods Delivered'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Closed' THEN 'Order Closed'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Cancelled' THEN 'Order Cancelled'
WHEN SourceFieldForActivity = '[Credit Check Status Field]' AND SourceValueForActivity = 'Passed' THEN 'Credit Check Performed'
WHEN SourceFieldForActivity = '[Inventory Status Field]' AND SourceValueForActivity = 'Allocated' THEN 'Inventory Allocated'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Created' THEN 'Invoice Created'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Sent' THEN 'Invoice Sent to Customer'
WHEN SourceFieldForActivity = '[Payment Status Field]' AND SourceValueForActivity = 'Received' THEN 'Payment Received'
ELSE 'Unknown'
END AS ActivityName
- The OrderStatus attribute should be populated with the 'New Value' when the changed field was 'Status'. For other events, you may need to look up the order's status at that point in time, which is a limitation of this method.
- Add 'SourceSystem' and 'LastDataUpdate' columns to the final combined dataset.
*/ Gotowi do rozpoczęcia?
Już dziś rozpocznij optymalizację procesu od zamówienia do płatności, przygotowując dane za pomocą tego szablonu. Uzyskaj informacje, które pomogą usprawnić operacje i poprawić przepływy pieniężne.
Popraw przepływy pieniężne: zoptymalizuj obsługę zamówień sprzedaży
Wskaż nieefektywne działania, skróć czas cyklu o 30% i szybciej uzyskuj środki.
Karta kredytowa nie jest wymagana • Rozpoczęcie zajmuje kilka minut