מודל התכנון

מודל-התכנון (planning model) הוא לב-ליבו של SAP IBP — מערך אבני-הבניין המגדירות אילו נתונים נשמרים, באיזו רזולוציה, ומה מחשבים מהם. אבני-הבניין הן: attributes (תכונות), master data types (סוגי נתוני-אב), time profiles (פרופילי-זמן), planning area (אזור-התכנון המאחד הכול), planning levels (רמות-תכנון), ו-key figures (מדדים). הבנת המודל = הבנת המוצר כולו, כי כל תצוגה, כל חישוב וכל דוח נגזרים ממנו. תכונות (Attributes) — Attribute הוא אבן-הבניין הקטנה ביותר במודל — שדה-יסוד המתאר מאפיין עסקי, כמו Product ID, Location ID, Customer ID או Brand. כל master data type, כל planning level וכל key figure מורכבים בסופו-של-דבר מ-attributes. הגדרה נכונה שלהם (שם, סוג-נתון, אורך) היא היסוד שעליו נשען כל המודל. סוגי נתוני-אב (Master Data Types) — master data type הוא הקבוצה המאגדת attributes למבנה נתוני-אב בעל-משמעות, כמו Product, Location או Customer. הוא קובע אילו attributes מהווים מפתח (key) ואילו תיאוריים, וכיצד נתוני-האב מאוחסנים ומקושרים. ב-IBP חמישה סוגים: simple, compound, reference, external ו-virtual — לכל אחד תפקיד מובחן. פרופילי-זמן (Time Profiles) — time profile מגדיר את ציר-הזמן של המודל — את היררכיית-התקופות שעליהן נשמרים ומחושבים ה-key figures, למשל Technical Week → Month → Quarter → Year. הוא קובע את הרזולוציה-הזמנית של כל התכנון, ולכן הוא החלטה-אסטרטגית: שינויו לאחר טעינת-נתונים קשה ויקר. אזורי-תכנון (Planning Areas) — planning area הוא המכולה המרכזית של המודל — הוא מאחד את ה-attributes, master data types, time profile, planning levels ו-key figures למודל-תכנון אחד שלם ופעיל. כל פעולה ב-IBP (תצוגה, חישוב, דוח) מתבצעת בהקשר של planning area. ה-planning area לדוגמה SAPIBP1 הוא נקודת-המוצא המומלצת לכל מימוש. רמות-תכנון (Planning Levels) — planning level הוא צירוף של attributes ושל time profile level, המגדיר את הרזולוציה שבה נשמר או מחושב key figure — לדוגמה Product-Customer-Month. הוא הגשר בין נתוני-האב לבין המספרים: ה-base planning level קובע את הרמה הבסיסית של אחסון, ורמות-אחרות משמשות לצבירה (aggregation) ולפירוק (disaggregation). מדדים (Key Figures) — key figure הוא 'המספר' שמתכננים — תחזית, מלאי-בטחון, אספקה, consensus demand, capacity. זהו האובייקט המרכזי שהמשתמש רואה ועורך בתצוגות. כל key figure מוגדר עם base planning level, כללי aggregation/disaggregation, ולעיתים calculation (נגזר מ-key figures אחרים). הבנת ה-key figures = הבנת מה המודל בעצם מודד. גרסאות ותרחישים מוגדרי-משתמש — versions ו-scenarios מאפשרים תכנון 'מה-אם' (what-if) בלי לפגוע בתכנית-הבסיס. version היא עותק מלא של נתוני-ה-key figures (לדוגמה Baseline מול Budget); scenario הוא שכבת-סימולציה קלת-משקל מעל גרסה, שבה התכנן מנסה שינויים ומשווה לפני אימוץ. שניהם חיוניים ל-S&OP, שבו דנים בחלופות לפני החלטה. תמיכה רב-לשונית לאובייקטי-מידול — IBP תומך בתרגום של תיאורי אובייקטי-המידול (attributes, key figures, planning levels וכו') למספר שפות, כך שמשתמשים גלובליים רואים את המודל בשפתם בעוד ה-Attribute ID / Key Figure ID הטכני נשאר אנגלי-אחיד. זו דרישה מעשית בארגון רב-לאומי, ומאפשרת אימוץ-משתמשים רחב ללא פגיעה בעקביות-המודל.

חשוב על המודל כמו על בניית-מסד-נתונים מסודר. קודם מגדירים 'מילים' קטנות — attributes (כמו Product, Location, Customer). אחר-כך מקבצים אותן ל-master data types (טבלאות נתוני-אב). מגדירים ציר-זמן (time profile). מאחדים את הכול ל-planning area אחד. בתוכו קובעים planning levels — רמות-הצבירה (לפי מוצר, לפי לקוח, לפי חודש). ולבסוף key figures — המספרים שמתכננים: תחזית, מלאי, אספקה. כל אבן-בניין נשענת על הקודמת. תכונות (Attributes) — attribute הוא פשוט 'עמודה' — שם של שדה ומה הוא מכיל. למשל attribute בשם PRDID מכיל מזהה-מוצר, attribute בשם LOCID מכיל מזהה-מיקום. אלה הלבנים הקטנות; מהן בונים את כל השאר. סוגי נתוני-אב (Master Data Types) — אם attribute הוא עמודה, master data type הוא הטבלה. למשל master data type בשם Product מכיל את העמודות PRDID, BRANDID, PRDFAMILY. הוא מארגן את ה-attributes למבנה שלם שאפשר לטעון אליו ערכים אמיתיים. פרופילי-זמן (Time Profiles) — time profile הוא 'הסרגל-הזמני' של המודל — הוא קובע אם מתכננים לפי שבוע, חודש, רבעון או שנה, וכיצד הם מתקפלים זה לתוך זה. כמו סרגל מדורג: השבועות מתקבצים לחודשים, החודשים לרבעונים, הרבעונים לשנים. אזורי-תכנון (Planning Areas) — planning area הוא 'הספר השלם' שאוסף את כל הפרקים: התכונות, נתוני-האב, ציר-הזמן, רמות-הצבירה והמדדים. כל מה שמתכננים — קורה בתוך planning area אחד. SAP נותנת ספר-דוגמה מוכן בשם SAPIBP1 שמשכפלים ומתאימים. רמות-תכנון (Planning Levels) — planning level עונה על השאלה 'באיזו רזולוציה?'. למשל: לתכנן תחזית לפי מוצר-לקוח-חודש, או רק לפי מוצר-שנה. כל key figure 'יושב' על planning level שקובע כמה מפורט הוא — וממנו אפשר לעלות (לצבור) או לרדת (לפרק). מדדים (Key Figures) — key figure הוא פשוט מדד-מספרי: 'כמה צופים למכור', 'כמה מלאי יש', 'כמה לייצר'. אלה התאים שהתכנן ממלא או רואה ב-Excel. כל מדד יודע באיזו רזולוציה הוא נשמר, ואם הוא נגזר ממדדים אחרים בנוסחה. גרסאות ותרחישים מוגדרי-משתמש — version היא כמו 'קובץ-שמירה בנפרד' של כל המספרים — אפשר להחזיק 'תכנית-בסיס' ו'תקציב' זה-לצד-זה. scenario הוא 'מצב-ניסוי' זמני מעל גרסה: 'מה יקרה אם המכירות יגדלו ב-10%?' — בודקים בלי לשנות את האמת, ואם אוהבים — מאמצים. תמיכה רב-לשונית לאובייקטי-מידול — השם-הטכני של כל אובייקט נשאר באנגלית (כדי שהמערכת תזהה אותו), אבל ה-תיאור (מה שהמשתמש קורא) אפשר לתרגם — לעברית, לגרמנית, לכל שפה. כך תכנן בישראל רואה תיאור-עברית ותכנן בגרמניה רואה גרמנית, אך שניהם עובדים על אותו key figure.

המטרה: להגדיר מבנה-נתונים גמיש המשרת את כל תהליכי-התכנון (demand, supply, inventory, S&OP) במודל אחד עקבי, כך שמספר אחד מחושב פעם אחת ומשמש את כולם — ללא כפילות וללא אי-התאמות. תכונות (Attributes) — המטרה: לתקנן את אוצר-המילים של המודל — כל מאפיין-עסקי מוגדר פעם אחת ומשמש בכל מקום, כך שאין שני שדות-שונים לאותו מושג. סוגי נתוני-אב (Master Data Types) — המטרה: לארגן את ה-attributes למבני נתוני-אב עקביים שאליהם נטענים הערכים האמיתיים, ושעליהם נבנות רמות-התכנון וה-key figures. פרופילי-זמן (Time Profiles) — המטרה: לקבוע את הרזולוציה-הזמנית האחידה של כל התכנון, כך שתחזית, אספקה ומלאי כולם מדברים באותן תקופות-זמן ומתקפלים זה לתוך זה בעקביות. אזורי-תכנון (Planning Areas) — המטרה: לספק single source of truth — מודל אחד שבו כל תהליכי-התכנון חולקים את אותם נתוני-אב, ציר-זמן ו-key figures, כך שמספר מחושב פעם אחת ומשמש את כולם. רמות-תכנון (Planning Levels) — המטרה: לאפשר אחסון-נתונים ברמת-פירוט אחת, וצפייה/חישוב במגוון-רמות, בלי לאחסן כל צירוף בנפרד — חיסכון בנפח ועקביות בצבירה. מדדים (Key Figures) — המטרה: לייצג כל גודל-תכנוני כמדד-יחיד עם התנהגות-צבירה ופירוק עקבית, כך שהמשתמש עורך במספר אחד וכל הרמות מתעדכנות נכון. גרסאות ותרחישים מוגדרי-משתמש — המטרה: לאפשר ניתוח-חלופות והשוואה לפני-החלטה — לב תהליך ה-S&OP — בלי לסכן את תכנית-הבסיס, ולתעד תרחישים שונים זה-מול-זה. תמיכה רב-לשונית לאובייקטי-מידול — המטרה: לאפשר אימוץ-משתמשים גלובלי — כל משתמש רואה את המודל בשפתו — תוך שמירה על ID-טכני אחיד שאינו תלוי-שפה, למניעת כפילות ובלבול.

• Web UI ► Configuration ► Planning Areas ► לצפייה ובנייה של המודל • Web UI ► Configuration ► Attributes / Master Data Types / Time Profiles • Web UI ► Configuration ► Copy Planning Area ► שכפול SAPIBP1 כבסיס • Web UI ► Configuration ► Attributes ► New ► הגדרת Attribute ID, Data Type, Length • Web UI ► Configuration ► Attributes ► Copy ► שכפול attribute מ-SAPIBP1 • Web UI ► Configuration ► Master Data Types ► New ► בחירת Type (simple/compound/reference/external/virtual) • Web UI ► Configuration ► Master Data Types ► שיוך attributes כ-key / non-key • Web UI ► Configuration ► Time Profiles ► New ► הגדרת Levels (Year/Quarter/Month/Week) • Web UI ► Configuration ► Time Profiles ► Generate Time Profile Data ► יצירת תקופות בפועל • Web UI ► Configuration ► Planning Areas ► Copy ► שכפול SAPIBP1 • Web UI ► Configuration ► Planning Areas ► Edit ► שיוך master data, time profile, key figures • Web UI ► Configuration ► Planning Areas ► Activate ► הפעלת המודל • Web UI ► Configuration ► Planning Levels ► New ► בחירת attributes + time profile level • Web UI ► Configuration ► Key Figures ► שיוך base planning level • Web UI ► Configuration ► Key Figures ► New ► base planning level + aggregation • Web UI ► Configuration ► Key Figures ► Calculations ► הגדרת נוסחה מ-KF אחרים • Web UI ► Configuration ► Key Figures ► Disaggregation ► בחירת בסיס-פירוק • Web UI ► Configuration ► Planning Areas ► Versions ► הגדרת/העתקת versions • Excel add-in ► Scenarios ► Create Scenario ► יצירת תרחיש מעל version • Excel add-in ► Scenarios ► Compare / Adopt ► השוואה ואימוץ • Web UI ► Configuration ► Attributes / Key Figures ► Translation ► תחזוקת תיאורים בשפות • Excel add-in / Web UI ► Logon Language ► קובע את שפת-התצוגה של התיאורים

• המודל = attributes, master data types, time profile, planning area, planning levels, key figures.
• סדר-הבנייה היררכי; כל אבן נשענת על הקודמת.
• שכפל את SAPIBP1, בדוק-עקביות, והפעל (Activate) בכל שינוי.
• attribute = שדה-יסוד; הלבנה הקטנה של המודל.
• מוגדר עם ID, Data Type, Length.
• השתמש-מחדש בקיימים מ-SAPIBP1; הימנע מכפילים.
• master data type = הטבלה המאגדת attributes.
• חמישה סוגים: simple/compound/reference/external/virtual.
• חייב להיות משויך ל-planning area כדי לשמש.
• time profile = ציר-הזמן והיררכיית-התקופות של המודל.
• planning area אחד מקושר ל-time profile אחד.
• קבע נכון מההתחלה; שינוי מאוחר יקר.
• planning area = המודל השלם והפעיל; הקשר לכל פעולה.
• שכפל את SAPIBP1 ואל תבנה מאפס.
• Consistency check + Activate חובה לפני שימוש.
• planning level = רזולוציה (attributes + time level).
• base planning level = רמת-האחסון הפיזית.
• צבירה/פירוק מאפשרים צפייה במגוון-רמות מאחסון-יחיד.
• key figure = המספר שמתכננים; האובייקט המרכזי בתצוגה.
• מוגדר עם base planning level, aggregation, disaggregation.
• stored מול calculated — איזון בין אחסון לזמן-ריצה.
• version = עותק-נתונים מלא; scenario = שכבת-סימולציה מעל version.
• scenarios לעבודת-תכנן; versions למבנה (Budget/Forecast).
• adopt מכניס תרחיש מוצלח חזרה לתכנית.
• תיאורים מתורגמים; ID טכני נשאר אנגלי-קבוע.
• התצוגה לפי logon language.
• תרגום-מלא מקדם אימוץ-משתמשים גלובלי.

בארגון המודל כולל attributes: Product (SKU משקה), Location (מפעל/DC), Customer (רשת-קמעונאות), Brand. נתוני-האב נטענים מ-S/4HANA, ציר-הזמן חודשי-שבועי, וה-planning area משוכפל מ-SAPIBP1 ומותאם לעולם-המשקאות. יועם בונה מודל-demand: מגדיר attributes (PRDID, LOCID, CUSTID), יוצר master data types לכל אחד, קושר time profile חודשי, מאחד ב-planning area, מגדיר planning level לפי Product-Customer-Month, ועליו key figure בשם CONSENSUSDEMAND. מרגע זה כל תצוגה ב-Excel נשענת על אותו מבנה. תכונות (Attributes) — בארגון ה-attributes הם: PRDID (SKU כמו 'Drink-1.5L'), LOCID (מפעל/DC), CUSTID (רשת), BRANDID (Example Product / Fanta / Sprite), PACKTYPE (בקבוק/פחית). כולם באנגלית מקור. יועם יוצר attribute חדש BRANDID (NVARCHAR אורך 20) לתיאור-מותג, ואז משייך אותו ל-master data type של המוצר, כדי לאפשר תכנון-לפי-מותג בהמשך. סוגי נתוני-אב (Master Data Types) — בארגון: master data type מסוג simple בשם Product (PRDID + BRANDID + PACKTYPE), simple בשם Location (LOCID), ו-compound בשם Customer-Product לתכנון-לקוח-מוצר. כולם נטענים מ-S/4HANA דרך CI-DS. יועם יוצר master data type מסוג simple בשם Product עם key attribute PRDID ועם attributes תיאוריים BRANDID, PRDFAMILY; טוען אליו את רשימת-המוצרים מ-S/4HANA; וכעת אפשר לתכנן לפי מוצר. פרופילי-זמן (Time Profiles) — בארגון ה-time profile שבועי-חודשי: תכנון-תפעולי שבועי לקווי-המילוי, ו-S&OP חודשי-רבעוני להנהלה. עונתיות-המשקאות (קיץ) ניכרת ברזולוציה החודשית. מודל-demand נשמר ברמת-חודש; ה-time profile מקפל את החודשים לרבעונים ולשנים אוטומטית, כך שמנהל רואה consensus ברמת-רבעון בלי חישוב-ידני. אזורי-תכנון (Planning Areas) — בארגון ה-planning area ZIBP_MFG משוכפל מ-SAPIBP1, כולל demand, supply ו-inventory; מותאם ל-SKU-משקאות, מפעלים-DC, ורשתות-קמעונאות; ומשמש את כל מדינות-האזור על מודל-אחד. צוות-מימוש משכפל את SAPIBP1 ל-planning area חדש ZIBP_MFG, מסיר key figures לא-רלוונטיים, מוסיף BRANDID, מריץ consistency check, ומפעיל (Activate). מאותו רגע התכננים עובדים מולו ב-Excel. רמות-תכנון (Planning Levels) — בארגון: base planning level = Product-Location-Customer-Week לתכנון-תפעולי; רמות-צבירה = Brand-Region-Month ל-S&OP. אותו מספר נראה בכל רמה בעקביות. key figure של תחזית נשמר ב-base planning level של Product-Customer-Month; מנהל פותח תצוגה ברמת-Brand-Quarter — IBP מצבר אוטומטית מהרמה-הבסיסית לרמה-המבוקשת. מדדים (Key Figures) — בארגון ה-key figures כוללים: STATISTICALFORECAST (תחזית-בסיס), CONSENSUSDEMAND (מוסכם), SAFETYSTOCK, PROJECTEDINVENTORY, SUPPLYPLAN. uplift-קיץ מוזן כ-key figure-תוספת ומחובר לתחזית-הבסיס. key figure בשם CONSENSUSDEMAND נערך ברמת Product-Customer-Month; key figure מחושב TOTALDEMAND = CONSENSUSDEMAND + PROMOTIONUPLIFT מתעדכן אוטומטית; פירוק לשבועות נעשה לפי PROPORTIONALFACTOR. גרסאות ותרחישים מוגדרי-משתמש — בארגון: version 'Baseline' מול 'Budget' לשנה; לקראת-קיץ התכנן בונה scenario 'Heatwave +15%' לבדיקת-מוכנות קווי-המילוי, ומשווה למלאי-הצפוי לפני אימוץ. בישיבת-S&OP התכנן יוצר scenario 'High Growth' מעל ה-Baseline, מעלה תחזית ב-10%, משווה side-by-side את ההשפעה על המלאי והאספקה, וכשמתקבלת החלטה — מאמץ (adopt) את ה-scenario ל-version. תמיכה רב-לשונית לאובייקטי-מידול — בארגון הרב-לאומי: תכננים בעברית, ערבית, אנגלית ויוונית רואים תיאורים מתורגמים של אותם key figures (CONSENSUSDEMAND, SAFETYSTOCK), והדיווח-האזורי עקבי כי ה-ID זהה לכולם. המודל מתוחזק עם Key Figure ID = CONSENSUSDEMAND; התיאור מתורגם ל'ביקוש מוסכם' (HE), 'Consensus Demand' (EN), 'Konsensbedarf' (DE). כל משתמש רואה את שפתו, החישוב זהה.

• סדר-בנייה: attributes → master data types → time profile → planning area → planning levels → key figures. • Sample content: שכפל את ה-planning area SAPIBP1 כנקודת-מוצא במקום לבנות מאפס. • Activation: כל שינוי-מודל דורש Activate ל-planning area כדי שייכנס לתוקף. • Consistency check: הרץ בדיקת-עקביות לפני הפעלה כדי לאתר תלויות-חסרות. תכונות (Attributes) • Attribute ID + Description: שם טכני באנגלית + תיאור קריא. • Data Type + Length: NVARCHAR/INTEGER/DECIMAL/DATETIME עם אורך מתאים. • Reference attribute: קישור לערכים-מותרים לבקרת-איכות-נתונים. סוגי נתוני-אב (Master Data Types) • בחירת-סוג: simple / compound / reference / external / virtual לפי הצורך. • Key attributes: סימון ה-attributes המהווים את המפתח הייחודי. • שיוך ל-planning area: כל master data type חייב להיכלל ב-planning area כדי לשמש. פרופילי-זמן (Time Profiles) • Time Profile Levels: הגדרת ההיררכיה (Year → Quarter → Month → Technical Week). • Time period generation: יצירת התקופות בפועל לטווח-השנים הרצוי. • שיוך ל-planning area: כל planning area מקושר ל-time profile אחד בלבד. אזורי-תכנון (Planning Areas) • Copy Planning Area: שכפול SAPIBP1 כבסיס, כולל key figures ו-planning levels מוכנים. • שיוך אובייקטים: master data types, time profile, planning levels, key figures. • Consistency check + Activate: בדיקה והפעלה לפני שימוש. רמות-תכנון (Planning Levels) • Root attributes + time profile level: הגדרת צירוף-הרזולוציה. • Base planning level: הרמה שבה ה-key figure נשמר פיזית. • Aggregation/disaggregation levels: רמות-צפייה וחישוב נגזרות. מדדים (Key Figures) • Base planning level: רמת-האחסון של ה-key figure. • Aggregation: SUM/AVG/... לצבירה למעלה בהיררכיה. • Disaggregation: proportional / equal / לפי reference key figure. • Stored vs calculated: נשמר פיזית מול מחושב בזמן-ריצה (calculation). גרסאות ותרחישים מוגדרי-משתמש • Versions: הגדרת version-Baseline ו-versions נוספות; copy operator להעתקה. • User-defined scenarios: מופעלים ל-planning area; נוצרים ע"י המשתמש. • Adopt scenario: אימוץ שינויי-scenario חזרה ל-version. תמיכה רב-לשונית לאובייקטי-מידול • Translatable Description: לכל modeling object תיאור הניתן-לתרגום לפי שפה. • Technical ID: נשאר אנגלי-קבוע ואינו מתורגם. • Logon language: קובע איזה תיאור מוצג ב-Excel add-in / Web UI.

נתוני אב • Attributes + Master Data Types מגדירים את מבנה נתוני-האב הנטענים. • Time Profile מגדיר את צירוף-תקופות-הזמן שעליו נשמרים key figures. שאלות ראיון מהן אבני-הבניין של מודל-IBP, בסדר-הבנייה? attributes → master data types → time profile → planning area → planning levels → key figures. מהו SAPIBP1? ה-planning area לדוגמה שמספקת SAP; משכפלים ומתאימים אותו כבסיס למודל-הלקוח. מדוע צריך Activate? כל שינוי-מודל נכנס לתוקף רק לאחר הפעלת ה-planning area; עד אז התצוגות עובדות על המבנה הישן. מהו attribute ב-IBP? שדה-היסוד המתאר מאפיין-עסקי (PRDID, LOCID); אבן-הבניין הקטנה ביותר של המודל. מה ההבדל בין key attribute ל-non-key? key attribute הוא מזהה (חלק מ-compound master data); non-key הוא תיאורי בלבד. מהם חמשת סוגי master data type? simple, compound, reference, external, virtual. מתי משתמשים ב-compound? כשהמפתח הייחודי מורכב מכמה attributes (לדוגמה Customer + Region). מהו reference master data type? מצביע על master data type קיים לשימוש-חוזר ללא שכפול-נתונים. מה מגדיר time profile? את ציר-הזמן והיררכיית-התקופות (Week→Month→Quarter→Year) שעליהם נשמרים key figures. כמה time profiles מקושרים ל-planning area? אחד בלבד; הוא קובע את הרזולוציה-הזמנית של כל המודל. מדוע קשה לשנות time profile מאוחר? כל הנתונים נשמרו לפיו; שינוי מצריך תכנון-מחדש וטעינה-מחדש. מהו planning area? המכולה המאחדת attributes, master data, time profile, planning levels ו-key figures למודל-תכנון אחד פעיל. מהו SAPIBP1 ולמה משכפלים אותו? ה-planning area לדוגמה של SAP; משכפלים אותו כדי לקבל key figures ו-planning levels מוכנים במקום לבנות מאפס. מתי planning area נכנס לתוקף? רק לאחר Activate שעובר consistency check. מהו planning level? צירוף attributes + time profile level הקובע את רזולוציית האחסון/החישוב של key figure. מהו base planning level? הרמה שבה ה-key figure נשמר פיזית; שאר-הרמות מחושבות בצבירה. כיצד נצפה מספר ברמה גסה יותר מהאחסון? דרך aggregation — IBP מצבר אוטומטית מה-base planning level לרמה-המבוקשת. מהו key figure? המדד-המספרי שמתכננים (תחזית, מלאי, אספקה); האובייקט המרכזי שהמשתמש עורך. מה ההבדל בין stored ל-calculated key figure? stored נשמר פיזית ב-HANA; calculated מחושב בזמן-ריצה מ-key figures אחרים דרך calculation. מהי disaggregation? פירוק ערך מרמה-גסה לרמות-נמוכות, לפי proportional factor / equal / reference key figure. מה ההבדל בין version ל-scenario ב-IBP? version היא עותק-נתונים מלא (Baseline/Budget); scenario הוא שכבת-סימולציה קלה מעל version לעבודת what-if. כיצד מאמצים תרחיש מוצלח? באמצעות adopt — שינויי ה-scenario נכתבים חזרה ל-version. למה scenarios חיוניים ל-S&OP? הם מאפשרים ניתוח-חלופות והשוואה side-by-side לפני-החלטה, מבלי לסכן את תכנית-הבסיס. מה מתורגם ומה נשאר קבוע באובייקטי-מידול? ה-Description מתורגם לפי שפת-ההתחברות; ה-ID הטכני (Attribute/Key Figure ID) נשאר אנגלי-קבוע. מדוע התמיכה הרב-לשונית חשובה בארגון גלובלי? היא מאפשרת אימוץ-משתמשים בשפתם תוך שמירה על מודל-אחיד וחישוב-זהה לכולם. נושאים קשורים • S&OP · ארכיטקטורה (2.1) • S&OP · key figures (2.2.6) • S&OP · master data types (2.2.2) • S&OP · attributes (2.2.1) • S&OP · planning levels (2.2.5) • S&OP · time profiles (2.2.3) • S&OP · versions ו-scenarios (2.2.7) • S&OP · ניווט במודל (2.3)

• key figure לא מוצג ➔ ודא שה-planning area הופעל אחרי השינוי (Activate). • בדיקת-עקביות נכשלת ➔ master data type חסר, attribute לא-משויך, או planning level לא-תקין. • מספרים לא-מתאחדים ➔ aggregation/disaggregation לא-מוגדר ב-key figure. תכונות (Attributes) • ערכים נקטעים בטעינה ➔ אורך ה-attribute קצר מהנתון במקור. • שגיאת-טיפוס בחישוב ➔ Data Type לא-מתאים (טקסט במקום מספר). סוגי נתוני-אב (Master Data Types) • טעינת-נתונים-כפולה / כשל-ייחודיות ➔ key attributes חסרים או סוג שגוי (simple במקום compound). • נתוני-אב לא-זמינים לתכנון ➔ master data type לא-משויך ל-planning area. פרופילי-זמן (Time Profiles) • תכנון לא-זמין לתקופות-עתיד ➔ לא נוצרו מספיק time periods (Generate). • אי-התאמה בין שכבות-זמן ➔ הגדרת Levels שגויה בהיררכיה. אזורי-תכנון (Planning Areas) • Activate נכשל ➔ consistency check חושף master data/planning level/KF פגומים. • תצוגה לא-מציגה נתונים ➔ master data לא-נטען ל-planning area או לא-הופעל. רמות-תכנון (Planning Levels) • צבירה לא-נכונה ➔ aggregation rule של ה-key figure שגוי לרמה זו. • ביצועים-איטיים ➔ base planning level מפורט מדי או יותר-מדי root attributes. מדדים (Key Figures) • עריכה ברמה-גסה לא-מתפרקת נכון ➔ disaggregation basis שגוי או חסר reference KF. • מספר לא-מתעדכן ➔ key figure מוגדר stored במקום calculated, או calculation שגוי. • סיכום חסר-משמעות ➔ aggregation mode לא-נכון למדד. גרסאות ותרחישים מוגדרי-משתמש • שינויי-scenario לא-משפיעים על התכנית ➔ לא בוצע adopt ל-version. • scenarios לא-זמינים ב-Excel ➔ לא הופעלו ל-planning area בקונפיגורציה. • נתוני-version ריקים ➔ לא בוצע copy מ-Baseline ל-version החדשה. תמיכה רב-לשונית לאובייקטי-מידול • משתמש רואה תיאורי-אנגלית במקום שפתו ➔ חסר תרגום לשפת-ההתחברות. • תיאור לא-מתעדכן ➔ תרגום הוזן אך ה-planning area לא הופעל מחדש.

• המודל = attributes, master data types, time profile, planning area, planning levels, key figures. • סדר-הבנייה היררכי; כל אבן נשענת על הקודמת. • שכפל את SAPIBP1, בדוק-עקביות, והפעל (Activate) בכל שינוי. • attribute = שדה-יסוד; הלבנה הקטנה של המודל. • מוגדר עם ID, Data Type, Length. • השתמש-מחדש בקיימים מ-SAPIBP1; הימנע מכפילים. • master data type = הטבלה המאגדת attributes. • חמישה סוגים: simple/compound/reference/external/virtual. • חייב להיות משויך ל-planning area כדי לשמש. • time profile = ציר-הזמן והיררכיית-התקופות של המודל. • planning area אחד מקושר ל-time profile אחד. • קבע נכון מההתחלה; שינוי מאוחר יקר. • planning area = המודל השלם והפעיל; הקשר לכל פעולה. • שכפל את SAPIBP1 ואל תבנה מאפס. • Consistency check + Activate חובה לפני שימוש. • planning level = רזולוציה (attributes + time level). • base planning level = רמת-האחסון הפיזית. • צבירה/פירוק מאפשרים צפייה במגוון-רמות מאחסון-יחיד. • key figure = המספר שמתכננים; האובייקט המרכזי בתצוגה. • מוגדר עם base planning level, aggregation, disaggregation. • stored מול calculated — איזון בין אחסון לזמן-ריצה. • version = עותק-נתונים מלא; scenario = שכבת-סימולציה מעל version. • scenarios לעבודת-תכנן; versions למבנה (Budget/Forecast). • adopt מכניס תרחיש מוצלח חזרה לתכנית. • תיאורים מתורגמים; ID טכני נשאר אנגלי-קבוע. • התצוגה לפי logon language. • תרגום-מלא מקדם אימוץ-משתמשים גלובלי.