הודעה

ההודעה (Notification) היא נקודת-הכניסה של מחזור-הפק"ע: מסמך המתעד אירוע-תחזוקה — תקלה, בקשה או פעילות. היא לוכדת את ה'מה קרה' (אובייקט, נזק, סיבה) עוד לפני שמתחילים לתכנן עבודה. ההודעה נשמרת ב-VIQMEL (תצוגת-עיבוד) / QMEL והיא בסיס היסטוריית-התחזוקה וניתוח-האמינות של הארגון. יצירת הודעה — יצירת-הודעה (IW21, או דרך Fiori) היא הצעד הראשון: בוחרים סוג-הודעה, מזינים אובייקט-ייחוס, תיאור-קצר ופרטי-תקלה. הסטטוס ההתחלתי הוא OSNO (Outstanding). זוהי הפעולה הנפוצה ביותר של משתמש-קצה ב-PM. סוגי הודעה — סוג-ההודעה (QMART) מסווג את האירוע: M1 (Malfunction Report), M2 (Maintenance Request), M3 (Activity Report) — ובקטגוריית-QM סוגים אחרים. הסוג שולט בקטלוג, ב-Field Selection, ב-Partner Determination ובמספור. תוכן ההודעה — תוכן-ההודעה כולל: כותרת (אובייקט, תאריכים, עדיפות), תיאור-קצר וארוך, פריטים (מה ניזוק), סיבות, פעילויות, משימות, שותפים וזמני-השבתה (Malfunction Start/End, Breakdown Duration). זהו מאגר-הנתונים שעליו נשען ניתוח-האמינות. אובייקטי ייחוס גמישים — הודעה יכולה להתייחס לאובייקטים שונים: Equipment, Functional Location, Assembly, Material/Serial, או Maintenance Object גנרי. הגמישות מאפשרת לדווח על תקלה בכל רמת-היררכיה — מהקו כולו ועד רכיב בודד. מידע אובייקט — חלון Object Information (כפתור 'i') מציג למתכנן תמונת-מצב של האובייקט בעת פתיחת/עיבוד ההודעה: הודעות פתוחות, הזמנות פתוחות, חוזי-שירות, אחריות, ונתוני-מחזור — הקשר מיידי לקבלת-החלטה. פריטי הודעה — פריט-הודעה (Item) מתאר רכיב-ספציפי שניזוק: Object Part + Damage Code, ולעיתים גם Cause ו-Activity ברמת-הפריט. הודעה יכולה לשאת מספר פריטים — תקלה מורכבת עם כמה נזקים. קטלוגים ופרופילי קטלוג — קטלוגים הם רשימות-קודים מובנות: Damage (B/5), Cause (C), Activity (A), Object Part (B), Tasks (2), Coding (D). פרופיל-הקטלוג מאגד אותם ומקשר לסוג-ההודעה, וכך מגדיר אילו קודים זמינים — הבסיס לכל ניתוח-תקלות. סיווג — סיווג (Classification) מאפשר לצרף להודעה מאפיינים (Characteristics) מעבר לשדות-הסטנדרט — דרך Class Type מתאים. שימושי ללכידת נתונים ספציפיים-לתעשייה ולחיפוש/ניתוח לפי מאפיין. שותפים — שותפים (Partners) הם הגורמים המעורבים בהודעה: מבקש (Requester), אחראי (Responsible), מתכנן, ספק, מחלקה. Partner Determination Procedure קובע אילו תפקידי-שותף נדרשים — ומאפשר ניתוב, אחריות ותקשורת. כתובות — כתובות מקשרות את ההודעה למיקום פיזי או לכתובת-שותף — היכן נמצא האובייקט או מי איש-הקשר. רלוונטי במיוחד לשירות-לקוחות (Customer Service) ולתחזוקה מבוזרת על-פני אתרים. מסמכים — ניתן לצרף מסמכים להודעה: תמונות, סרטוני-תקלה, שרטוטים, מפרטים — דרך DMS (Document Management) או GOS (Generic Object Services). תיעוד-ויזואלי משפר את הבנת-התקלה ואת איכות-התכנון. הדפסה — ניתן להדפיס הודעה (Notification print / Shop paper) למסירה לטכנאי או לתיעוד. ההדפסה נשלטת דרך Print Control — אילו טפסים, למי, ובאיזה אירוע. ב-S/4HANA מועדף PDF/Adobe Forms. סטטוסי מערכת ומשתמש — סטטוסים מנהלים את מחזור-חיי-ההודעה. System Statuses קבועים (OSNO Outstanding, NOPR In Process, NOCO Completed); User Statuses מוגדרים-ארגונית דרך Status Profile (BS02) ויכולים לחסום/לאפשר פעולות (Business Transactions).

