WEBVTT

00:00:00.000 --> 00:00:07.740
דמיינו שלקוח רוצה מאה אופניים בחודש הבא, השלדות מגיעות באיחור, הגלגלים נמצאים במחסן אחר, וקו ההרכבה שלכם כבר עמוס בעבודה על השבועיים הקרובים.

00:00:07.860 --> 00:00:12.220
אז, מה אתם קונים? מה אתם בונים? מה אתם מעבירים? ומתי אתם צריכים כל חלק?

00:00:12.380 --> 00:00:23.660
ימי, מלקו פטס מ-M365FM, טיפ הידע הזה עוסק ב-Dynamics 365 Master Planning O, החלק בניהול שרשרת ההספקה שעונה על השאלות האלו מאחורי הקלעים.

00:00:23.660 --> 00:00:32.460
חישבו על העסק שלכם כמו בניין משרדים עם מחסן צמוד. הזמנות נכנסות דרך דלת אחת. המלאי יושב על המדפים. ספקים מביאים סחורה לרציף ההעמסה.

00:00:32.580 --> 00:00:39.940
הייצור הופך חלקים למוצרים מוגמרים. תכנון אב מסתכל על כל הבניין במקום להשאיר כל צוות עם רשימה נפרדת משלו.

00:00:40.340 --> 00:00:46.040
היום, אנחנו נלך בעקבות הזמנת אופניים אחת מבקשת הלקוח ועד לפעולות ההספקה.

00:00:46.040 --> 00:00:55.440
דיינמיקס 365 מראה למה עסקים צריכים תוכנית, לא גיליון אלקטרוני. לפני שהיו כלי תכנון מקושרים, חברות עבדו עם פיסות מידע נפרדות.

00:00:55.620 --> 00:01:05.960
למחירות היו הזמנות לקוחות במקום אחד. צוותי המחסן בדקו מלאי במערכת אחרת, הרכש עקב אחרי תאריכי ספקים במיילים או גיליונות, והייצור החזיק רשימות משלו על מה שהמפעל יכול לבנות השבוע.

00:01:05.960 --> 00:01:13.940
כל רשימה נראיתה נכונה בפני עצמה. הבעיה התחילה כשמי שהוא ניסה לענות על שאלה אחת של לקוח. פה, האם נוכל לספק מאה אופניים בתאריך שהבטחנו?

00:01:14.080 --> 00:01:21.440
יולה תאפץ, דמיינו שבמחסן יש 30 אופניים מוכנים היום. זה נשמע כמו התחלה טובה, אבל ההזמנה עדיין צריכה עוד 70 אופניים.

00:01:21.440 --> 00:01:29.320
וו מינוס 70 האופניים, האלה צריכים שלדות, גלגלים, שרשראות, מושבים, ברגים, חומרי אריזה, אנשים שירכיבו אותם וזמן במכונות הנכונות.

00:01:29.320 --> 00:01:37.080
ספירת מלאי פשוטה רק אומרת לכם מה יושב על המדף כרגע. היא לא אומרת לכם אם 70 שלדות נוספות יכולות להגיע לפני שהייצור צריך אותן.

00:01:37.200 --> 00:01:45.420
היא לא אומרת לכם אם הזמנת רכש פתוחה כבר מכסה את הגלגלים. והיא לא אומרת לכם אם למפעל יש מספיק זמן להרכיב הכל לפני תאריך ההספקה.

00:01:46.200 --> 00:01:49.380
כאן התכנון הופך להרבה יותר מסתם ספירה.

00:01:49.380 --> 00:01:59.400
כשלוקח מזמין 100 אופניים, המערכת מסתכלת על הביקוש למד מינוס 100. היא מכסירה את 30 האופניים שכבר זמינים, ואז היא עוקבת אחרי מה שצריך לקרות עבור 70 הנותרים.

00:01:59.600 --> 00:02:06.400
היא בודקת את החלקים שמתחת לאופניים המוגמרים. היא בודקת את ההספקה שכבר בדרך. והיא בודקת את התאריכים הקשורים לכל פיסת עבודה.

00:02:06.400 --> 00:02:15.740
חלק אחד חסר יכול לשנות את כל התשובה. אולי יש לכם מספיק גלגלים ומספיק מושבים. אבל אם המסגרות דורשות שבועיים מהספק, רכישתן יום לפני ההרכבה לא תועיל.

00:02:15.900 --> 00:02:24.340
ההזמנה עשויה להיראות אפשרית בגיליון אלקטרוני עד שמציבים כל פריט בלוח שנה. ולוח השנה הזה משתנה כל הזמן. ספק עשוי להקדים את מועד ההספקה שלו.

00:02:24.340 --> 00:02:35.740
הזמנת מחירה אחרת עשויה לקחת מלאי שחשבת שהוא פנוי. עבודת ייצור עלולה להסתיים באיחור. כאשר הפרטים האלה נמצאים במקומות נפרדים, אנשים מבלים את כל זמנם בשיחות, מיילים, בדיקות ועדכונים של גרסת התוכנית שלהם.

00:02:35.740 --> 00:02:46.040
דיינמיקס 365. תכנון אב מאחד את הביקוש הנוכחי וההצע הנוכחי לתצוגת תכנון אחת. הוא קורא יחד הזמנות לקוחות, מלאי זמין, הצע נכנס ומידע על הייצור.

00:02:46.200 --> 00:02:55.880
לאחר מכן הוא מחשב היכן ההצע המחסה את הביקוש והיכן נותר פער. במקום לבקש מכל צוות לחבר את הנקודות ידנית, המערכת יוצרת הצעות לפעולה בהתבסס על המידע שהיא רואה.

00:02:55.880 --> 00:03:06.980
זה לא אומר שהמערכת מנהלת את העסק בעצמה. מתכנן עדיין בודק את ההצעות, שואל שאלות ומחליט מה צריך לקרות. אבל המתכנן מתחיל עם תמונה מחוברת במקום ערמה של רשימות נפרדות.

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

