רכש בשירות-עצמי

רכש בשירות-עצמי (Self-Service Procurement) מאפשר למשתמש-העסקי הרגיל — לא רוכש מקצועי — לבקש בעצמו מוצרים ושירותים דרך 'עגלת-קניות' (Shopping Cart) ידידותית, בדומה לחנות-אונליין. ב-S/4HANA היכולת מובְנֵית בליבה (לא עוד SRM נפרד), עם קטלוגים, אישורים אוטומטיים והמרה ל-PR/PO ברקע. המטרה: להוריד את עומס-הרכש מהמשתמשים-העסקיים ולקצר זמני-מחזור. יצירת דרישה או עגלת-קניות — השלב הפותח של הרכש התפעולי: רישום הצורך כדרישת-רכש (ME51N / Fiori) או כעגלת-קניות. כאן נקבעים החומר/השירות, הכמות, המפעל, תאריך-האספקה ושיוך-החשבון — הבסיס לכל המשך-התהליך. מעקב טביעת-רגל פחמנית — S/4HANA מאפשר לשייך נתוני-פליטה (carbon footprint) לפריטי-רכש כבר בשלב הדרישה/ההזמנה — כך שהחלטות-רכש לוקחות בחשבון לא רק מחיר וזמינות אלא גם השפעה-סביבתית, בתמיכת יעדי-קיימות (ESG). מכירות בין-חברתיות מתקדמות — תרחיש בין-חברתי מתקדם שבו רכש בחברה אחת מקושר אוטומטית למכירה בחברה-קשורה (Advanced Intercompany Sales / Stock). הזמנת-רכש בחברה הקונה יוצרת בו-זמנית הזמנת-מכירה בחברה המוכרת, עם תמחור-העברה ורישומי-IC אוטומטיים. אישור ומשלוח-החזרה — Confirmation היא הודעת-ספק על מועד/כמות-אספקה צפויים (לפני הקבלה בפועל), המעדכנת את ה-PO ואת ה-MRP. Return Delivery היא החזרת-טובין לספק לאחר קבלה (איכות לקויה / עודף), עם תנועת-מלאי הפוכה ותיעוד. Shopping Cart מול Requisition-to-Pay והגירה — השוואה אסטרטגית בין שני מודלים: Shopping Cart הקלאסי (SRM) מול תהליך Requisition-to-Pay המובְנֵה ב-S/4HANA, ושיקולי ההגירה ביניהם. ב-S/4HANA הכיוון הוא Self-Service Requisitioning בליבה / Ariba, ולא SRM נפרד. תהליך אישורים (Workflow) — מנגנון האישורים ברכש התפעולי. ב-S/4HANA ה-flexible workflow מחליף את ה-release strategy הקלאסית — ניתוב-אישור מבוסס-תנאים (שווי, קטגוריה, מרכז-עלות) דרך אפליקציות-Fiori ('My Inbox'), ללא תכנות-workflow מורכב. פונקציונליות-רכש מבוססת למידת-מכונה — S/4HANA משלב למידת-מכונה ברכש כדי לאוטמט ולשפר החלטות: סיווג-מקור אוטומטי, ניתוב-עגלות חכם, חיזוי-מחיר וזיהוי-חריגות. המטרה: להפוך את הרוכש מ'מקליד' ל'מקבל-החלטות', עם המלצות מבוססות-נתונים.

