Šablona dat pro proces nákupu a platby, žádanky
Šablona dat pro proces nákupu a platby, žádanky
- Doporučené atributy pro podrobnou analýzu
- Důležité aktivity pro sledování a objevování procesů
- Návod na extrakci dat ze SAP S/4HANA
Atributy procesu nákupu a platby, žádanky
| Název | Popis | ||
|---|---|---|---|
| Čas události EventTime | Přesné datum a čas, kdy konkrétní aktivita proběhla. | ||
| Popis Čas události je časové razítko, které zaznamenává, kdy aktivita proběhla. Je důležité pro chronologické seřazení událostí v rámci případu a slouží jako základ všech výpočtů doby trvání a výkonnosti v process mining. Například rozdíl mezi událostmi „Odeslání nákupního požadavku ke schválení“ a „Schválení nákupního požadavku“ určuje dobu schválení. Přesná časová razítka jsou nezbytná pro analýzu výkonnosti procesu, odhalování zdržení a sledování dodržování dohodnutých úrovní služeb. Tento atribut umožňuje vytvářet dashboardy, které zobrazují dobu průchodu procesem, sledují nevyřízené požadavky a porovnávají výkonnost v různých obdobích. Proč je to důležité Toto časové razítko je nezbytné pro řazení událostí, výpočet doby průchodu procesem a analýzu výkonnosti procesu i úzkých míst. Kde data získat Časová razítka se obvykle získávají z hlaviček dokumentů změn (CDHDR-UDATE, CDHDR-UTIME) nebo z protokolů událostí workflow. Příklady 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID nákupního požadavku PurchaseRequisitionId | Jedinečný identifikátor nákupního požadavku. | ||
| Popis ID nákupního požadavku je primární klíč, který jednoznačně identifikuje každý požadavek na zboží nebo služby v SAP S/4HANA. Slouží jako hlavní identifikátor případu a propojuje všechny aktivity a změny související s konkrétním požadavkem, od jeho vytvoření až po konečný stav, například schválení, zamítnutí nebo převod na objednávku. V process mining je tento atribut základem pro rekonstrukci celého životního cyklu každého požadavku. Seskupením všech souvisejících událostí pod jedno ID nákupního požadavku mohou analytici přesně měřit dobu průchodu procesem, sledovat změny stavu a analyzovat různé cesty, kterými požadavek prochází při schvalování. Proč je to důležité Jde o základní identifikátor případu, který propojuje všechny související kroky procesu a poskytuje ucelený přehled o životním cyklu požadavku. Kde data získat Jde o číslo nákupního požadavku v tabulce EBAN, v poli BANFN. Příklady 100178901001789110017892 | |||
| Název aktivity ActivityName | Název obchodní aktivity, která proběhla v konkrétním okamžiku procesu zpracování požadavku. | ||
| Popis Název aktivity popisuje konkrétní událost nebo úkol, který proběhl během životního cyklu nákupního požadavku. Aktivity se odvozují ze systémových protokolů, například z dokumentů změn a historie workflow, a označují důležité milníky procesu, jako jsou „Vytvoření nákupního požadavku“, „Zahájení kroku schválení“ nebo „Vytvoření objednávky“. Analýza těchto aktivit umožňuje zobrazit průběh procesu, odhalit úzká místa a měřit čas strávený v jednotlivých fázích. Znalost pořadí a četnosti aktivit, jako jsou „Úprava nákupního požadavku“ nebo „Zamítnutí nákupního požadavku“, pomáhá odhalit neefektivní postupy a možnosti zlepšení. Proč je to důležité Určuje jednotlivé kroky procesu, tvoří základ procesní mapy a umožňuje analyzovat průběh, odchylky i úzká místa. Kde data získat Jde o odvozený atribut, který se obvykle vytváří interpretací dat z tabulek dokumentů změn (CDHDR, CDPOS) a protokolů workflow (například SWWLOGHIST). Příklady Vytvoření nákupního požadavkuDokončení kroku schváleníSchválení nákupního požadavkuVytvoření objednávky | |||
| Částka nákupního požadavku RequisitionAmount | Celková peněžní hodnota nákupního požadavku. | ||
| Popis Částka nákupního požadavku představuje celkové odhadované náklady na požadované zboží nebo služby. Často ovlivňuje složitost a délku schvalovacího workflow. U požadavků s vyšší hodnotou bývá obvykle potřeba více úrovní schválení. Analýza tohoto atributu umožňuje rozdělit proces podle hodnoty požadavku. Pomůže například odpovědět na otázky: „Trvá schválení požadavků s vysokou hodnotou déle?“ nebo „Jakou hodnotu mají požadavky, které se často zamítají?“ Jde o důležitý rozměr pro pochopení finančního dopadu neefektivních procesů. Proč je to důležité Umožňuje rozdělit proces podle finančního dopadu, který často souvisí se složitostí schvalování a dobou průchodu. Je důležitý pro analýzu procesů podle hodnoty. Kde data získat Celková hodnota je v tabulce EBAN v poli GFWERT. Hodnota položky je v EBAN-PREIS. Příklady 1500.0075000.50250.75 | |||
| ID schvalovatele ApproverId | Identifikátor uživatele, který provedl krok schválení nebo zamítnutí. | ||
| Popis ID schvalovatele označuje konkrétního uživatele, který dokončil aktivitu schválení nebo zamítnutí. Na rozdíl od obecného ID uživatele se vztahuje výhradně na osoby, které rozhodují v rámci schvalovacího workflow. Zachycení této informace je důležité pro podrobnou analýzu schvalování. Tento atribut umožňuje analyzovat způsob schvalování, například zjistit, kteří vedoucí schvalují pomalu nebo často zamítají požadavky. Je základem dashboardů zaměřených na dobu jednotlivých kroků schválení a analýzu úzkých míst ve workflow. Pomáhá určit konkrétní osoby nebo role, které mohou způsobovat zdržení. Proč je to důležité Určuje konkrétní osobu, která rozhodla v kroku schválení, a umožňuje podrobně analyzovat dobu schválení a úzká místa podle jednotlivců nebo rolí. Kde data získat Tyto informace se obvykle získávají z tabulek SAP Business Workflow, například SWW_WI2OBJ a SWWLOGHIST, které propojují pracovní položky s uživatelem, jenž je dokončil. Příklady MJOHNSONCWILLIAMSLBLACK | |||
| ID uživatele UserId | Identifikátor uživatele, který vytvořil požadavek nebo provedl konkrétní aktivitu. | ||
| Popis ID uživatele označuje zaměstnance nebo systémového uživatele odpovědného za konkrétní událost v životním cyklu požadavku. Může jít o osobu, která požadavek vytvořila, vedoucího, který jej schválil, nebo pracovníka, který jej upravil. U automatizovaných kroků může jít o ID systémového nebo dávkového uživatele. Analýza podle ID uživatele pomáhá porozumět chování jednotlivých uživatelů, rozložení pracovní zátěže a výkonnosti. Umožňuje určit potřebu školení, rozpoznat výkonné pracovníky a zajistit odpovědnost za jednotlivé kroky procesu. V kombinaci s kmenovými daty uživatelů podporuje také analýzu výkonnosti oddělení. Proč je to důležité Umožňuje analyzovat výkonnost uživatelů, rozložení pracovní zátěže a shodu procesu. Pomáhá určit potřebu školení a odhalit úzká místa v kapacitách. Kde data získat U tvůrce se nachází v poli EBAN-ERNAM. U pozdějších změn je v poli CDHDR-USERNAME. U schválení se získává z protokolů workflow. Příklady JSMITHRROEWF-BATCH | |||
| Oddělení Department | Oddělení nebo nákladové středisko, kterému se účtují náklady na požadavek. | ||
| Popis Atribut Oddělení, v SAP často vyjádřený nákladovým střediskem, označuje organizační jednotku odpovědnou za požadovaný nákup. Jde o důležitou finanční a organizační informaci přiřazenou na úrovni položky požadavku. V process mining je tento atribut důležitý pro analýzu výkonnosti jednotlivých oddělení. Umožňuje vytvářet dashboardy, které porovnávají důležité ukazatele, jako je doba průchodu procesem, četnost úprav a zamítnutí, napříč odděleními. Pomáhá tak určit oddělení s osvědčenými postupy, které lze převzít jinde, i ta, která potřebují další školení nebo podporu při zpracování. Proč je to důležité Umožňuje porovnávat výkonnost organizačních jednotek a odhalit rozdíly v době průchodu procesem nebo četnosti zamítnutí. Pomáhá najít osvědčené postupy i oblasti ke zlepšení. Kde data získat Jde o nákladové středisko, které se obvykle nachází v tabulce přiřazení účtů EBKN, v poli KOSTL. Příklady FIN-1001IT-2005MKT-3010 | |||
| Stav nákupního požadavku RequisitionStatus | Aktuální stav zpracování nebo schválení nákupního požadavku. | ||
| Popis Stav nákupního požadavku označuje jeho aktuální fázi životního cyklu. V SAP jej často vyjadřuje ukazatel uvolnění, který ukazuje, zda je požadavek blokován, čeká na schválení, je částečně schválen nebo plně schválen. Stav se mění podle toho, jak požadavek postupuje workflow. Sledování stavu v čase je základem pro pochopení průběhu procesu. Pomáhá zjistit, kde se požadavky zastavují a jak dlouho tam zůstávají. Analýza přechodů mezi stavy poskytuje podrobný přehled o schvalování a jeho variantách. Proč je to důležité Označuje aktuální stav požadavku. Je důležitý pro sledování průběhu, odhalování úzkých míst a analýzu procesu. Kde data získat Stav uvolnění se často určuje podle ukazatele uvolnění v tabulce EBAN, v poli FRGZU. Příklady B1S | |||
| Typ nákupního požadavku RequisitionType | Kód, který klasifikuje nákupní požadavek, například na standardní položky, služby nebo kapitálové výdaje. | ||
| Popis Typ nákupního požadavku, v SAP označovaný také jako typ dokladu, je konfigurační pole, které kategorizuje nákupní požadavky. Různé typy mohou spouštět odlišná schvalovací workflow, mít různá nastavení polí a sloužit různým obchodním účelům, například pro standardní skladové položky, externí služby nebo nákup majetku. Analýza procesu podle typu nákupního požadavku ukazuje, jak se zpracovávají různé druhy požadavků. Umožňuje porovnat výkonnost, dobu průchodu procesem a schvalovací cesty napříč kategoriemi. Díky tomu lze zjistit, zda jsou některé typy požadavků méně efektivní, a přizpůsobit jim zlepšování procesů. Proč je to důležité Kategorizuje požadavky a umožňuje jejich porovnání. Pomáhá zjistit, zda se různé typy požadavků liší průběhem procesu, úzkými místy nebo dobou průchodu. Kde data získat Jde o pole Typ dokladu v tabulce EBAN, pole BSART. Příklady NBFORV | |||
| Automatizováno IsAutomated | Příznak určující, zda aktivitu provedl systémový uživatel, nebo člověk. | ||
| Popis Atribut Is Automated je booleovský příznak, který má hodnotu true, pokud aktivitu provedl systém nebo dávkový uživatel, například „WF-BATCH“ při akcích workflow. Díky tomu lze v procesu rozlišit ruční a automatické kroky. Tento atribut je důležitý pro měření míry automatizace procesu žádanky a výpočet KPI „Automated Approval Rate“. Analytici mohou filtrovat automatické nebo ruční kroky, porovnat jejich efektivitu a najít další příležitosti k automatizaci, která zkrátí dobu zpracování a omezí ruční práci. Proč je to důležité Rozlišuje činnosti prováděné lidmi od činností řízených systémem. Pomáhá měřit míru automatizace a hledat úkoly, které lze automatizovat. Kde data získat Jde o odvozený atribut, který se obvykle určuje podle pravidla ověřujícího, zda User ID události patří mezi známé systémové nebo dávkové uživatele. Příklady truefalse | |||
| Čas ukončení EndTime | Přesné datum a čas dokončení konkrétní aktivity. | ||
| Popis EndTime je časové razítko, které zaznamenává dokončení aktivity. Mnoho událostí generovaných systémem proběhne okamžitě, takže StartTime a EndTime jsou stejné. U lidských úkolů, například schvalování, se však čas zahájení a ukončení může lišit. Časové razítko EndTime označuje dokončení práce. Samostatný údaj EndTime umožňuje přesněji měřit aktivní dobu zpracování a dobu nečinného čekání. Spolu s údajem StartTime se používá k výpočtu metriky ProcessingTime. Tento detail zpřesňuje analýzu využití zdrojů a efektivity ručních úkolů. Proč je to důležité Označuje dokončení aktivity, umožňuje vypočítat aktivní dobu zpracování a podrobněji analyzovat délku úkolu. Kde data získat Údaj se odvozuje z protokolů workflow, které mohou zaznamenávat vytvoření pracovní položky (StartTime) i její dokončení (EndTime). Příklady 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Číslo objednávky PurchaseOrderNumber | Číslo objednávky vytvořené z nákupního požadavku. | ||
| Popis Číslo objednávky je identifikátor oficiálního nákupního dokladu vytvořeného ze schváleného požadavku. Vytvoření objednávky bývá konečným úspěšným výsledkem zpracování požadavku a znamená, že se požadavek změnil na formální objednávku u dodavatele. Tento atribut je důležitý pro měření KPI doby od nákupního požadavku k objednávce a celkové míry převodu. Propojuje proces vytváření požadavků s navazujícím nákupním procesem a umožňuje sledovat celý cyklus Purchase-to-Pay. Proč je to důležité Propojuje požadavek s navazujícím nákupním dokladem a umožňuje měřit míru převodu požadavků na objednávky i dobu, kterou převod trvá. Kde data získat Nachází se v tabulce EBAN, v poli EBELN, jakmile je z položky požadavku vytvořena objednávka. Příklady 450001789045000178914500017892 | |||
| Důvod zamítnutí RejectionReason | Důvod uvedený při zamítnutí nákupního požadavku. | ||
| Popis Důvod zamítnutí vysvětluje, proč se schvalovatel rozhodl nákupní požadavek zamítnout. Může jít například o překročení rozpočtu, nesprávné údaje, nedodržení pravidel nebo duplicitní požadavek. Tato informace poskytuje důležitý kontext pro pochopení neúspěšného zpracování. Analýza důvodů zamítnutí pomáhá odhalit příčiny neefektivních postupů a opakovaného zpracování. Pokud se například často objevuje důvod „Nesprávné nákladové středisko“, může být potřeba lépe proškolit uživatele nebo přidat systémovou kontrolu. Tento atribut je základem dashboardu pro analýzu zamítnutých nákupních požadavků a pomáhá cíleně zlepšovat procesy. Proč je to důležité Odhaluje příčiny neúspěšného zpracování a umožňuje cíleně omezit opakovanou práci a zvýšit podíl požadavků správně vyřízených napoprvé. Kde data získat Často nejde o standardní pole. Důvod může být uložen v prvcích kontejneru workflow, v dlouhém textu přiřazeném k požadavku nebo ve vlastních polích. Příklady Překročení rozpočtuNesprávný dodavatelDuplicitní požadavek | |||
| Jde o přepracování IsRework | Příznak označuje, zda aktivita představuje přepracování, například změnu po odeslání. | ||
| Popis Is Rework je vypočítaný booleovský příznak, který označuje činnosti bez přidané hodnoty nebo opakovanou práci. V tomto procesu jde například o aktivitu „Žádanka upravena“, která nastane až po odeslání žádanky ke schválení a způsobí opětovné spuštění schvalování. Tento atribut umožňuje vyčíslit rozsah přepracování a jeho vliv na celkovou dobu průchodu. Dashboard Requisition Amendment and Rework Rate pomocí tohoto příznaku upozorňuje na neefektivní místa v procesu. Omezení přepracování bývá jedním z hlavních cílů zlepšování procesů, protože přímo šetří čas a úsilí. Proč je to důležité Označuje činnosti, které představují zbytečnou nebo opakovanou práci. Umožňuje přímo měřit rozsah přepracování a jeho vliv na efektivitu procesu. Kde data získat Jde o vypočítaný atribut. Pravidlo obvykle označí každou aktivitu „Žádanka upravena“, která nastane po první aktivitě „Žádanka odeslána ke schválení“, jako přepracování. Příklady truefalse | |||
| Měna Currency | Kód měny částky nákupního požadavku. | ||
| Popis Tento atribut určuje měnu, ve které je částka nákupního požadavku uvedena, například USD, EUR nebo JPY. Poskytuje potřebný kontext k atributu Částka nákupního požadavku, zejména v nadnárodních organizacích, které pracují s více měnami. Pro přesnou finanční analýzu a vykazování je nutné zohlednit měnu. Při sčítání nebo porovnávání hodnot požadavků je třeba převést všechny částky na společnou měnu, aby výsledky dávaly smysl. Tento atribut je pro takový převod nezbytný. Proč je to důležité Doplňuje kontext k částce nákupního požadavku a umožňuje přesnou finanční analýzu a porovnávání v prostředí s více měnami. Kde data získat Nachází se v tabulce EBAN, v poli WAERS. Příklady USDEURGBP | |||
| Název kroku schválení ApprovalStepName | Konkrétní název nebo popis kroku schválení ve workflow. | ||
| Popis Název kroku schválení srozumitelně popisuje konkrétní fázi schvalovacího workflow, například „Schválení manažerem“ nebo „Schválení finančním ředitelem“. Je výstižnější než obecná aktivita „Krok schválení dokončen“. Tento atribut je důležitý pro dashboardy Approval Step Cycle Time a Workflow Bottleneck Analysis. Umožňuje podrobně analyzovat schvalovací proces, přesně určit, které fáze schvalování způsobují největší zpoždění a kde se hromadí práce. Takový detail pomáhá cíleně upravit schvalovací řetězec. Proč je to důležité Podrobně popisuje jednotlivé fáze schvalování a umožňuje přesně určit úzká místa ve víceúrovňovém schvalovacím workflow. Kde data získat Tyto informace se odvozují z popisu úlohy ve workflow. Najdete ho propojením protokolu workflow s tabulkami definic úloh, například T528T. Příklady Schválení manažeremSchválení ředitelemSchválení finančním ředitelem | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data tohoto záznamu naposledy obnovena ze zdrojového systému. | ||
| Popis Tento atribut zaznamenává datum a čas poslední extrakce nebo aktualizace dat ze zdrojového systému. Jde o důležitá metadata, která ukazují, jak aktuální jsou analyzovaná data. Analytici a uživatelé z řad vedení podle tohoto časového razítka poznají, zda procesní data odrážejí současný stav provozu. Při analýze procesů je aktuálnost dat zásadní pro informované rozhodování. Tento atribut pomáhá nastavit očekávání uživatelů a zajistit, aby závěry vycházely z dat aktuálních v míře potřebné pro danou analýzu. Proč je to důležité Ukazuje aktuálnost dat, která je důležitá pro důvěryhodnou analýzu a včasná obchodní rozhodnutí. Kde data získat Toto časové razítko se vytvoří a přidá během procesu extrakce, transformace a načítání dat (ETL). Příklady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Požadované datum dodání RequiredByDate | Datum, do kterého žadatel potřebuje požadované zboží nebo služby. | ||
| Popis Požadované datum dodání, v SAP označované jako datum dodání, určuje, kdy jsou potřeba zboží nebo služby uvedené na položce požadavku. Datum zadává žadatel a slouží jako cílový termín pro celý nákupní proces. Tento atribut je nezbytný pro výpočet KPI „Míra včasného dokončení nákupních požadavků“. Porovnáním požadovaného data dodání s datem konečného schválení nebo vytvoření objednávky může organizace měřit, zda plní interní úrovně služeb a obchodní potřeby. Analýza požadavků, u nichž tento termín nebyl dodržen, může odhalit systémová zdržení v nákupním procesu. Proč je to důležité Určuje cílové datum vyřízení požadavku a umožňuje měřit včasné dodání i dodržování interních úrovní služeb. Kde data získat Jde o datum dodání na úrovni položky v tabulce EBAN, v poli LFDAT. Příklady 2023-11-152023-12-012024-01-20 | |||
| Úroveň naléhavosti UrgencyLevel | Označuje naléhavost žádanky a může ovlivnit prioritu jejího zpracování. | ||
| Popis Úroveň naléhavosti vyjadřuje prioritu nákupního požadavku. Samostatné standardní pole pro ni neexistuje, některé organizace však k zaznamenání této informace používají například pole Requirement Tracking Number. Žadatelé tak mohou označit naléhavé potřeby, které vyžadují přednostní zpracování. Analýza vlivu naléhavosti ukazuje, zda proces skutečně upřednostňuje kritické požadavky. Dashboard Urgency Level Impact Analysis pomocí tohoto atributu porovnává dobu průchodu a míru schválení naléhavých a běžných žádanek. Pomáhá tak ověřit, zda přednostní zpracování funguje podle očekávání. Proč je to důležité Umožňuje porovnat výkonnost procesu u požadavků s vysokou prioritou a ověřit, zda se naléhavé požadavky skutečně vyřizují rychleji. Kde data získat Standardní pole pro naléhavost neexistuje. Některé společnosti k tomuto účelu používají Requirement Tracking Number (EBAN-BEDAR). Může jít také o vlastní pole. Příklady VysokáStředníNízká | |||
| Zdrojový systém SourceSystem | Určuje konkrétní instanci SAP S/4HANA, ze které byla data extrahována. | ||
| Popis Atribut Zdrojový systém označuje systém, ve kterém procesní data vznikla. V organizacích s více instancemi SAP, například pro vývoj, zajištění kvality a produkci nebo pro různé regiony, je toto pole důležité pro správu dat a jejich kontext. Umožňuje rozlišit data z různých zdrojů, předchází jejich nesprávnému agregování a podporuje analýzu jednotlivých systémů. Jde o povinný atribut pro zachování původu dat a jejich dohledatelnosti. Proč je to důležité Poskytuje důležitý kontext o původu a správě dat. V prostředí s více systémy zajišťuje jejich dohledatelnost. Kde data získat Obvykle jde o ID systému SAP (SID), které lze získat ze systémových proměnných nebo konfiguračních tabulek. Příklady S4PECCS4H_PROD_01 | |||
Aktivity v procesu nákupu a platby, žádanky
| Aktivita | Popis | ||
|---|---|---|---|
| Dokončení kroku schválení | Nastane, když schvalovatel kladně rozhodne o požadavku a dokončí jeden krok víceúrovňového schvalovacího workflow. Událost se odvozuje ze změny stavu uvolnění požadavku. | ||
| Proč je to důležité Tato aktivita umožňuje podrobnou analýzu schvalovacího workflow a měření času potřebného pro jednotlivé kroky. Pomáhá rozlišit rychlé schvalovatele od úzkých míst procesu. Kde data získat Odvozuje se z dokumentů změn (CDHDR/CDPOS) pro tabulku EBAN. Změna stavu kódu uvolnění, například v poli FRGZU, z neuvolněného na uvolněný pro konkrétní kód označuje tuto událost. Zachycení Sledujte změny polí stavu uvolnění v tabulce EBAN pro každý kód uvolnění definovaný ve strategii. Typ události inferred | |||
| Schválení nákupního požadavku | Označuje konečné a úplné schválení nákupního požadavku, po kterém jej lze převést na objednávku. Tento milník se odvozuje od dosažení konečného schváleného stavu celkovým stavem uvolnění. | ||
| Proč je to důležité Jde o důležitý milník úspěšného dokončení a častý koncový bod analýzy doby průchodu procesem. Potvrzuje, že požadavek prošel všemi kontrolami a nákupní oddělení jej může zpracovat. Kde data získat Odvozuje se ze změny stavu v tabulce EBAN, konkrétně když se celkový ukazatel uvolnění (FRGZU) nebo stav zpracování (PROCSTAT) změní na konečnou hodnotu „Approved“. Zachycení Určete časové razítko, kdy se použije poslední kód uvolnění nebo kdy se celkový stav požadavku změní na „Approved“. Typ události inferred | |||
| Uzavření nákupního požadavku | Označuje, že položka požadavku je plně zpracovaná a nelze z ní vytvořit další objednávky. Tento stav se obvykle nastaví automaticky, jakmile je objednáno celé požadované množství. | ||
| Proč je to důležité Tato aktivita představuje konečné úspěšné dokončení životního cyklu položky požadavku. Potvrzuje, že se obchodní potřeba promítla do nákupní objednávky. Kde data získat Odvozuje se z tabulky EBAN. Nastane, když se nastaví ukazatel „Closed“ (EBAKZ), obvykle poté, co se množství objednané v objednávkách vyrovná požadovanému množství. Zachycení V dokumentech změn najděte událost, při které se v tabulce EBAN nastaví ukazatel „Closed“ (EBAKZ). Typ události inferred | |||
| Vytvoření nákupního požadavku | Označuje první vytvoření nákupního požadavku v systému. Událost se zaznamená ve chvíli, kdy uživatel nový požadavek poprvé uloží, včetně času vytvoření. | ||
| Proč je to důležité Tato aktivita je hlavním počátečním bodem analýzy životního cyklu požadavku. Je nezbytná pro měření celkové doby průchodu procesem, od zjištění potřeby až po konečné schválení nebo převod na objednávku. Kde data získat Jde o explicitní událost z tabulky EBAN. Použijí se pole data vytvoření (ERDAT) a času vytvoření (ERZEIT) pro konkrétní číslo nákupního požadavku (BANFN). Zachycení Pro každý požadavek (BANFN) použijte pole data a času vytvoření (ERDAT, ERZEIT) z tabulky EBAN. Typ události explicit | |||
| Vytvoření objednávky | Označuje vytvoření objednávky s odkazem na položku požadavku. Jde o explicitní systémovou událost, která propojuje požadavek s navazujícím nákupním dokladem. | ||
| Proč je to důležité Jde o významný milník a úspěšný výsledek procesu zpracování požadavku. Doba mezi schválením požadavku a vytvořením objednávky je důležitým KPI pro měření efektivity nákupu. Kde data získat Událost se výslovně zaznamená při vytvoření položky objednávky. Vazba je uložena v tabulce EKPO (položka objednávky), která obsahuje číslo zdrojového nákupního požadavku (BANFN) a číslo položky (BNFPO). Zachycení Propojte tabulku EKPO s tabulkou EBAN podle čísla požadavku a položky. Událost označuje datum vytvoření položky objednávky. Typ události explicit | |||
| Zamítnutí nákupního požadavku | Označuje konečné zamítnutí nákupního požadavku schvalovatelem, které proces zastaví. Zaznamená se konkrétní změnou stavu označující zamítnutí. | ||
| Proč je to důležité Tato aktivita představuje konečný bod neúspěšného zpracování. Analýza četnosti zamítnutí, jejich důvodů a míst v procesu pomáhá odhalit problémy s dodržováním pravidel, rozpočtem nebo kvalitou požadavků. Kde data získat Odvozuje se ze změny stavu v tabulce EBAN. Stav zpracování (PROCSTAT) nebo ukazatel uvolnění se nastaví na hodnotu, která výslovně znamená „Rejected“. Zachycení V dokumentech změn najděte časové razítko, kdy se celkový stav v tabulce EBAN změní na „Rejected“. Typ události inferred | |||
| Odeslání nákupního požadavku ke schválení | Označuje okamžik, kdy žadatel formálně odešle požadavek a spustí schvalovací workflow. Obvykle se odvozuje od určení strategie uvolnění požadavku a změny jeho stavu na „In Approval“. | ||
| Proč je to důležité Tento důležitý milník spouští měření KPI doby schválení. Analýza času mezi vytvořením a odesláním může odhalit zdržení při přípravě požadavku. Kde data získat Odvozuje se z dokumentů změn (CDHDR/CDPOS) pro tabulku EBAN, konkrétně při vyplnění polí strategie uvolnění (například FRGST) nebo při změně celkového stavu (PROCSTAT) na stav čekající na schválení. Zachycení Najděte první záznam v dokumentech změn, který označuje začátek schvalovacího workflow nebo změnu stavu na „In Approval“. Typ události inferred | |||
| Přiřazení zdroje dodávek | Označuje přiřazení konkrétního dodavatele, smlouvy nebo informačního záznamu schválené položce požadavku nákupčím. Jde o důležitý krok při přípravě požadavku k vytvoření objednávky. | ||
| Proč je to důležité Tato aktivita propojuje schválení s objednáním. Měření času potřebného k přiřazení zdroje pomáhá odhalit zdržení v práci nákupčího a neefektivní výběr zdrojů. Kde data získat Odvozuje se od vyplnění polí souvisejících se zdrojem dodávek v tabulce EBAN, například pevného dodavatele (LIFNR), informačního záznamu (INFNR) nebo smlouvy (KONNR). Zachycení Pomocí dokumentů změn sledujte vyplnění polí, jako jsou LIFNR, INFNR nebo KONNR, v tabulce EBAN. Typ události inferred | |||
| Resetování schválení | Označuje resetování celého schvalovacího workflow, často kvůli významné úpravě požadavku. Schvalování se pak musí znovu spustit od první úrovně. | ||
| Proč je to důležité Tato aktivita upozorňuje na rozsáhlé opakované zpracování, které výrazně prodlužuje dobu průchodu procesem. Odhalení příčin resetování schválení pomáhá zjednodušit proces a omezit zdržení. Kde data získat Odvozuje se z dokumentů změn (CDHDR/CDPOS) v tabulce EBAN. Událost se rozpozná, když se pole stavu uvolnění, například FRGKZ nebo FRGZU, vymažou poté, co byla částečně nebo úplně vyplněna. Zachycení V protokolech změn hledejte změnu stavu uvolnění z uvolněného zpět na neuvolněný. Typ události inferred | |||
| Stažení nákupního požadavku | Nastane, když původní žadatel zruší nebo smaže požadavek před jeho úplným zpracováním. Obvykle jde o výslovnou akci, která nastaví příznak smazání položky požadavku. | ||
| Proč je to důležité Sledování stažených požadavků pomáhá porozumět kolísání poptávky a důvodům rušení. Jde o konečný stav požadavku, po kterém už nelze pokračovat ve zpracování. Kde data získat Událost se výslovně zaznamená, když se v tabulce EBAN nastaví pole příznaku smazání (LOEKZ) pro položku požadavku. Změna se zapíše do CDHDR/CDPOS. Zachycení Najděte událost, při které se příznak smazání (LOEKZ) v tabulce EBAN nastaví na „L“. Typ události explicit | |||
| Úprava nákupního požadavku | Nastane, když uživatel po vytvoření požadavku změní některé důležité pole, například množství, cenu nebo materiál. Tato akce se výslovně zaznamenává v systému dokumentů změn SAP. | ||
| Proč je to důležité Sledování úprav je důležité pro odhalení opakovaného zpracování a jeho vlivu na dobu průchodu procesem. Časté úpravy mohou ukazovat na problémy s kvalitou dat nebo měnící se požadavky, tedy na oblasti vhodné ke zlepšení procesů. Kde data získat Změny v tabulce EBAN se výslovně zaznamenávají do tabulek dokumentů změn SAP (CDHDR a CDPOS). Každá změna sledovaného pole vytvoří záznam. Zachycení Z tabulek CDHDR/CDPOS extrahujte události změn, u nichž je třída objektu BANF pro nákupní požadavky. Typ události explicit | |||
| Zahájení kroku schválení | Označuje, že požadavek čeká na akci konkrétního schvalovatele nebo schvalovací skupiny. Odvozuje se ze stavu požadavku, který čeká na konkrétní kód uvolnění. | ||
| Proč je to důležité Tato aktivita pomáhá přesně určit úzká místa ve schvalovacím řetězci. Analýza doby trvání tohoto stavu odhalí požadavky, které se zastavily, i přetížené schvalovatele. Kde data získat Odvozuje se z polí stavu uvolnění v tabulce EBAN (například FRGZU) a z příslušného nastavení strategie uvolnění. Událost začíná, když se konkrétní kód uvolnění stane dalším krokem ke zpracování. Zachycení Podle protokolů workflow nebo polí stavu určete, kdy požadavek přejde do stavu, v němž konkrétní kód uvolnění čeká na schválení. Typ události inferred | |||
Návody na extrakci dat
Kroky
- Předpoklady: Zajistěte, aby měl váš uživatelský účet v SAP S/4HANA potřebná oprávnění k přístupu k požadovaným CDS views. Obvykle jde o oprávnění k objektům, jako je S_TABU_NAM, a přístup k nástrojům pro zobrazení dat.
- Zvolte způsob připojení k systému: Rozhodněte, jak se připojíte k databázi SAP S/4HANA a spustíte SQL dotazy. Použít můžete například SAP HANA Studio, Eclipse IDE s ADT (ABAP Development Tools) nebo externí SQL klient, jako je DBeaver, který se připojí přes klienta databáze SAP HANA.
- Projděte si SQL dotaz: Seznamte se s dodaným SQL skriptem. Pomocí Common Table Expressions (CTE) shromažďuje data o různých aktivitách a spojuje je do jednotného záznamu událostí.
- Upravte zástupné hodnoty: V dotazu najděte zástupné hodnoty a nahraďte je. Nastavte období extrakce ve formátu
[YYYY-MM-DD]a zadejte příslušné kódy společností ([Your Company Code]). - Spusťte dotaz: Spusťte celý upravený SQL dotaz nad databází SAP S/4HANA. Doba zpracování závisí na objemu dat a zvoleném období.
- Zkontrolujte první výsledky: Po dokončení dotazu si prohlédněte několik prvních řádků. Ověřte, že jsou vyplněné všechny sloupce, například PurchaseRequisitionId, ActivityName a EventTime, a že data mají správný formát.
- Ověřte transformaci dat: Dotaz připravuje data ve formátu vhodném pro process mining. Funkce
CASTaCONCATzajišťují jednotné datové typy. Po spuštění by neměla být potřeba žádná rozsáhlá další transformace. - Exportujte záznam událostí: Z SQL klienta exportujte celou sadu výsledků do souboru CSV. Nastavte kódování UTF-8, aby nedocházelo k problémům se znaky.
- Připravte soubor k nahrání: Před nahráním do nástroje pro process mining ověřte, že soubor CSV obsahuje správné záhlaví (
PurchaseRequisitionId,ActivityName,EventTimeatd.) a že formát data a času ve sloupciEventTimeje jednotný a cílová platforma ho podporuje. - Nahrajte data do ProcessMind: Nahrajte výsledný soubor CSV do projektu ProcessMind. V nastavení projektu namapujte
PurchaseRequisitionIdjako ID případu,ActivityNamejako aktivitu aEventTimejako časové razítko.
Konfigurace
- Základní CDS views: Extrakce využívá především
I_PurchaseRequisitionAPI01pro základní data o žádankách,I_ChangeDocumentaI_ChangeDocumentItempro sledování změn a aktualizací stavu aI_PurchaseOrderItemAPI01pro propojení s objednávkami. - Oprávnění: Uživatel spouštějící dotaz potřebuje přístup pro čtení k uvedeným CDS views. Potřebné role a oprávnění ověřte s týmem zabezpečení SAP.
- Filtr období: Omezení objemu dat vyžaduje filtr podle data vytvoření žádanky (
CreationDate). Pro první analýzu doporučujeme období 3 až 6 měsíců. - Filtr organizace: Filtrujte podle
CompanyCode, abyste analyzovali proces správné obchodní jednotky. Podle potřeby můžete použít takéPurchaseRequisitionTypea zaměřit se na konkrétní nákupní procesy, například na běžné zboží nebo služby. - Nastavení protokolování změn: Záznam aktivit, jako je „Žádanka upravena“, a jednotlivých kroků schválení závisí na tom, zda je v systému SAP aktivní protokolování změn příslušných polí. Pokud tyto události chybí, zkontrolujte nastavení tabulky EBAN.
- Výkon: Spuštění dotazu za dlouhé období může v rozsáhlých systémech s miliony žádanek ovlivnit výkon. Zvažte spuštění mimo špičku nebo v neprodukčním prostředí s nedávno aktualizovanými daty.
Ukázkový dotaz sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Kroky
- Ověřte, že máte přímý přístup pro čtení ke schématu SAP HANA obsahujícímu EBAN a EBKN. Zjistěte také, které objekty pro dokumenty změn a nákupní doklady váš systém používá ke sledování změn žádanek, schvalování, přiřazení zdroje, odkazů na objednávky a uzavření. Tyto objekty a pole se mohou lišit podle verze a konfigurace, proto v dotazu nahraďte každou hodnotu v hranatých závorkách odpovídajícím objektem nebo polem ve vašem systému.
- V SAP GUI použijte transakci SE16H nebo schválený nástroj pro správu databáze a prohlédněte si tabulky EBAN a EBKN. Ověřte klíčová pole žádanky a dostupná pole pro datum, čas, uživatele, stav, odstranění, uvolnění, přiřazení účtu a odkaz na nákupní doklad. Definice polí ověřte pomocí SE11 nebo datového slovníku SAP. Při testování nezpřístupňujte produkční data.
- Zjistěte, odkud systém čerpá dokumenty změn žádanky a změny schválení. Dotaz očekává normalizovaný zdroj změn s názvem [Your requisition change document source] a poli pro číslo žádanky, číslo položky, změněné pole, původní hodnotu, novou hodnotu, datum změny, čas změny a uživatele. Před spuštěním namapujte tento zdroj na příslušné tabulky dokumentů změn nebo CDS view ve vašem systému.
- Zjistěte, který zdroj workflow nebo uvolnění zaznamenává odeslání, reset schválení, zahájení a dokončení kroku schválení, konečné schválení a zamítnutí. Dotaz očekává [Your requisition approval event source], kde každý řádek představuje změnu stavu nebo uvolnění a obsahuje číslo žádanky, číslo položky, typ události, kód uvolnění nebo skupinu schvalovatelů, schvalovatele, datum události, čas události a stav. Namapujte jej na úložiště uvolnění nebo workflow používané ve vaší konfiguraci S/4HANA.
- Určete zdroje přiřazení zdroje, odkazu na objednávku a uzavření. Dotaz očekává [Your requisition source assignment source], [Your requisition purchase order reference source] a [Your requisition closure source]. Namapujte tyto zástupné hodnoty na schválené tabulky nebo views ve vašem systému. Vytvoření objednávky musí být doloženo přímým odkazem z položky objednávky na položku žádanky, nikoli odvozeno z nesouvisející nákupní aktivity.
- Nastavte období extrakce pomocí hodnot [Start date] a [End date]. Pro první spuštění doporučujeme období tří až šesti měsíců. Delší období použijte až po ověření výkonu databáze a objemu událostí. Dotaz filtruje data vytvoření a data událostí, přičemž identifikátor žádanky ponechává jako identifikátor případu.
- Spusťte dotaz ve schváleném SQL klientovi připojeném k SAP HANA. Měňte pouze údaje pro připojení mimo dotaz, parametry data, filtry specifické pro společnost a výslovně popsané zástupné hodnoty zdrojů a polí. Názvy výstupních sloupců zachovejte přesně: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount a RequisitionStatus.
- Zkontrolujte duplicitní události, přesnost časových razítek, práci s časovými pásmy a podrobnost dat na úrovni položky nebo dokladu. Dotaz vytváří identifikátory případů na úrovni dokladu a interně zahrnuje kontext položky. Pokud více položek vytvoří stejnou aktivitu se stejným časovým razítkem, ponechte samostatné řádky, pokud návrh v ProcessMind výslovně nevyžaduje odstranění duplicit.
- Ověřte, že se každá požadovaná aktivita vyskytuje jako hodnota ActivityName, že EventTime obsahuje věrohodné časové údaje v chronologickém pořadí a že požadovaný identifikátor případu není prázdný. Porovnejte počty s reporty SAP nebo schválenými provozními výstupy za stejné období.
- Exportujte výsledek do souboru CSV v kódování UTF-8 nebo do jiného tabulkového formátu podporovaného ProcessMind. Přidejte řádek záhlaví, zachovejte časová razítka kompatibilní s ISO a prázdné hodnoty ponechte prázdné. Při nahrávání nastavte PurchaseRequisitionId jako identifikátor případu, ActivityName jako sloupec aktivity a EventTime jako sloupec časového razítka.
Konfigurace
- Identifikátor případu: Použijte číslo nákupní žádanky z EBAN, označené jako PurchaseRequisitionId. Pokud je proces nastaven na úrovni položky, použijte místo něj zdokumentovaný složený klíč, například číslo žádanky a číslo položky, a stejný klíč použijte pro všechny události.
- Primární zdroj: EBAN obsahuje data položek žádanek. EBKN slouží k doplnění údajů o přiřazení účtu, oddělení nebo nákladovém středisku. Před spuštěním ověřte přesné názvy polí a datové typy v datovém slovníku SAP.
- Zdroje událostí: Dotaz záměrně používá popisné zástupné hodnoty pro zdroje změn, schválení, přiřazení zdroje, odkazu na objednávku a uzavření. Tyto zdroje závisí na verzi S/4HANA, návrhu workflow, postupu uvolnění, aktivovaných obchodních funkcích a rozšířeních zákazníka.
- Období: Začněte třemi až šesti měsíci. Pokud jsou k dispozici indexovaná nebo dělená datová pole, omezte období podle nich. Při přírůstkovém načítání nechte období extrakce dostatečně překrývat, aby se zachytily opožděné změny. Poté odstraňte duplicity podle případu, aktivity, časového razítka, položky a klíče zdrojové události.
- Obchodní filtry: Filtry [Company code filter], [Document type filter], [Purchasing group filter] a [Plant filter] nastavte pouze tehdy, pokud jsou tato pole dostupná a jejich obchodní význam je ověřený. Pokud potřebujete zachytit celý životní cyklus, nefiltrujte podle stavu.
- Mapování stavů: Hodnoty pro In Approval, final approved, rejected, reset, pending release code a closed nastavte podle strategie uvolnění nebo konfigurace workflow v cílovém systému. Nepředpokládejte, že se v různých klientech SAP používá stejný kód stavu.
- Mapování změn: Zahrňte změny množství, ceny, materiálu, data dodání, přiřazení účtu a dalších polí, která váš proces považuje za důležitá. Dotaz obsahuje výslovné podmínky pro uvedená pole a vyžaduje, aby zdroj poskytoval název změněného pole.
- Časová razítka: Spojte datum a čas události v časovém pásmu databáze a zdokumentujte případný převod na UTC. Pokud zdroj ukládá pouze datum, použijte půlnoc jen tehdy, když přesnější časové razítko není k dispozici, a toto omezení zaznamenejte.
- Výkon: První extrakci omezte podle období a obchodního rozsahu, vybírejte pouze potřebné sloupce a vyhněte se neomezeným spojením s rozsáhlou historií změn nebo workflow. Zkontrolujte plán provádění v HANA. Pokud budete extrakci opakovat, zvažte přípravu nebo uložení normalizovaných zdrojů událostí.
- Oprávnění a předpoklady: Zajistěte přístup pro čtení k EBAN, EBKN, nastaveným zdrojům změn a workflow, datům přiřazení zdroje, odkazům na objednávky a datům o uzavření. Ověřte, že je přímý přístup k databázi schválený, příslušné nákupní funkce a workflow jsou aktivní a máte potřebnou licenci k databázi SAP HANA nebo nástroje pro správu.
- Zabezpečení: Uplatňujte princip nejnižších oprávnění, chraňte identifikátory uživatelů a schvalovatelů a dodržujte interní pravidla pro extrakci nákupních a finančních údajů.
Ukázkový dotaz sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Chcete začít?
Pomocí této šablony připravíte data a využijete process mining při analýze procesu nákupu a platby, konkrétně žádanek. Začněte zlepšovat efektivitu svého procesu.
Omezte zpoždění žádanek v procesu P2P. Optimalizujte workflow.
Zjednodušte procesy, zkraťte dobu vyřízení a dobu průchodu až o 30 %.
Bez platební karty, nastavení za 5 minut.