ניטור התראות (Alert Monitoring)

ניטור-התראות הוא השימוש היומיומי בכלי: צריכת ההתראות וטיפול בהן. ההתראות נצרכות בשלוש דרכים — מתוך ה-Alert Monitor המרכזי, כ-DB alerts הנוצרות ברקע, ובהקשר מתוך יישומי-PP/DS עצמם (כמו ה-Product View או ה-DS Board). היכולת לעבור מהתראה ישירות לאובייקט ולפעולה היא מה שהופך את הכלי לאפקטיבי. ניטור התראות מתוך מוניטור ההתראות — הדרך המרכזית לניטור: פתיחת /SAPAPO/AMON1 עם overall profile, סקירת ההתראות לפי חומרה/סוג, ו-drill-down ישיר לאובייקט הבעייתי. זהו "לוח-המחוונים" היומי של המתכנן. יצירת התראות ברקע — database alerts נוצרות ע"י job-רקע שמריץ alert determination על-פני היקף נרחב, ושומר את התוצאות ב-/SAPAPO/ALERTDB. כך, בעת פתיחת המוניטור, ההתראות נקראות מהר ללא חישוב כבד בזמן-אמת — מתאים לסקירות-מסה ולנפחים גדולים. ניטור התראות מתוך יישומי PP/DS — התראות אינן מוגבלות למוניטור המרכזי; הן מוטמעות בתוך יישומי-PP/DS עצמם — Product View, DS Planning Board, Detailed Scheduling — כ-context alerts. כך המתכנן רואה את החריגה במקום-העבודה הטבעי שלו ומגיב מיד, בלי לעבור מסך.

עד כה כיוונּו את האזעקה; כעת מקשיבים לה ומגיבים. יש שלוש דרכים "לשמוע": לפתוח את לוח-ההתראות המרכזי, לקבל התראות שחושבו בלילה ברקע, או לראות נורות-אזהרה בתוך מסכי-העבודה הרגילים. בכל מקרה, לחיצה על התראה לוקחת אותך ישר לבעיה כדי לתקן. ניטור התראות מתוך מוניטור ההתראות — פותחים את לוח-ההתראות המרכזי, רואים רשימה ממוינת לפי חומרה (אדום=Error, צהוב=Warning), ולוחצים על שורה כדי לקפוץ למקום הבעיה. כל הבעיות במקום אחד, מסודרות. יצירת התראות ברקע — במקום שהמחשב יחשב את כל ההתראות ברגע שאתה פותח את המסך (איטי), הוא מחשב אותן בלילה ושומר אותן מוכנות. בבוקר הרשימה נטענת מיד. זה ה-"background" — עבודה מראש ברקע. ניטור התראות מתוך יישומי PP/DS — במקום ללכת ללוח-ההתראות, האזהרות מופיעות ישר במסך שבו אתה כבר עובד — כמו נורה-אדומה על שורה בעייתית. אתה מתכנן, רואה את ההתראה בהקשר, ומתקן בו-במקום.

להפוך התראה לפעולה במהירות: לזהות חריגה, לקפוץ לאובייקט הרלוונטי, ולתקן (לתזמן-מחדש, להזיז, לפצל, לשנות-מקור) — מינימום זמן בין גילוי לתיקון. ניטור התראות מתוך מוניטור ההתראות — לתת למתכנן נקודת-כניסה אחת ומסודרת לכל החריגות, עם מעבר מהיר לפעולה. יצירת התראות ברקע — לאפשר ניטור-מסה מהיר בנפחים גדולים, ולהכין סקירת-בוקר מוכנה למתכננים בלי המתנה לחישוב. ניטור התראות מתוך יישומי PP/DS — לקצר עוד יותר את הלולאה גילוי→תיקון, ע"י הצגת ההתראה בהקשר התכנון עצמו במקום במסך נפרד.

• Easy Access ► APO ► Supply Chain Monitoring ► Current Settings ► Alert Monitor (/SAPAPO/AMON1) • SPRO ► APO ► Supply Chain Monitoring ► Alert Monitor ► Settings for Background Alert Determination • Easy Access ► APO ► Supply Chain Monitoring ► Reporting ► Alert Monitor Reorganization • Easy Access ► APO ► Production Planning ► Interactive Production Planning ► Product View (/SAPAPO/RRP3) • Easy Access ► APO ► Production Planning ► Detailed Scheduling Planning Board (/SAPAPO/CDPS0)

