Szablon danych do procesu od zatrudnienia do odejścia: zarządzanie stanowiskami
Szablon danych do procesu od zatrudnienia do odejścia: zarządzanie stanowiskami
- Zalecane atrybuty do zebrania na potrzeby szczegółowej analizy
- Najważniejsze działania procesowe do śledzenia, aby dokładnie odtworzyć przebieg procesu
- Wskazówki dotyczące eksportu danych z Microsoft Dynamics 365 Human Resources
Atrybuty procesu od zatrudnienia do odejścia: zarządzanie stanowiskami
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Znacznik czasu wskazujący, kiedy wystąpiło działanie. | ||
| Opis Czas zdarzenia, czyli znacznik czasu, określa dokładną datę i godzinę zakończenia działania. Jest niezbędny do uporządkowania zdarzeń chronologicznie oraz obliczania czasu trwania i czasu realizacji. Ten atrybut jest wykorzystywany w niemal każdej analizie process mining, od tworzenia mapy procesu po obliczanie KPI, takich jak „Średni czas akceptacji stanowiska”. Pomaga ustalić, kiedy występują opóźnienia i ile trwa każdy krok procesu. Dlaczego to ważne Ten znacznik czasu jest niezbędny do uporządkowania zdarzeń, obliczania wszystkich miar czasu i wykrywania wąskich gardeł procesu. Skąd pobrać Te informacje znajdują się zwykle w tabelach dzienników systemowych lub w polach „CreatedDateTime” i „ModifiedDateTime” powiązanych z rekordami stanowisk i workflow w Dynamics 365 HR. Przykłady 2023-04-15T09:00:00Z2023-04-15T14:35:10Z2023-04-18T11:21:05Z2023-05-02T16:45:00Z2024-01-10T10:00:00Z | |||
| Identyfikator stanowiska PositionId | Unikatowy identyfikator stanowiska w organizacji. | ||
| Opis Identyfikator stanowiska pełni funkcję głównego identyfikatora sprawy. Łączy wszystkie działania i dane dotyczące jednego stanowiska w organizacji. Umożliwia śledzenie całego cyklu życia stanowiska, od utworzenia i modyfikacji po dezaktywację lub zamknięcie. W analizie procesów ten identyfikator jest niezbędny do odtworzenia przebiegu obsługi każdego stanowiska. Pozwala tworzyć dashboardy monitorujące czas realizacji, wykrywać wąskie gardła w akceptacjach i analizować warianty procesu od złożenia wniosku do zamknięcia stanowiska. Dlaczego to ważne To podstawowy identyfikator, który łączy wszystkie powiązane zdarzenia w jedną sprawę procesową i umożliwia analizę całego cyklu życia stanowiska. Skąd pobrać W Microsoft Dynamics 365 Human Resources jest to zwykle pole HcmPosition.PositionId. Można je znaleźć w encjach danych, takich jak HcmPositionV2Entity. Przykłady POS001234MKT-0056FIN-SR-ANALYST-02HRBP-EAST-01IT-DEV-9876 | |||
| Nazwa działania ActivityName | Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w procesie zarządzania stanowiskami. | ||
| Opis Ten atrybut opisuje pojedynczy krok w cyklu życia stanowiska, na przykład „Zainicjowano wniosek o stanowisko”, „Utworzono stanowisko w systemie HR” lub „Dezaktywowano stanowisko”. Pokazuje kolejność zdarzeń i stanowi podstawę mapy procesu. Analiza nazwy działania pozwala wizualizować przebieg procesu, wykrywać odstępstwa od standardowego przebiegu i obliczać czas przejścia między poszczególnymi krokami. Dzięki temu można ustalić, co się wydarzyło i w jakiej kolejności. Dlaczego to ważne Określa kroki procesu, umożliwiając tworzenie map procesów oraz analizę ich przebiegu i wariantów. Skąd pobrać Ten atrybut jest ustalany na podstawie zdarzeń biznesowych, zmian statusu lub historii workflow w Microsoft Dynamics 365 Human Resources. Nie odpowiada mu jedno konkretne pole, ponieważ jest wyznaczany na podstawie kontekstu danych. Przykłady Zainicjowano wniosek o stanowiskoKierownik zaakceptował wniosek o stanowiskoUtworzono stanowisko w systemie HRZmieniono atrybuty stanowiskaZamknięto stanowisko | |||
| Centrum kosztów CostCenter | Centrum kosztów, na które przypisywane są wydatki związane ze stanowiskiem. | ||
| Opis Centrum kosztów to ważny wymiar finansowy, który łączy stanowisko z określonym budżetem lub obszarem odpowiedzialności finansowej. Warto monitorować zmiany tego atrybutu. Atrybut ten jest istotny dla dashboardu „Kontrola spójności danych stanowiska”, który analizuje zmiany ważnych atrybutów po utworzeniu stanowiska. Służy też do analizy kosztów i budżetów związanych ze stanowiskami w różnych jednostkach finansowych. Dlaczego to ważne Łączy stanowisko z danymi finansowymi, umożliwiając analizę kosztów procesu i kontrolę spójności danych. Skąd pobrać Zazwyczaj jest skonfigurowany jako wymiar finansowy w rekordzie stanowiska. Szczegóły konfiguracji wymiarów finansowych można sprawdzić w Dynamics 365. Przykłady CC-1001-FINCC-2500-ITCC-4510-SALESCC-7000-OPSCC-9002-HR | |||
| Czas zakończenia EndTime | Znacznik czasu wskazujący, kiedy zakończyła się dana czynność. | ||
| Opis EndTime oznacza zakończenie czynności. Czas między StartTime a EndTime to czas realizacji tej czynności. Atrybut ten jest niezbędny do obliczania czasu trwania poszczególnych czynności i sprawdzania, na co poświęcany jest czas w procesie. Pozwala na przykład ustalić, ile czasu zajmuje kierownikowi zatwierdzenie wniosku o utworzenie stanowiska po jego przypisaniu. Dlaczego to ważne Umożliwia obliczanie czasu realizacji czynności, co jest podstawą szczegółowej analizy efektywności i wąskich gardeł. Skąd pobrać Można go ustalić na podstawie znaczników czasu kolejnych zdarzeń lub konkretnych pól „completion” w logach workflow w Dynamics 365 HR. Często trzeba go wywnioskować. Przykłady 2023-04-15T09:05:12Z2023-04-15T15:00:00Z2023-04-19T09:00:00Z2023-05-03T10:00:00Z2024-01-10T10:05:00Z | |||
| Dział DepartmentName | Dział, do którego przypisane jest stanowisko. | ||
| Opis Ten atrybut określa dział organizacji, na przykład „Finanse”, „Marketing” lub „IT”, powiązany ze stanowiskiem. To podstawowy wymiar filtrowania i agregowania danych o procesie. Analiza według działu jest niezbędna w dashboardzie „Liczba stanowisk w działach”. Ułatwia porównanie wyników procesu, wykrywanie wąskich gardeł w poszczególnych działach i analizę trendów rekrutacyjnych w różnych częściach firmy. Dlaczego to ważne Pozwala analizować proces z podziałem na jednostki biznesowe, wykrywać problemy dotyczące konkretnych działów i porównywać wyniki. Skąd pobrać Informacja ta jest częścią szczegółów stanowiska. Zazwyczaj znajduje się w encji HcmPositionDetail i jest powiązana z wymiarem jednostki operacyjnej. Przykłady FinanseTechnologie informatyczneSprzedaż i marketingZasoby ludzkieOperacje | |||
| Nazwa stanowiska JobTitle | Nazwa stanowiska pracy powiązanego z pozycją, na przykład „Starszy księgowy”. | ||
| Opis Nazwa stanowiska pracy określa rolę i zakres obowiązków związanych z pozycją. Różni się od identyfikatora pozycji, ponieważ kilka pozycji może mieć tę samą nazwę stanowiska. W analizie ten atrybut pozwala grupować i filtrować dane według rodzaju roli. Przydaje się w dashboardzie „Trendy zmian klasyfikacji stanowisk”, który pokazuje, jakie stanowiska są najczęściej przeklasyfikowywane. Dlaczego to ważne Dostarcza kontekstu biznesowego i pozwala analizować dane według roli, poziomu lub funkcji stanowiska. Skąd pobrać Informacja pochodzi z rekordu „Job” powiązanego z pozycją. Można jej szukać w encjach takich jak HcmPositionV2Entity lub połączyć dane z HcmJobEntity. Przykłady Starszy analityk finansowyInżynier oprogramowania IIPartner biznesowy HRKoordynator ds. marketinguKierownik ds. logistyki | |||
| Nazwa użytkownika UserName | Imię i nazwisko lub identyfikator użytkownika, który wykonał daną czynność. | ||
| Opis Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za dany krok procesu, na przykład kierownika, który zatwierdził wniosek, albo specjalistę HR, który utworzył stanowisko w systemie. Analiza według użytkownika pomaga określić potrzeby szkoleniowe, porównać wyniki pracy członków zespołu i sprawdzić rozkład obciążenia. Jest też istotna przy kontroli zgodności, ponieważ pozwala zweryfikować prawidłowy podział obowiązków. Dlaczego to ważne Pozwala ustalić, kto odpowiadał za daną czynność, oraz analizować wyniki pracy poszczególnych osób i zespołów. Ma to znaczenie przy zarządzaniu zasobami i planowaniu szkoleń. Skąd pobrać Powiązany z historią workflow lub zapisami ścieżki audytu w Dynamics 365 HR. Może być połączony za pomocą identyfikatora użytkownika z encji HcmWorker. Przykłady John SmithJane DoeSYSTEMHRAdmin01MGR-FINANCE | |||
| Status stanowiska PositionStatus | Bieżący lub historyczny status stanowiska. | ||
| Opis Ten atrybut wskazuje stan stanowiska w danym momencie, na przykład „Proponowane”, „Aktywne”, „Zamrożone” lub „Zamknięte”. Zmiany statusu często odpowiadają czynnościom w procesie. Śledzenie statusu pozwala zrozumieć przebieg procesu dotyczącego stanowiska i korzystać z dashboardów takich jak „Status weryfikacji zgodności stanowisk” oraz „Nieaktualne i niewykorzystane stanowiska”. Pokazuje bieżący stan stanowiska i pomaga zweryfikować przebieg procesu. Dlaczego to ważne Jasno określa stan każdego stanowiska, co ułatwia filtrowanie spraw i analizę ich wyników. Skąd pobrać Informacje można znaleźć w dokumentacji Microsoft Dynamics 365 Human Resources. Prawdopodobnie pochodzą z pól statusu w głównym rekordzie Position. Przykłady ProponowaneW trakcie weryfikacjiAktywneZamrożoneZamknięte | |||
| Czas zatwierdzania ApprovalCycleTime | Łączny czas od złożenia wniosku o stanowisko do jego ostatecznego zatwierdzenia. | ||
| Opis Ten obliczany wskaźnik mierzy czas od czynności „Złożenie wniosku o stanowisko” do końcowej czynności zatwierdzającej, na przykład „Wniosek o stanowisko zatwierdzony przez HR”. Jest to KPI dotyczący początkowego etapu procesu zarządzania stanowiskami. Atrybut ten zasila dashboard i KPI „Czas zatwierdzania stanowiska”. Pokazuje ogólną sprawność procesu zatwierdzania i pozwala śledzić wpływ działań usprawniających. Dlaczego to ważne To ważny KPI mierzący sprawność całego procesu zatwierdzania. Bezpośrednio wskazuje opóźnienia w przygotowaniu stanowisk do utworzenia. Skąd pobrać Wartość oblicza się na poziomie sprawy, znajdując znaczniki czasu czynności rozpoczynającej i kończącej etap zatwierdzania, a następnie obliczając różnicę. Przykłady P3DT2H15MP10DP1DT12HP5DT6HP2W | |||
| Czy budżet zatwierdzony IsBudgetApproved | Flaga wskazująca, czy zatwierdzono budżet stanowiska. | ||
| Opis Ten atrybut logiczny ma wartość true, jeśli w historii danej sprawy dotyczącej stanowiska wystąpiła czynność „Zatwierdzenie budżetu stanowiska”. Ułatwia analizę przebiegu procesu i wykrywanie stanowisk oczekujących na budżet. Atrybut ten można wykorzystać do filtrowania procesów i dokładniejszej analizy KPI „Czas zatwierdzania budżetu stanowiska”. Pozwala odróżnić stanowiska, dla których zatwierdzono budżet, od tych, które nadal na to czekają, co ułatwia analizę wąskich gardeł. Dlaczego to ważne Ułatwia analizę, oznaczając ważny etap procesu, dzięki czemu można wyodrębnić i zmierzyć czas zatwierdzania budżetu. Skąd pobrać Wartość jest wyznaczana podczas transformacji danych przez sprawdzenie, czy w historii sprawy występuje czynność „Zatwierdzenie budżetu stanowiska”. Przykłady truefalse | |||
| Czy ponowna praca IsRework | Flaga wskazująca, czy czynność należy do pętli ponownej pracy. | ||
| Opis Ta flaga logiczna ma wartość true, jeśli czynność oznacza powtórzenie kroku procesu, na przykład ponowne zatwierdzenie po zmianie atrybutów. Ułatwia określenie skali nieefektywnych pętli w procesie. Atrybut ten bezpośrednio wspiera dashboard „Analiza ponownej pracy przy obsłudze stanowisk” oraz KPI „Odsetek ponownej pracy przy tworzeniu stanowiska”. Oznaczenie ponownej pracy ułatwia filtrowanie danych i pomiar częstotliwości oraz wpływu nieefektywności procesu. Dlaczego to ważne Jednoznacznie wskazuje i pozwala mierzyć ponowną pracę w procesie, która jest jednym z głównych obszarów działań usprawniających. Skąd pobrać Wartość oblicza się na podstawie kolejności czynności w danej sprawie. Na przykład czynność „Wniosek o stanowisko zatwierdzony przez kierownika” można oznaczyć jako ponowną pracę, jeśli występuje po czynności „Zmiana atrybutów stanowiska”. Przykłady truefalse | |||
| Data ostatniej aktualizacji LastDataUpdate | Znacznik czasu ostatniego odświeżenia danych z systemu źródłowego. | ||
| Opis Ten atrybut wskazuje, kiedy ostatnio pobrano dane z Microsoft Dynamics 365 Human Resources. Informuje, jak aktualne są dane wykorzystane w analizie. Wyświetlanie tej informacji na dashboardach pozwala użytkownikom sprawdzić, czy pracują na aktualnych danych. To ważny element metadanych każdego projektu process mining. Dlaczego to ważne Informuje użytkowników o aktualności danych, co ma znaczenie przy podejmowaniu decyzji na podstawie analizy. Skąd pobrać Ten znacznik czasu jest generowany i zapisywany podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Kierownik wnioskujący RequestingManager | Kierownik, który zainicjował wniosek o utworzenie stanowiska. | ||
| Opis Ten atrybut wskazuje kierownika ds. rekrutacji lub kierownika działu, który rozpoczął proces, składając wniosek o nowe stanowisko lub zastępstwo. Informacja ta pokazuje, skąd wynika zapotrzebowanie na stanowiska. Analiza według kierownika wnioskującego pomaga wykrywać wzorce dotyczące liczby wniosków, odsetka zatwierdzeń i jakości wniosków. Ułatwia też ocenę obciążenia pracą i przestrzegania procesu. Dlaczego to ważne Pomaga ustalić źródło zapotrzebowania na stanowiska i analizować wskaźniki procesu z perspektywy kierownika ds. rekrutacji. Skąd pobrać Informacje można znaleźć w dokumentacji Microsoft Dynamics 365 Human Resources. Prawdopodobnie są zapisywane w danych inicjujących workflow. Przykłady Robert JonesSusan MillerDavid ChenMaria GarciaPaul Williams | |||
| Lokalizacja Location | Fizyczna lub geograficzna lokalizacja stanowiska. | ||
| Opis Ten atrybut określa miejsce przypisania stanowiska, na przykład biuro, miasto lub kraj. To kolejny ważny wymiar filtrowania i segmentowania danych o procesie. Lokalizacja jest używana bezpośrednio w dashboardzie „Liczba stanowisk w działach” do analizy trendów zatrudnienia i wyników procesu w różnych regionach. Może pomóc ustalić, czy tworzenie lub zatwierdzanie stanowisk trwa dłużej w niektórych lokalizacjach. Dlaczego to ważne Dostarcza kontekstu geograficznego i pozwala analizować wyniki oraz trendy procesu w różnych lokalizacjach. Skąd pobrać Informacje można znaleźć w dokumentacji Microsoft Dynamics 365 Human Resources. Mogą być częścią szczegółów stanowiska lub być powiązane z działem albo jednostką prawną. Przykłady Nowy Jork, USALondyn, Wielka BrytaniaBerlin, NiemcySingapurPraca zdalna | |||
| Powód odrzucenia RejectionReason | Powód podany przy odrzuceniu wniosku o stanowisko. | ||
| Opis Gdy kierownik lub dział HR odrzuca wniosek o stanowisko, często zapisuje powód. Może nim być brak budżetu, nieprawidłowe informacje lub zmiana strategii. Atrybut ten jest niezbędny do obliczenia KPI „Odsetek odrzuconych wniosków o stanowisko” i ustalenia przyczyn ponownej pracy. Analiza najczęstszych powodów odrzucenia pomaga wykryć problemy na wcześniejszych etapach, takie jak niska jakość wniosków lub niejasne wytyczne, i wskazać, co można poprawić w procesie. Dlaczego to ważne Pokazuje bezpośrednio, dlaczego wnioski są odrzucane, co pozwala wprowadzać ukierunkowane usprawnienia i ograniczać ponowną pracę oraz liczbę odrzuceń. Skąd pobrać Informacje można znaleźć w dokumentacji Microsoft Dynamics 365 Human Resources. Powód jest często zapisywany w komentarzach workflow lub w dedykowanym polu kodu przyczyny odrzucenia. Przykłady Brak dostępnego budżetuZduplikowany wniosekNieprawidłowy profil stanowiskaWstrzymanie rekrutacjiZmiana kierunku strategicznego | |||
| Rodzaj stanowiska PositionType | Określa, czy stanowisko jest pełnoetatowe, niepełnoetatowe, tymczasowe itp. | ||
| Opis Ten atrybut klasyfikuje stanowisko według warunków zatrudnienia. Dostarcza dodatkowego kontekstu do analizy i planowania zatrudnienia. Filtrowanie według rodzaju stanowiska może ujawnić, czy różne rodzaje stanowisk mają odmienne ścieżki procesu lub dłuższy czas realizacji. Na przykład zatwierdzanie stanowisk tymczasowych może przebiegać szybciej i wymagać mniej kroków niż w przypadku stałych stanowisk pełnoetatowych. Dlaczego to ważne Pozwala analizować różnice w przebiegu procesu dla poszczególnych rodzajów zatrudnienia, co wspiera planowanie zatrudnienia i usprawnianie procesu. Skąd pobrać Informacja ta jest zazwyczaj dostępna w rekordzie stanowiska w Dynamics 365 HR. Odpowiedniego pola można szukać w encjach takich jak HcmPositionV2Entity. Przykłady Pełny etatNiepełny etatKontraktorStażystaTymczasowe | |||
| Rodzina stanowisk JobFamily | Grupa stanowisk o podobnym zakresie obowiązków, na przykład „Inżynieria” lub „Finanse”. | ||
| Opis Rodzina stanowisk to klasyfikacja grupująca powiązane nazwy stanowisk. Na przykład „Inżynier oprogramowania” i „Inżynier ds. zapewnienia jakości” mogą należeć do rodziny stanowisk „Inżynieria”. Atrybut ten jest niezbędny w dashboardzie „Trendy zmian klasyfikacji stanowisk”, ponieważ pozwala analizować na wyższym poziomie, które kategorie stanowisk zmieniają się najczęściej. Daje szerszy obraz niż analiza poszczególnych nazw stanowisk. Dlaczego to ważne Umożliwia analizę stanowisk według szerszych kategorii, przydatną w strategicznym planowaniu zatrudnienia i analizie trendów. Skąd pobrać Informacja ta jest częścią konfiguracji stanowisk pracy w Dynamics 365 HR. W encji HcmJobEntity można szukać pól związanych z „Job family” lub „Job function”. Przykłady InżynieriaFinanse i księgowośćSprzedażZasoby ludzkieZarządzanie produktem | |||
| System źródłowy SourceSystem | System, z którego wyodrębniono dane. | ||
| Opis Ten atrybut wskazuje źródło danych o procesie. W tym przypadku będzie to zwykle „Microsoft Dynamics 365 Human Resources”. W środowiskach korzystających z wielu systemów pole to jest ważne dla śledzenia pochodzenia danych i rozwiązywania problemów. Pozwala potwierdzić, że dane pochodzą z oczekiwanego źródła, i filtrować analizy według systemu. Dlaczego to ważne Informuje o pochodzeniu danych, co ma znaczenie dla zarządzania danymi i analiz obejmujących wiele systemów przedsiębiorstwa. Skąd pobrać Wartość statyczna dodawana podczas ekstrakcji i transformacji danych, aby oznaczyć źródło zbioru danych. Przykłady Microsoft Dynamics 365 Human ResourcesD365 HRDynamicsHR | |||
Działania w procesie od zatrudnienia do odejścia: zarządzanie stanowiskami
| Działanie | Opis | ||
|---|---|---|---|
| Aktywowano stanowisko | Oznacza moment, w którym stanowisko zostaje oficjalnie otwarte i można rozpocząć rekrutację. Zdarzenie można ustalić na podstawie zmiany statusu w rekordzie stanowiska na „Active” lub podobny. | ||
| Dlaczego to ważne To ważny etap pomiaru gotowości do rekrutacji i sprawności końcowych działań przygotowawczych. Jest niezbędny do obliczenia KPI średniego czasu aktywacji stanowiska. Skąd pobrać Zdarzenie można ustalić, śledząc znacznik czasu zmiany pola statusu, takiego jak „PositionStatus”, w rekordzie stanowiska na „Active” lub „Open”. Rejestrowanie Na podstawie daty wypełnienia pola ActivationDate stanowiska lub zmiany pola statusu na „Active”. Typ zdarzenia inferred | |||
| Dezaktywowano stanowisko | Stanowisko przestaje być aktywne i zostaje usunięte z aktywnej struktury organizacyjnej, często po jego obsadzeniu. Zdarzenie można ustalić na podstawie zmiany statusu na „Inactive” lub podobny. | ||
| Dlaczego to ważne Oznacza ważny etap kończący aktywny okres istnienia stanowiska. Jest potrzebne do analizy średniego czasu do dezaktywacji stanowiska i prawidłowego zarządzania liczbą etatów. Skąd pobrać Zdarzenie można ustalić na podstawie znacznika czasu wypełnienia pola „RetirementDate” lub zmiany pola statusu w rekordzie stanowiska na „Inactive”. Rejestrowanie Na podstawie daty ustawienia pola RetirementDate stanowiska lub zmiany pola statusu na „Inactive”. Typ zdarzenia inferred | |||
| Dział HR zaakceptował wniosek o stanowisko | Oznacza ostateczną akceptację działu HR, wymaganą przed formalnym utworzeniem stanowiska. Zdarzenie jest jawnie rejestrowane w systemie workflow po ukończeniu zadania akceptacji przez HR. | ||
| Dlaczego to ważne Oznacza koniec etapu akceptacji i jest ważnym punktem pomiaru średniego czasu akceptacji stanowiska. Skąd pobrać Rejestrowane w tabelach historii workflow, takich jak WorkflowTrackingTable, gdy przedstawiciel HR ukończy zadanie akceptacji. Rejestrowanie Zdarzenie ze znacznikiem czasu jest zapisywane w historii workflow po zakończeniu etapu akceptacji przez HR. Typ zdarzenia explicit | |||
| Utworzono stanowisko w systemie HR | Zdarzenie oznacza oficjalne utworzenie rekordu stanowiska w Dynamics 365 HR. Jest rejestrowane na podstawie znacznika czasu utworzenia samego rekordu stanowiska. | ||
| Dlaczego to ważne To podstawowy etap przejścia od wniosku do utworzenia stanowiska w strukturze organizacyjnej. Wyznacza koniec pomiaru KPI czasu utworzenia stanowiska. Skąd pobrać Na podstawie systemowego pola „CreatedDateTime” w głównej tabeli stanowisk, na przykład HcmPosition. Rejestrowanie Dane pochodzą z systemowego pola CreatedDateTime w tabeli HcmPosition. Typ zdarzenia explicit | |||
| Zainicjowano wniosek o stanowisko | To formalny początek cyklu życia stanowiska. Zdarzenie jest zwykle rejestrowane, gdy użytkownik składa wniosek o nowe stanowisko za pomocą dedykowanego formularza lub workflow w Dynamics 365 HR. | ||
| Dlaczego to ważne To punkt początkowy pomiaru całego cyklu życia stanowiska, w tym takich KPI jak czas akceptacji stanowiska i czas utworzenia stanowiska. Skąd pobrać Dane pochodzą ze znacznika czasu utworzenia rekordu wniosku o stanowisko lub rekordu inicjującego w tabeli historii workflow, na przykład WorkflowTrackingStatusTable. Rejestrowanie Zdarzenie jest rejestrowane po przesłaniu nowego wniosku o stanowisko w workflow. Typ zdarzenia explicit | |||
| Zamknięto stanowisko | Oznacza ostateczne zarchiwizowanie rekordu stanowiska i koniec jego cyklu życia. Zdarzenie można ustalić na podstawie zmiany statusu na „Closed” lub podobny status końcowy. | ||
| Dlaczego to ważne To końcowe zdarzenie procesu, które umożliwia analizę całego cyklu życia stanowiska i pomaga wykrywać nieaktualne stanowiska wymagające zamknięcia. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany pola statusu rekordu stanowiska na „Closed”. Występuje rzadziej niż dezaktywacja, ponieważ rekordy często są zachowywane do celów historycznych. Rejestrowanie Zdarzenie można ustalić na podstawie znacznika czasu aktualizacji pola statusu na „Closed”. Typ zdarzenia inferred | |||
| Kierownik zaakceptował wniosek o stanowisko | Oznacza zakończenie pierwszego etapu akceptacji przez kierownika ds. rekrutacji. Zdarzenie jest jawnie rejestrowane w historii workflow, gdy kierownik wykona przypisane mu zadanie akceptacji. | ||
| Dlaczego to ważne Pozwala zmierzyć czas trwania pierwszego etapu akceptacji i wykryć wąskie gardła związane z konkretnymi kierownikami lub działami. Skąd pobrać Rejestrowane jako ukończony krok w tabelach historii workflow, takich jak WorkflowTrackingTable, i powiązane z wnioskiem o stanowisko. Rejestrowanie Dane pochodzą ze znacznika czasu zakończenia etapu akceptacji przez kierownika w dzienniku workflow. Typ zdarzenia explicit | |||
| Odrzucono wniosek o stanowisko | Oznacza odrzucenie wniosku o stanowisko na jednym z etapów akceptacji. Zdarzenie jest jawnie rejestrowane w historii workflow, gdy osoba akceptująca wybierze działanie „Reject”. | ||
| Dlaczego to ważne Wskazuje problemy w procesie i konieczność ponownego wykonywania pracy. Analiza przyczyn odrzucenia pomaga poprawić jakość składanych wniosków i mierzyć KPI odsetka odrzuconych wniosków o stanowisko. Skąd pobrać Rejestrowane dla danego wniosku o stanowisko ze statusem „Rejection” w tabelach historii workflow, takich jak WorkflowTrackingStatusTable. Rejestrowanie Dane pochodzą z dziennika workflow, w którym zdarzenie jest zapisywane po odrzuceniu wniosku przez osobę akceptującą. Typ zdarzenia explicit | |||
| Przeklasyfikowano stanowisko | Oznacza istotną zmianę podstawowej klasyfikacji stanowiska, na przykład rodziny zawodowej lub poziomu. Zdarzenie jest zwykle ustalane na podstawie zmiany pola „Job” w rekordzie stanowiska. | ||
| Dlaczego to ważne Pomaga analizować zmiany struktury organizacyjnej i stabilność definicji stanowisk. Jest podstawowym zdarzeniem przy pomiarze KPI odsetka przeklasyfikowanych stanowisk. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany pola „JobId” w tabeli HcmPosition, zarejestrowanej w dzienniku bazy danych lub wykrytej przez porównanie wersji rekordu z różnych okresów. Rejestrowanie Zdarzenie można ustalić na podstawie zarejestrowanej zmiany pola klasyfikacji stanowiska w jego rekordzie. Typ zdarzenia inferred | |||
| Rozpoczęto rekrutację | Oznacza przekazanie stanowiska z obszaru zarządzania stanowiskami do rekrutacji. Zdarzenie można ustalić, gdy zostanie utworzony nowy wakat lub projekt rekrutacyjny powiązany z identyfikatorem tego stanowiska. | ||
| Dlaczego to ważne Łączy proces zarządzania stanowiskami z jego rezultatem i pozwala analizować czas od aktywacji stanowiska do rozpoczęcia działań rekrutacyjnych. Skąd pobrać Zdarzenie można ustalić na podstawie daty utworzenia rekordu w tabeli rekrutacji lub wakatów, takiej jak HcmRecruitingRequest, który zawiera identyfikator stanowiska. Rejestrowanie Zdarzenie można ustalić, łącząc PositionId z utworzeniem odpowiedniego rekordu w module rekrutacyjnym. Typ zdarzenia inferred | |||
| Sprawdzono zgodność stanowiska | Oznacza przeprowadzenie formalnej kontroli zgodności stanowiska. Zdarzenie można ustalić na podstawie zmiany statusu, ukończenia zadania z listą kontrolną lub aktualizacji pola niestandardowego. | ||
| Dlaczego to ważne Zdarzenie jest potrzebne do monitorowania zgodności z przepisami i politykami wewnętrznymi. Bezpośrednio wspiera pomiar KPI odsetka stanowisk zgodnych z zasadami. Skąd pobrać Zdarzenie można prawdopodobnie ustalić na podstawie pola statusu ze znacznikiem czasu, takiego jak „ComplianceReviewStatus”, lub pola logicznego „IsComplianceReviewed” w rekordzie stanowiska. Rejestrowanie Zdarzenie można ustalić na podstawie znacznika czasu aktualizacji pola statusu zgodności na „Completed” lub „Reviewed”. Typ zdarzenia inferred | |||
| Zamrożono stanowisko | Oznacza tymczasowe wstrzymanie obsady stanowiska, które uniemożliwia prowadzenie rekrutacji. Zdarzenie można ustalić na podstawie zmiany statusu rekordu stanowiska na „Frozen” lub „On Hold”. | ||
| Dlaczego to ważne Pozwala śledzić przerwy w cyklu życia stanowiska, które mogą wpływać na plany zatrudnienia i budżet. Pomaga ustalić przyczyny opóźnień w rekrutacji. Skąd pobrać Zdarzenie można ustalić, śledząc znacznik czasu zmiany pola statusu w rekordzie stanowiska na „Frozen” lub podobną wartość. Rejestrowanie Zdarzenie można ustalić na podstawie znacznika czasu zmiany statusu na „Frozen” lub „On Hold”. Typ zdarzenia inferred | |||
| Zatwierdzono budżet stanowiska | Ważny etap akceptacji potwierdzający przydzielenie środków na nowe stanowisko. Zwykle jest rejestrowany jako osobny krok akceptacji w workflow tworzenia stanowiska. | ||
| Dlaczego to ważne Pozwala wyodrębnić etap akceptacji finansowej, analizować opóźnienia związane z przydzieleniem budżetu i mierzyć KPI czasu akceptacji budżetu stanowiska. Skąd pobrać Rejestrowane w tabelach historii workflow, takich jak WorkflowTrackingTable, jako ukończone zadanie akceptacji, często przypisane do osoby z działu finansowego. Rejestrowanie Dane pochodzą ze znacznika czasu zakończenia zadania akceptacji budżetu w dzienniku workflow. Typ zdarzenia explicit | |||
| Zmieniono atrybuty stanowiska | Oznacza każdą zmianę podstawowych atrybutów stanowiska, takich jak nazwa lub dział, po jego utworzeniu. Zdarzenie jest zwykle ustalane na podstawie zmian w dzienniku bazy danych systemu. | ||
| Dlaczego to ważne Częste występowanie tego zdarzenia może świadczyć o niskiej jakości danych lub konieczności ponownego wykonywania pracy. Jest ono potrzebne do pomiaru KPI częstotliwości zmian atrybutów stanowiska i odsetka ponownego wykonywania pracy. Skąd pobrać Zdarzenie można ustalić na podstawie tabeli SysDatabaseLog, jeśli dla tabeli stanowisk włączono śledzenie zmian. Można też porównać historyczne migawki danych o stanowiskach. Rejestrowanie Zdarzenie można ustalić na podstawie operacji aktualizacji kluczowych pól tabeli HcmPosition zapisanych w dzienniku bazy danych. Typ zdarzenia inferred | |||
Instrukcje eksportu danych
Kroki
- Otwórz obszar roboczy zarządzania danymi: Zaloguj się do Microsoft Dynamics 365 Human Resources. Użyj głównego paska wyszukiwania, aby przejść do obszaru roboczego „Data management”.
- Utwórz nowy projekt eksportu: W obszarze roboczym wybierz kafelek „Export”. Na stronie projektu „Export” kliknij „New”, aby utworzyć projekt. Nadaj mu opisową nazwę, na przykład „PositionManagement_EventLog_Export”, i wybierz format danych. Do dalszego przetwarzania zalecany jest format „CSV”.
- Dodaj encje danych do projektu: W nowym projekcie kliknij „Add entity”. Aby uwzględnić cały cykl życia stanowiska, dodaj kolejno następujące encje: „HcmPositionV2”, „WorkflowTrackingStatusTable” i „HcmRecruitingRequest”. Jeśli rejestrowanie zmian w bazie danych jest włączone, dodaj również „SysDatabaseLog”.
- Skonfiguruj filtry encji: Dla każdej encji ustaw filtry ograniczające zakres danych. Wybierz encję, a następnie kliknij „Filter”. W przypadku „HcmPositionV2” ustaw zakres dat na podstawie pól „CreatedDateTime” lub „ModifiedDateTime”. W przypadku „WorkflowTrackingStatusTable” filtruj pole „CONTEXTTABLENAME”, aby uwzględnić tylko workflow związane ze stanowiskami.
- Wybierz pola dla każdej encji: Upewnij się, że eksport obejmuje wszystkie pola potrzebne do dalszego przetwarzania. Dla „HcmPositionV2” uwzględnij „PositionId”, „CreatedDateTime”, „ActivationDate”, „RetirementDate”, „ModifiedDateTime”, „JobId” i „DepartmentNumber”. Dla „WorkflowTrackingStatusTable” uwzględnij „ContextRecId”, „WorkflowTrackingStatus”, „CreatedDateTime” i „UserId”.
- Uruchom eksport: Po skonfigurowaniu encji, pól i filtrów kliknij „Export” na stronie głównej projektu. System utworzy pakiet danych z osobnym plikiem dla każdej encji.
- Sprawdź postęp i pobierz pakiet danych: Postęp zadania można śledzić w sekcji „Job history”. Po pomyślnym zakończeniu pobierz pakiet danych w postaci skompresowanego pliku.
- Rozpakuj i przetwórz dane: Rozpakuj pobrany pakiet. Znajdują się w nim osobne pliki CSV dla każdej encji. Zawierają one surowe dane, a nie gotowy dziennik zdarzeń. Do ich przetworzenia potrzebny jest zewnętrzny skrypt, na przykład w Pythonie z biblioteką pandas lub w PowerShell.
- Zastosuj logikę przekształcania danych: Skrypt powinien wykonać następujące czynności:
- Wczytać plik „HcmPositionV2.csv”. Na jego podstawie utworzyć zdarzenie „Utworzenie stanowiska w systemie HR”, korzystając z pól „PositionId” i „CreatedDateTime”.
- Utworzyć zdarzenia zmiany statusu („Aktywacja stanowiska”, „Zamrożenie stanowiska”, „Dezaktywacja stanowiska”, „Zamknięcie stanowiska”), interpretując pola statusu lub daty, takie jak „ActivationDate” i „RetirementDate” w pliku „HcmPositionV2.csv”.
- Wczytać plik „WorkflowTrackingStatusTable.csv” i połączyć jego dane z danymi stanowisk na podstawie identyfikatora rekordu. Następnie utworzyć zdarzenia workflow: „Rozpoczęcie wniosku o stanowisko”, „Zatwierdzenie wniosku o stanowisko przez kierownika”, „Zatwierdzenie budżetu stanowiska”, „Zatwierdzenie wniosku o stanowisko przez HR” i „Odrzucenie wniosku o stanowisko”. Status workflow i kontekst kroku trzeba przypisać do właściwej nazwy działania.
- Jeśli wyeksportowano plik „SysDatabaseLog.csv”, przeanalizować go i utworzyć zdarzenia „Modyfikacja atrybutów stanowiska” oraz „Zmiana klasyfikacji stanowiska” na podstawie zmian konkretnych pól w tabeli HcmPosition.
- Wczytać plik „HcmRecruitingRequest.csv” i utworzyć zdarzenie „Rozpoczęcie procesu rekrutacji”, ustalając, kiedy utworzono wniosek rekrutacyjny dla danego stanowiska.
- Zbuduj końcowy dziennik zdarzeń: Skrypt powinien połączyć wszystkie wygenerowane zdarzenia z różnych źródeł w jeden plik CSV. Plik musi zawierać wymagane kolumny: „PositionId”, „ActivityName” i „EventTime”, a także wszystkie zalecane atrybuty, które udało się przypisać.
- Przygotuj plik do przesłania: Upewnij się, że nagłówki kolumn w końcowym pliku CSV odpowiadają wymaganym nazwom atrybutów, a kolumna „EventTime” ma spójny format znacznika czasu. Plik jest teraz gotowy do przesłania do narzędzia process mining.
Konfiguracja
- Najważniejsze encje danych: Do eksportu potrzebne są przede wszystkim:
HcmPositionV2: zawiera podstawowe informacje o każdym stanowisku, w tym daty utworzenia i aktywacji oraz atrybuty takie jak stanowisko pracy i dział.WorkflowTrackingStatusTable: zawiera historię instancji workflow, w tym zgłoszenia, zatwierdzenia i odrzucenia. Jest niezbędna do śledzenia procesu zatwierdzania.HcmRecruitingRequest: pozwala ustalić, kiedy rozpoczął się proces rekrutacji, jeśli wniosek rekrutacyjny jest powiązany ze stanowiskiem.SysDatabaseLog: opcjonalna encja, która pozwala rejestrować szczegółowe zmiany, takie jak „Modyfikacja atrybutów stanowiska” i „Zmiana klasyfikacji stanowiska”. Można jej użyć, jeśli wcześniej skonfigurowano rejestrowanie zmian w tabeli HcmPosition.
- Filtrowanie według zakresu dat: Zaleca się filtrowanie encji „HcmPositionV2” według pola „CreatedDateTime”. Dobrym punktem wyjścia jest zakres od 6 do 12 miesięcy, który pozwala zachować rozsądną wielkość zbioru danych.
- Eksporty przyrostowe: Przy regularnej analizie warto skonfigurować eksport przyrostowy. Pozwala on pobierać tylko rekordy zmienione od poprzedniego uruchomienia, co znacznie skraca czas przetwarzania.
- Wymagania wstępne: Osoba uruchamiająca eksport musi mieć rolę zabezpieczeń z uprawnieniami do obszaru roboczego „Data management” oraz dostępem do odczytu wszystkich wskazanych encji danych. Zwykle wymagane są role takie jak „Data management administrator” lub rola niestandardowa z odpowiednimi uprawnieniami do encji.
Przykładowe zapytanie sql
/*
This extraction uses the Dynamics 365 Data Management Framework. The 'query' is defined by configuring an export project via the user interface, not by running a script directly against the database.
A post-processing script is required to transform the output of this configuration into a final event log.
*/
-- Data Export Project Configuration --
Project Name: PositionManagement_EventLog_Export
Data Format: CSV
-- Entity 1: Positions --
Source Entity: HcmPositionV2
Fields to Export:
- PositionId
- CreatedDateTime (Used for 'Position Created In HR System' event)
- ActivationDate (Used for 'Position Activated' event)
- RetirementDate (Used for 'Position Deactivated' / 'Position Closed' event)
- ModifiedDateTime (Can be used for 'Position Attributes Modified' if SysDatabaseLog is not available)
- JobId (Used for 'Position Reclassified' event and 'JobTitle' attribute)
- DepartmentNumber (Used for 'DepartmentName' attribute)
- [Other fields for attributes like CostCenter, PositionStatus]
-- Entity 2: Workflow History --
Source Entity: WorkflowTrackingStatusTable
Fields to Export:
- ContextRecId (The record ID, used to link back to the HcmPosition record)
- ContextTableName (Filter this for 'HcmPosition')
- WorkflowTrackingStatus (Values like 'Submitted', 'Approved', 'Rejected')
- CreatedDateTime (Timestamp for the workflow event)
- UserId (The user who performed the action)
- [Workflow step name or ID field if available, to differentiate approval types]
-- Entity 3: Recruitment Requests --
Source Entity: HcmRecruitingRequest
Fields to Export:
- PositionId
- CreatedDateTime (Used for 'Hiring Process Started' event)
- RecruitingId
-- Entity 4: Database Change Log (Optional) --
Source Entity: SysDatabaseLog
Fields to Export:
- RefRecId (The record ID of the changed record)
- RefTableId (The table ID, filter for HcmPosition)
- CreatedDateTime (Timestamp of the change)
- [Fields indicating the old and new values, if available] Kroki
- Sprawdź wymagania wstępne: Przed rozpoczęciem upewnij się, że funkcja „Bring Your Own Database” (BYOD) jest skonfigurowana dla instancji Microsoft Dynamics 365 Human Resources. Sprawdź, czy wymagane encje danych są eksportowane do Azure SQL Database. Należą do nich:
HcmPositionV2,HcmPositionDetail,WorkflowTrackingStatusTable,HcmJob,OMOperatingUnitiHcmRecruitingRequest. - Połącz się z Azure SQL Database: Użyj klienta SQL, takiego jak SQL Server Management Studio (SSMS) lub Azure Data Studio, aby połączyć się z Azure SQL Database skonfigurowaną jako miejsce docelowe BYOD.
- Sprawdź schemat bazy danych: Po nawiązaniu połączenia zapoznaj się ze schematem bazy. Encje danych D365 HR są replikowane jako tabele. Nazwy tabel w bazie BYOD mogą nie być identyczne z nazwami encji, ale zazwyczaj są do nich zbliżone.
- Wprowadź zapytanie SQL: Otwórz nowe okno zapytania w kliencie SQL i wklej pełny skrypt SQL z sekcji „query” tego dokumentu.
- Dostosuj parametry: Zmień zmienne zastępcze w zapytaniu. Ustaw
@[YourCompanyId]na identyfikator analizowanej jednostki prawnej, na przykład „USMF”. Dostosuj zakres dat w klauzulachWHERE, na przykładCREATEDDATETIME >= '2023-01-01', aby ograniczyć eksport do wybranego okresu. - Uruchom zapytanie: Wykonaj pełne zapytanie SQL w bazie BYOD. Czas wykonania zależy od ilości danych i wybranego zakresu dat.
- Sprawdź wyniki: Po zakończeniu zapytania sprawdź dane w panelu wyników klienta SQL. Upewnij się, że kolumny
PositionId,ActivityName,EventTimei pozostałe zawierają oczekiwane wartości. - Wyeksportuj dane do CSV: Zapisz cały zestaw wyników w pliku CSV. Większość klientów SQL umożliwia bezpośredni zapis wyników do pliku CSV. Na przykład w SSMS można kliknąć prawym przyciskiem myszy siatkę wyników i wybrać „Save Results As...”.
- Przygotuj plik do przesłania: Upewnij się, że wyeksportowany plik CSV jest zakodowany w UTF-8. Sprawdź, czy nagłówki kolumn dokładnie odpowiadają wymaganym atrybutom (
PositionId,ActivityName,EventTimeitd.), aby bez problemu przesłać plik do narzędzia process mining.
Konfiguracja
- Encje danych BYOD: Upewnij się, że wszystkie potrzebne encje danych zostały opublikowane z Dynamics 365 HR w instancji BYOD. W tym procesie potrzebne są encje dotyczące stanowisk, szczegółów stanowisk, historii workflow, stanowisk pracy, działów i wniosków rekrutacyjnych.
- Opóźnienie replikacji danych: BYOD replikuje dane niemal w czasie rzeczywistym, ale nie natychmiast. Między wykonaniem transakcji w D365 HR a pojawieniem się danych w Azure SQL Database może upłynąć od kilku minut do godziny.
- Filtrowanie według zakresu dat: Filtry dat w zapytaniu pomagają kontrolować wydajność i ilość danych. Na początek warto wybrać zakres od 3 do 6 miesięcy. Filtry należy stosować do dat utworzenia lub znaczników czasu zdarzeń w każdym bloku
UNION ALL. - Filtr firmy: Zawsze filtruj według
DATAREAID(identyfikatora jednostki prawnej lub firmy), aby analizować dane właściwej jednostki organizacyjnej. W zapytaniu użyto w tym celu zmiennej zastępczej@[YourCompanyId]. - Wymagania wstępne: Ta metoda wymaga aktywnej subskrypcji Azure, skonfigurowanej instancji BYOD, uprawnień do odczytu w docelowej bazie Azure SQL Database oraz odpowiedniego klienta SQL do wykonywania zapytań.
- Niestandardowe kroki workflow: W zapytaniu użyto typowych nazw kroków zatwierdzania, takich jak „Approve position request”. Jeśli w Państwa organizacji stosowane są własne nazwy tych kroków, należy zaktualizować wartości
CONTEXTw odpowiednich klauzulachWHERE.
Przykładowe zapytanie sql
SELECT
p.POSITIONID AS PositionId,
'Position Request Initiated' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Initiated' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 1 -- Submitted
AND w.CONTEXT LIKE '%Create position request%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Approved By Manager' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Pending Budget' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%Manager approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Budget Approved' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Pending HR' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%Budget approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Approved By HR' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Approved' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 5 -- Approval
AND w.CONTEXT LIKE '%HR approval%'
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Request Rejected' AS ActivityName,
w.CREATEDDATETIME AS EventTime,
w.CREATEDDATETIME AS EndTime,
w.USERID AS UserName,
dept.NAME AS DepartmentName,
pd.DESCRIPTION AS JobTitle,
'Rejected' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM WorkflowTrackingStatusTable w
JOIN HcmPositionV2 p ON w.REFRECID = p.RECID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE w.TRACKINGSTATUS = 3 -- Rejection
AND p.DATAREAID = '[YourCompanyId]'
AND w.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Created In HR System' AS ActivityName,
p.CREATEDDATETIME AS EventTime,
p.CREATEDDATETIME AS EndTime,
p.CREATEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Created' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.DATAREAID = '[YourCompanyId]'
AND p.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Attributes Modified' AS ActivityName,
p.MODIFIEDDATETIME AS EventTime,
p.MODIFIEDDATETIME AS EndTime,
p.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Modified' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.MODIFIEDDATETIME > p.CREATEDDATETIME
AND p.DATAREAID = '[YourCompanyId]'
AND p.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Reviewed For Compliance' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime,
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Compliance Reviewed' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.[YourComplianceStatusField] = 'Reviewed' -- This requires a custom field indicating compliance review
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Reclassified' AS ActivityName,
p.MODIFIEDDATETIME AS EventTime,
p.MODIFIEDDATETIME AS EndTime,
p.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Reclassified' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.MODIFIEDDATETIME > p.CREATEDDATETIME -- This is an inference. See known limitations.
AND p.DATAREAID = '[YourCompanyId]'
AND p.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Activated' AS ActivityName,
pd.VALIDFROM AS EventTime,
pd.VALIDFROM AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Active' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.VALIDFROM >= '[StartDate]'
AND p.DATAREAID = '[YourCompanyId]'
UNION ALL
SELECT
hr.POSITIONID AS PositionId,
'Hiring Process Started' AS ActivityName,
hr.CREATEDDATETIME AS EventTime,
hr.CREATEDDATETIME AS EndTime,
hr.CREATEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Recruiting' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmRecruitingRequest hr
JOIN HcmPositionV2 p ON hr.POSITIONID = p.POSITIONID
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE hr.DATAREAID = '[YourCompanyId]'
AND hr.CREATEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Frozen' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime, -- Assuming a status change triggers modification time
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Frozen' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.[YourPositionStatusField] = 'Frozen' -- Requires a dedicated status field on the position
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Deactivated' AS ActivityName,
pd.VALIDTO AS EventTime,
pd.VALIDTO AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Inactive' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE pd.VALIDTO < '2154-12-31' -- D365 often uses this far-future date for 'never expires'
AND pd.VALIDTO >= '[StartDate]'
AND p.DATAREAID = '[YourCompanyId]'
UNION ALL
SELECT
p.POSITIONID AS PositionId,
'Position Closed' AS ActivityName,
pd.MODIFIEDDATETIME AS EventTime, -- Assuming a status change triggers modification time
pd.MODIFIEDDATETIME AS EndTime,
pd.MODIFIEDBY AS UserName,
dept.NAME AS DepartmentName,
j.DESCRIPTION AS JobTitle,
'Closed' AS PositionStatus,
pd.DEFAULTDIMENSIONDISPLAYVALUE AS CostCenter
FROM HcmPositionV2 p
JOIN HcmPositionDetail pd ON p.POSITIONID = pd.POSITIONID
LEFT JOIN HcmJob j ON p.JOBID = j.JOBID
LEFT JOIN OMOperatingUnit dept ON pd.DEPARTMENT = dept.OMOPERATINGUNITNUMBER
WHERE p.[YourPositionStatusField] = 'Closed' -- Requires a dedicated status field on the position
AND p.DATAREAID = '[YourCompanyId]'
AND pd.MODIFIEDDATETIME >= '[StartDate]' Jak zacząć?
Skorzystaj z tego szablonu, aby usprawnić zbieranie danych i lepiej poznać proces zarządzania stanowiskami w cyklu od zatrudnienia do odejścia. Już dziś rozpocznij działania na rzecz większej efektywności i zgodności.
Szybko usprawnij zarządzanie stanowiskami w cyklu od zatrudnienia do odejścia
Skróć czas cyklu procesu o 30% i wyeliminuj wąskie gardła.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.