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

בלוג · Mirko Peters

ניתוח תרחישי What-If בתכנון ייצור: שיטה

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 ·

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

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

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

עיקרי הדברים

  • תרחיש what-if לוקח את תוכנית הבסיס שלכם, משנה הנחה אחת, כמו תקלה במכונה או הזמנה דחופה, ומשווה את התוצאה לבסיס לפני שמשהו קורה בפועל.
  • התחילו מההחלטה, ואז בחרו שניים או שלושה מנופים ושניים או שלושה מדדי KPI, כי תרחיש בלי החלטה שעומדת מאחוריו הוא רק תרגיל.
  • שנו מנוף אחד בכל פעם, ושלבו מנופים רק אחרי שהבנתם את ההשפעה של כל אחד לבדו.
  • בדקו את המודל מול תקופה עברית לפני שאתם סומכים עליו לתקופה עתידית, כי ערכו של מודל תלוי בכך שהתוצאות שלו מדויקות מספיק למטרה שלשמה הוא נועד.
  • כלי Microsoft מכסים חלק מהעבודה: תוכניות אב ב-Dynamics 365 יכולות להחזיק אסטרטגיות תכנון חלופיות, ופרמטרים של what-if ב-Power BI מתאימים לחישובים פשוטים, לא לרצף לוחות זמנים.

מהו תרחיש what-if, ומה הוא לא?

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

שווה להפריד בין שלושה רעיונות שאנשים נוטים לבלבל ביניהם.

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

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

אילו החלטות שוות תרחיש?

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

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

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

איך מריצים ניתוח תרחישי what-if בייצור?

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

  1. רשמו את ההחלטה. משפט אחד: "עלינו להחליט על X עד יום שישי." אם אינכם מצליחים לנסח זאת, עדיין אין צורך בתרחיש.
  2. הקפאת קו הבסיס. שמרו את התוכנית הנוכחית יחד עם ההנחות שלה: לוחות זמנים, זמני מחזור, רשימת הזמנות וזמינות חומרים. כל תרחיש יושווה לגרסה הזו, ולכן היא לא צריכה להשתנות תחת ידיכם.
  3. בחרו את המנופים. מנופים הם הדברים שאתם יכולים לשנות, או דברים שעשויים להשתנות: קיבולת, כוח אדם, סדרי עדיפויות של הזמנות, תאריכי יעד והגעת חומרים. בחרו שניים או שלושה שחשובים להחלטה הזו.
  4. קבעו טווחים ריאליים. שאלו את האנשים שיודעים. כמה זמן לוקח תיקון טיפוסי? באיזו תדירות ספקים מאחרים באספקה, וכמה? אל תמציאו מספרים; השתמשו בהיסטוריה שלכם, וסמנו כל הערכה ככזו.
  5. בחרו את המדדים. שניים או שלושה מדדי KPI מספיקים: אספקה בזמן, זמן אספקה (lead time), ניצולת צוואר הבקבוק, שעות נוספות ו-work in process. הגדירו אותם לפני שמריצים דבר, כדי שאף אחד לא יבחר אחר כך את המדד שנוח לו.
  6. שנו מנוף אחד בכל פעם. הריצו כל תרחיש מול קו הבסיס. שלבו מנופים רק אחרי שהבנתם את ההשפעה של כל אחד בנפרד.
  7. השוו והחליטו. הציבו זה לצד זה את קו הבסיס והתרחישים. דנו במה שהייתם עושים בכל מקרה, ורשמו את ההחלטה ואת הסיבה לה.
  8. שמרו תיעוד. שמרו את ההנחות ואת התוצאה יחד עם ההחלטה. תזדקקו להם כשתבדקו מה באמת קרה.