• ניטור = צריכת התראות וטיפול מהיר.
• DB alerts (רקע) + dynamic + context alerts ביישומים.
• הכוח הוא ב-navigation מהתראה ישר לאובייקט ולתיקון.
• המוניטור המרכזי = לוח-המחוונים היומי.
• מיון לפי חומרה + drill-down לאובייקט.
• תקן, רענן, ההתראה נסגרת.
• DB alerts נוצרות ב-job-רקע ונשמרות ב-ALERTDB.
• יתרון: ביצועים בנפחים גדולים; חיסרון: עדכניות תלוית-job.
• חובה לתזמן reorg לצד ה-job.
• context alerts מוטמעות ביישומי-PP/DS עצמם.
• מחושבות dynamic בהקשר האובייקט המוצג.
• closed-loop: תכנון ותיקון באותו מסך.

בארגון המתכנן רואה התראת resource overload על קו-מילוי-2 בשיא-הקיץ; הוא קופץ ל-DS Board, מעביר חלק מהפק"ע לקו-3 שפנוי, והעומס יורד מתחת לסף — ההתראה נסגרת. מתכנן פותח /SAPAPO/AMON1, רואה 8 התראות-מחסור באדום. הוא לוחץ על אחת, נופל ישירות ל-Product View של אותו מוצר, מזהה הזמנה-מתוכננת מאוחרת, מקדים אותה, וההתראה נעלמת ברענון. ניטור התראות מתוך מוניטור ההתראות — בארגון מתכנן-המילוי פותח /SAPAPO/AMON1 בבוקר עם פרופיל "MFG_DAILY", רואה מחסור-תרכיז כ-Error, קופץ ל-RRP3 ומקדים אספקת-תרכיז לפני ריצת-המילוי. מתכנן טוען overall profile, ממיין לפי חומרה, פותח קבוצת Shortage, לוחץ על מוצר, נופל ל-RRP3, מקדים הזמנה, חוזר ומרענן — השורה נעלמה. יצירת התראות ברקע — בארגון job-לילי מחשב התראות-מחסור ופיגור על כל קווי-המילוי וכל המפעלים; בבוקר מתכננֵי-המשמרת רואים סקירה מוכנה. reorg-שבועי מנקה התראות-ישנות מ-ALERTDB. job-לילי מריץ alert determination על כל המוצרים ושומר 1,200 התראות ב-ALERTDB. בבוקר 30 מתכננים פותחים את המוניטור — כל אחד רואה רק את שלו, מיד, ללא חישוב חוזר. ניטור התראות מתוך יישומי PP/DS — בארגון מתכנן-המילוי ב-DS Board של קו-2 רואה context alert של עומס-יתר תוך-כדי גרירת פק"ע-משקה; הוא מעביר חלק לקו-3 וההתראה במסך נעלמת מיד. מתכנן עובד ב-DS Board, גורר פק"ע לקו אחר; מיד מופיעה התראת resource overload על הקו-החדש. הוא מבטל את ההזזה או מפצל — closed loop באותו מסך.

• הגדר אילו Alert Types נוצרים ברקע (DB) ואילו דינמית. • הגדר navigation targets מהתראה (Product View / DS Board). • תזמן job-רקע לחישוב DB alerts ו-job ל-reorg. ניטור התראות מתוך מוניטור ההתראות • בחר overall profile בפתיחת המוניטור. • קבע קיבוץ/מיון/סינון (severity, product, resource). • ודא navigation targets פעילים (RRP3 / CDPS0). יצירת התראות ברקע • סמן אילו Alert Types נוצרים ברקע (DB) ב-Settings for Background Alert Determination. • צור variant עם היקף (מוצרים/משאבים/גרסה) ושייך לפרופיל. • תזמן job תקופתי (SM36) לחישוב ה-DB alerts. • תזמן reorg (/SAPAPO/AMON_REORG) לניקוי התראות-ישנות. ניטור התראות מתוך יישומי PP/DS • שייך alert profile ליישום (Product View / DS Board) דרך הגדרות-היישום. • הפעל alert icons/columns בתצוגת היישום. • ודא חישוב dynamic של ההתראות בהקשר.

