SAP S/4HANA Cloud

SAP S/4HANA Cloud (public edition) היא מהדורת-SaaS רב-דיירית המבוססת על SAP Best Practices: היקף-תהליכים מוגדר-מראש, Fiori, עדכונים רבעוניים אוטומטיים והרחבה מבוקרת. בתחום-הרכש היא מספקת תהליכי-best-practice סטנדרטיים עם time-to-value מהיר, אך בהתאמה-מוגבלת. היקף SAP Best Practices — ה-scope של Public Cloud מוגדר על-ידי SAP Best Practices — חבילת scope items מוכנים-לרוץ המכסים תהליכי-רכש סטנדרטיים (r.requisition-to-pay, source-to-contract). מה שאינו ב-scope אינו זמין במהדורה זו; זו נקודת-המוצא של כל פרויקט-ענן. שיקולי IT — ב-Public Cloud רוב נטל-ה-IT עובר ל-SAP: תשתית, גיבוי, HA/DR, אבטחת-תשתית ועדכונים מנוהלים על-ידי הספק. הארגון מתמקד באבטחת-יישום (roles), בניהול-העדכון-הרבעוני, ובאינטגרציה — שינוי-מהותי בתפקיד-ה-IT לעומת On-Premise. אינטגרציה והתאמה סטנדרטיות — ב-Public Cloud האינטגרציה וההתאמה מתבצעות בדרכים-מבוקרות-ומתועדות בלבד: אינטגרציה דרך SAP Integration Suite ו-published APIs, והתאמה דרך key-user extensibility (in-app), developer extensibility (restricted ABAP) ו-side-by-side על SAP BTP. אין modifications לליבה.

S/4HANA Cloud (public) = הגרסה ה'מוכנה-לשימוש' של SAP בענן. מקבלים תהליכים סטנדרטיים מומלצים, ממשק-Fiori יפה, ו-SAP מעדכנת לבד כל רבעון. פחות התאמה אישית — אבל מהיר וזול-תפעולית. היקף SAP Best Practices — ה-scope = 'התפריט' של Public Cloud — אוסף תהליכים-מוכנים ש-SAP בנתה. כל תהליך-רכש שמופיע בו זמין מיד; מה שלא — לא קיים במהדורה זו. שיקולי IT — בענן-ציבורי, ה-IT 'הכבד' הוא של SAP. הצוות הפנימי כבר לא מתחזק שרתים — אלא מנהל הרשאות, בודק עדכונים, ומחבר מערכות. פחות תחזוקה-טכנית, יותר ניהול-תהליך. אינטגרציה והתאמה סטנדרטיות — אפשר להתאים ולחבר — אך רק ב'דרכים המאושרות'. מוסיפים שדות וטפסים דרך כלי key-user, מפתחים תוספות נפרדות על BTP, ומחברים מערכות דרך Integration Suite. את הליבה עצמה לא נוגעים.

לספק מערכת-רכש מודרנית במהירות ובעלות-תפעול נמוכה, לארגונים שתהליכיהם תואמים-במידה-רבה ל-Best Practices. היקף SAP Best Practices — לספק בסיס-תהליכים מוכח-ומתועד שמאיץ הקמה ומבטיח עקביות ועדכניות. שיקולי IT — להפחית עומס-תפעולי ולמקד את ה-IT בערך-עסקי (תהליך, אינטגרציה, אבטחת-גישה) במקום בתחזוקת-תשתית. אינטגרציה והתאמה סטנדרטיות — לאפשר התאמה ואינטגרציה מבלי לשבור את ה-upgrade האוטומטי — extensibility שנשמרת בין עדכונים-רבעוניים.

• SAP S/4HANA Cloud (public edition) ► SAP Best Practices Explorer • Central Business Configuration ► Scope & Configure • SAP Activate ► Cloud Roadmap • SAP Best Practices Explorer ► SAP S/4HANA Cloud ► Sourcing and Procurement • Manage Your Solution ► Configure Your Solution • SAP Cloud Identity Services (IAS/IPS) • Maintain Business Roles • SAP Cloud ALM ► Test Automation • Custom Fields and Logic • Custom Business Objects • SAP BTP ► ABAP Environment / CAP • SAP API Business Hub

• Public Cloud = SaaS מבוסס Best Practices, time-to-value מהיר.
• התאמה-מבוקרת בלבד (key-user / BTP), עדכונים רבעוניים כפויים.
• קונפיגורציה דרך Central Business Configuration.
• scope items = הבסיס המוגדר-מראש ל-Public Cloud.
• כל item נושא test script ו-config.
• Best Practices Explorer = הקטלוג.
• רוב נטל-ה-IT עובר ל-SAP.
• לקוח אחראי על roles, identity, אינטגרציה ו-test automation.
• test automation חיוני לחלון-העדכון הרבעוני.
• התאמה בדרכים-מבוקרות בלבד: key-user, developer (restricted), side-by-side.
• אינטגרציה דרך released APIs + Integration Suite.
• הכל upgrade-stable; אין modifications.