במקום למלא טופס-רכש מסובך, העובד נכנס לקטלוג, בוחר פריטים, ומוסיף ל'עגלה' — בדיוק כמו קנייה ברשת. כשהוא מאשר, SAP יוצר ברקע דרישת-רכש או הזמנת-רכש, מנתב לאישור, ושולח לספק. העובד לא צריך להכיר תנועות-SAP או טבלאות — הוא רק 'קונה'. יצירת דרישה או עגלת-קניות — זה ה'אני צריך X'. ממלאים מה רוצים, כמה, לאן ולמתי. ב-Fiori זה נראה כמו טופס-הזמנה פשוט; בעגלת-קניות זה נראה כמו חנות-אונליין. התוצאה זהה: רשומת-דרישה במערכת. מעקב טביעת-רגל פחמנית — מעבר ל'כמה זה עולה', המערכת יכולה להראות 'כמה CO2 הפריט הזה פולט'. כך אפשר להעדיף ספק ירוק יותר. זה נתון נוסף שמופיע ליד הפריט בדרישה/בעגלה. מכירות בין-חברתיות מתקדמות — כשחברה אחת בקבוצה קונה מחברה אחרת באותה קבוצה, צריך גם 'קנייה' וגם 'מכירה' שמסתנכרנות. התרחיש המתקדם עושה את זה אוטומטית: PO בצד-הקונה ► SO בצד-המוכר, עם המחיר-הפנימי, בלי הקלדה כפולה. אישור ומשלוח-החזרה — Confirmation = 'הספק אמר: אשלח 100 יחידות ב-15 בחודש'. זה עוזר לתכנון לדעת מתי הסחורה באמת תגיע. Return Delivery = 'קיבלנו, אבל זה פגום — מחזירים לספק'. שתי הפעולות מעדכנות את המלאי ואת ההזמנה. Shopping Cart מול Requisition-to-Pay והגירה — פעם השתמשו במערכת נפרדת (SRM) ל'עגלות-קניות'. עכשיו S/4HANA עושה את זה בעצמה. אם ארגון מגיע מ-SRM, הוא צריך 'להגר' — לעבור לתהליך החדש המובְנֵה. הסעיף מסביר את ההבדלים ואיך עוברים. תהליך אישורים (Workflow) — לפני שדרישה/הזמנה יוצאת לפועל, מישהו צריך לאשר אותה — בדרך-כלל מנהל. ה-workflow שולח את הבקשה לאדם-הנכון, הוא לוחץ 'אשר' או 'דחה' ב-Inbox, וההזמנה ממשיכה או נעצרת. הכל אוטומטי לפי כללים. פונקציונליות-רכש מבוססת למידת-מכונה — המערכת 'לומדת' מהיסטוריית-הרכש: היא יודעת לנחש לאיזה ספק כדאי, אם המחיר חריג, ולמי לנתב את האישור. כך פחות עבודה ידנית ופחות טעויות. זה כמו 'השלמה-אוטומטית' חכמה לרכש.

לאפשר 'רכש מבוזר מבוקר' — המשתמשים מבקשים בעצמם, אך כל בקשה עוברת אישור-תקציבי וכללי-מקור-אספקה. מפחית צווארי-בקבוק במחלקת-הרכש, מקצר lead-time, ומגדיל ציות (compliance) דרך קטלוגים מאושרים מראש. יצירת דרישה או עגלת-קניות — לתעד את הצורך באופן מובנה לפני התחייבות כספית — ולאפשר אישור, בחירת-מקור והמרה ל-PO מבוקרת. מעקב טביעת-רגל פחמנית — להטמיע שיקולי-קיימות בהחלטות-הרכש התפעוליות — לעמוד ביעדי-ESG, רגולציה ודרישות-לקוחות לשרשרת-אספקה ירוקה. מכירות בין-חברתיות מתקדמות — לייעל סחר פנים-קבוצתי — לשקף נכון רווח/עלות בכל ישות, לעמוד בדרישות transfer-pricing, ולמנוע עבודה כפולה בין הצדדים. אישור ומשלוח-החזרה — Confirmation משפרת את אמינות-התכנון (תאריכים ריאליים מהספק); Return Delivery מטפלת בכמות/איכות לקויה בצורה מתועדת ומבוקרת, עם השפעה נכונה על המלאי וה-IR. Shopping Cart מול Requisition-to-Pay והגירה — להחליט נכון על מודל-הרכש העתידי בעת מעבר ל-S/4HANA — להימנע מהשקעה ב-SRM שהופסק, ולבחור בין הפתרון המובְנֵה ל-Ariba לפי גודל וצרכים. תהליך אישורים (Workflow) — לאכוף הפרדת-תפקידים ובקרה-תקציבית — שאף התחייבות-רכש לא יוצאת ללא אישור-מורשה — בצורה גמישה, שקופה ונטולת-תכנות. פונקציונליות-רכש מבוססת למידת-מכונה — להגדיל יעילות ודיוק — לקצר זמני-מחזור, להפחית טעויות-הקלדה, לזהות סיכונים (חריגות-מחיר, חשבוניות-כפולות) ולשחרר רוכשים למשימות אסטרטגיות.

