התראות מותאמות (Custom Alerts)

Custom Alerts הן הלב של 'ניהול-לפי-חריגים' ב-SAP IBP. במקום שמתכנן יסרוק אלפי שורות, המערכת בודקת רעיונית כל שילוב-תכנון מול תנאי שהוגדר מראש (למשל 'מלאי מתחת לבטיחות' או 'תחזית סוטה ביותר מ-X%') ומתריעה רק על מה שחורג. כך מופנית תשומת-הלב המוגבלת של הצוות בדיוק למקומות הדורשים החלטה. אפליקציות SAP Fiori — ניהול-החריגים ב-IBP נחשף דרך אפליקציות בסגנון SAP Fiori — Custom Alerts, Alert Overview, Dashboards ו-Application Jobs. אפליקציות אלו מספקות חוויה אחידה, מבוססת-תפקיד וריאקטיבית, שבה מגדירים התראות, רואים אותן מרוכזות, וצוללים מהן ישירות לפעולה. שימוש בהתראות מותאמות — שימוש ב-Custom Alerts הוא שגרת-העבודה היומית של המתכנן: לפתוח את מסך-החריגים, לתעדף לפי Severity, לצלול מכל חריג ישירות לתצוגה הרלוונטית, לפעול, ולסמן טיפול. זהו ההבדל בין 'נתונים' ל'ניהול' — ההתראה הופכת לפעולה. הגדרת התראות מותאמות — הגדרת Custom Alert היא צעד-הקונפיגורציה שמתרגם 'כלל-עסקי' ל'התראה-מערכתית': בוחרים Planning Area ו-Key Figures, מנסחים תנאי (operator + threshold), קובעים Planning Level, אופק-זמן, Severity ו-scope, ומתזמנים חישוב. הגדרה מדויקת = התראות שימושיות; הגדרה רשלנית = רעש או שתיקה.

דמיין נורת-אזהרה ברכב: היא נדלקת רק כשמשהו לא בסדר — לא צריך לבדוק כל מד בעצמך. Custom Alert היא נורה כזו על נתוני-התכנון: אתה מגדיר מתי 'לדלוק' (איזה תנאי), והמערכת מסמנת לך רק את הפריטים החריגים. זה חוסך שעות של 'חיפוש מחט בערימה'. אפליקציות SAP Fiori — אלו ה'מסכים' שדרכם עובדים עם התראות: מסך אחד להגדיר התראה, מסך אחד לראות את כל ההתראות שלך, ולוח-מחוונים שמציג אותן בגרפים. כולם בסגנון Fiori — נקי, אחיד, ומותאם למה שהתפקיד שלך צריך. שימוש בהתראות מותאמות — אחרי שההתראות מוגדרות, ככה עובדים איתן: פותחים את רשימת-ההתראות שלי, מסתכלים על האדומות (החמורות) קודם, לוחצים על אחת — וזה לוקח אותך ישר למקום בנתונים שצריך לתקן. מתקנים, ומסמנים שטיפלת. זהו 'ניהול-לפי-חריגים' בפעולה. הגדרת התראות מותאמות — כדי 'ללמד' את המערכת מתי להתריע, ממלאים טופס: על איזה מודל (Planning Area), איזה מספר (Key Figure), מה התנאי (קטן-מ / גדול-מ וכמה), על איזו רמה (מוצר? מחסן?), לאיזה טווח-זמן, ובאיזו חומרה. בסוף קובעים מתי לחשב (לרוב כל לילה). זהו 'מתכון' להתראה.

להפוך תכנון מ-'תגובתי ויסודי-מדי' ל-'ממוקד-חריגים'. בארגון עם עשרות-אלפי שילובי-תכנון, רק מודל-חריגים מאפשר לצוות-קטן לנהל תיק-תכנון גדול ולהגיב מהר לסטיות. אפליקציות SAP Fiori — לתת לכל בעל-תפקיד את הכלי הנכון לחריגים בחוויה אחידה — להגדיר, לצרוך ולפעול — מבלי ללמוד מסכים שונים לכל פעולה. שימוש בהתראות מותאמות — להפוך את החריג מ'תצפית' ל'תוצאה': לקצר את הזמן מזיהוי-סטייה ועד תיקון-תכנון, ולוודא שאף חריג משמעותי לא נופל בין הכיסאות. הגדרת התראות מותאמות — לתרגם את ה'מה חשוב לנו' העסקי לכלל-מערכתי מדיד, כך שהמערכת תשמור על ה-portfolio במקום האדם — ותפנה את האדם רק לחריגים.