הודעה היא 'טופס דיווח-תקלה' דיגיטלי. מישהו רואה בעיה במכונה ופותח הודעה: מה האובייקט, מה התקלה, מתי. זה לא מתקן כלום — זה רק מדווח ומתעד. אחר-כך מישהו מחליט אם לפתוח הזמנת-עבודה. יצירת הודעה — פותחים מסך-יצירה, בוחרים סוג ('תקלה'), אומרים על איזו מכונה מדובר וכותבים מה הבעיה. שומרים — וקיבלנו מספר-הודעה. זהו, דיווחנו. סוגי הודעה — כמו 'סוגי-טפסים' שונים: דיווח-תקלה, בקשת-תחזוקה, דיווח-פעילות. כל סוג נראה קצת אחר ומבקש מידע אחר, כי הוא משמש למטרה שונה. תוכן ההודעה — ההודעה היא לא רק שורה אחת. יש בה הרבה 'מגירות': תיאור, מה בדיוק נשבר, למה, מה עשו, מי אחראי, וכמה זמן המכונה הייתה מושבתת. אובייקטי ייחוס גמישים — אפשר לדווח תקלה על 'הקו כולו' או על 'המכונה הספציפית' או אפילו על 'החלק הפנימי'. המערכת מאפשרת לבחור את הרמה המתאימה — זה ה'אובייקט-הייחוס'. מידע אובייקט — כשפותחים הודעה על מכונה, המערכת יכולה להציץ ולהראות: 'למכונה הזו כבר יש 3 תקלות פתוחות החודש, והיא עדיין באחריות'. זה עוזר להחליט מה לעשות. פריטי הודעה — אם נשברו כמה דברים באותה תקלה, כל אחד מקבל 'פריט' משלו: 'המסוע — שחוק', 'המנוע — התחמם'. ככה מתעדים בדיוק מה קרה ולא מערבבים. קטלוגים ופרופילי קטלוג — במקום שכל טכנאי יכתוב במילים שלו, נותנים לו רשימות-בחירה: רשימת-נזקים, רשימת-סיבות, רשימת-פעולות. ה'פרופיל' מחליט אילו רשימות מופיעות בהודעה. ככה כולם מדברים באותה שפה. סיווג — לפעמים רוצים לשמור פרט שאין לו שדה רגיל בהודעה — למשל 'טמפרטורת-סביבה בעת התקלה'. הסיווג מאפשר להוסיף 'שדות-מותאמים' כאלה בלי תכנות. שותפים — לכל הודעה יש 'אנשים מעורבים': מי דיווח, מי אחראי לתקן, לאיזו מחלקה זה שייך. ה'שותפים' מתעדים את כל אלה כדי שנדע למי לפנות. כתובות — לפעמים צריך לדעת 'איפה זה' — באיזה בניין, באיזה אתר, או מה הכתובת של הלקוח. שדות-הכתובת בהודעה שומרים את המידע הזה. מסמכים — אפשר לצרף תמונה של התקלה, סרטון או PDF להודעה. ככה מי שמתכנן את התיקון רואה בדיוק מה קורה, בלי לרדת לרצפה. הדפסה — אפשר להדפיס את ההודעה על נייר — למשל לתת לטכנאי שאין לו מסך, או לתיעוד-ארכיון. המערכת יודעת איזה טופס להדפיס ולמי. סטטוסי מערכת ומשתמש — סטטוס הוא 'באיזה שלב ההודעה': פתוחה, בטיפול, סגורה. סטטוסי-המערכת קבועים; אפשר להוסיף סטטוסים-משלנו (כמו 'ממתין-לחלק') שחוסמים או מתירים פעולות.

