איך לשלב MES עם ERP: מנקודת המבט של קומת הייצור

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

איך לשלב MES עם ERP מצד ה-MES: מה קומת הייצור צריכה מה-ERP, מה ה-ERP צריך בחזרה, איך להתאים נתוני מאסטר ואילו מלכודות פרויקט כדאי להימנע מהן.

Automatically translated with AI from the original post. Read the English original

כדי לשלב MES עם ERP, הסכימו תחילה על רשימה קצרה של עצמי נתונים והודעות, ואז בנו אותם לפי הסדר הבא: נתוני מאסטר, שחרור הזמנות, משוב מקומת הייצור וטיפול בשגיאות. מנקודת המבט של MES, המשימה פשוטה: לקבל מה לייצר, ולדווח מה קרה. החלקים הקשים הם שתי המערכות חייבות להתכוון לאותו דבר במונחים "פריט", "פעולה" ו"הושלם", וצריך שמישהו יהיה אחראי על השגיאות. מאמר זה מיועד למנהלי מפעלים שאחראים על צד קומת הייצור בפרויקט.

עיקרי הדברים

• מנקודת המבט של ה-MES, לשילוב יש שני תפקידים: לקבל מה לייצר ועם אילו נתונים, ולדווח בחזרה מה קרה בצורה שה-ERP יכול לרשום.
• הודעות הזמנה ונתוני עזר הם זרמים שונים: בממשק MES של Microsoft, מוצרים, עצי מוצר ומסלולים נשלפים בנפרד דרך ישויות נתונים (data entities) או OData.
• הסכימו על המשמעות של "הושלם", על אופן דיווח הפסולת ועל אופן ביצוע התיקונים לפני שבונים כל ממשק.
• לנתוני המאסטר צריך להיות בעלים, מיפוי מזהים ותיאום קבוע, שכן ה-MES יורש כל שגיאה במסלולי הייצור ובזמנים שב-ERP.
• בדקו כשלים בכוונה, והחליטו מי רואה הודעה שנכשלה, כי תור שקט של אישורים שנדחו מסתיים בפערים במלאי.

מה ה-MES צריך מה-ERP?

שלושה דברים, והם מועברים בדרכים שונות.

ראשית, הזמנות. ה-MES צריך הוראות ייצור משוחררות עם מוצר, כמות, תאריכים ובהמשך עדכוני סטטוס. בـממשק Microsoft ל-MES של צד שלישי, ה-MES מאזין לאירוע עסקי כאשר הזמנה משתחררת או משנה סטטוס. מערכות ERP אחרות משתמשות במנגנונים אחרים, אבל העיקרון נשאר: ה-ERP מודיע וה-MES קולט.

שנית, נתוני עזר. אלה התיאור של אופן ייצור המוצר: פריטים, עצי מוצר, מסלולים וזמני הכנה. אותו דף של Microsoft קובע שההודעות שלו מכסות רק אירועים בקומת הייצור ואינן נושאות נתוני מאסטר. ה-MES שולף מוצרים, עצי מוצר ומסלולים מה-ERP דרך ישויות נתונים או OData. תכננו זאת כמשימת שילוב שנייה, כי זו המשימה שצוותים שוכחים.

שלישית, מידע על משאבים. תקן ISA-95 מגדיר ארבעה סוגי מידע שמערכות מחליפות בין רמת הארגון לרמת התפעול: חומר, ציוד, נכסים פיזיים, וכוח אדם עם תפקידיו והכשרותיו. אם ה-MES מקצה עבודה לפי מיומנות או לפי יכולת מכונה, הוא צריך את הגרסה של ה-ERP, או של מערכת משאבי האנוש, של העובדות האלה. הגדירו בבירור איזו מערכת היא המקור.

אם אתם משתמשים ב-SAP, ב-Dynamics 365 או בכל מערכת ERP אחרת, השאלות זהות. רק השמות הטכניים משתנים.

מה ה-ERP צריך בחזרה מה-MES?