זוהי דוגמה היפותטית, שהומצאה רק כדי להמחיש את ההיגיון. בתא ייצור יש מכבש צוואר בקבוק אחד שמייצר 300 יחידות במשמרת. המפעל פועל עשר משמרות בשבוע, ולכן הקיבולת היא 3,000 יחידות. ההזמנות של השבוע מסתכמות ב-2,700 יחידות, שהם 90% מהקיבולת. קו הבסיס ישים, עם מרווח של משמרת אחת.

  • תרחיש A: המכבש מושבת לשתי משמרות. הקיבולת יורדת לשמונה משמרות, או 2,400 יחידות. נותרות 300 יחידות ללא כיסוי, ולכן חלק מההזמנות יחמיצו את התאריכים שלהן.
  • תרחיש B: אותה השבתה, בתוספת משמרת בשבת. הקיבולת חוזרת ל-2,700 יחידות, אך העומס עומד כעת על 100%. כל הפרעה נוספת משמעה החמצת תאריך.
  • תרחיש C: אותה השבתה, והמתכנן מעביר 300 יחידות של הזמנות בעדיפות נמוכה לשבוע הבא. ההזמנות החשובות יוצאות בזמן, ולקוח אחד מקבל שיחה היום, ולא הפתעה ביום שישי.

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

אילו נתונים וכלים דרושים לכם?

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

לאחר מכן בחרו את הכלי לפי מורכבות השאלה.

  • גיליון אלקטרוני מספיק כאשר משאב אחד או שניים ומספר קטן של הזמנות קובעים את התשובה, כמו בדוגמה לעיל.
  • הרצת התכנון במערכת ה-ERP שלכם יכולה לטפל בשאלות מונחות חומרים. ב-Dynamics 365 Supply Chain Management, master plans מאפשרים לדמות אסטרטגיות תכנון שונות, ובתיעוד של Microsoft נכתב שניתן להגדיר כמה תוכניות שתרצו ולשמור חלק מהן לתחזיות או לסימולציות שונות. בדקו עם שותף היישום שלכם איך זה מתאים לגרסה ולמנוע התכנון שלכם, כי הדף אינו מתאר בפירוט את הטיפול בתרחישים. תכנון מאסטר פועל על חומרים וקיבולת ברמה גסה, ואינו כלי לתזמון מפורט.
  • מתזמן עם קיבולת סופית או מודל סימולציה הוא הבחירה הנכונה כאשר מכונות משותפות, הכנות התלויות ברצף, משמרות ומיומנויות מתקיימים זה לצד זה. במקרה כזה חישוב פשוט עשוי להיראות תקין, בעוד שלוח הזמנים היומי אינו ישים.
  • Power BI הוא מקום טוב להציג תוצאות תרחישים למנהלים. פרמטרי what-if מאפשרים למשתמשים להזיז מחוון ולראות איך מדד משתנה. לפי Microsoft, הם נועדו לשימוש במדדים בתוך חזותיים, ולפרמטר יכולים להיות עד 1,000 ערכים ייחודיים לכל היותר. זה הופך אותם לשימושיים לשאלות פשוטות כמו "מה קורה לתפוקה אם תהיה 5% יותר פסולת?" הם לא מתזמנים לוח זמנים. יש להתייחס אליהם כממשק קדמי לתוצאות, ולא כמנוע החישוב.

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

איך יודעים שאפשר לסמוך על התשובות?

תרחיש טוב רק כמו המודל שעומד מאחוריו. שלוש בדיקות עוזרות.

בצעו backtest. הריצו את המודל על תקופה קודמת שבה אתם יודעים מה קרה. השוו את הפלט שלו לתוצאות האמיתיות. בספרות הסימולציה זה נקרא operational validity: האם התנהגות הפלט של המודל מדויקת מספיק למטרה המיועדת שלו, בתוך טווח התנאים שבהם ישתמשו בו. מאמר של Sargent ועמיתיו מ-Winter Simulation Conference מציג זאת בדרך הזו, ומציין שיש לשמור על הסיכון של משתמש המודל, כלומר קבלת מודל שגוי, במינימום. במילים פשוטות: אם המודל לא מצליח לשחזר את החודש שעבר, אל תשתמשו בו כדי להחליט על החודש הבא.

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

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

איך הופכים את זה להרגל ולא לפרויקט?

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

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

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

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

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

איפה Polaris נכנס לתמונה

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

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

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

הצעד הבא

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

Entities in this article

Factory simulation Dynamics 365 Power BI Polaris Simulator Polaris Optimizer iFAKT GmbH

Related articles

RSS

תוכן ממומן

iFAKT GmbH