ללכוד מידע-אירוע מהר וקרוב-למקור, לבנות היסטוריה ניתנת-לניתוח, ולשמש טריגר לתכנון-עבודה. ההודעה מפרידה בין 'דיווח' (זול, מהיר, כל אחד) ל'ביצוע' (מתוכנן, מתומחר). יצירת הודעה — ללכוד את האירוע מהר וברגע-התרחשותו, כדי שלא יישכח ושיתועד עם נתונים מדויקים. סוגי הודעה — להתאים את ההודעה למטרתה — דיווח-תקלה מבקש קוד-נזק; בקשת-תחזוקה מבקשת עדיפות ותאריך-רצוי. תוכן ההודעה — לתעד את האירוע במלואו — מתאר, ניתוח-שורש וזמני-השבתה — לצורך תיקון, חיוב והפקת-לקחים. אובייקטי ייחוס גמישים — לאפשר דיווח ברמת-ההיררכיה הנכונה — לפעמים יודעים רק את הקו, לפעמים את הרכיב המדויק — בלי לכפות רמה אחת. מידע אובייקט — לתת למתכנן הקשר היסטורי ומסחרי מיידי — האם זו תקלה-חוזרת? באחריות? יש כבר הזמנה פתוחה? — לפני שמשקיע בעבודה. פריטי הודעה — לפרק תקלה מורכבת לרכיביה, ולאפשר ניתוח-כשלים מדויק ברמת-החלק (לא רק ברמת-המכונה). קטלוגים ופרופילי קטלוג — לתקנן את אוצר-המילים של התחזוקה — נזקים, סיבות, פעולות — כדי לאפשר ניתוח-מצרפי אמין על-פני אלפי הודעות. סיווג — להרחיב את ההודעה במאפיינים מובְנים ללא פיתוח, ולאפשר חיפוש/דיווח לפי מאפיינים אלה. שותפים — לתעד אחריות ותקשורת — מי ביקש, מי אחראי, את מי ליידע — ולאפשר ניתוב-עבודה ו-SLA. כתובות — לתעד את המיקום הפיזי של העבודה — חיוני לתחזוקה רב-אתרית ולשירות-בשטח (Field Service). מסמכים — להעשיר את ההודעה בתיעוד-ויזואלי ובמסמכים-טכניים — שיפור הבנה, תכנון ותקשורת. הדפסה — לאפשר עבודה מנותקת-מסך ותיעוד-פיזי, בסביבות שבהן לא כל הטכנאים מקוונים. סטטוסי מערכת ומשתמש — לשלוט בזרימת-העבודה ולאכוף תהליך — לדוגמה, למנוע סגירת-הודעה לפני אישור או לחסום עריכה אחרי השלמה.

• Plant Maintenance and Customer Service ► Maintenance and Service Processing ► Maintenance and Service Notifications ► Notification Creation ► Notification Types ► Define Notification Types • Plant Maintenance ► ... ► Notification Processing ► Field Selection for Notifications • Logistics ► Plant Maintenance ► Maintenance Processing ► Notification ► Create (Special) — IW21 • Plant Maintenance ► Maintenance and Service Notifications ► Notification Creation ► Notification Types ► Define Notification Types • Plant Maintenance ► Maintenance and Service Notifications ► Notification Processing ► Define Long-Text Control / Subscreens • Plant Maintenance ► Maintenance and Service Notifications ► Notification Creation ► Notification Types ► Define Screen Templates (Reference Object) • Plant Maintenance ► Maintenance and Service Notifications ► Notification Processing ► Object Information ► Define Object Information Keys • Plant Maintenance ► Maintenance and Service Notifications ► Notification Processing ► Item ► Define Catalogs/Catalog Profile • Plant Maintenance ► Maintenance and Service Notifications ► Notification Creation ► Notification Content ► Maintain Catalogs / Define Catalog Profile • Cross-Application Components ► Classification System ► ... ► Assign Object Types/Class Types to Notifications • Plant Maintenance ► Maintenance and Service Processing ► Maintenance and Service Notifications ► Partners ► Define Partner Determination Procedure • Plant Maintenance ► Master Data ► ... ► Addresses (derived via Functional Location / Equipment) • Cross-Application Components ► Document Management ► Control Data ► Define Document Types (DMS) • GOS — Attachment list (no SPRO needed) • Plant Maintenance ► Maintenance and Service Notifications ► Notification Processing ► Define Shop Papers, Forms, and Output Programs • Cross-Application Components ► General Status Management ► Define Status Profile (BS02) • Plant Maintenance ► ... ► Notifications ► Set User Status / Assign Status Profile