• SAP IBP ► Custom Alerts (web UI) ► Define Custom Alerts • SAP IBP ► Custom Alerts ► Alert Overview / My Alerts • SAP IBP ► Application Jobs ► Calculate Custom Alerts (batch) • SAP IBP ► Dashboards ► Alert Card (drill-to-context) • SAP IBP ► Apps ► Define Custom Alerts • SAP IBP ► Apps ► Alert Overview / My Alerts • SAP IBP ► Apps ► Application Jobs (Calculate Custom Alerts) • SAP IBP ► Apps ► Dashboards (Alert Cards) • SAP IBP ► My Alerts / Alert Overview ► Filter/Sort by Severity • SAP IBP ► Alert ► Open in Planning View (drill-to-context) • SAP IBP ► Dashboards ► Alert Card • SAP IBP ► Alert ► Create Case / Create Task (ניתוב) • SAP IBP ► Define Custom Alerts ► New (Planning Area + Key Figures) • SAP IBP ► Define Custom Alerts ► Condition (operator + threshold) • SAP IBP ► Define Custom Alerts ► Planning Level / Time / Filters / Severity • SAP IBP ► Application Jobs ► Calculate Custom Alerts (schedule)

• Custom Alerts = מנוע 'ניהול-לפי-חריגים' של IBP.
• מגדירים תנאי/סף על Key Figures ברמה ובאופק שנבחרו.
• כיול-ספים נכון מונע הצפה ושומר את ההתראות שימושיות.
• ניהול-חריגים נחשף דרך אפליקציות בסגנון SAP Fiori.
• הגדרה / צריכה / חישוב / תצוגה — כל אחת באפליקציה ייעודית.
• הכל כפוף ל-business roles ומשתלב ב-Work Zone.
• שימוש = תעדוף לפי Severity, drill-to-context, פעולה וסגירה.
• חריג מורכב מנותב ל-Case; פעולה מוקצית ל-Task.
• ההתראה הופכת מ'תצפית' ל'תוצאה' — זה ניהול-לפי-חריגים.
• הגדרה = מודל + Key Figures + תנאי + רמה + אופק + חומרה + תזמון.
• Planning Level הוא ההחלטה המכריעה לדיוק.
• החישוב רץ דרך Application Job (batch/on-demand) למנויים.