00:03:18.700 --> 00:03:23.220
השלב הבא הוא להפריד בין סוגי הביקוש השונים שתהליך התכנון יכול לקרוא.

00:03:23.860 --> 00:03:25.300
שלושת מצבי התכנון

00:03:25.300 --> 00:03:28.440
אז הנה העניין לגבי דינמיקס 365.

00:03:29.960 --> 00:03:35.880
אין רק דרך אחת לתכנן. מצב התכנון שבו תשתמשו תלוי בשאלה שהעסק שלכם צריך לענות עליה.

00:03:36.060 --> 00:03:42.760
חברה שמטפלת בהזמנות לקוחות של השבוע זקוקה לתצוגה שונה לחלוטין מחברה שמכינה חומרים לעונה הבאה.

00:03:42.760 --> 00:03:47.960
המצב הראשון הוא תכנון אב. זוהי התוכנית היומיומית שלכם והיא מחשבת דרישות נטו.

00:03:47.960 --> 00:03:53.620
זה פשוט אומר שהמערכת בוחנת מה אתם צריכים ומכסירה את ההצעה שכבר יש לכם או שאתם מצפים לקבל.

00:03:53.780 --> 00:04:02.120
היא קוראת פעילות עסקית אמיתית או הזמנות מחירה מלקוחות, הזמנות רכש שכבר נשלחו לספקים, פקודות ייצור שכבר נמצאות בקו הייצור ומליי שנמצא במחסן.

00:04:02.300 --> 00:04:05.200
דמיינו הזמנת לקוח למד מינוס מאה יחידות של מוצר.

00:04:05.360 --> 00:04:08.700
במחסן שלכם יש 30 יחידות שהתכנון יכול להשתמש בהן עבור אותה הזמנה.

00:04:08.700 --> 00:04:13.400
המערכת לא תנסה להציע לקנות או לייצר את כל היי מינוס מאה שוב כי היא רואה את היי מינוס 30 האלה כהצעה.

00:04:13.480 --> 00:04:15.920
לכן היא מחשבת צורך שנותר של 70 יחידות.

00:04:16.080 --> 00:04:18.320
אותן 70 יחידות שנותרו הן דרישת הנטו.

00:04:18.400 --> 00:04:21.280
תוכנית אמיתית יכולה לכלול יותר מסתם מלאי על המדף.

00:04:21.460 --> 00:04:26.260
אולי עוד 20 יחידות אמורות להגיע מספק לפני התאריך המבוקש על ידי הלקוח.

00:04:26.480 --> 00:04:31.800
במקרה כזה המערכת לוקחת בחשבון גם את היי מינוס 20 הללו ומותירה פער קטן עוד יותר לכיסוי.

00:04:31.800 --> 00:04:33.680
אך התאריכים הם שקובעים את התשובה.

00:04:33.780 --> 00:04:37.960
אם 20 היחידות הללו מגיעות אחרי שהלקוח מצפה למשלוח, הן לא באמת עוזרות הרבה.

00:04:38.100 --> 00:04:41.660
אתה מקבל אותן פיזית, אך הן מגיעות מאוחר מדי לצורך הספציפי הזה.

00:04:41.800 --> 00:04:44.160
תכנון אב בוחן כמות ותזמון יחדיו.

00:04:44.300 --> 00:04:47.400
או, מספר מלאי כולל פשוט עלול לספק תשובה שגויה.

00:04:47.620 --> 00:04:50.760
עבור עסקים רבים, זו התוכנית שהם מריצים בתדירות הגבוהה ביותר.

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

00:04:55.480 --> 00:05:00.040
הטווח המדויק תלוי בזמן שלוקח להספקה להגיע או בזמן הנדרש להשלמת הייצור.

00:05:00.220 --> 00:05:04.000
חברה שרוכשת פריטים מקומיים פשוטים עשויה לתכנן רק כמה שבועות קדימה.

00:05:04.120 --> 00:05:07.200
אך יצרן עם חלקים הדורשים חודשים צריך להסתכל רחוק יותר,

00:05:07.460 --> 00:05:10.840
לעיתים קרובות עד לזמן ההספקה הכולל הארוך ביותר עבור מוצריו.

00:05:10.840 --> 00:05:15.080
אחרת, הרצת התכנון תגלה מחסור כאשר כבר מאוחר מדי להימנע ממנו.

00:05:15.180 --> 00:05:17.340
המצב השני הוא תכנון לפי תחזית.

00:05:17.500 --> 00:05:22.040
במקום להתחיל עם הזמנות מחירה מאושרות, תכנון תחזית מתחיל בביקוש צפוי.

00:05:22.200 --> 00:05:25.360
אולי צוות המחירות מצפה למחירות אופניים גבוהות בקיץ,

00:05:25.560 --> 00:05:28.820
או שכמוניים מצפה למבצע גדול שייצור ביקוש בהמשך השנה.

00:05:29.000 --> 00:05:32.580
אלו תחזיות המבוססות על מה שהצוות צופה לא הזמנות מאושרות.

00:05:32.580 --> 00:05:37.580
הן שימושיות כי המתנה לכל הזמנת לקוח עלולה להותיר מעט מידי זמן לרכישת חומרי גלם,

00:05:37.800 --> 00:05:40.180
הזמנת עבודה במפעל או הכנת קיבולת מספקת.

00:05:40.260 --> 00:05:45.420
פריטים בעלי זמן הספקה ארוך דורשים החלטות מוקדמות גם כשהזמנת הלקוח הסופית תרם הגיעה.

00:05:45.500 --> 00:05:47.540
תכנון תחזית מחשב דרישות ברוטו.

00:05:47.680 --> 00:05:50.280
כלומר, הוא מתחיל עם נפח הביקוש הצפוי.