• ההודעה = נקודת-הכניסה של המחזור.
• מתעדת 'מה קרה', לא מבצעת.
• אובייקט-ייחוס הוא לב ההיסטוריה.
• IW21 = יצירת הודעה.
• ברירות-מחדל נמשכות מהאובייקט.
• סטטוס התחלתי OSNO.
• QMART מסווג את ההודעה.
• M1/M2/M3 סטנדרטיים.
• הסוג שולט בקטלוג/שדות/שותפים.
• ההודעה רב-שכבתית.
• זמני-השבתה מזינים MTBF/MTTR.
• פריטים+סיבות = ניתוח-שורש.
• ייחוס גמיש בכל רמת-היררכיה.
• הרמה קובעת היכן ההיסטוריה.
• המתכנן מדייק את האובייקט.
• Object Info = הקשר מיידי.
• מונע כפילויות ומזהה אחריות.
• נשלט ע"י Object Information Key.
• פריט = רכיב שניזוק.
• מפרק תקלה מורכבת.
• בסיס ניתוח-כשלים לפי-רכיב.
• קטלוגים = אוצר-מילים מקודד.
• Profile מקשר קבוצות לסוג-הודעה.
• תקנון בין-מפעלי = ניתוח-תאגידי.
• סיווג = הרחבה ללא פיתוח.
• מאפיינים ניתנים-לחיפוש (AUSP).
• השלמה לשדות-הסטנדרט.
• שותפים = הגורמים המעורבים.
• Procedure קובע תפקידים-נדרשים.
• ב-S/4HANA דרך Business Partner.
• כתובת = מיקום פיזי/איש-קשר.
• נגזרת מ-FL/Equipment/Partner.
• חיוני לתחזוקה רב-אתרית.
• צרף תמונות/שרטוטים להודעה.
• GOS מהיר / DMS מבוקר-גרסה.
• משפר תכנון ותקשורת.
• הדפסת Shop Paper לטכנאי/ארכיון.
• נשלטת ע"י Print Control.
• Adobe Forms ב-S/4HANA.
• סטטוסים מנהלים מחזור-חיים.
• System קבוע / User מותאם (BS02).
• User Status אוכף תהליך דרך Transactions.

