דמיינו שלקוח רוצה מאה אופניים בחודש הבא, השלדות מגיעות באיחור, הגלגלים נמצאים במחסן אחר, וקו ההרכבה שלכם כבר עמוס בעבודה על השבועיים הקרובים. אז, מה אתם קונים? מה אתם בונים? מה אתם מעבירים? ומתי אתם צריכים כל חלק? ימי, מלקו פטס מ-M365FM, טיפ הידע הזה עוסק ב-Dynamics 365 Master Planning O, החלק בניהול שרשרת ההספקה שעונה על השאלות האלו מאחורי הקלעים. חישבו על העסק שלכם כמו בניין משרדים עם מחסן צמוד. הזמנות נכנסות דרך דלת אחת. המלאי יושב על המדפים. ספקים מביאים סחורה לרציף ההעמסה. הייצור הופך חלקים למוצרים מוגמרים. תכנון אב מסתכל על כל הבניין במקום להשאיר כל צוות עם רשימה נפרדת משלו. היום, אנחנו נלך בעקבות הזמנת אופניים אחת מבקשת הלקוח ועד לפעולות ההספקה. דיינמיקס 365 מראה למה עסקים צריכים תוכנית, לא גיליון אלקטרוני. לפני שהיו כלי תכנון מקושרים, חברות עבדו עם פיסות מידע נפרדות. למחירות היו הזמנות לקוחות במקום אחד. צוותי המחסן בדקו מלאי במערכת אחרת, הרכש עקב אחרי תאריכי ספקים במיילים או גיליונות, והייצור החזיק רשימות משלו על מה שהמפעל יכול לבנות השבוע.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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