המלצות לביצועי-מערכת
System Performance Recommendations
הגדרת SAP IBP ל-S&OP · שיעור 8
- ביצועים = מודל רזה + Base level חכם.
- צמצם cross-level calc ונקה נתונים שוטף.
- תזמן Jobs כבדים off-peak ונטר דרך Logs.
מטרת השיעור
ידע אצורביצועי IBP נשענים על מודל-נתונים רזה ועל הגדרות-חישוב חכמות. ההמלצות: מינימום Planning Levels ו-Storage levels, רמת-בסיס לא-דקה-מדי, צמצום cross-level calculations, ניקוי-נתונים שוטף (Data Lifecycle), ותזמון-אופרטורים בחלונות שקטים. מודל מתוכנן-נכון מגיב בשניות; מודל מנופח מגיב בדקות.
למה זה חשוב
ידע אצורכדי ש-IBP יהיה מהיר, שומרים את המודל 'רזה': לא יותר מדי רמות, לא יותר מדי נתונים-שמורים, ולא חישובים כבדים מיותרים. מנקים נתונים ישנים ומריצים פעולות-כבדות בלילה. מודל פשוט = מערכת מהירה.
ערך עסקי
ידע אצורלהבטיח חוויית-תכנון מהירה ויציבה גם בנפחי-נתונים גדולים, ולשמור על עלויות-מערכת ועל זמני-תגובה סבירים לאורך מחזורי-S&OP.
היכן בשימוש
ידע אצור• IBP Web UI ► Configuration ► Key Figures ► review Stored vs Calculated + Base Level • IBP Web UI ► Application Jobs ► schedule heavy operators in off-peak windows • IBP Web UI ► Application Logs / Performance traces ► monitor run times
מושגי מפתח
ידע אצור- ביצועים = מודל רזה + Base level חכם.
- צמצם cross-level calc ונקה נתונים שוטף.
- תזמן Jobs כבדים off-peak ונטר דרך Logs.
דוגמה מ-CBC
ידע אצורבארגון המודל הואט בעונת-הקיץ; הצוות הריץ Purge לתרחישים-ישנים, העלה את רמת-הבסיס של key figures שוליים מ-Day ל-Week, וצמצם cross-level calculations — וזמני-התגובה השתפרו משמעותית. צוות מגלה ש-planning view נטען ב-90 שניות; הם מצמצמים Stored key figures לא-בשימוש, מעלים את ה-base level מ-Day ל-Week, ומוסיפים Filters — זמן-הטעינה יורד ל-8 שניות.
תהליך
ידע אצורטבלאות
ידע אצור| טבלה | תיאור |
|---|---|
| Planning Level | Planning Level |
| Key Figure (metadata) | Key Figure (metadata) |
| Application Log | Application Log |
טרנזקציות
ידע אצוראפליקציות Fiori
ידע אצורקונפיגורציה (SPRO)
ידע אצור• צמצם Planning Levels ו-Stored key figures לנדרש בלבד. • קבע Base level ברזולוציה הנדרשת (לא דק-מדי, למשל Week לא Day). • צמצם cross-level calculations ו-non-base aggregations; פרק נוסחאות ל-Auxiliary. • הרץ Data Lifecycle (Purge/Time-shift) ותזמן Jobs כבדים בלילה.
הערות
ידע אצורנתוני אב • כל Stored key figure ו-Planning Level צורך זיכרון/חישוב. • Base level דק מדי = נפח-נתונים מתפוצץ. שאלות ראיון מהם המנופים העיקריים לשיפור-ביצועי IBP? מודל רזה (מעט levels/Stored KF), Base level לא-דק-מדי, צמצום cross-level calculations, ניקוי-נתונים (Data Lifecycle), תזמון-Jobs off-peak ו-Filters בתצוגות. מדוע Base level דק-מדי פוגע בביצועים? כל ירידה ברזולוציה מכפילה את נפח-הנתונים והחישוב; Day מול Week יכול להגדיל פי-7 את הנפח. נושאים קשורים • S&OP · קונפיגורציה מתקדמת (10.7) • S&OP · רמות תכנון (10.3)
טעויות נפוצות
ידע אצור- Base level ב-Day כשמספיק Week ➔ נפח עצום וביצועים איטיים.
- Stored key figures רבים שאינם בשימוש.
- cross-level calculations כבדים בכל תצוגה.
- תזמון Jobs כבדים בשעות-עומס.
פתרון תקלות
ידע אצור• planning view איטי ➔ יותר מדי key figures/levels או Base level דק; הוסף Filters. • Application Job ארוך ➔ scope רחב מדי או חישוב כבד; צמצם והרץ off-peak. • צריכת-זיכרון גבוהה ➔ נפח-נתונים גדול; הרץ Purge/Time-shift.
שיטות עבודה מומלצות
ידע אצור- שמור מודל רזה — מינימום levels ו-Stored key figures.
- Base level ברזולוציה הנדרשת בלבד.
- נקה נתונים שוטף ותזמן Jobs כבדים בלילה.
- השתמש ב-Filters בתצוגות ונטר זמני-תגובה דרך Logs.
טיפים
ידע אצור- מנופי-ביצועים: (1) מינימום Planning Levels ו-Stored key figures — כל אחד צורך זיכרון/חישוב; (2) Base level ברזולוציה הנדרשת בלבד (לא דק-מדי); (3) צמצום Calculated key figures cross-level ו-non-base aggregations; (4) Data Lifecycle (Purge/Time-shift) להקטנת-נפח; (5) תזמון Application Jobs כבדים בחלונות-לילה; (6) Filters ב-planning views להגבלת-scope; (7) הימנעות מנוסחאות-מורכבות-מדי — פירוק ל-Auxiliary. ניטור דרך Application Logs ו-performance traces. HANA in-memory מהיר, אך מודל-מנופח עדיין יכשל.
סיכום
ידע אצור• ביצועים = מודל רזה + Base level חכם. • צמצם cross-level calc ונקה נתונים שוטף. • תזמן Jobs כבדים off-peak ונטר דרך Logs.