סקירת אפשרויות מימוש

לפני כל פרויקט S/4HANA חייב הארגון לבחור בשני צירים: היכן רצה המערכת (Deployment — Cloud מול On-Premise) וכיצד מגיעים אליה (Transition — מימוש-חדש מול המרת-מערכת). שתי ההחלטות קובעות עלות, מהירות, גמישות-התאמה והיקף-תהליכי-הרכש. החלטה שגויה כאן יקרה לתקן בהמשך — היא משפיעה על שנים של תפעול. אפשרויות פריסה — פריסה (Deployment) קובעת היכן רצה המערכת ומי אחראי על התשתית: On-Premise (במרכז-הנתונים של הארגון), Private Cloud (תשתית-ייעודית מנוהלת תחת RISE with SAP) או Public Cloud (תשתית-משותפת רב-דיירית של SAP). הבחירה משפיעה על שליטה, עלות, מהירות-עדכון וגמישות-התאמה. ענן — במודל-הענן SAP מספקת את התוכנה כשירות מנוהל: תשתית, עדכונים, גיבוי ואבטחה באחריות-הספק. היתרון — האצה, עלות-תפעול נמוכה וחדשנות-תמידית; המחיר — פחות שליטה והתאמה-מוגבלת לתהליכים סטנדרטיים. On-Premise — במודל On-Premise הארגון מתקין ומתחזק את S/4HANA במרכז-הנתונים שלו (או בתשתית-ענן בבעלותו). היתרון — שליטה-מלאה והתאמות-עומק חופשיות; המחיר — אחריות-תפעול מלאה על חומרה, גרסאות, אבטחה ושדרוגים. מימוש חדש מול המרת מערכת — ציר-המעבר: New Implementation (Greenfield) בונה מערכת מאפס עם מודל-תהליכים חדש ונתונים-נקיים; System Conversion (Brownfield) ממיר את ה-ECC הקיים במקומו, משמר התאמות והיסטוריה. הבחירה קובעת היקף-פרויקט, סיכון, משך וניצול-הזדמנות לניקוי-תהליכים.

דמיין שאתה פותח חנות חדשה. שתי שאלות-יסוד: (1) איפה תשב — בבניין משלך שאתה מתחזק (On-Premise), או בקניון מנוהל שבו רק שוכרים מקום (Cloud)? (2) איך תתחיל — מחדש על דף-חלק (New Implementation), או שתעביר את החנות הישנה כמו-שהיא לבניין החדש (System Conversion)? ארבעת השילובים האפשריים הם 'אפשרויות-המימוש'. אפשרויות פריסה — שלוש דרכים לגור: בית פרטי שאתה מתחזק (On-Premise), דירה-שכורה פרטית עם שירות-אחזקה (Private Cloud), או חדר בבית-מלון משותף (Public Cloud). ככל שעולים בסולם — פחות עבודת-תחזוקה אך פחות חופש לשנות. ענן — ענן = שוכרים את המערכת במקום לקנות ולתחזק. SAP דואגת לחומרה, לעדכונים ולגיבוי; אתה מתמקד בתהליכים-העסקיים. כמו לשכור רכב עם שירות-מלא במקום לקנות ולתחזק בעצמך. On-Premise — On-Premise = המערכת 'בבית שלך'. אתה קונה רישיון, מתקין על שרתים שלך, ואחראי על הכל — מהחשמל ועד לעדכון-הגרסה. חופש מלא, אך גם כל העבודה עליך. מימוש חדש מול המרת מערכת — שתי דרכים לעבור לבית-חדש: לארוז הכל ולהעביר כמו-שהוא (Conversion — מהיר, שומר היסטוריה, אך גם את הבלגן הישן), או לקנות רהיטים-חדשים ולהתחיל נקי (New Implementation — הזדמנות-לסדר, אך יותר עבודה).