00:05:50.280 --> 00:05:58.080
אם תחזית צופה 500 אופניים ביולי, התכנון רואה תחילה את הדרישה המלאה של 500 יחידות ופועל על סמך צורך צפוי זה.

00:06:02.580 --> 00:06:04.860
תכנן חומרים וקיבול את סביב אותו נפח צפוי.

00:06:04.980 --> 00:06:10.680
ייתכן שתצטרך לדבר עם ספקים מוקדם, להכין שטח מחסן או לבדוק אם הייצור יכול להתמודד עם עומס העבודה הצפוי.

00:06:10.780 --> 00:06:14.960
תחזיות הן הבטחות הן יכולות להשתנות והמחירות בפועל עשויות שלא להתאים להן.

00:06:15.080 --> 00:06:19.540
ועדיין, הן מעניקות לך מבט ארוך יותר מאשר תוכנית המבוססת רק על הזמנות שכבר בוצעו.

00:06:19.540 --> 00:06:21.640
ואז ישנו תכנון אב בין חברתי.

00:06:21.640 --> 00:06:25.200
זה נכנס לתמונה כאשר ישות משפטית אחת זקוקה להספקה מאחרת.

00:06:25.360 --> 00:06:31.000
לדוגמה, חברה אחת בקבוצה שלך עשויה לייצר פריט בזמן שחברה אחרת מוכרת אותו ללקוחות במדינה אחרת.

00:06:31.220 --> 00:06:33.340
חברת המחירות רואה את ביקוש הלקוחות.

00:06:33.500 --> 00:06:37.040
חברת הייצור צריכה לראות את דרישת ההספקה שביקוש זה יוצר.

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

00:06:44.460 --> 00:06:48.060
אז החברות בקבוצה אינן מתכננות כאילו הן פועלות לבדן.

00:06:48.260 --> 00:06:56.040
חברת המחירות יכולה לתכנן הספקה מהחברה היצרנית, בעוד החברה היצרנית רואה שהיא זקוקה לו חומרים ולקיבולת כדי לתמוך בביקוש הזה.

00:06:56.200 --> 00:06:59.520
הקישור מעביר את אות התכנון מישות משפטית אחת לאחרת.

00:06:59.520 --> 00:07:07.540
כל מודל מתחיל בביקוש, אך הביקוש הוא רק האות הראשון, כי מוצר מוגמר אחד יכול ליצור שרשרת צרכים להרבה חלקים ברמה נמוכה יותר.

00:07:07.540 --> 00:07:13.660
מהזמנה אחת לשרשרת הספקה בואו נשאר עם האופניים, כי כאן תכנון האב מתחיל בעבודתו האמיתית.

00:07:13.860 --> 00:07:19.300
תארו לעצמכם שלקוח מבצע הזמנה למד מינוס 70 זוגות אופניים ומבקש משלוח בתאריך ספציפי.

00:07:19.400 --> 00:07:22.040
התאריך הזה אינו רק הערה עבור צוות המחירות.

00:07:22.040 --> 00:07:28.800
הוא הופך לנקודת המוצא שממנה התכנון עובד לאחור, תוך בחינה מה צריך לקרות לפני שהאופניים האלו יוכלו לצאת מהמחסן.

00:07:28.960 --> 00:07:31.220
האופניים המוגמרים הם רק השכבה הראשונה.

00:07:31.220 --> 00:07:34.980
דיינמיקס 365 בודקת את עץ המוצר, המכונה לעיתים בום.

00:07:35.140 --> 00:07:37.440
חישבו על הבום כעל המתכון לאופניים בודדים.

00:07:37.600 --> 00:07:43.360
הוא מפרט את השלדה, הגלגלים, השרשרת, המושב, הקידון, הבלמים, הברגים וכל חלק אחר הנדרש לבנייתם.

00:07:43.360 --> 00:07:48.280
אם ההזמנה דורשת 70 זוגות אופניים, התכנון מרחיב את ההזמנה לחלקים הדרושים עבור כל ה-70.

00:07:48.520 --> 00:07:50.620
זו יכולה להפוך לרשימה ארוכה במהירות רבה.

00:07:50.620 --> 00:07:55.400
ייתכן שתזדקקו למד מינוס 70 שלדות, 140 גלגלים, 70 שרשראות, 70 מושבים ומאות ברגים קטנים.

00:07:55.560 --> 00:07:58.300
מתכנן אינו צריך לספור כל חלק וחלק באופן ידני.

00:07:58.460 --> 00:08:04.980
עץ המוצר מעניק לדיינמיקס 365 עת המבנה המאפשר למערכת לעקוב אחר הביקוש מהאופניים המוגמרים ועד לכל רכיב.

00:08:05.100 --> 00:08:07.440
אבל חלקים בלבד אינם מייצרים אופניים.

00:08:07.620 --> 00:08:09.220
ייצור דורש גם נתיב ייצור.

00:08:09.220 --> 00:08:16.800
נתיב מתאר את שלבי העבודה הנדרשים לבניית הפריט, הרכבת השלדה, התאמת הגלגלים, בדיקת הבלמים והריזת האופניים המוגמרים.

00:08:17.000 --> 00:08:18.640
כל שלב עשוי לדרוש משאב.

00:08:18.780 --> 00:08:24.800
המשאב הזה עשוי להיות קו הרכבה, שולחן עבודה, תא צבע, מכונה או קבוצת אנשים בעלי הכישורים המתאימים.

00:08:24.960 --> 00:08:28.120
התכנון משתמש במידע זה כדי לקבוע את העבודה בזמן הנכון.

00:08:28.280 --> 00:08:32.640
במקום להתייחס לייצור כאל משהו שקורה באופן מיידי, כאן התאריכים מתחילים לנוע אחורה.

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

00:08:39.200 --> 00:08:41.360
ההרכבה עשויה להצטרך להתחיל ביום שלישי.