בארגון מוגדרות Alerts ל'מלאי-מוגמר מתחת לבטיחות לפני סוף-שבוע', 'קיבולת-קו-מילוי מעל 95%' ו'סטיית-תחזית-מבצע > 20%'. בעונת-השיא מנהל-S&OP מנהל את כל ה-portfolio דרך מסך-החריגים בלבד — כל פריט שאינו חריג פשוט אינו דורש מבט. מוגדרת Alert: 'Projected Stock < Safety Stock בתוך 4 שבועות' ברמת-Product/Location. ה-batch מריץ בלילה, ובבוקר המתכנן רואה 12 חריגים ב-Alert Overview. הוא פותח את החמור ביותר, drill-to-context לתצוגת-התכנון, מזהה איחור-אספקה, ומפעיל פעולה — בלי לסרוק את שאר אלפי הפריטים התקינים. אפליקציות SAP Fiori — בארגון מנהלי-הקווים משתמשים ב-'My Alerts' לראות חריגי-קיבולת, ומנהל-S&OP ב-Dashboard עם Alert Cards אזוריות — אותה שפת-Fiori לכל התפקידים. Admin מגדיר alert ב-'Define Custom Alerts'; הוא מתזמן חישוב ב-'Application Jobs'; המתכנן צורך ב-'Alert Overview' ורואה Alert Card ב-Dashboard; לחיצה צוללת לתצוגת-התכנון — מסך אחד מוביל לבא בזרימה אחידה. שימוש בהתראות מותאמות — בארגון בעונת-השיא מנהל-S&OP פותח את מסך-החריגים פעמיים ביום: כל 'קיבולת > 95%' שמופיעה מנותבת או למשימה (להזיז ייצור לקו אחר) או ל-Case (אם דורשת החלטה בין-מחלקתית), וכל מלאי-בטיחות חורג מטופל מיד. בבוקר המתכנן פותח 'My Alerts', ממיין לפי High, רואה 'מלאי < בטיחות' ל-SKU מוביל, צולל לתצוגה (ה-filter כבר על אותו SKU/Location), מזהה הזמנת-רכש מאחרת, מקדים אותה, ומסמן טופל. חריג מורכב יותר — 'פער-קיבולת קבוע בקו' — הוא מנתב ל-Case לדיון רב-משתתפים. הגדרת התראות מותאמות — בארגון ה-key-user מגדיר שלוש Alerts: מלאי-מוגמר < בטיחות (High), ניצולת-קו > 95% (Medium), סטיית-תחזית-מבצע > 20% (Low), כל אחת ברמת-הצבירה הנכונה, ומתזמן חישוב-לילי לקראת ישיבת-ה-S&OP הבוקרת. Admin מגדיר alert: Planning Area = SOP1, KF = Projected Stock, תנאי = '< Safety Stock', Level = Product/Location, אופק = 8 שבועות, Severity = High. הוא מתזמן Application Job יומי 05:00. למחרת בבוקר המנויים רואים את החריגים מחושבים ומוכנים.

• Definition: בחירת Planning Area, Key Figures ותנאי (operator/threshold) ל-alert. • Scope: Planning Level (רמת-בדיקה), Time horizon ו-Filters לתחום-הבדיקה. • Severity: סיווג High/Medium/Low לתעדוף בעין. • Execution & subscription: הרצה כ-Application Job או on-demand, והקצאת ה-alert למשתמשים/roles. אפליקציות SAP Fiori • Role catalogs: שיוך אפליקציות-ההתראות ל-business roles (Admin מול Planner). • Launchpad/Work Zone: חשיפת האפליקציות כ-tiles/cards במרחב. • Jobs: הגדרת Application Job לחישוב-התראות וקביעת תדירות. שימוש בהתראות מותאמות • Subscriptions: ודא שכל משתמש מנוי על ה-alerts הרלוונטיים לתפקידו. • Drill-to-context: קישור ה-alert לתצוגת-תכנון יעד עם filters אוטומטיים. • Routing: אפשרות ליצור Case או Task מתוך alert לחריגים הדורשים דיון/מעקב. הגדרת התראות מותאמות • Planning Area & Key Figures: בחירת המודל וה-Key Figures לבדיקה (כולל calculated KFs). • Condition: operator (<, >, =, <>) מול constant או מול Key Figure אחר; threshold/בטיחות. • Scope: Planning Level (רמת-בדיקה), Time horizon ו-Filters לתיחום. • Severity & schedule: סיווג חומרה והקצאה ל-Application Job (batch/on-demand) + מנויים.