להעמיד מסגרת-החלטה מסודרת: התאמת דרך-המימוש לאסטרטגיה, לתקציב, ללוח-הזמנים ולמורכבות תהליכי-הרכש הקיימים, במקום לבחור 'כמו שכולם' או 'כמו שהיה'. אפשרויות פריסה — להתאים את מודל-האחריות והגמישות לצרכים: שליטה-מקסימלית מול תחזוקה-מינימלית. ענן — להפחית עומס-IT, להאיץ time-to-value ולקבל חדשנות-רציפה ללא פרויקטי-שדרוג גדולים. On-Premise — לתת שליטה-מקסימלית והתאמה בלתי-מוגבלת היכן שהעסק דורש ייחודיות-תהליכית או ריבונות-נתונים. מימוש חדש מול המרת מערכת — לבחור בין שימור (היסטוריה, התאמות, מהירות) לחידוש (תהליכים-נקיים, פישוט, סטנדרטיזציה).

• SAP S/4HANA ► Implementation Roadmap ► SAP Activate Methodology • Maintenance Planner ► System Conversion Readiness (Pre-Check) • SAP Readiness Check 2.0 ► Deployment & Transition Recommendation • RISE with SAP ► Deployment Model Selection • SAP S/4HANA ► Cloud / On-Premise editions • SAP S/4HANA Cloud ► Subscription & Onboarding • SAP BTP ► Extensibility Services • SAP S/4HANA On-Premise ► Installation Guide • SUM ► Software Update Manager • SAP Activate ► Transition Path: New Implementation • SAP Activate ► Transition Path: System Conversion (SUM/DMO) • Maintenance Planner ► Conversion Pre-Check

• שתי החלטות-יסוד: Deployment ו-Transition — בלתי-תלויות.
• החלטה שגויה כאן יקרה לתקן בהמשך.
• בסס על Fit-to-Standard ו-SAP Readiness Check, לא על הרגל.
• שלושה מודלים: On-Premise, Private Cloud, Public Cloud.
• ככל שמנוהל יותר — פחות תחזוקה, פחות חופש-התאמה.
• ענן = תוכנה-כשירות מנוהל במנוי.
• האצה וחדשנות-רציפה במחיר פחות-שליטה.
• עדכונים רבעוניים ב-Public דורשים אוטומציית-בדיקות.
• On-Premise = שליטה-מלאה והתאמה חופשית.
• כל נטל-התחזוקה על הארגון.
• מתאים לדרישות-התאמה/ריבונות גבוהות.
• שתי דרכי-מעבר: New Implementation (חידוש) מול System Conversion (שימור).
• Conversion = SUM/DMO + התאמת-Z-קוד; New = Fit-to-Standard + Migration Cockpit.
• Selective Data Transition מאזנת בין השתיים.