00:08:41.460 --> 00:08:43.820
השלדות והגלגלים עשויים להצטרך להגיע עד יום שני.

00:08:43.940 --> 00:08:48.680
אם ספק זקוק למד מינוס עשרה ימים כדי לספק גלגלים, אז הזמנת הרכש צריכה לצאת מהעסק שלכם אפילו מוקדם יותר.

00:08:48.860 --> 00:08:51.080
תאריך הלקוח יוצר שרשרת של תאריכים.

00:08:51.080 --> 00:08:56.240
דיינמיקס 365 עובדת לאחור לאורך השרשרת הזו תוך התחשבות בזמני הספקה.

00:08:56.400 --> 00:09:04.020
זמן הספקה הוא פשוט הזמן שנדרש למשהו, בין אם זה ספק שמספק חלק, מחסן שמשנה סחורה או מפעל שמסיים עבודה.

00:09:04.200 --> 00:09:06.360
חלק שמאחר עלול לעקב את כל השאר.

00:09:06.540 --> 00:09:09.000
נניח שהמערכת מוצאת 70 שלדות במלאי.

00:09:09.120 --> 00:09:14.500
היא גם רואה הזמנת רכש פתוחה למד מינוס 140 גלגלים עם הספקה מתוכננת לפני תחילת ההרכבה.

00:09:14.680 --> 00:09:18.400
ההצעה הזה מכסה את דרישת הגלגלים בזמן שהשלדות כבר מכסות את חלקן.

00:09:18.400 --> 00:09:23.840
אז היא בודקת את השרשראות. אולי יש רק 40 שרשראות בהישג יד ואין הזמנת רכש שמביאה את 30 הנותרות.

00:09:23.960 --> 00:09:26.540
התכנון מזהה פער ויוצר הצעה לכיסוי שלו.

00:09:26.680 --> 00:09:30.800
אותה בדיקה רצה עבור אופניים מוכנים, החלקים שמתחתיהם וכל עבודה שביניהם.

00:09:30.920 --> 00:09:32.380
חלק מההצעה כבר קיים.

00:09:32.560 --> 00:09:34.100
מלאי זמין יכול למלא צורך.

00:09:34.240 --> 00:09:37.180
הזמנת רכש פתוחה יכולה למלא אותו אם הסחורה מגיעה בזמן.

00:09:37.360 --> 00:09:40.400
הזמנת ייצור פתוחה יכולה למלא אותו אם המפעל מסיים בזמן.

00:09:40.400 --> 00:09:44.580
כשאף אחד מהמקורות האלה לא מכסה את הביקוש, התוכנית יוצרת הזמנה מתוכננת.

00:09:44.660 --> 00:09:47.540
הזמנת רכש מתוכננת מציעה לקנות מה שהוא מספק.

00:09:47.700 --> 00:09:51.000
הזמנת ייצור מתוכננת מציעה לבנות מה שהוא בתוך העסק שלך.

00:09:51.160 --> 00:09:55.400
הזמנת העברה מתוכננת מציעה להעביר מלאי מאתר או מחסן אחד לאחר.

00:09:55.540 --> 00:09:57.240
אלו הצעות לא התחייבויות.

00:09:57.460 --> 00:10:03.100
דיינמיקס 365 לא שולחת בשקט הזמנה לספק או מתחילה עבודה ברצפת הייצור.

00:10:03.100 --> 00:10:07.380
היא נותנת למתכנן כמות ותאריך מוצאים על סמך הנתונים שהיא יכולה לראות.

00:10:07.540 --> 00:10:12.860
אדם עדיין בודק אם הספק מתאים, אם התאריך אפשרי ואם העסק צריך לאשר את הפעולה.

00:10:12.980 --> 00:10:15.380
דמיינו בעיה קטנה עם הזמנת האופניים שלנו.

00:10:15.520 --> 00:10:17.320
הכל נראה מוכן חוץ מגלגל אחד.

00:10:17.500 --> 00:10:21.220
ההצעה המתוכנן מחסה שלדות, שרשראות, מושבים וכמעט כל גלגל.

00:10:21.340 --> 00:10:23.920
אבל גלגל אחד מגיע יום אחרי שההרכבה זקוקה לו.

00:10:24.080 --> 00:10:26.600
בלי הגלגל הזה, אופניים אחת פחות יוכלו להסתיים.

00:10:26.600 --> 00:10:31.380
למרות שהמחסן עשוי להיראות מלא בחלקים, התכנון הראשי מאתר את הפער חזרה למקור שלו.

00:10:31.480 --> 00:10:34.900
המתכנן יכול לראות שהמחסור לא מגיע מהזמנת הלקוח עצמה.

00:10:35.040 --> 00:10:38.040
או הוא מגיע מתאריך הספק בהזמנת רכש הגלגלים.

00:10:38.240 --> 00:10:40.400
זה נותן למתכנן משהו ספציפי לפעול לפיו.

00:10:40.540 --> 00:10:43.980
לבקש הספקה מוקדמת יותר, למצוא מקור אחר או לשנות את תאריך הייצור.

00:10:44.140 --> 00:10:47.760
התוכנית יכולה להציע הצעה, אבל השאלה הבאה שימושית באותה מידה.

00:10:47.760 --> 00:10:53.880
מדוע דינמיקס 365 חיברה את ההצעה הזה לביקוש ההוא, קריאת דרישות נטו, שיחת התכנון.

00:10:54.040 --> 00:10:57.640
אז מתכננים משתמשים בדף דרישות נטו כדי להעמיק בחיבור הזה.

00:10:57.780 --> 00:11:01.520
הדף הזה מרכז את כל שיחת התכנון עבור פריט אחד במקום אחד.

00:11:01.680 --> 00:11:07.140
היא מציגה כל דרישה שזקוקה לפריט וכל מקור הספקה שיכול לחסות אותה, עם תאריכים ממש לצד כל שורה.