חשבו על זה כעל אישורים. התיעוד של Microsoft מפרט את התהליכים הבאים לממשק שלו: פתיחת הזמנה, דיווח על כמויות שיוצרו ושנפסלו, דיווח על צריכת חומרים, דיווח על זמן שהושקע בפעולה, וסגירת ההזמנה. לכל אחד מהם יש סוג הודעה נפרד. הודעת סיום צריכה רק את מספר הזמנת הייצור, ואילו הודעת כמות נושאת שורות שיכולות לכלול את הפריט, כמות התקינה וסיבת שגיאה במקרה של פסולת.

אין צורך להעתיק את המודל הזה. עם זאת, יש להחליט על הנקודות הבאות לפני הבנייה:

• כמה מפורט אישור צריך להיות? לפי הזמנה, לפי פעולה או לפי משמרת?
• האם מפעיל יכול לאשר כמות חלקית, ומה ה-ERP עושה איתה?
• איך מדווחים על פסולת, ואילו קודי סיבה קיימים בשתי המערכות?
• האם צריכת החומרים נמדדת בתחנה, או שה-ERP מחשב אותה מתוך רשימת החומרים?
• איך מתקנים טעויות: ביטול, התאמה או אישור חדש?
• מה המשמעות של "גמור" ומה המשמעות של "נסגר"? בסקירת תהליך הייצור של Microsoft, דיווח כגמור מוסיף את הסחורה למלאי, ואילו סגירת ההזמנה מחשבת את העלות בפועל חוסמת רישומי עלות נוספים. ייתכן שה-ERP שלכם מגדיר את הגבול במקום אחר.

השאלה האחרונה גורמת לוויכוחים הרבה ביותר. תכנון, כספים ואיכות קוראים את אותו סטטוס, וכל אחד מהם מצפה ממנו משהו שונה. יישבו את ההגדרות בפגישה קצרה עם שלושתם לפני שמישהו כותב ממשק.

איך מתאימים נתוני מאסטר בין ה-MES ל-ERP?

הזמנות הן עסקאות. נתוני מאסטר הם תיאור התהליך שלכם, וה-MES יורש כל טעות שיש בו. נתיב ייצור שמציין פעולה של 12 דקות שבפועל לוקחת 20 דקות ייראה כבעיית ביצועים בקו הייצור, עד שמישהו יתקן אותו.

עברו על הנקודות הבאות עבור קו הפיילוט:

1. ציינו את הבעלים של כל ישות. סידור נפוץ הוא שה-ERP הוא הבעלים של פריטים, רשימות חומרים ונתיבי ייצור, וה-MES הוא הבעלים של הגדרות תחנה והוראות עבודה. זו המלצה, לא כלל מחייב. מה שחשוב הוא שאף אחד לא יצטרך לנחש.
2. מפו מזהים. מרכז העבודה "WC-110" ב-ERP עשוי להיות "Press 3" בקו הייצור. ל-ISA-95 אפילו יש חלק שעוסק בכך: מודל שירות הכינויים שלו מגדיר כיצד מזהים שווי ערך משויכים ומתמפים, לפי התיאור של ISA לתקן.
3. השוו פעולות. רשמו את השלבים בנתיב הייצור של ה-ERP ואת השלבים שהמפעילים מבצעים בפועל. הפערים מתגלים מהר, למשל שלב בדיקה או ליטוש שקיים רק בקו הייצור.
4. בדקו יחידות מידה, לוחות שנה ואזורי זמן. חתיכות לעומת קרטונים, וזמן מקומי לעומת UTC, גורמים לשגיאות שקטות.
5. קבעו כלל לשינויים. כאשר ההנדסה משנה נתיב ייצור, מי מודיע ל-MES, כמה מהר ההודעה מגיעה, ומה קורה להזמנות שכבר נמצאות בביצוע?
6. חזרו על ההשוואה לפי לוח זמנים. נתוני מאסטר נוטים להתסיט.

