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

בלוג · Mirko Peters

נתוני מודל סימולציה: מאיפה הם מגיעים ובאיזו רמת דיוק הם חייבים להיות

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 ·

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

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

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

עיקרי הדברים

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

נתוני מודל סימולציה: מה המודל צריך

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

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

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

מאיפה מגיעים נתוני קלט של סימולציה: איסוף נתונים בפועל

מאמר של Maja Bärring ועמיתיה בכנס Winter Simulation Conference 2018 מתאר את המקורות בשתי קבוצות, בהמשך לעבודה קודמת של Anders Skoogh ועמיתיו.

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

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

מדוע הנתונים לרוב אינם טובים מספיק

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

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

המחברים מציינים גם כי מערכות ERP מדגישות ערכים דטרמיניסטיים על פני ערכים סטוכסטיים, ולכן לעיתים קרובות חסרה השונות שסימולציה זקוקה לה. במקרה השני, איסוף אוטומטי מנע חמש מתוך שמונה הבעיות שהם מונים. המאמר ממליץ, בין היתר, להקצות בעלות על הנתונים לפונקציות בתוך החברה. סקר של סקוג', פררה ויוהנסון שפורסם ב-Simulation Modelling Practice and Theory מצא כי כ-80% ממשתמשי הסימולציה עדיין נשענים על נהלי עבודה ידניים מאוד עבור נתוני הקלט.

ניתוב ורשימת חומרים בסימולציה

שני סוגים של נתוני מאסטר גורמים לעיתים קרובות לבעיות. הניתוב (routing) קובע אילו פעולות דרושות למוצר, באיזה סדר, על איזה משאב ובאיזה זמן. רשימת החומרים (bill of materials) קובעת אילו חלקים נכנסים למוצר. במודל זרימה, הניתוב הוא בדרך כלל עמוד השדרה, ורשימת החומרים חשובה כאשר חלקים עלולים להיעדר או כאשר תחנה ממתינה להרכבה של תת-מכלול.

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

עד כמה איכות נתוני הסימולציה חייבת להיות טובה?

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

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

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

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

דוגמה: זמן ניתוב מול זמן בפועל

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

  • תפוקה לשעה עם זמן הניתוב: 3,600 ÷ 42 = 85.7 חלקים.
  • תפוקה לשעה עם הזמן בפועל: 3,600 ÷ 47 = 76.6 חלקים.
  • הניתוב מגזים בקצב בכ-12 אחוזים: 85.7 ÷ 76.6 = בערך 12 אחוזים. במשמרת של 8 שעות זה כ-686 חלקים לעומת 613, כלומר פער של 73 חלקים.

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

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

שימוש נכון בנתונים: תוכנית בשישה צעדים

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

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

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

איך תוכנה יכולה לעזור

גרף ידע שמקשר בין מוצרים, שלבי תהליך ומשאבים יכול לצמצם נתונים כפולים ומסתירים, מכיוון שכל עובדה נשמרת פעם אחת. iFAKT's Polaris Designer הוא מודול של iFAKT Polaris שבונה גרף ידע מסוג מוצר-תהליך-משאב (PPR) כמקור האמת היחיד למוצרים, שלבי תהליך ומשאבים. הוא אינו מחליף את הבדיקה מול זמנים בפועל, את הבעלים או את אימות המודל. לא משנה באיזה כלי תשתמשו, שאלו כיצד הוא מייבא נתונים מה-ERP וה-MES ואיך שינויים נעקבים.

הצעד הבא

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

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

Entities in this article

Factory simulation Polaris Designer Manufacturing execution system (MES)

Related articles

RSS

תוכן ממומן

iFAKT GmbH