בארגון כל עצירת קו-מילוי מתועדת בהודעת M2 הנפתחת ליד הקו. ההודעה נושאת את ה-Functional Location של הקו, את הציוד שכשל, ואת זמן-ההשבתה (Malfunction Start/End) — בסיס לחישוב MTBF של הקו. מפעיל מבחין ברעש חריג במסוע. פותח הודעה IW21 מסוג M2, בוחר Functional Location של הקו, מזין Object Part=מסוע ו-Damage=רעש. המתכנן רואה את ההודעה ברשימת-העבודה (IW28) ומחליט על המשך. יצירת הודעה — בארגון המפעיל פותח הודעת M2 בטאבלט ליד הקו תוך 20 שניות: סורק את ה-Equipment של מכונת-המילוי, בוחר תקלה, ושומר. מפעיל לוחץ Create Notification, בוחר M2, מקליד Equipment של המכונה; ברירות-המחדל (מרכז-עבודה, קבוצת-מתכנן) נטענות אוטומטית מהציוד. כותב תיאור ושומר. סוגי הודעה — בארגון: M2 לכל עצירת-קו (Malfunction), M1 לבקשת-שיפור מהמחלקה, M3 לתיעוד ניקוי-CIP שבוצע. ארגון משתמש ב-M1 לדיווחי-תקלה מהרצפה, M2 לבקשות-תחזוקה מתוכננות, ו-M3 לתיעוד-פעילות בדיעבד. כל סוג עם מסך וקטלוג מותאמים. תוכן ההודעה — בארגון הודעת-קו מלאה מתעדת זמן-עצירה ותחילת/סיום-תקלה — מנהל-המפעל רואה כמה דקות-תפוקה אבדו ומאיזו סיבה. הודעה מלאה: תיאור 'מסוע נעצר', פריט: מסוע/Damage שחיקה, סיבה: חוסר-שימון, פעילות: שימון+החלפת-מיסב, Breakdown 90 דק'. כל זה נשמר לניתוח. אובייקטי ייחוס גמישים — בארגון היררכיה: FL=קו-מילוי ► Equipment=מכונת-מילוי ► Assembly=ראש-מילוי. תקלה מדווחת ברמה הידועה, ומדויקת ע"י המתכנן. מפעיל יודע רק שהקו נעצר → מדווח על ה-Functional Location של הקו. המתכנן מזהה שזו המשאבה → משייך מחדש ל-Equipment של המשאבה לפני יצירת-ההזמנה. מידע אובייקט — בארגון כשפותחים תקלה על משאבה, Object Info מראה שהיא עדיין באחריות-ספק — לכן פותחים תביעת-אחריות במקום לתקן על-חשבון-המפעל. מתכנן פותח הודעה; Object Info מתריע '2 הודעות פתוחות לאותו ציוד החודש'. הוא מאחד אותן במקום לפתוח עבודה כפולה. פריטי הודעה — בארגון תקלת מכונת-מילוי מתועדת בפריטים: ראש-מילוי/דליפה, שסתום/בלאי — לזיהוי הרכיב הבעייתי בקו. תקלת-מסוע: פריט 1 = מסוע/שחיקה; פריט 2 = חיישן/תקלה-חשמלית. כל פריט עם סיבה ופעילות נפרדות. דוח-כשלים מציג איזה רכיב נכשל הכי הרבה. קטלוגים ופרופילי קטלוג — בארגון פרופיל-קטלוג אחיד לכל המפעלים: קוד-סיבה 'בלאי-מיסב' זהה בכל אתר, כך שניתוח-תאגידי מזהה תקלה-חוזרת בכל קווי-המילוי בעולם. פרופיל-קטלוג 'PM-Standard' מקשר Code Groups לנזק/סיבה/פעילות. הודעה חדשה מציגה רק את הקודים הרלוונטיים. דוח שנתי מצרף אלפי הודעות לפי קוד-סיבה. סיווג — בארגון מסווגים הודעות-קו לפי 'מהירות-קו בעת התקלה' ו-'סוג-מוצר' — לניתוח האם תקלות נפוצות במהירות גבוהה או במוצר מסוים. ארגון מוסיף Class עם מאפיינים 'תנאי-סביבה' ו-'משמרת'. כל הודעה מסווגת, ודוח מסנן תקלות לפי משמרת-לילה. שותפים — בארגון הודעת-קו נושאת את מפעיל-הקו כ-Requester ואת ראש-משמרת-התחזוקה כ-Responsible; כך ברור מי דיווח ומי צריך לפעול. הודעה נושאת Requester=מפעיל-קו, Responsible=ראש-צוות-תחזוקה, Department=מילוי. סגירת-ההודעה מיידעת אוטומטית את ה-Requester. כתובות — בארגון עם מספר מפעלים, כתובת-ההודעה נגזרת מה-FL ומציינת את האתר והאזור — חשוב לצוות-תחזוקה אזורי המשרת כמה מפעלים. הודעת-שירות נושאת כתובת-לקוח שנגזרת מה-Equipment המותקן באתרו; הטכנאי-בשטח רואה היכן להגיע. מסמכים — בארגון מפעיל מצלם דליפה במכונת-המילוי ומצרף ל-GOS; המתכנן מזהה את הרכיב ומתכנן תיקון מדויק מרחוק. מפעיל מצרף תמונת-נזק ל-GOS; המתכנן רואה את הסדק ומזמין את החלק הנכון מראש בלי לרדת לקו. הדפסה — בארגון רוב התהליך דיגיטלי (Fiori/טאבלט), אך לעבודות-חוץ באתרי-הפצה מרוחקים מדפיסים את ההודעה כגיבוי-נייר. באזור ללא-כיסוי-רשת, המתכנן מדפיס את ההודעה כ-Shop Paper ומוסר לטכנאי; אחרי הביצוע הנתונים מוקלדים בחזרה. סטטוסי מערכת ומשתמש — בארגון הודעת-קו עם User Status 'ממתין-לאישור-מנהל-משמרת' חוסמת המרה-להזמנה עד שמנהל-המשמרת מאשר — אכיפת-תהליך אוטומטית. הודעה: OSNO ➔ (החל-עיבוד) NOPR ➔ (משימות הושלמו) ➔ NOCO. User Status 'ממתין-לאישור-בטיחות' חוסם יצירת-הזמנה עד אישור.