נתוני אב • ההתראה נשענת על Planning Area, Key Figures (כולל calculated) ו-Planning Levels של המודל. • Time horizon נגזר מ-Time Profile של מודל-התכנון. שאלות ראיון מהן Custom Alerts ב-SAP IBP? הגדרות-חריגה על Planning Area הבודקות Key Figures מול תנאי וסף ומתריעות רק על שילובי-תכנון החורגים — הבסיס לניהול-לפי-חריגים. כיצד נמנעים מ'הצפת-התראות'? על-ידי כיול-ספים לפי כאב-עסקי, שימוש ב-Severity וקיבוץ, ובחירת Planning Level נכון — כך שרק חריגים משמעותיים מסומנים. אילו אפליקציות SAP Fiori משרתות ניהול-חריגים ב-IBP? Define Custom Alerts (הגדרה), Alert Overview / My Alerts (צריכה), Application Jobs (חישוב מתוזמן) ו-Dashboards עם Alert Cards (תצוגה + drill-to-context). מי אמור לגשת לאפליקציית 'Define Custom Alerts'? בעיקר Admin/key-user; מתכננים רגילים מקבלים catalog-צריכה (Alert Overview/My Alerts) כדי למנוע שינויי-תצורה לא-מבוקרים. כיצד מתכנן עובד עם Custom Alerts ביום-יום? פותח מסך-חריגים, מתעדף לפי Severity, צולל מכל חריג לתצוגה (drill-to-context), מבצע פעולת-תכנון, ומנתב חריגים מורכבים ל-Case או מעקב ל-Task. מתי מנתבים חריג ל-Case לעומת Task? ל-Case כשנדרשים דיון/החלטה רב-משתתפים סביב נושא; ל-Task כשנדרשת פעולה מוקצית עם מעקב-ביצוע — לעיתים alert→case→task ברצף. אילו רכיבים מגדירים ב-Custom Alert? Planning Area, Key Figures, תנאי (operator + threshold), Planning Level, אופק-זמן, Filters, Severity, ותזמון חישוב דרך Application Job. מדוע Planning Level הוא ההחלטה הקריטית בהגדרה? כי רמת-הצבירה שבה נבדק התנאי קובעת אם החריג מזוהה נכון; רמה שגויה יוצרת חריגים-שקריים או מחמיצה חריגים אמיתיים. נושאים קשורים • S&OP · SAP Build Work Zone (7.1) • S&OP · ניהול מקרים (7.3) • S&OP · משימות (7.4) • S&OP · שימוש בהתראות (7.2.2)

• אין התראות כלל ➔ ה-Application Job לא רץ, או התנאי/הספים לעולם לא מתקיימים. • יותר מדי התראות ➔ ספים רגישים מדי או Planning Level נמוך מדי. • המשתמש לא רואה alert קיימת ➔ חסרה subscription/הרשאת-planning-area. אפליקציות SAP Fiori • אפליקציה לא מופיעה ל-role ➔ catalog/role assignment חסר. • Alert Overview ריק ➔ Application Job לא רץ או אין חריגים. • Dashboard card ריק ➔ ה-card לא חובר ל-alert/Key Figure. שימוש בהתראות מותאמות • drill-to-context פותח תצוגה בלי filter ➔ קישור-היעד לא מעביר את ה-context. • חריג שטופל חוזר ➔ הבעיה התכנונית לא נפתרה, או ה-Job עדיין רואה את הסטייה. • אין אפשרות ליצור Case/Task מ-alert ➔ חסרה הרשאה ל-Manage Cases / Tasks. הגדרת התראות מותאמות • ההתראה לא מחזירה תוצאות ➔ תנאי לעולם לא מתקיים, Level/Filter מצמצמים מדי, או ה-Job לא רץ. • חריגים-שקריים ➔ Planning Level לא-נכון או threshold לא-מותאם. • המנויים לא רואים ➔ subscription/role/planning-area authorization חסרים.

• Custom Alerts = מנוע 'ניהול-לפי-חריגים' של IBP. • מגדירים תנאי/סף על Key Figures ברמה ובאופק שנבחרו. • כיול-ספים נכון מונע הצפה ושומר את ההתראות שימושיות. • ניהול-חריגים נחשף דרך אפליקציות בסגנון SAP Fiori. • הגדרה / צריכה / חישוב / תצוגה — כל אחת באפליקציה ייעודית. • הכל כפוף ל-business roles ומשתלב ב-Work Zone. • שימוש = תעדוף לפי Severity, drill-to-context, פעולה וסגירה. • חריג מורכב מנותב ל-Case; פעולה מוקצית ל-Task. • ההתראה הופכת מ'תצפית' ל'תוצאה' — זה ניהול-לפי-חריגים. • הגדרה = מודל + Key Figures + תנאי + רמה + אופק + חומרה + תזמון. • Planning Level הוא ההחלטה המכריעה לדיוק. • החישוב רץ דרך Application Job (batch/on-demand) למנויים.