00:11:07.320 --> 00:11:09.100
ניקח את גלגל האופניים כדוגמה.

00:11:09.260 --> 00:11:12.700
למעלה, אתה בוחר את האתר או המחסן שבו הגלגל הזה רלוונטי.

00:11:12.700 --> 00:11:19.620
לאחר מכן למטה, דינמיקס 365 מציגה את כל העסקאות הקשורות, מחירות, רכישות, מלאי, ייצור, הכל ברשימה אחת.

00:11:19.680 --> 00:11:22.480
ביקוש מופיע כמספר שלילי מול המלאי הזמין שלך.

00:11:22.620 --> 00:11:24.720
הביקוש הזה יכול להגיע ממקומות רבים.

00:11:24.940 --> 00:11:27.980
הזמנת מחירה זקוקה לגלגלים כי לקוח יזמין אופניים.

00:11:28.100 --> 00:11:30.160
תחזית יוצרת ביקוש עתידי צפוי.

00:11:30.320 --> 00:11:32.860
פקודת ייצור זקוקה לגלגלים עבור תוכנית המפעל.

00:11:33.020 --> 00:11:36.220
והזמנת העברה יוצרת ביקוש כאשר מחסן אחר מבקש מלאי.

00:11:36.220 --> 00:11:37.980
כל שורה עונה על שאלה פשוטה.

00:11:38.100 --> 00:11:41.120
מי זקוק לפריט הזה? כמה הם צריכים? ובאיזה תאריך?

00:11:41.280 --> 00:11:43.540
זה נשמע פשוט, אבל זה מונה הטעות מפוצה.

00:11:43.660 --> 00:11:48.140
אנשים רואים לעיתים קרובות כמות כוללת ומניחים שהיא שייכת ללקוח אחד או לעבודה אחת,

00:11:48.360 --> 00:11:51.400
כאשר אותו פריט עשוי לתמוך במספר הזמנות לאורך כמה תאריכים.

00:11:51.540 --> 00:11:55.380
בצד ההספקה, יש לך עמליי בהישג יד או מה שכבר נמצא במלאי.

00:11:55.520 --> 00:11:57.440
לאחר מכן הזמנות רכש מספקים,

00:11:57.440 --> 00:11:59.860
פקודות ייצור שהעסק שלך מתכנן לבנות,

00:12:00.060 --> 00:12:03.980
העברות בין מחסנים והזמנות מתוכננות שהמערכת מציעה, אך איש עוד לא יצר.

00:12:04.100 --> 00:12:05.840
הדף ממיין הכל לפי תאריך.

00:12:06.040 --> 00:12:07.440
כשאתה גולל למטה ברשימה,

00:12:07.620 --> 00:12:09.400
אתה יכול לצפות בכמות הזמינה משתנה.

00:12:09.540 --> 00:12:11.440
המלאי עשוי להיראות טוב בתחילת החודש,

00:12:11.620 --> 00:12:13.820
ואז לרדת כשפקודת ייצור משתמשת בחלקים,

00:12:14.020 --> 00:12:16.040
ואז לעלות שוב כשהשפק מבצע משלוח.

00:12:16.180 --> 00:12:17.700
התזמון משנה את התוצאה.

00:12:17.700 --> 00:12:20.620
נניח שין מינוס מאה גלגלים נמצאים במחסן אחד ביום שני,

00:12:20.860 --> 00:12:22.720
אך פקודת ייצור צריכה שמונים ביום שלישי,

00:12:22.900 --> 00:12:25.360
וצורך של לקוח אחר מופיע עבור שלושים ביום רביעי.

00:12:25.500 --> 00:12:26.740
סך הביקוש עולה על המלאי,

00:12:26.900 --> 00:12:30.260
למרות שהזמנת רכש נכנסת של חמישים גלגלים מגיעה ביום שישי.

00:12:30.360 --> 00:12:33.020
המשלוח של יום שישי לא פותר את המחסור של יום רביעי.

00:12:33.120 --> 00:12:36.180
התצוגה הזו, מיום ליום, מסבירה מדוע המערכת מציעה את הצעותיה.

00:12:36.180 --> 00:12:39.440
דיינמיקס 365 לא סתם מבקשת בהקראי עוד גלגלים.

00:12:39.600 --> 00:12:43.260
היא רואה בדיוק מתי האספקה הזמינה יורדת מתחת לביקוש שעליה לחסות.

00:12:43.400 --> 00:12:45.260
כעת, אולי תשאל שאלה ספציפית יותר.

00:12:45.420 --> 00:12:47.440
איזו שורת אספקה מכסה איזו שורת ביקוש?

00:12:47.580 --> 00:12:49.600
לקשר הזה קוראים פגינג, קישור ביקוש הצעה.

00:12:49.680 --> 00:12:53.060
פגינג הוא קישור התכנון של דיינמיקס 365 בין ביקוש להצעה.

00:12:53.140 --> 00:12:55.340
הוא מחבר צורך, כמו פקודת ייצור לאופניים,

00:12:55.340 --> 00:12:56.820
עם המקור שצפוי לחסות אותו,

00:12:56.820 --> 00:12:59.500
כמו הזמנת רכש לגלגלים או הזמנת רכש מתוכננת.

00:12:59.580 --> 00:13:02.480
המערכת בונה את הקישור הזה במהלך חישוב התכנון.

00:13:02.640 --> 00:13:05.800
אם הביקוש משתנה, התכנון יכול לחשב מחדש את הקשר.

00:13:06.020 --> 00:13:09.940
אולי לקוח מזיז את תאריך ההספקה שלו או שהזמנת רכש נכנסת מתעכבת.

00:13:10.140 --> 00:13:14.900
פגינג יכול אז להצביע על מקור הספקה אחר או ליצור הזמנה מתוכננת חדשה היכן שהפער מופיע.

00:13:14.900 --> 00:13:16.940
זה עוזר לך לעקוב אחר השרשרת כולה.