• Notification Type (QMART): קטגוריית-הודעה (PM/QM), Catalog Profile, Partner Determination, Number Range. • Field Selection: שדות חובה/אופציונליים/מוסתרים לכל סוג-הודעה. • Screen Templates / Subscreen-categories לכל סוג. יצירת הודעה • וודא Number Range לסוג-ההודעה. • הגדר ברירות-מחדל הנמשכות מהאובייקט (Work Center/Planner Group). סוגי הודעה • הגדר QMART ➔ Category, Catalog Profile, Partner Schema, Number Range. • העתק מסוג-סטנדרטי (M1/M2/M3) ליצירת Z-type. תוכן ההודעה • הגדר אילו תת-מסכים (פריטים/סיבות/פעילויות/משימות) פעילים לסוג. • הגדר Breakdown indicator ושדות-זמן. אובייקטי ייחוס גמישים • הגדר Reference Object View לכל סוג-הודעה: אילו אובייקטים מותרים (EQ/FL/Assembly/Serial). מידע אובייקט • הגדר Object Information Key: טווח-זמן, מה לספור (הודעות/הזמנות), הצגת אחריות/חוזה. • שייך את ה-Key לסוג-ההודעה. פריטי הודעה • הגדר קטלוג Object Part (B) ו-Damage (5/B). • קשר אותם ב-Catalog Profile לסוג-ההודעה. קטלוגים ופרופילי קטלוג • הגדר Code Groups ו-Codes (QS41). • בנה Catalog Profile (T350) המקבץ קבוצות לכל קטלוג-סוג. • הקצה את הפרופיל לסוג-ההודעה או לאובייקט. סיווג • הגדר Characteristics (CT04) ו-Class (CL02) מסוג-המחלקה המתאים להודעות. • שייך Class Type להודעה ב-Customizing. שותפים • הגדר Partner Functions ו-Partner Determination Procedure. • שייך את הסכמה לסוג-ההודעה; סמן חובה/אופציונלי. כתובות • הגדר נגזרת-כתובת מה-FL/Equipment/Partner. • אפשר הזנת-כתובת ידנית לפי הצורך. מסמכים • להנדסי-גרסה: הגדר Document Types ב-DMS (CV01N). • ל-GOS: ודא Content Repository מוגדר (OAC0). הדפסה • הגדר Shop Papers (Forms) לסוג-ההודעה. • הגדר Printer Determination ו-Output device. סטטוסי מערכת ומשתמש • הגדר User Status Profile (BS02): סטטוסים, סדר, ראשוני/סופי. • הגדר influence על Business Transactions (Allowed/Forbidden/Warning). • שייך את הפרופיל לסוג-ההודעה.