בארגון (מוצר לדוגמה) ה-Public Cloud לא נבחר לליבה (בשל אינטגרציות ואצוות-ייחודיות), אך Best-Practice scope items שימשו כבסיס-עיצוב גם תחת ה-Private Cloud — 'fit-to-standard first'. חברה צעירה מאמצת Public Cloud: מפעילה scope items לרכש סטנדרטי, מבצעת Fit-to-Standard, מגדירה דרך הארגון, ועולה-לאוויר תוך חודשים — עם עדכונים-רבעוניים אוטומטיים. היקף SAP Best Practices — בארגון scope items לרכש-ישיר ועקיף שימשו כבסיס-עיצוב; הצוות בחן אותם ב-Best Practices Explorer לפני קונפיגורציה. צוות-הרכש בוחן את scope item J45, מריץ את test script המצורף, ומאשר שהוא תואם את תהליך-הרכש-הישיר — או מזהה פער לטיפול. שיקולי IT — בארגון המודל-הענני (גם תחת Private) הפחית את עומס-ה-IT התשתיתי; הצוות התמקד בהרשאות-רכש (SOD), באינטגרציות ובבדיקות-עדכון. צוות-ה-IT מגדיר business roles דרך business catalogs, מחבר identity ל-IAS, ומריץ test automation לפני כל עדכון-רבעוני — ללא נגיעה בתשתית. אינטגרציה והתאמה סטנדרטיות — בארגון הרחבות-רכש (שדות ולוגיקה) תוכננו דרך key-user extensibility; אינטגרציות-הספקים דרך Integration Suite — שמירה על upgrade-stability. הוספת שדה לרכש: דרך key-user Custom Fields and Logic; הוספת לוגיקה דרך BAdI ב-Custom Logic app; חיבור לספק דרך Integration Suite — הכל נשמר אחרי ה-upgrade.

• מבוסס SAP Best Practices (scope items); קונפיגורציה דרך Central Business Configuration. • Extensibility: key-user (in-app) + developer extensibility (restricted) + side-by-side על SAP BTP. • Quarterly upgrades אוטומטיים; landscape מנוהל (2/3-system). היקף SAP Best Practices • בחר scope items מ-SAP Best Practices Explorer; הם נושאים test scripts ו-config מוכן. הרחבה ל-extensibility בלבד. שיקולי IT • אחריות-לקוח: business roles, identity (IAS/IPS), integration, test automation, data protection. אחריות-SAP: תשתית, HA/DR, גיבוי ועדכונים. אינטגרציה והתאמה סטנדרטיות • התאמה: key-user (in-app) + developer extensibility (restricted ABAP) + side-by-side (BTP). אינטגרציה: published APIs + Integration Suite. ללא modifications.

נתוני אב • Business Partner ל-supplier; Material Master דרך Fiori / migration template. • טעינת-נתונים דרך Migrate Your Data (cloud migration cockpit, templates). שאלות ראיון על מה מבוססת S/4HANA Cloud (public)? על SAP Best Practices (scope items) — תהליכים סטנדרטיים מוגדרים-מראש, multi-tenant, עם עדכונים רבעוניים אוטומטיים והרחבה מבוקרת. מהו כלי-הקונפיגורציה המרכזי ב-Public Cloud? Central Business Configuration — שדרכו מגדירים scope ופרמטרים, כ-single source לקונפיגורציה הענן. מה מגדיר את ה-scope של Public Cloud? SAP Best Practices — אוסף scope items מוכנים-לרוץ עם test scripts ו-config; מה שאינו ב-scope items אינו זמין במהדורה. כיצד משתנה תפקיד-ה-IT ב-Public Cloud לעומת On-Premise? תשתית, HA/DR, גיבוי ועדכונים עוברים ל-SAP; הלקוח מתמקד ב-business roles, identity, אינטגרציה ו-test automation — פחות תחזוקה-טכנית, יותר ניהול-תהליך ואבטחת-גישה. אילו סוגי-extensibility קיימים ב-Public Cloud? key-user / in-app (custom fields, logic, forms), developer extensibility (restricted ABAP Cloud על released APIs), ו-side-by-side על SAP BTP. אין modifications לליבה. מדוע חשוב להשתמש ב-released APIs בלבד? כדי לשמור על upgrade-stability — הרחבות על released APIs/extensibility שורדות את העדכונים הרבעוניים, בעוד שימוש ב-API לא-released עלול להישבר. נושאים קשורים • MM · ענן (2.1.2) • MM · SAP Best Practices (2.5.2) • MM · אפשרויות אינטגרציה (2.2.5)

• התאמה לא-נתמכת ➔ עבור ל-side-by-side על BTP או שקול Private Cloud. • תהליך נשבר אחרי עדכון ➔ הקם test automation לתהליכי-רכש קריטיים. • scope חסר ➔ בדוק זמינות-scope-item במהדורת-הענן הרלוונטית. היקף SAP Best Practices • תהליך-רכש חסר ➔ בדוק זמינות scope item; אם אין — שינוי-תהליך או BTP. • אי-ודאות על כיסוי ➔ עיין ב-Best Practices Explorer. שיקולי IT • משתמש חסר-הרשאה ➔ בדוק business role / restriction / IAS. • עדכון שובר תהליך ➔ הרחב test automation. אינטגרציה והתאמה סטנדרטיות • הרחבה נשברה אחרי upgrade ➔ ודא שימוש ב-released APIs/extensibility בלבד. • API חסר ➔ בדוק SAP API Business Hub לזמינות.

• Public Cloud = SaaS מבוסס Best Practices, time-to-value מהיר. • התאמה-מבוקרת בלבד (key-user / BTP), עדכונים רבעוניים כפויים. • קונפיגורציה דרך Central Business Configuration. • scope items = הבסיס המוגדר-מראש ל-Public Cloud. • כל item נושא test script ו-config. • Best Practices Explorer = הקטלוג. • רוב נטל-ה-IT עובר ל-SAP. • לקוח אחראי על roles, identity, אינטגרציה ו-test automation. • test automation חיוני לחלון-העדכון הרבעוני. • התאמה בדרכים-מבוקרות בלבד: key-user, developer (restricted), side-by-side. • אינטגרציה דרך released APIs + Integration Suite. • הכל upgrade-stable; אין modifications.