הנה מקרה היפותטי. לנתיב ייצור ב-ERP יש שלוש פעולות, אבל המפעילים מבצעים חמש, משום שבדיקה וליטוש נוספו לפני שנים ומעולם לא הוזנו לנתיב. ה-MES יכול לדווח רק על מה שיש בנתיב. לכן ה-ERP מציג את פעולה שלוש כמאחרת, בעוד שבקו הייצור פשוט עובדים על שלבים שה-ERP לא מכיר. אף אחד לא עשה שום דבר שגוי. הנתונים לא שלמים. הדוגמה בדויה, אבל מפעלים נתקלים בפער מסוג זה כל הזמן.

לגבי פורמטים של קבצים, כדאי להכיר את B2MML. MESA מתארת אותו כסט של הגדרות סכמת XML המממשות את ISA-95, המשמש לשילוב מערכות עסקיות כמו ERP עם מערכות ייצור כמו MES. גרסה 7 הוסיפה סכמת JSON ראשונה. שימוש בסכמה מפורסמת נותן לכם אוצר מילים משותף כנקודת פתיחה, אם כי הוא אינו מבטל את הצורך להסכים על המשמעות של כל שדה.

איך הממשק צריך להתנהג כשמשהו משתבש?

נתיב ההצלחה יעבוד בהדגמה. השקיעו את זמן הפרויקט בנתיבים האחרים.

ההתנהגות של מוצר Microsoft מתוארת בתיעוד, וזו נקודת פתיחה טובה לשאלות שכדאי להפנות לספק שלכם. הודעות עבור אותה הזמנת ייצור מעובדות לפי הסדר שבו התקבלו. הודעות עבור הזמנות שונות עשויות להיות מעובדות שלא לפי הסדר, מאחר שעבודות אצווה רצות במקביל. הודעה שנכשלה מנסים לשלוח שוב עד שלוש פעמים, ואז היא מסומנת ככשלה. עמוד ניטור מאפשר לבדוק, לתקן ולעבד מחדש הודעות שנכשלו, וניתן להגדיר התראה שתעדכן מנהל IT או מנהל רצפת ייצור.

כדי להפוך זאת לארבע שאלות עבור כל זוג ERP ו-MES:

• מה קורה לאישור ייצור שה-ERP דוחה, למשל מפני שההזמנה כבר נסגרה?
• מי רואה את הכשל, ומה מהירות ההתראה?
• האם רצפת הייצור יכולה להמשיך לעבוד כשה-ERP אינו זמין, ולשלוח את כל הנתונים לאחר מכן לפי הסדר הנכון?
• האם אותו אישור יכול להגיע פעמיים מבלי להירשם פעמיים?

אם אף אחד אינו אחראי על הודעות שנכשלו, הן יצטברו עד שמישהו יגלה פער במלאי בסוף החודש. ציינו אדם בשם, לא צוות.

האם סוג הייצור משנה את האינטגרציה?

כן. במאמר של Automation World על יישום ISA-95, הנדסה לפי הזמנה מכונה אולי האינטגרציה התובענית ביותר, מאחר שמערכות הארגון ומערכות הבקרה חייבות להחליף מידע כמעט בזמן אמת. תעופה היא הדוגמה: התכנונים מניעים את התכנון אך עשויים להשתנות במהלך הביצוע. כאשר מתרחש שינוי, הביצוע נעצר עד שהתכנון משקף אותו, ופעולות חדשות, כמו בדיקות נוספות, מועברות לרצפת הייצור. המאמר מזהיר גם כי פרשנויות שונות של ספקים לתקנים עלולות לגרום לבעיות תאימות הדדית.

מכאן נובעים שני לקחים. אם המוצרים שלכם מוגדרים או מתוכננים לפי הזמנה, שלבו את מקרה השינוי כבר בפיילוט הראשון, לא באחרון. ובדקו ממשקים מבוססי תקנים עם הנתונים שלכם, מאחר ש"סטנדרטי" אינו אומר "זהה".

איך משלבים MES עם ERP שלב אחר שלב?