שאלות ראיון מהי הודעת-PM? מסמך המתעד אירוע-תחזוקה (תקלה/בקשה/פעילות) עם אובייקט-ייחוס, קודי-קטלוג וסטטוס; נשמרת ב-VIQMEL/QMEL ומשמשת היסטוריה וטריגר-לתכנון. מה מבדיל בין סוגי-הודעה? Catalog Profile, Field Selection, Partner Determination ו-Number Range — כולם נשלטים דרך QMART. מהו הסטטוס ההתחלתי של הודעה חדשה? OSNO (Outstanding) — ההודעה פתוחה וממתינה לעיבוד/החלטה. מהם M1, M2, M3? M1=Malfunction Report (תקלה), M2=Maintenance Request (בקשה), M3=Activity Report (תיעוד-פעילות) — סוגי-ההודעה הסטנדרטיים של PM. אילו זמנים מזינים את ה-MTBF? Malfunction Start/End ו-Breakdown indicator בהודעה; הם נותנים את Breakdown Duration שעליו נשען MTBF/MTTR. לאילו אובייקטים יכולה הודעה להתייחס? Equipment, Functional Location, Assembly, Material/Serial או Maintenance Object — בכל רמת-היררכיה, לפי ה-View Profile. מה מציג Object Information? הקשר מיידי על האובייקט: הודעות/הזמנות פתוחות בטווח, סטטוס-אחריות, חוזה-שירות ונתוני-מחזור — נשלט ע"י Object Information Key. מהו פריט-הודעה? תיאור רכיב-ספציפי שניזוק: Object Part + Damage Code (נשמר ב-QMFE); מאפשר ניתוח-כשלים ברמת-החלק. מהו פרופיל-קטלוג? אוסף Code Groups לכל קטלוג-סוג (Damage/Cause/Activity/Object Part), המוקצה לסוג-הודעה וקובע אילו קודים זמינים. מהו המבנה ההיררכי של קטלוג? Catalog Type ► Code Group ► Code; מנוהל ב-QS41 ומקובץ ל-Profile. מתי להשתמש בסיווג בהודעה? כאשר נדרש מאפיין שאין לו שדה-סטנדרט; Classification מרחיב ללא Z-fields ומאפשר חיפוש/דיווח לפי המאפיין. מה קובע Partner Determination Procedure? אילו תפקידי-שותף (Requester/Responsible/Department) זמינים/חובה בהודעה; מוקצה לסוג-ההודעה ונשמר ב-IHPA. מהיכן נגזרת כתובת-ההודעה? מה-Functional Location, מהציוד או מהשותף (דרך ADRC/ILOA); ניתן גם להזין ידנית — חיוני לשירות-בשטח. מה ההבדל בין GOS ל-DMS לצירוף מסמכים? GOS = קבצים חופשיים מהירים (Attachment list); DMS = Document Info Record מנוהל-גרסאות (CV01N), מועדף לשרטוטים-הנדסיים. כיצד נשלטת הדפסת-הודעה? דרך Print Control / Shop Papers לפי סוג-הודעה ואירוע; ב-S/4HANA מועדף Adobe Forms עם Printer Determination. מה ההבדל בין System ל-User Status? System Status קבוע ע"י SAP (OSNO/NOPR/NOCO) ב-JEST; User Status מוגדר-ארגונית ב-Status Profile (BS02) ויכול לחסום/לאפשר Business Transactions. כיצד סטטוס חוסם פעולה? דרך influence על Business Transactions בפרופיל (Forbidden/Allowed/Warning). נושאים קשורים • PM Academy · מחזור פקודת-העבודה • אובייקט · VIQMEL

