M365Con 2027 – כנס אונליין חינמי · 11–22 Jan 2027 · 120 sessions→ m365con.net

בלוג · Mirko Peters

אינטגרציית 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 ·

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

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

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

עיקרי הדברים

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

מה כולל רוחב היישום של אינטגרציית ERP עם תוכנת מפעל חכם?

התחילו בתמונה משותפת של השכבות. תקן ISA-95, המכונה גם IEC 62264, מתואר על ידי ISA כסט תקנים בינלאומי לשילוב מערכות עסקיות ולוגיסטיות עם מערכות בקרת ייצור. הוא משתמש במודל חמש רמות המבוסס על Purdue Reference Model, ומעניק לצוותי הייצור וה-IT מונחים משותפים לפרויקטים של אינטגרציה.

הסיכום של OPC Foundation על ISA-95 מציג את הרמות כך:

  • רמות 0 עד 2 מכסות את התהליך הפיזי, חיישנים ומפעילים, ואוטומציה ובקרה על גבי PLC.
  • רמה 3 היא ניהול תפעול הייצור. היא פועלת בטווח של שניות עד ימים, וכוללת תזמון, מעקב עבודה, איכות ופונקציות מלאי.
  • רמה 4 היא תכנון עסקי ולוגיסטיקה, פועלת בטווח של ימים עד חודשים, ובדרך כלל במערכת ERP.

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

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

אילו נתונים צריכים לזרום, ובאיזה כיוון?

כדאי לחשוב על שני זרמים: הזמנות יורדות מלמעלה למטה, ומשוב עולה מלמטה למעלה, ועוד זרם שלישי לנתוני אב.

Microsoft מתעדת דוגמה קונקרטית. האינטגרציה של Dynamics 365 Supply Chain Management עם מערכות ביצוע ייצור (MES) של צדדים שלישיים מיועדת לחברות שעובדות עם MES חיצוני במקום בפונקציות הרצפה המובנות. היא מכסה את התהליכים הבאים:

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

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

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

מדוע נתוני אב הם החוליה החלשה?

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

באיזו מהירות הנתונים צריכים לנוע?

"זמן אמת" היא המילה המנופחת ביותר בתחום הזה, ולכן הפכו אותה למספר.

ISA-95 עצמו מתייחס לכך לפי רמה. בסיכום OPC, זמן אמת ברמה 3 פירושו שניות לאחר אירוע ברצפה, וברמה 4 פירושו מדי יום או בתוך שעות אחרי משמרת. אלו הבטחות שונות מאוד, והן עולות סכומים שונים.

לכל זרם, שאלו איזו החלטה הוא תומך בה:

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

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

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

איך מחברים בין המערכות?

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

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

כשאתם משווים הצעות, שאלו את השאלות הבאות:

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

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

מה לגבי אבטחה?

חיבור רצפת הייצור למערכות עסקיות יוצר נתיב חדש אל ציוד שהיה מבודד בעבר. המדריך Guide to Operational Technology Security של NIST, SP 800-82 גרסה 3, מכסה טופולוגיות OT טיפוסיות, איומים ופגיעויות נפוצים ואמצעי נגד, תוך התחשבות בדרישות הביצועים, האמינות והבטיחות של מערכות OT. קראו אותו, או בקשו מצוות האבטחה שלכם לקרוא, לפני שהתכנון נסגר.

כמה כללים מעשיים נובעים מכך, ללא התמקדות במוצר מסוים:

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

איך כדאי להריץ את הפרויקט?

שמרו עליו קטן וניתן למדידה.

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

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

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

היכן Polaris משתלב

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

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

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

הצעד הבא

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

עקבו אחרי הפודקאסטSpotify

Entities in this article

Industry 4.0 Enterprise resource planning (ERP) Manufacturing execution system (MES) ISA-95 Dynamics 365 Supply Chain Management Polaris Designer Polaris Operator iFAKT GmbH

Related articles

RSS

תוכן ממומן

iFAKT GmbH