שמרו על היקף צר ובדיקות יומיות.

1. בחרו קו אחד ומשפחת מוצרים אחת.
2. כתבו טבלת ממשק הכוללת אובייקט, שולח, מקבל, טריגר, תדירות ובעלים. שורה ללא בעלים היא הסיכון הראשון שלכם.
3. התאימו את נתוני הבסיס למשפחת המוצרים הזו, כפי שתואר לעיל.
4. הסכימו על סטטוסים ועל המשמעות של "הושלם", "גרוטאה" ו"תיקון".
5. בנו קודם הזמנות, אישורי התחלה וסיום. הוסיפו חומרים וזמנים לאחר מכן.
6. בדקו כשלים בכוונה: שלחו כמות שגויה, עצרו את הממשק, הפעילו אותו מחדש ושלחו כפילות.
7. החליטו מה יקרה להזמנות שכבר רצות ביום העלייה לאוויר.
8. הריצו את התהליך החדש לצד התהליך הישן במשך כמה שבועות, והשוו מדי יום כמות תקינה, גרוטאה, שעות וחומרים לכל הזמנה בשתי המערכות.
9. ספרו את השלבים הנוספים למפעילים. אם אישור במערכת ה-MES לוקח יותר זמן מטופס הנייר, בררו מדוע לפני שממשיכים להרחיב.
10. הרחיבו לקו הבא רק כאשר ההבדלים מוסברים.

טעויות נפוצות

• התייחסות לנתוני הבסיס כאל טעינה חד-פעמית במקום כמשימה מתמשכת.
• תכנון הממשק מנקודת המבט של ה-ERP בלבד, כך שה-MES אינו יכול לדווח ברמת הפירוט שבה עובדת רצפת הייצור.
• שימוש באותה מילת סטטוס עם משמעויות שונות בכל מערכת.
• היעדר כלל להזמנות בעבודה בזמן העלייה לאוויר.
• בדיקה רק של המסלול התקין.
• השארת הודעות שנכשלו ללא בעלים.
• בקשה ממפעילים להזין את אותם נתונים פעמיים, פעם בכל מערכת.

היכן Polaris מתאים

אם הבעיה שלכם היא הלולאה שבין תכנון ה-ERP לרצפת הייצור, כדאי לבחון את iFAKT Polaris כאפשרות אחת. iFAKT מתארת את Polaris כשילוב של AI ותאום דיגיטלי לייצור שעובד עם נתוני ERP. המודול Polaris Designer הופך נתוני ERP, רשימות חומרים, זמני תהליך ומבני משאבים לגרף ידע של מוצר, תהליך ומשאב. המודול Polaris Operator מביא תוכניות לרצפת הייצור כמשימות מבוססות זמן, ומזין חזרה לתכנון התקדמות, עיכובים ושיבושים. השאלה אילו אישורים ה-ERP שלכם חייב לרשום לצורך מלאי, עלויות ועקיבות נפרדת, ולכן רשמו אותם לפני שמחליטים מה הכלי אמור לכסות.

נושאים קשורים לחקירה

• ISA-95 בשפה פשוטה: אילו פעילויות שייכות לרמת ה-ERP ואילו לרמת התפעול.
• תכנון בלולאה סגורה: איך אישורים מקו הייצור משנים את לוח הזמנים הבא.
• אבטחת החיבור בין רשתות המפעל לרשתות העסקיות: חשבונות, הפרדה לקטעי רשת ועדכוני אבטחה לממשקים.
• דיווח מקו הייצור ללא MES מלא: מה סריקות ואישורים פשוטים יכולים לכסות.

הצעד הבא

בחרו משפחת מוצרים אחת ורשמו בטבלה כל אובייקט שחייב לעבור בין ה-MES לבין ה-ERP, עם השולח, המקבל והבעלים. אם אתם רוצים לשלב MES עם ERP בלי הפתעות, הביאו את הטבלה הזו לפגישה הראשונה עם צוות ה-IT והספק שלכם.