בארגון (מפעל-בקבוק מוצר לדוגמה): תהליכי-הרכש (חומרי-גלם, אריזה, חלפי-PM) סטנדרטיים ברובם, אך יש אינטגרציות-ספקים ואצוות-מנוהלות ייחודיות. ההחלטה: Private Cloud (RISE with SAP) עם System Conversion — לשמר את ההיסטוריה והאינטגרציות, אך לעבור לתשתית-ענן מנוהלת. ועדת-היגוי ממפה: כמה Z-תהליכים יש ברכש? כמה אינטגרציות לספקים? מה רמת-הסיכון לעצירת-ייצור? לפי התשובות נבחר השילוב — למשל ארגון עם רכש סטנדרטי בוחר Public Cloud + New Implementation; ארגון עם רכש מותאם-מאוד והיסטוריה ארוכה בוחר Private Cloud + System Conversion. אפשרויות פריסה — בארגון נבחר Private Cloud (RISE with SAP) — שילוב של תחזוקה-מנוהלת עם גמישות לשמר את אינטגרציות-הספקים והאצוות הייחודיות לתעשיית-המשקאות. ארגון רב-לאומי עם דרישות-ריבונות-נתונים בוחר Private Cloud באזור-גיאוגרפי מסוים; חברה צעירה עם תהליכים סטנדרטיים בוחרת Public Cloud להאצה ולעלות-תפעול נמוכה. ענן — בארגון מודל-הענן (Private) מסיר מהארגון את תחזוקת-ה-Basis וה-HANA, ומאפשר לצוות-ה-IT להתמקד בתהליכי-הרכש ולא בתשתית. ארגון מאמץ Public Cloud: כל רבעון SAP דוחפת עדכון; צוות-הבדיקות מריץ test automation על תהליכי-הרכש לפני הפעלת-העדכון בפרודקשן. On-Premise — בארגון לא נבחר On-Premise טהור — אך הוא היה החלופה אילו דרישות-הריבונות חייבו אחסון מקומי-מלא; במצב זה כל תחזוקת-ה-Basis הייתה על צוות-ה-IT הפנימי. ארגון-ביטחוני עם דרישות-רגולציה מחמירות מתקין On-Premise באתר-מאובטח, מבצע התאמות-Z עמוקות ושולט במלואו במועדי-השדרוג. מימוש חדש מול המרת מערכת — בארגון נבחר System Conversion — שימור אינטגרציות-הספקים, היסטוריית-רכש ואצוות-מנוהלות, תוך מעבר ל-S/4HANA והפעלת Material Ledger החובה. ארגון עם Z-רכש מועט וחזון תהליכי-חדש בוחר New Implementation: מגדיר תהליכי-רכש מ-Best Practices, מעביר רק נתוני-אב פעילים. ארגון עם התאמות-עומק והיסטוריה ארוכה בוחר System Conversion: מריץ SUM/DMO ומתאים את ה-Z-קוד.

• החלטה ולא קונפיגורציה: בחר Deployment (Cloud Public / Cloud Private / On-Premise) ו-Transition (New Implementation / System Conversion / Selective). • הרץ SAP Readiness Check על ה-ECC הקיים לקבלת המלצת-מעבר מבוססת-נתונים. אפשרויות פריסה • החלטה ארכיטקטונית: בחר On-Premise / Private Cloud / Public Cloud לפי שליטה, עלות וגמישות-התאמה נדרשת. ענן • מודל-מנוי (subscription); הרחבה דרך key-user extensibility ו-side-by-side על SAP BTP; עדכונים מנוהלים על-ידי SAP. On-Premise • רישוי perpetual; התקנה ותחזוקה עצמית; שדרוגים בשליטת-הארגון דרך SUM; התאמות-Z חופשיות. מימוש חדש מול המרת מערכת • New Implementation: Fit-to-Standard ► Data Migration (Migration Cockpit) ► Activation. • System Conversion: Pre-Checks (Maintenance Planner) ► SUM with DMO ► Custom Code Adaptation (SPDD/SPAU + ATC) ► Simplification Items.