00:13:17.040 --> 00:13:19.700
התחל בהזמנת מחירה, ראה את הוראת הייצור שהיא מקושרת אליה,

00:13:19.700 --> 00:13:22.820
עקוב אחריה עד לחלקים הדרושים ומצא את הזמנת הרכש שמחסה אותם.

00:13:22.920 --> 00:13:24.500
לפעמים אתה זקוק ליותר שליטה.

00:13:24.580 --> 00:13:26.480
כאן נכנס לתמונה הסימון, מארקינג.

00:13:26.620 --> 00:13:29.700
סימון הוא קשר ידני בין עסקת היצע לעסקת ביקוש.

00:13:29.840 --> 00:13:32.420
הוא מורה למערכת שהצע זה צריך לחסות ביקוש זה,

00:13:32.640 --> 00:13:35.220
במקום לתת לתכנון להתאים אותו בחופשיות למקום אחר.

00:13:35.220 --> 00:13:38.300
תחשוב על זה כעל הדבקת תווית על שני רשומות קשורות.

00:13:38.300 --> 00:13:42.720
ייתכן שתסמן הזמנת רכש נכנסת ספציפית של גלגלים מול הוראת ייצור מסוימת,

00:13:42.980 --> 00:13:45.160
כיוון שהגלגלים האלה נרכשו עבור אותה עבודה.

00:13:45.340 --> 00:13:48.920
התכנון מכבד את הקשר הזה בצורה איתנה יותר מאשר קישור הפגינג הרגיל שלו.

00:13:49.040 --> 00:13:51.820
ובכל זאת, היצע מסומן אינו החיבור החזק ביותר שקיים.

00:13:52.000 --> 00:13:53.820
הזמנה, רזרווישון, חזקה יותר.

00:13:53.820 --> 00:13:56.880
כאשר אתה משריין מלאי או היצע נכנס עבור ביקוש ספציפי,

00:13:57.040 --> 00:13:58.080
אתה יוצר קישור קשיח.

00:13:58.080 --> 00:14:00.480
הכמות הזו מוקצת בצד עבור הזמנת המחירה,

00:14:00.640 --> 00:14:02.400
הוראת הייצור או ביקוש אחר שנבחר.

00:14:02.520 --> 00:14:06.720
והתכנון הראשי מתייחס להזמנה כאל עדיפות על פני פגינג וסימון רגילים.

00:14:06.860 --> 00:14:08.840
תאר לעצמך עשרה גלגלים במלאי,

00:14:09.040 --> 00:14:11.040
אך הם משוריינים עבור הוראת תיקון תחופה.

00:14:11.180 --> 00:14:13.760
הזמנת לקוח מאוחרת יותר עשויה להזדקק לגלגלים גם היא,

00:14:13.760 --> 00:14:17.480
אך התכנון לא יכול להתייחס למד מינוס עשרה הגלגלים המשוריינים כזמינים באופן חופשי.

00:14:17.480 --> 00:14:21.520
עליו למצוא היצע אחר או להציע היצע נוסף כי ההזמנה כבר יקצתה אותם למקום אחר.

00:14:21.660 --> 00:14:24.760
לכן, פגינג, סימון והזמנה נותנים לך שלוש רמות של חיבור.

00:14:24.880 --> 00:14:26.980
פגינג הוא ההתאמה האוטומטית של המערכת.

00:14:27.180 --> 00:14:28.900
סימון הוא קישור ידני וקבוע יותר.

00:14:29.160 --> 00:14:31.300
הזמנה נועלת את ההיצע לצרכה ספציפי.

00:14:31.400 --> 00:14:33.000
וזהו החזק מבין השלושה.

00:14:33.000 --> 00:14:34.820
ברגע שתוכל לקרוא את הכישורים האלה,

00:14:35.000 --> 00:14:37.400
פקודות מתוכננות יפסיקו להיראות כהוראות ללא הסבר.

00:14:37.560 --> 00:14:40.320
השאלה הבאה היא באיזו תדירות תצוגת התכנון הזו משתנה

00:14:40.320 --> 00:14:43.160
ובאיזו מהירות דיינמיקס 365 יכול לחשב אותה.

00:14:43.240 --> 00:14:45.720
תכנון סטטי, דינמי ואופטימיזציית תכנון.

00:14:45.920 --> 00:14:47.700
דף הדרישות נטו מציג תוצאת תכנון,

00:14:47.900 --> 00:14:49.680
אך לא כל תוכנית מתעדכנת באותה דרך.

00:14:49.860 --> 00:14:53.280
תוכנית סטטית משתנה רק כאשר מי שהוא מריץ את עבודת התכנון הראשי.

00:14:53.280 --> 00:14:56.320
זה נותן לי מתכננים תצוגה היציבה שהם יכולים לבחון במהלך היום

00:14:56.320 --> 00:14:58.800
מבלי שכל עסקה חדשה תשנה את המספרים שמתחתיהם.

00:14:58.880 --> 00:15:02.020
תאר לעצמך שהזמנת מחירה גדולה מגיעה בית מינוס 11 בבוקר.

00:15:02.140 --> 00:15:03.940
אם התוכנית הסטטית רצה במהלך הלילה,

00:15:04.120 --> 00:15:07.100
ההזמנה החדשה לא תופיע בהצעות שלה עד להרצת התכנון הבאה.

00:15:07.200 --> 00:15:09.540
התוכנית עדיין מציגה את התוצאה המחושבת האחרונה,

00:15:09.540 --> 00:15:12.660
מה שיכול להיות שימושי כשצוות זקוק לתצוגה מוסכמת אחת ליום.

00:15:12.780 --> 00:15:14.280
אך ליציבות הזו יש מחיר.

00:15:14.420 --> 00:15:17.060
ביקוש חדש יכול להישאר מחוץ לתוכנית הסטטית למשך זמן מה,