נתוני אב • DB alerts נשמרות ב-/SAPAPO/ALERTDB ומתוחזקות ב-reorg. • ה-navigation נשען על מוצר/משאב/גרסה תקפים. • התראות נשמרות ב-/SAPAPO/ALERTDB; ה-job ב-TBTCO. • ה-variant מצביע על היקף-אובייקטים וגרסת-תכנון. שאלות ראיון אילו שלוש דרכים לצרוך התראות? מתוך ה-Alert Monitor המרכזי, כ-DB alerts מהרקע, ובהקשר מתוך יישומי-PP/DS (context alerts). למה התראה נשארת אחרי שתיקנת את הבעיה? כי היא DB alert שלא רוענן; צריך חישוב/reorg של ALERTDB או מעבר ל-dynamic alerts. מהי נקודת-הכניסה המרכזית לניטור התראות? הטרנזקציה /SAPAPO/AMON1 עם overall profile. לאן אפשר לעשות drill-down מהתראה? ל-Product View (/SAPAPO/RRP3), ל-DS Board (/SAPAPO/CDPS0) או ל-Detailed Scheduling. מהי המטרה של יצירת התראות ברקע? לחשב מראש database alerts ולשמור ב-ALERTDB כך שהמוניטור נטען מהר בנפחים גדולים, ללא חישוב בזמן-אמת. מדוע חשוב reorg ל-ALERTDB? כדי לנקות התראות-ישנות/שנפתרו, למנוע התנפחות-טבלה ולמנוע הצגת מצב מיושן. אילו יישומי-PP/DS מציגים context alerts? Product View (/SAPAPO/RRP3), DS Planning Board (/SAPAPO/CDPS0) ו-Detailed Scheduling — לפי ה-alert profile המשויך. מה היתרון של ניטור מתוך היישום מול המוניטור המרכזי? ההתראה מופיעה בהקשר-העבודה ומחושבת dynamic, כך שהמתכנן רואה השפעת-שינוי מיד ומקצר את הלולאה גילוי→תיקון. נושאים קשורים • PP/DS · פרופילי התראות (7.1) • PP/DS · התראות ברקע (7.2.2) • PP/DS · ניטור התראות (7.2) • אובייקט · /SAPAPO/ALERTDB • PP/DS · ניטור מהמוניטור (7.2.1)

• התראה נשארת אחרי תיקון ➔ DB alert לא רוענן; הרץ חישוב/reorg או עבור ל-dynamic. • אין navigation מהתראה לאובייקט ➔ target לא הוגדר או הרשאה חסרה. • התראות סותרות בין מסכים ➔ DB מול dynamic מציגים זמנים שונים. ניטור התראות מתוך מוניטור ההתראות • drill-down לא עובד ➔ navigation target לא מוגדר או הרשאה חסרה. • רשימה לא מתעדכנת אחרי תיקון ➔ מצב DB; הרץ רענון/חישוב. יצירת התראות ברקע • המוניטור ריק למרות job ➔ ה-variant/פרופיל לא תואם לאובייקטים, או ה-job נכשל (SM37). • התראות שכבר נפתרו עדיין מוצגות ➔ חסר reorg; הרץ /SAPAPO/AMON_REORG. • ALERTDB גדל מאוד ➔ reorg לא רץ או חלון-שמירה ארוך מדי. ניטור התראות מתוך יישומי PP/DS • אין alert icons ביישום ➔ alert profile לא משויך או התצוגה לא הופעלה. • context alert לא מתעדכן ➔ מצב dynamic תקול; רענן את היישום.

• ניטור = צריכת התראות וטיפול מהיר. • DB alerts (רקע) + dynamic + context alerts ביישומים. • הכוח הוא ב-navigation מהתראה ישר לאובייקט ולתיקון. • המוניטור המרכזי = לוח-המחוונים היומי. • מיון לפי חומרה + drill-down לאובייקט. • תקן, רענן, ההתראה נסגרת. • DB alerts נוצרות ב-job-רקע ונשמרות ב-ALERTDB. • יתרון: ביצועים בנפחים גדולים; חיסרון: עדכניות תלוית-job. • חובה לתזמן reorg לצד ה-job. • context alerts מוטמעות ביישומי-PP/DS עצמם. • מחושבות dynamic בהקשר האובייקט המוצג. • closed-loop: תכנון ותיקון באותו מסך.