• ההודעה לא בהיסטוריית-הציוד ➔ לא הוזן Reference Object (Equipment/FL). • שדות-קטלוג חסרים ➔ Catalog Profile לא מקושר לסוג-ההודעה. • לא ניתן לסגור הודעה ➔ משימות (QMSM) פתוחות. יצירת הודעה • לא נוצר מספר-הודעה ➔ Number Range חסר/מלא. • ברירות-מחדל לא נטענות ➔ האובייקט חסר Work Center/Planner Group. סוגי הודעה • שדות שגויים בהודעה ➔ QMART עם Field Selection/Category לא-נכונים. תוכן ההודעה • Breakdown Duration ריק ➔ לא סומן Breakdown או חסרים זמני Malfunction. • אין נתוני-שורש ➔ פריטים/סיבות לא הוזנו. אובייקטי ייחוס גמישים • היסטוריה לא נמצאת ברכיב ➔ דווח ברמת-FL ולא עודכן ל-Equipment. • אובייקט לא ניתן-לבחירה ➔ View Profile חוסם את סוג-האובייקט. מידע אובייקט • Object Info ריק ➔ לא הוקצה Key לסוג-ההודעה. • אחריות לא מוצגת ➔ Warranty לא מתוחזק על-האובייקט. פריטי הודעה • ניתוח-כשלים לא-מדויק ➔ פריט-יחיד במקום פירוק. • קודי-נזק לא-זמינים ➔ Catalog Profile חסר. קטלוגים ופרופילי קטלוג • קודים לא-זמינים בהודעה ➔ Catalog Profile לא מוקצה/חסר Code Group. • ניתוח-תאגידי לא-עקבי ➔ קטלוגים שונים בין מפעלים. סיווג • לא ניתן לסווג הודעה ➔ Class Type לא מוקצה. • חיפוש לפי מאפיין ריק ➔ לא בוצע סיווג בפועל. שותפים • שותף לא ניתן-להזנה ➔ לא בסכמת ה-Partner Determination. • Business Partner לא נמצא ➔ לא הוקם ב-BP. כתובות • כתובת ריקה בהודעה ➔ לא מתוחזקת ב-FL/Equipment. • כתובת שגויה ➔ מקור-הנגזרת לא-מעודכן. מסמכים • קובץ לא נשמר ➔ Content Repository לא מוגדר. • אין ניהול-גרסה ➔ נעשה שימוש ב-GOS במקום DMS. הדפסה • הודעה לא מודפסת ➔ Shop Paper/Printer Determination לא מוגדרים. • פלט ריק ➔ Form לא-מותאם לסוג. סטטוסי מערכת ומשתמש • פעולה חסומה ולא-מובן מדוע ➔ בדוק System+User Status (כפתור 'i' של Status). • User Status לא-זמין ➔ Profile לא-מוקצה לסוג.

• ההודעה = נקודת-הכניסה של המחזור. • מתעדת 'מה קרה', לא מבצעת. • אובייקט-ייחוס הוא לב ההיסטוריה. • IW21 = יצירת הודעה. • ברירות-מחדל נמשכות מהאובייקט. • סטטוס התחלתי OSNO. • QMART מסווג את ההודעה. • M1/M2/M3 סטנדרטיים. • הסוג שולט בקטלוג/שדות/שותפים. • ההודעה רב-שכבתית. • זמני-השבתה מזינים MTBF/MTTR. • פריטים+סיבות = ניתוח-שורש. • ייחוס גמיש בכל רמת-היררכיה. • הרמה קובעת היכן ההיסטוריה. • המתכנן מדייק את האובייקט. • Object Info = הקשר מיידי. • מונע כפילויות ומזהה אחריות. • נשלט ע"י Object Information Key. • פריט = רכיב שניזוק. • מפרק תקלה מורכבת. • בסיס ניתוח-כשלים לפי-רכיב. • קטלוגים = אוצר-מילים מקודד. • Profile מקשר קבוצות לסוג-הודעה. • תקנון בין-מפעלי = ניתוח-תאגידי. • סיווג = הרחבה ללא פיתוח. • מאפיינים ניתנים-לחיפוש (AUSP). • השלמה לשדות-הסטנדרט. • שותפים = הגורמים המעורבים. • Procedure קובע תפקידים-נדרשים. • ב-S/4HANA דרך Business Partner. • כתובת = מיקום פיזי/איש-קשר. • נגזרת מ-FL/Equipment/Partner. • חיוני לתחזוקה רב-אתרית. • צרף תמונות/שרטוטים להודעה. • GOS מהיר / DMS מבוקר-גרסה. • משפר תכנון ותקשורת. • הדפסת Shop Paper לטכנאי/ארכיון. • נשלטת ע"י Print Control. • Adobe Forms ב-S/4HANA. • סטטוסים מנהלים מחזור-חיים. • System קבוע / User מותאם (BS02). • User Status אוכף תהליך דרך Transactions.