• Fiori Launchpad ► Procurement ► Create Purchase Requisition / My Shopping Cart • Materials Management ► Purchasing ► Self-Service Procurement ► Catalog Management • Materials Management ► Purchasing ► Purchase Requisition ► Activate Self-Service Requisitioning • Logistics ► Materials Management ► Purchasing ► Purchase Requisition ► Create (ME51N) • Fiori ► Procurement ► Create Purchase Requisition • Fiori ► Sustainability ► Manage Footprint Inventory • Materials Management ► Purchasing ► Sustainability / Footprint integration • Sales & Distribution ► Billing ► Intercompany Billing • Materials Management ► Purchasing ► Purchase Order ► Intercompany / STO setup • Materials Management ► Purchasing ► Confirmations ► Define Confirmation Control • Logistics ► Materials Management ► Inventory Management ► Goods Movement (MIGO) — Return Delivery 122 • Materials Management ► Purchasing ► Self-Service Procurement ► Activate / Migrate • Migration Cockpit (LTMC / Migrate Your Data) — Open Purchase Requisitions • Fiori ► Manage Workflows for Purchase Requisitions / Purchase Orders • Materials Management ► Purchasing ► Purchase Order ► Release Procedure (קלאסי — OMGS/OMGQ) • Fiori ► Intelligent Scenario Lifecycle Management (ISLM) • Materials Management ► Purchasing ► Machine Learning–Based Functionality (activation)

• Self-Service = משתמש-עסקי קונה דרך Shopping Cart, לא רוכש מקצועי.
• העגלה ממופה ל-PR/PO ברקע; המשתמש לא נוגע בטבלאות.
• מובְנֵה ב-S/4HANA — לא SRM נפרד.
• הדרישה = ה'אני צריך' הפותח את התהליך.
• נשמרת ב-EBAN.
• מקור: ידני / MRP / Shopping Cart.
• מעקב-פחמן מוסיף ממד-קיימות לרכש.
• ערכי-CO2e ברמת-הפריט מזינים החלטה ודיווח.
• תומך ביעדי-ESG ושרשרת-אספקה ירוקה.
• מקשר PO (קונה) ל-SO (מוכר) בין ישויות הקבוצה.
• כולל transfer pricing ו-Intercompany Billing.
• מייעל סחר פנים-קבוצתי.
• Confirmation = תאריך/כמות צפויים מהספק, משפר תכנון.
• Return Delivery = החזרת-טובין (תנועה 122).
• Confirmation Control Key שולט באישורים הצפויים.
• S/4HANA מחליף את SRM בתהליך מובְנֵה / Ariba.
• הגירה = מיפוי עגלות ל-PRs + קטלוגים + workflow.
• החלט מוקדם: embedded מול Ariba.
• flexible workflow = אישורים מבוססי-תנאים ב-Fiori.
• מחליף את ה-release strategy הקלאסית.
• אישורים מתבצעים ב-'My Inbox'.
• ML הופך את הרוכש למקבל-החלטות מבוסס-נתונים.
• תרחישים: חיזוי-אספקה, סיווג-מקור, זיהוי-חריגות.
• נשען על ISLM ו-Business AI; שמור אדם-בלולאה.

