תוכנת תכנון וקביעת לוחות זמנים מתקדמת: איך להעריך APS

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

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

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

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

עיקרי הדברים

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

מהי תוכנת תכנון וקביעת לוחות זמנים מתקדמת?

מילון APICS, שמצוטט על ידי ASCM, מתאר מערכת APS כתוכנת מחשב שמשתמשת באלגוריתמים מתמטיים מתקדמים או בלוגיקה כדי לבצע אופטימיזציה של פונקציות תכנון ותזמון. זו הגדרה רחבה. הגדרה מעשית יותר מגיעה מ-Fraunhofer IPA (מאמר בגרמנית, בתרגום שלי). המאמר ממקם את APS לצד שתי קטגוריות תוכנה נוספות, ניהול שרשרת אספקה ברמת הרשת והוצאה לפועל של הייצור ברמת הפס, כאשר ERP נמצא ברמה הארגונית. הוא גם מתאר שלושה שלבים בלוגיקת התכנון.

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

המאמר הזה מציג נקודת מבט של קונה: מה להחליט קודם, אילו קריטריונים חשובים ואיך לבדוק. להגדרה קצרה של המונח עצמו, ראו את הערך advanced planning and scheduling באתר זה.

היכן APS ממוקמת בין ERP לרצפת הייצור?

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

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

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

איזו בעיה אתם צריכים שהמערכת תפתור?

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

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

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

אילו קריטריונים מבדילים בין APS אחד למשנהו?

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

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

מה כדאי לשאול ספק?

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

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

איך בודקים APS לפני הרכישה?

השתמשו בהרצה חוזרת. זו הדרך הזולה ביותר להפריד בין שיווק להתאמה אמיתית.

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

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

דוגמה: הרצה חוזרת עם מספרים שהומצאו

הדוגמה הזו הומצאה כדי להראות איך קוראים הרצה חוזרת. זו לא תוצאה שנמדדה.

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

מה נדרש כדי לבצע הטמעה?

בעיקר נתונים ואחריות, לא תוכנה.

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

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

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

היכן Polaris משתלב

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

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

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

הצעד הבא

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