נתוני אב • אין נתוני-אב בשלב-ההחלטה; ההחלטה קובעת אֵיך ינוהלו נתוני-האב בהמשך (טעינה-חדשה מול המרה). • New Implementation: טעינת נתוני-אב נקייה דרך Migration Cockpit (LTMC). • System Conversion: נתוני-האב והתנועות נשמרים במקום; Business Partner ו-Material Ledger הופכים mandatory ב-S/4. שאלות ראיון מהם שני הצירים העצמאיים בבחירת אפשרות-מימוש? Deployment (היכן: Cloud Public/Private או On-Premise) ו-Transition (כיצד: New Implementation מול System Conversion). הם בלתי-תלויים זה בזה. כיצד מבססים את ההחלטה על נתונים? מריצים SAP Readiness Check על ה-ECC הקיים — הוא מנתח Z-objects, simplification items והתאמות, ומפיק המלצת-מעבר. מה ההבדל בין Private ל-Public Cloud ב-S/4HANA? Private = תשתית-ייעודית מנוהלת (RISE with SAP) עם היקף-פונקציונלי כמעט-מלא וחלון-שדרוג גמיש; Public = רב-דיירי, Best Practices בלבד, עדכונים רבעוניים כפויים והרחבה מוגבלת. מהו ההבדל המהותי בין ענן ל-On-Premise מבחינת אחריות? בענן SAP/Hyperscaler אחראים על תשתית, עדכונים, גיבוי ואבטחה; ב-On-Premise כל אלה באחריות הארגון. מתי On-Premise עדיף על ענן? כשנדרשות התאמות-עומק בלתי-מוגבלות, ריבונות-נתונים מחמירה או שליטה-מלאה במועדי-שדרוג, והארגון מוכן לשאת בנטל-התחזוקה. מה ההבדל בין Greenfield ל-Brownfield? Greenfield (New Implementation) בונה מאפס עם תהליכים-חדשים ונתונים-נקיים; Brownfield (System Conversion) ממיר את ה-ECC במקומו ושומר התאמות והיסטוריה. מהו SUM with DMO? Software Update Manager עם Database Migration Option — כלי שמבצע המרת-DB ל-HANA ושדרוג ל-S/4HANA בצעד-טכני אחד, בליבת ה-System Conversion. מהי Selective Data Transition? גישת-ביניים בין Greenfield ל-Brownfield — בונים shell חדש ומעבירים נתונים סלקטיבית (חברות/טווחי-זמן נבחרים), מאזנת בין ניקוי לשימור-היסטוריה. נושאים קשורים • MM · On-Premise S/4HANA (2.2) • MM · SAP S/4HANA Cloud (2.3) • MM · System Conversion (2.2.6) • MM · SAP Activate (2.5.4)

• ועדת-ההיגוי תקועה בהחלטה ➔ הרץ SAP Readiness Check לקבלת בסיס-נתונים אובייקטיבי. • ספק שאינו תומך ב-API ענני ➔ שקול Private Cloud / On-Premise במקום Public. • אי-בהירות על עלות-התאמות ➔ מפה Fit-to-Standard מול ה-Best Practices לפני בחירה. אפשרויות פריסה • דרישת-התאמה לא נתמכת ב-Public ➔ עבור ל-Private Cloud / On-Premise. • עומס-תחזוקה גבוה ב-On-Premise ➔ שקול מעבר ל-RISE with SAP. ענן • עדכון רבעוני שובר תהליך ➔ הקם test automation ובדיקות-רגרסיה לפני הפעלה. • צורך-התאמה חורג ➔ עבור ל-Private Cloud. On-Premise • עומס-תחזוקה גבוה מדי ➔ שקול מעבר ל-RISE with SAP (Private Cloud). • פיגור-גרסאות מצטבר ➔ תכנן SUM שגרתי. מימוש חדש מול המרת מערכת • Conversion נכשל ב-Pre-Check ➔ טפל ב-Simplification Items ובהתאמות לפני SUM. • Z-קוד שבור אחרי המרה ➔ הרץ ATC מול Simplification Database ותקן ב-SPAU. • נתונים מלוכלכים נגררו ➔ שקול Selective Data Transition עם ניקוי-סלקטיבי.

• שתי החלטות-יסוד: Deployment ו-Transition — בלתי-תלויות. • החלטה שגויה כאן יקרה לתקן בהמשך. • בסס על Fit-to-Standard ו-SAP Readiness Check, לא על הרגל. • שלושה מודלים: On-Premise, Private Cloud, Public Cloud. • ככל שמנוהל יותר — פחות תחזוקה, פחות חופש-התאמה. • ענן = תוכנה-כשירות מנוהל במנוי. • האצה וחדשנות-רציפה במחיר פחות-שליטה. • עדכונים רבעוניים ב-Public דורשים אוטומציית-בדיקות. • On-Premise = שליטה-מלאה והתאמה חופשית. • כל נטל-התחזוקה על הארגון. • מתאים לדרישות-התאמה/ריבונות גבוהות. • שתי דרכי-מעבר: New Implementation (חידוש) מול System Conversion (שימור). • Conversion = SUM/DMO + התאמת-Z-קוד; New = Fit-to-Standard + Migration Cockpit. • Selective Data Transition מאזנת בין השתיים.