בארגון טכנאי-תחזוקה זקוק לאטם ולמסנן לקו-מילוי. הוא פותח Shopping Cart, בוחר מקטלוג-ה-MRO, ומאשר; הדרישה מנותבת לראש-צוות-התחזוקה לאישור, ואז הופכת ל-PO מול ספק-החלפים. כך טכנאים מזמינים MRO ללא תלות יומיומית במחלקת-הרכש. עובד פותח 'My Shopping Cart' (Fiori) ► בוחר 5 פריטי-משרד מקטלוג פנימי ► מוסיף free-text item לכבל-מיוחד ► מאשר ► נוצרת דרישת-רכש (EBAN) ► flexible workflow מנתב למנהל לאישור-תקציבי ► לאחר אישור, הדרישה מומרת ל-PO אוטומטית (אם יש מקור) ► נשלחת לספק ► העובד מבצע Confirmation עם קבלת-הפריטים. יצירת דרישה או עגלת-קניות — בארגון רוב דרישות-חומרי-הגלם (סוכר, תרכיז, CO2) נוצרות אוטומטית מ-MRP לפי תכנון-הייצור; דרישות-MRO נוצרות ידנית כ-Shopping Cart על-ידי טכנאים. מתכנן-ייצור פותח ME51N ► חומר 'סוכר', כמות 20 טון, מפעל 1000, תאריך-אספקה בעוד שבוע, Account Assignment ריק (מלאי) ► שומר ► נוצרת PR מספר 10xxxxxx ב-EBAN, ממתינה לבחירת-מקור והמרה. מעקב טביעת-רגל פחמנית — בארגון, מוצר לדוגמה מציבה יעדי-קיימות לאריזה; מעקב-הפחמן מאפשר להעדיף ספקי-PET ממוחזר עם טביעת-רגל נמוכה, ולדווח על פליטות שרשרת-האספקה (Scope 3). רוכש בוחר בין שני ספקי-בקבוקים: המחיר זהה, אך אפליקציית-הרכש מציגה לספק A פליטה של 0.8 kg CO2e ליחידה ולספק B 0.5 — הרוכש בוחר ב-B מתוך שיקול-קיימות, והבחירה מתועדת. מכירות בין-חברתיות מתקדמות — בארגון קבוצת-הבקבוק כוללת ישויות-ייצור וישויות-הפצה נפרדות; משקאות 'נמכרים' ממפעל-הייצור לישות-ההפצה האזורית דרך תרחיש בין-חברתי מתקדם, עם תמחור-העברה פנימי. חברת-ההפצה (CC 2000) מזמינה מוצר ממפעל-הייצור (CC 1000) ► PO ב-2000 יוצר אוטומטית SO ב-1000 ► המפעל מספק ► Intercompany Billing מ-1000 ל-2000 לפי transfer price ► כל ישות רושמת רווח/עלות נפרדים. אישור ומשלוח-החזרה — בארגון ספקי-תרכיז שולחים Order Acknowledgements שמעדכנים את תכנון-המילוי; אצוות-אריזה שנכשלו בבדיקת-QA מוחזרות לספק כ-Return Delivery (122) עם תיעוד-איכות. PO ל-100 בקבוקים עם Confirmation Control Key 0004 ► הספק שולח Order Acknowledgement (AB) ל-100 ב-20 בחודש ► נרשמת Confirmation, MRP מעדכן תאריך ► בקבלה מתגלים 10 פגומים ► נרשמת Return Delivery (122) ל-10, החשבונית תשולם רק על 90. Shopping Cart מול Requisition-to-Pay והגירה — בארגון, אם ישות הסתמכה על SRM ל-MRO, ההגירה ל-S/4HANA תעביר את עגלות-ה-MRO ל-Self-Service Requisitioning המובְנֵה, ותשמור על חוויית-המשתמש של הטכנאים. ארגון על SRM נכנס לפרויקט-S/4HANA ► ממפה את תהליכי-ה-Shopping-Cart ל-Self-Service Requisitioning ► מהגר קטלוגים ל-OCI ► בונה flexible workflow מקביל לאישורי-SRM ► מכבה את SRM לאחר העברת-עגלות פתוחות. תהליך אישורים (Workflow) — בארגון הזמנות-רכש לחומרי-גלם בשווי-גבוה מנותבות ל-flexible workflow רב-שלבי (ראש-רכש ► מנהל-מפעל ► כספים), בעוד דרישות-MRO זניחות מאושרות אוטומטית מתחת לסף. דרישת-רכש ב-50,000 ₪ נשמרת ► start condition מזהה שווי>10,000 ► ה-workflow מנתב למנהל-המחלקה (Inbox) ► הוא מאשר ► שווי>40,000 מפעיל שלב-שני למנהל-כספים ► אישור ► הדרישה משוחררת ומומרת ל-PO. פונקציונליות-רכש מבוססת למידת-מכונה — בארגון ML מציע אוטומטית את ספק-הסוכר המתאים לפי עונתיות ומחיר, וחוזה עיכובי-אספקה אפשריים בתקופות-שיא — מה שמאפשר תכנון-מילוי יציב. רוכש פותח PR ללא מקור ► מנוע-ה-ML מציע ספק מומלץ לפי היסטוריה, מחיר ואמינות-אספקה ► הרוכש מאשר בלחיצה ► בעת רישום-חשבונית, ה-ML מסמן חריגת-מחיר של 18% מעל הממוצע — הרוכש בודק לפני אישור.