00:15:17.260 --> 00:15:19.920
במיוחד עם העסק של לך מריץ תכנון פעם בלילה או פעם בשבוע.

00:15:20.080 --> 00:15:22.120
מתכנן עשוי לדעת שהזמנת לקוח קיימת,

00:15:22.340 --> 00:15:24.920
אך התוכנית הסטטית תרם חישבה מחדש את תגובת ההצעה.

00:15:25.020 --> 00:15:26.700
כאן נכנסת לתמונה תוכנית דינמית.

00:15:26.700 --> 00:15:29.300
תוכנית דינמית מציגה את הביקוש הנוכחי בזמן אמת.

00:15:29.460 --> 00:15:32.600
מתכננים יכולים לראות את ההשפעה של הזמנות מחירה חדשות ודרישות אחרות

00:15:32.600 --> 00:15:34.100
מבלי להמתין לעבודת תכנון אב מלאה.

00:15:34.260 --> 00:15:35.680
זוהי ראייה לטווח קצר יותר.

00:15:35.900 --> 00:15:39.220
תוכניות דינמיות מדלגות על תחזיות ומתמקדות במה שקורה ממש עכשיו.

00:15:39.420 --> 00:15:43.380
נניח שלקוח מבצע הזמנה בלתי צפויה למד מינוס 200 אופניים אחר הצהוריים.

00:15:43.380 --> 00:15:45.120
לפני שמבטיחים תאריך הספקה,

00:15:45.300 --> 00:15:48.200
המתכנן יכול לפתוח את התוכנית הדינמית ולבדוק את ההשפעה.

00:15:48.280 --> 00:15:50.160
האם ההזמנה החדשה יוצרת מחסור?

00:15:50.320 --> 00:15:52.500
האם היא דוחה צורך קיים לתאריך מאוחר יותר?

00:15:52.720 --> 00:15:55.620
האם היא מפעילה פעולת רכש או ייצור חדשה ומוצעת?

00:15:55.800 --> 00:15:58.320
זה מעניק לצוות תמונת מהם מעשית.

00:15:58.480 --> 00:16:01.900
אתם לא משנים את התוכנית הסטטית רק כדי לבדוק הזמנה אחת חדשה.

00:16:01.900 --> 00:16:03.800
אתם בודקים תחילה את ההשפעה הסבירה,

00:16:03.960 --> 00:16:08.360
ואז מחליטים אם ההזמנה דורשת טיפול מיידי או יכולה להמתין להרצת התכנון המתוכננת הבאה.

00:16:08.440 --> 00:16:11.520
תוכניות סטטיות ודינמיות עונות על שאלות קשורות אך שונות.

00:16:11.520 --> 00:16:16.160
התוכנית הסטטית שואלת מה חישוב התכנון הרשמי האחרון שלנו הורה לנו לעשות.

00:16:16.280 --> 00:16:19.660
התוכנית הדינמית שואלת איך נראה הביקוש הנוכחי ברגע זה.

00:16:19.660 --> 00:16:24.220
מאחורי שתי התוכניות עומד מנוע התכנון עבור סביבות הענן של דינמיקס 365.

00:16:24.740 --> 00:16:26.780
אופטימיציית תכנון, פלנינג אופטימיזיישון,

00:16:26.800 --> 00:16:29.420
היא המנוע המודרני שמייקרוסופט משתמשת בו להרצת תכנון אב.

00:16:29.520 --> 00:16:31.980
היא מחשבת את הדרישות מחוץ לאיסום העסקי הראשי,

00:16:31.980 --> 00:16:35.180
מה שמפחית את האומס על המערכת שבה משתמשים לעבודה יומיומי.

00:16:35.280 --> 00:16:37.600
הרצות תכנון ישנות יכלו לקחת זמן רב.

00:16:37.600 --> 00:16:40.840
דיווחים מלקוחות ושותפים מתארים עבודת תכנון שפעם לקחה שעות,

00:16:41.000 --> 00:16:43.060
ומסתיימת כעת בדקות עם אופטימיזיית תכנון.

00:16:43.220 --> 00:16:46.440
הרצות מהירות יותר מאפשרות לצוותים לרענן את התוכנית לעיתים קרובות יותר,

00:16:46.640 --> 00:16:48.860
במקום לחכות לסוף היום כדי לראות אם הביקוש השתנה,

00:16:49.080 --> 00:16:50.940
אך תשובה מהירה עדיין עלולה להיות תשובה שגויה.

00:16:50.940 --> 00:16:54.740
אופטימיזיית תכנון יכולה לחשב כמות עצומה של נתונים מקושרים במהירות.

00:16:54.900 --> 00:16:57.700
עם זאת, היא עובדת רק על בסיס הרשומות שהעסק שלכם מספק לה.

00:16:57.700 --> 00:17:01.400
אם זמן ההספקה של ספק שגוי, גם תאריך ההזמנה המוצע עלול להיות שגוי.

00:17:01.500 --> 00:17:04.640
אם המערכת חושבת שין מינוס 500 גלגלים נמצאים במלייק שזה לא המצב,

00:17:04.820 --> 00:17:06.660
היא עלולה לדלג על הצעת רכש שאתם באמת צריכים.

00:17:06.800 --> 00:17:09.180
ואם עץ המוצר, בום, משמית רכיב כלשהו,

00:17:09.300 --> 00:17:11.420
התכנון לא יוכל ליצור ביקוש לאותו רכיב חסר.

00:17:11.540 --> 00:17:13.180
החישוב אולי יסתיים תוך דקות,

00:17:13.360 --> 00:17:15.860
אך המפעל עדיין יעצר כשהרכיב הזה לא יהיה שם.

00:17:16.000 --> 00:17:17.920
יש גם שינוי באופן שבו התכנון רץ.

00:17:17.920 --> 00:17:20.860
עם אופטימיזיית תכנון, התוכניות הן רגנרטיביות מתחדשות.