• הפעלת Self-Service Requisitioning והגדרת Document Type ייעודי ל-Shopping Cart. • ניהול קטלוגים (internal catalog / OCI punch-out) כמקור-בחירה למשתמש. • flexible workflow לאישור עגלת-הקניות לפי שווי / קטגוריה / מרכז-עלות. • מיפוי Account Assignment ברירת-מחדל למשתמש (לרוב K=Cost Center של המבקש). יצירת דרישה או עגלת-קניות • Document Type (NB) קובע טווח-מספרים ובקרת-שדות לדרישה. • Field Selection (per Document Type / transaction) — חובה/אופציונלי/מוסתר לכל שדה. • Account Assignment Category ברירת-מחדל לפי תרחיש (מלאי vs צריכה). מעקב טביעת-רגל פחמנית • הפעלת אינטגרציית Footprint Management ושיוך ערכי-פליטה ל-master של המוצר/ספק. • הצגת שדות-פליטה במסכי-הדרישה/ההזמנה (Fiori). • הגדרת יחידות-מדידה לפליטה (CO2e) ומקורות-הנתונים. מכירות בין-חברתיות מתקדמות • הגדרת Intercompany flow בין קודי-חברה ומפעלים (sales-area assignment). • תנאי transfer pricing (PI01 / IV01) ל-Intercompany Billing. • Document Types ו-Item Categories לתרחיש הבין-חברתי המתקדם. אישור ומשלוח-החזרה • Confirmation Control Key (BSTAE): אילו אישורים צפויים (AB/LA), GR-relevance ו-MRP-relevance. • Movement Type 122 ל-Return Delivery; הגדרת סיבות-החזרה (Reason for movement). • Advanced Returns Management להפעלת תהליך-החזרה מובנה (אופציונלי). Shopping Cart מול Requisition-to-Pay והגירה • החלטת-ארכיטקטורה: Self-Service Requisitioning מובְנֵה מול SAP Ariba Buying. • מיפוי Shopping Carts פתוחים ל-PRs ב-Migration Cockpit. • העברת קטלוגים (internal / OCI) והמרת אישורי-SRM ל-flexible workflow. תהליך אישורים (Workflow) • flexible workflow: Preconditions (שווי/קטגוריה/מפעל) + Steps + Agent determination. • Agent determination: role / responsibility rule / expression למאשר. • (קלאסי) Release Group / Release Code / Release Strategy עם Classification. פונקציונליות-רכש מבוססת למידת-מכונה • הפעלת Intelligent Scenarios (ISLM) ואימון/פריסה של מודלי-ML. • הגדרת ספי-ביטחון (confidence) להצגת המלצות-ML. • אינטגרציה ל-SAP AI Core / Business AI עבור תרחישים מתקדמים.

נתוני אב • Catalog (internal / external OCI) · Material Master / Product · Cost Center ברירת-מחדל למבקש. • Business Partner (Vendor) ומקור-אספקה לקטגוריות-הקטלוג. • Material Master (תצוגת Purchasing/MRP) · Plant/Storage Location · Cost Center / Order לשיוך-חשבון. • Product footprint data (kg CO2e/unit) · Supplier sustainability ratings · ערכי-Scope 3 ברמת-הפריט. • Plant ↔ Company Code · Customer/Supplier בין-חברתי (Business Partner) · תנאי-תמחור-העברה. • Confirmation Control Key במאסטר/ב-PO · Reason for Movement · Vendor returns settings. • מבנה-אישורים (responsibility / org) · תפקידי-מאשרים · ערכי-סף (thresholds) לשווי. • נתוני-רכש היסטוריים (EKKO/EKPO/EKBE) כבסיס-אימון · דירוגי-ספקים · היסטוריית-מחירים. שאלות ראיון מהו Shopping Cart וכיצד הוא שונה מ-PR? Shopping Cart הוא ממשק עסקי-ידידותי לבקשת-רכש; ברקע הוא מתורגם ל-PR (EBAN). ה-PR הוא אובייקט-ה-SAP הרשמי; העגלה היא חוויית-המשתמש. האם SRM עדיין נדרש ל-Self-Service ב-S/4HANA? לא. היכולת מובְנֵית בליבת S/4HANA (Self-Service Requisitioning) או דרך Ariba Buying; SRM הקלאסי הופסק. באילו דרכים נוצרת דרישת-רכש? ידנית (ME51N / Fiori), אוטומטית מ-MRP, או מ-Shopping Cart בשירות-עצמי. באיזו טבלה נשמרת ה-PR? EBAN (שורות) ו-EBKN (שיוך-חשבון לכל שורה). מדוע לשלב carbon footprint ברכש? כדי לכלול שיקולי-קיימות (ESG) בהחלטות-רכש — מעבר למחיר וזמינות — ולעמוד ברגולציה ובדרישות-לקוח. מאיפה מגיעים נתוני-הפליטה? מ-master של המוצר/ספק ומ-SAP Sustainability Footprint Management, מוצגים במסמכי-הרכש. מה ייחודי ב-Advanced Intercompany Sales? PO בצד-הקונה יוצר אוטומטית SO בצד-המוכר, עם תמחור-העברה ו-Intercompany Billing — סחר פנים-קבוצתי מסונכרן ללא עבודה כפולה. מה ההבדל בין Confirmation ל-Goods Receipt? Confirmation היא הצהרת-ספק צפויה (לפני הקבלה) המעדכנת תכנון; GR הוא הרישום בפועל של קבלת-הסחורה למלאי. באיזו תנועה נרשמת Return Delivery? תנועה 122 (החזרה ל-GR) ב-MIGO, היוצרת MSEG הפוך ומעדכנת EKBE. מה קורה ל-SRM ב-S/4HANA? SRM הקלאסי הופסק; הפונקציונליות עברה לליבה (Self-Service Requisitioning) או ל-SAP Ariba Buying. מהם השלבים העיקריים בהגירה מ-Shopping Cart? מיפוי עגלות-פתוחות ל-PRs, העברת קטלוגים, והמרת אישורי-SRM ל-flexible workflow. מה החליף את ה-release strategy ב-S/4HANA? flexible workflow — ניתוב-אישור מבוסס-תנאים דרך Fiori ('My Inbox'), בלי תכנות-workflow קלאסי. מהם שלושת מרכיבי שלב ב-flexible workflow? Precondition (תנאי-התחלה), Step (פעולת-האישור) ו-Agent determination (מי המאשר). אילו תרחישי-ML נפוצים ברכש? חיזוי-תאריכי-אספקה, סיווג-מקור אוטומטי, ניתוב-אישור חכם, וזיהוי-חריגות/כפילויות בחשבוניות. מהו ISLM? Intelligent Scenario Lifecycle Management — הכלי ב-S/4HANA לניהול אימון, פריסה וניטור של מודלי-ML מובְנֵים. נושאים קשורים • MM · עיבוד דרישות (5.3) • MM · workflow (5.2.6) • אובייקט · EBAN • MM · עיבוד הזמנת-רכש (5.4) • MM · קונפיג רכש בשירות-עצמי (5.7.1)