00:17:21.020 --> 00:17:23.500
משמעות הדבר היא שכל הרצה סוקרת מחדש את כל הדרישות,

00:17:23.640 --> 00:17:25.260
במקום להשתמש בגישת שינוי נטו,

00:17:25.400 --> 00:17:28.160
הישנה שהדכנה רק פריטים עם דרישות חדשות מאז ההרצה האחרונה.

00:17:28.300 --> 00:17:31.560
חישבו על זה כעל חישוב מחדש של כל תמונת התכנון בכל פעם.

00:17:31.560 --> 00:17:35.320
זה מסיר אי-וודאות לגבי השאלה אם שינוי מוקדם יותר חמק מהחישוב,

00:17:35.360 --> 00:17:38.940
בעוד שהמנוע המהיר הופך חישוב מחדש מלא למעשי יותר עבור עסקים רבים.

00:17:38.940 --> 00:17:40.100
אז מהירות היא יתרון,

00:17:40.300 --> 00:17:43.040
אך נתונים נקיים הם שקובעים אם התוכנית ראויה לאמון.

00:17:43.180 --> 00:17:45.080
ברגע שהתוכנית מפיקה את הצעותיה,

00:17:45.320 --> 00:17:48.100
העבודה הבאה היא להחליט אילו מהן דורשות פעולה מיידית.

00:17:48.180 --> 00:17:50.440
אבל מה תכנון אב עושה ומה הוא לא עושה?

00:17:50.540 --> 00:17:52.480
אז הנה ההגדרה הפשוטה ביותר.

00:17:52.480 --> 00:17:57.520
תכנון אב לוקח את כל הנתונים בתוך דיינמיקס 365 ומציע מה לקנות,

00:17:57.720 --> 00:17:59.980
לייצר או להעביר עם תאריכים וחמויות.

00:17:59.980 --> 00:18:03.220
מתכנן בוחן את ההזמנות המתוכננות הללו לפני ביצוע פעולה.

00:18:03.300 --> 00:18:05.720
הוא בודק את הספק, תאריך ההספקה, הכמות,

00:18:05.900 --> 00:18:07.460
ואם המפעל מסוגל לעמוד במשימה.

00:18:07.580 --> 00:18:10.840
ברגע שהמתכנן מאשר, אישור ההצעה הופך אותה להזמנת רכש,

00:18:11.060 --> 00:18:12.800
הזמנת ייצור או הזמנת העברה אמיתי.

00:18:12.940 --> 00:18:14.860
אבל תכנון אב לא יכול לראות את העתיד.

00:18:15.020 --> 00:18:16.320
תחזיות הן רק הערכות,

00:18:16.320 --> 00:18:19.020
והזמנות לקוחות אמיתיות יכולות להשתנות בין לילה.

00:18:19.080 --> 00:18:21.180
והוא בהחלט לא מחליף מתכננים אנושיים.

00:18:21.380 --> 00:18:23.340
אנשים עדיין מטפלים בסיכוני ספקים.

00:18:23.340 --> 00:18:25.020
הבטחות ללקוחות וחריגים.

00:18:25.140 --> 00:18:26.880
המערכת פשוט לא יכולה לשפוט.

00:18:27.080 --> 00:18:28.480
מלאי לבדו גם הוא לא מספיק.

00:18:28.640 --> 00:18:30.340
המלאי הזה עלול להגיע מאוחר מדי,

00:18:30.500 --> 00:18:31.700
לשבת במחסן הלא נכון,

00:18:31.840 --> 00:18:33.260
או להיות משוריין להזמנה אחרת.

00:18:33.380 --> 00:18:34.740
כדי לקבל תוצאות טובות,

00:18:34.900 --> 00:18:36.060
התחל עם נתונים נקיים,

00:18:36.300 --> 00:18:37.440
רשומות פריט מדויקות,

00:18:37.660 --> 00:18:38.720
זמני הספקה נכונים,

00:18:38.720 --> 00:18:39.860
עצי מוצר תקינים,

00:18:40.080 --> 00:18:41.500
מלאי מעודכן וביקוש ריאלי.

00:18:41.640 --> 00:18:43.020
עבור הזמנת האופניים שלנו,

00:18:43.220 --> 00:18:45.020
המלאי הקיים מחסה חלק מהצורך.

00:18:45.020 --> 00:18:46.700
התכנון מציע הספקה לשאר,

00:18:46.880 --> 00:18:48.380
והמתכנן מאשר את הפעולה.

00:18:48.520 --> 00:18:51.320
זה מחזיר אותנו לשאלה שכל צוות צריך להשיב עליה.

00:18:51.480 --> 00:18:52.720
מה צריך לקרות עכשיו?

00:18:53.400 --> 00:18:55.320
לסיכום, תוכנית אחת מחוברת.

00:18:55.520 --> 00:18:57.060
תכנון אב משקלל ביקוש,

00:18:57.220 --> 00:18:57.880
רמות מלאי,

00:18:58.100 --> 00:18:59.700
תאריכי הספקה של ספקים,

00:18:59.900 --> 00:19:01.460
לוחות זמני ייצור וקיבולת,

00:19:01.460 --> 00:19:04.120
והופך הכל לפעולות שהצוות שלך יכול לבחון.

00:19:04.320 --> 00:19:06.740
הזמנות מתוכננות מתחילות את ההחלטה האנושית כעת.

00:19:06.900 --> 00:19:07.800
הן לא מסיימות אותה.

00:19:07.920 --> 00:19:09.680
זו הסיבה שמתכננים נשארים חיוניים.

00:19:09.680 --> 00:19:11.640
הרשמו בפלטפורמת הפודקאסט המועדפת עליכם

00:19:11.640 --> 00:19:12.680
ושתפו את פיסת הידע הזו

00:19:12.680 --> 00:19:15.180
עם מי שלומד את ניהול שרשרת ההספקה של דיינמיקס 365.