• עגלה לא הופכת ל-PR ➔ Self-Service Requisitioning לא מופעל או Document Type חסר. • אין פריטים בקטלוג ➔ הקטלוג לא הוגדר / לא מוקצה למשתמש. • עגלה תקועה באישור ➔ flexible workflow לא מצא מאשר (חסר agent determination). יצירת דרישה או עגלת-קניות • שמירת PR נכשלת ➔ שדה-חובה (Field Selection) חסר. • PR לא נראית ב-MRP/רכש ➔ מפעל/Purchasing Group שגוי. מעקב טביעת-רגל פחמנית • אין נתוני-פליטה בפריט ➔ master לא הוזן או אינטגרציה לא פעילה. • ערכים לא-עקביים ➔ יחידות-מדידה/מקורות שונים. מכירות בין-חברתיות מתקדמות • SO לא נוצר מ-PO ➔ Intercompany flow / sales-area לא הוגדר. • Billing בין-חברתי חסר ➔ תנאי PI01/IV01 לא מתוחזק. אישור ומשלוח-החזרה • Confirmation לא מתקבלת ➔ Control Key לא מצפה לסוג-האישור, או IDoc-Ack נכשל. • החזרה לא מעדכנת חשבונית ➔ ה-122 לא קושר ל-PO/GR הנכון. Shopping Cart מול Requisition-to-Pay והגירה • עגלות-SRM לא הומרו ➔ מיפוי-הגירה חסר. • אישורים לא עובדים אחרי הגירה ➔ flexible workflow לא הוגדר במקביל ל-SRM. תהליך אישורים (Workflow) • אישור לא מגיע למאשר ➔ Agent determination שגוי / חסר. • מסמך לא משתחרר ➔ start condition לא מתאים או שלב לא הושלם. פונקציונליות-רכש מבוססת למידת-מכונה • אין המלצות ➔ מודל לא אומן/נפרס (ISLM) או נתונים לא-מספיקים. • המלצות גרועות ➔ נתוני-אימון מוטים / לא-מנוקים.

• Self-Service = משתמש-עסקי קונה דרך Shopping Cart, לא רוכש מקצועי. • העגלה ממופה ל-PR/PO ברקע; המשתמש לא נוגע בטבלאות. • מובְנֵה ב-S/4HANA — לא SRM נפרד. • הדרישה = ה'אני צריך' הפותח את התהליך. • נשמרת ב-EBAN. • מקור: ידני / MRP / Shopping Cart. • מעקב-פחמן מוסיף ממד-קיימות לרכש. • ערכי-CO2e ברמת-הפריט מזינים החלטה ודיווח. • תומך ביעדי-ESG ושרשרת-אספקה ירוקה. • מקשר PO (קונה) ל-SO (מוכר) בין ישויות הקבוצה. • כולל transfer pricing ו-Intercompany Billing. • מייעל סחר פנים-קבוצתי. • Confirmation = תאריך/כמות צפויים מהספק, משפר תכנון. • Return Delivery = החזרת-טובין (תנועה 122). • Confirmation Control Key שולט באישורים הצפויים. • S/4HANA מחליף את SRM בתהליך מובְנֵה / Ariba. • הגירה = מיפוי עגלות ל-PRs + קטלוגים + workflow. • החלט מוקדם: embedded מול Ariba. • flexible workflow = אישורים מבוססי-תנאים ב-Fiori. • מחליף את ה-release strategy הקלאסית. • אישורים מתבצעים ב-'My Inbox'. • ML הופך את הרוכש למקבל-החלטות מבוסס-נתונים. • תרחישים: חיזוי-אספקה, סיווג-מקור, זיהוי-חריגות. • נשען על ISLM ו-Business AI; שמור אדם-בלולאה.