WEBVTT

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

00:00:06.700 --> 00:00:08.940
כל מה שהלקוח באמת מצפה לו זה שני דברים.

00:00:09.160 --> 00:00:11.340
הבטחה ברורה וחבילה שמגיעה לפתח ביתו.

00:00:11.480 --> 00:00:15.360
ברוכים הבאים לפרק נוסף של Microsoft Knowledge Nuggets ב-M365FM.

00:00:15.500 --> 00:00:20.020
אני מו פיטרס והיום נבחן את ניהול ההזמנות החכם של Dynamics 365 בשפה פשוטה.

00:00:20.160 --> 00:00:24.080
נעקוב אחרי ההזמנה מרגע הלחיצה בקופה ועד לעבודה שמביאה אותה בפועל ליעדה.

00:00:24.080 --> 00:00:27.140
חישבו על זה כעל דאסק שיגור מרכזי בבניין משרדים עמוס.

00:00:27.300 --> 00:00:29.860
זו לא עוד חנות מקוונת והיא לא הורזת את הקופסה.

00:00:29.960 --> 00:00:34.240
היא פשוט מכוונת את האנשים והמערכות הנכונים כדי שהעבודה תתבצע במקום הנכון.

00:00:34.940 --> 00:00:36.740
למה הזמנות הופכות למבולגנות?

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

00:00:43.500 --> 00:00:46.420
עבור הלקוח, כל אלו הן רק דרכים שונות לקנות אוזניות.

00:00:46.420 --> 00:00:50.600
אבל מאחורי הקלעים, כל ערוץ שולח את פרטי ההזמנה למערכת שונה לחלוטין.

00:00:50.720 --> 00:00:58.700
האתר מחזיק רשומה אחת, קופה בחנות מחזיקה אחרת, זירת מסחר שולחת פורמט משלה, ונציג מוקד יוצר הזמנה במקום אחר לגמרי.

00:00:58.880 --> 00:01:05.360
הבטחה אחת פשוטה ללקוח מתפצלת למספר חלקים נעים שלא מדברים זה עם זה, ומליי מוסיף רובד נוסף של מורכבות.

00:01:05.520 --> 00:01:07.640
במחסן הראשי עשויים להיות 20 זוגות.

00:01:07.640 --> 00:01:13.580
בחנות בצד השני של העיר יש חמישה, וגם במחסן אחר יש מליי, אבל הוא רחוק יותר עם עלויות משלוח גבוהות יותר.

00:01:13.780 --> 00:01:17.620
חלק מהמליי כבר שמור להזמנות אחרות, פריטים שהוחזרו או לקוחות בחנות.

00:01:17.720 --> 00:01:22.300
אז לראות מספר לצד מוצר לא באמת פותר את הבעיה, ואז צריך להחליט איך לשלוח.

00:01:22.480 --> 00:01:27.400
האם המחסן צריך לשלוח את זה? האם חנות צריכה לשלוח את זה? או שאולי הלקוח יכול לאסוף את זה מקומית?

00:01:27.400 --> 00:01:29.860
ואם מי שהוא קונה שני פריטים, ואף מיקום לא מחזיק את שניהם,

00:01:29.980 --> 00:01:32.980
האם מפצלים את ההזמנה לשתי חבילות או מחכים שכל מה שניתן ישלח יחד?

00:01:33.080 --> 00:01:36.520
כל בחירה משפיעה על העלות, זמן ההספקה וההבטחה שנתת ללקוח.

00:01:36.680 --> 00:01:40.280
לפני שני עשורים, חברות ניהלו את העבודות האלו במערכות נפרדות עם צוותים נפרדים.

00:01:40.400 --> 00:01:41.700
המחירות קיבלו את ההזמנה.

00:01:41.820 --> 00:01:42.780
מי שהוא בדק מלאי.

00:01:42.900 --> 00:01:44.000
המחסן קיבל בקשה.

00:01:44.180 --> 00:01:45.860
שותף למשלוחים קיבל בקשה אחרת.

00:01:45.860 --> 00:01:47.740
החיוב טיפל בחלק שלא מאוחר יותר.

00:01:57.400 --> 00:01:59.760
אימייל לצוות המחסן, אז מתקשר לחברת שילוח,

00:01:59.980 --> 00:02:03.660
ובינתיים, מוצר יכול להימחר בערוץ אחר לפני שידקון המלאי מגיע לאתר.

00:02:03.780 --> 00:02:06.000
עכשיו ישלח הזמנה למה שהוא שאינך יכול לשלוח.

00:02:06.180 --> 00:02:10.160
ככה קורה מצב של מחירת יתר, וככה גם בחירת אפשרויות משלוח עורכת זמן רב מדי.

00:02:10.300 --> 00:02:12.220
צוותים ממשיכים להעתיק פרטים ממקום למקום,

00:02:12.380 --> 00:02:14.780
והלקוחות מקבלים עדכונים מאורפלים במקום תשובות ברורות.

00:02:14.780 --> 00:02:19.080
מצד הלקוח, כל המורכבות הזו לא משנה, כי הם רק שואלים שאלה אחת.

00:02:19.080 --> 00:02:20.180
איפה ההזמנה שלי?

00:02:20.360 --> 00:02:24.960
מה שחברה באמת צריכה זה מקום אחד שיכול לראות את מסע ההזמנה בכל היישומים העסקיים המקושרים,

00:02:25.180 --> 00:02:27.380
בזמן שכל יישום ממשיך לעשות את מה שהוא עושה הכי טוב.

00:02:27.520 --> 00:02:29.040
המחירות מתעדות את העסקה.

00:02:29.120 --> 00:02:30.900
המחסן מנהל את הליקוט והאריזה.

00:02:31.060 --> 00:02:32.340
המשלוחים מטפלים בהפצה.

00:02:32.460 --> 00:02:33.700
החיובים מטפלים בכספים.

00:02:33.860 --> 00:02:35.880
אף אחד לא צריך לזרוק את כל המערכות הקיימות.

00:02:35.880 --> 00:02:37.600
מה שחסר הוא המטעם ביניהן.

00:02:37.680 --> 00:02:41.300
עבור, מקום שיכול לקבל הזמנה, לראות מה צריך לקרות בהמשך,

00:02:41.300 --> 00:02:44.540
ולכוון את העבודה מבלי להסתמך על שרשרת העברות ידניות.

00:02:44.780 --> 00:02:45.380
זו הבעיה.

00:02:45.620 --> 00:02:50.700
Dynamics 365 Intelligent Order Management עונה על ההגדרה הפשוטה הזו.

00:02:50.820 --> 00:02:55.080
אז מה זה בדיוק Dynamics 365 Intelligent Order Management?

00:02:55.480 --> 00:02:58.300
היום אנחנו הולכים לפרק את זה לשפה פשוטה.

00:02:58.300 --> 00:03:00.360
הנה ההגדרה הפשוטה ביותר.

00:03:00.520 --> 00:03:06.060
זהו יישום ענן שלוקח, הזמנה ומנחה אותה דרך כל המערכות שהחברה כבר משתמשת בהן,

00:03:06.320 --> 00:03:09.320
מרגע הגעת ההזמנה ועד לסיום הביצוע והחיוב.

00:03:09.320 --> 00:03:11.380
תחשבו על תחנת רכבת עמוסה.

00:03:11.520 --> 00:03:14.980
רכבות מגיעות מכיוונים שונים, נושאים זקוקים לרציפים שונים,

00:03:15.200 --> 00:03:17.460
חלק מהחיבורים מהירים, אחרים צריכים להמתין.

00:03:17.640 --> 00:03:20.500
Intelligent Order Management פועל כמו חדר הבקרה של התחנה.

00:03:20.640 --> 00:03:22.460
הוא לא נוהג ברכבת ולא מוכר את הכרטיס,

00:03:22.660 --> 00:03:25.340
אבל הוא רואה את כל המסלול ואומר לכל מערכת מה לעשות הלאה.

00:03:25.340 --> 00:03:28.640
מייקרוסופט בנתה את Intelligent Order Management על גבי Dataverse.

00:03:28.780 --> 00:03:34.140
Dataverse הוא בסיס הנתונים המשותף שעומד מאחורי יישומי Dynamics 365 וPower Platform רבים.

00:03:34.140 --> 00:03:39.020
במילים פשוטות, הוא מעניק ליישומים עסקיים מקום אחד ופורמט אחד להיחסון מידע.

00:03:39.160 --> 00:03:42.980
זה אומר שהזמנה לא מקבלת משמעות שונה לחלוטין בכל מסך ומערכת.

00:03:43.120 --> 00:03:46.860
הבסיס המשותף הזה עוזר, אבל לא צריך לקנות כל יישום אחר של Dynamics 365

00:03:46.860 --> 00:03:48.960
כדי להשתמש ב-Intelligent Order Management.

00:03:48.960 --> 00:03:53.140
חברה עשויה להריץ את Dynamics 365 Finance או Supply Chain Management.

00:03:53.320 --> 00:03:58.240
אחרת עשויה להשתמש במערכת מחסן שונה, חנות מקוונת אחרת או שירות משלוחים מספק אחר.

00:03:58.240 --> 00:04:01.900
היישום הזה יכול לעבוד גם עם יישומים עסקיים של מייקרוסופט וגם של ספקים אחרים.

00:04:02.100 --> 00:04:04.280
נקודות החיבור נקראות ספקים, Providers.

00:04:04.460 --> 00:04:08.640
ספק מעביר מידע על הזמנות וביצועים בין Intelligent Order Management לבין מערכת אחרת.

00:04:08.840 --> 00:04:11.300
חישבו על ספק כעל מתרגם שנמצא בדלת הכניסה.

00:04:11.440 --> 00:04:13.460
מערכת אחת שולחת הזמנה בפורמט שלה.

00:04:13.460 --> 00:04:17.280
הספק מבין את הפורמט הזה, מעביר את המידע לתוך Intelligent Order Management

00:04:17.280 --> 00:04:20.820
ויכול לשלוח את הבקשה הבאה החזרה בפורמט שהמערכת השנייה מבינה.

00:04:20.940 --> 00:04:24.900
אז האפליקציה מרכזת את פרטי ההזמנה גם כשההזמנה התחילה במקום אחר.

00:04:25.060 --> 00:04:27.400
לקוח עשוי לקנות דרך אתר מסחר AIO.

00:04:27.520 --> 00:04:30.600
לקוח אחר עשוי לבצע הזמנה דרך מערכת נקודת מחירה.

00:04:30.760 --> 00:04:34.200
לקוח עסקי יכול לשלוח הזמנה אלקטרונית בתהליך B2B.

00:04:34.200 --> 00:04:39.540
ניהול הזמנות חכם נותן לחברה מקום אחד לצפות בהזמנות ולראות היכן כל אחת עומדת בביצוע.

00:04:39.720 --> 00:04:41.520
לא כל הזמנה עוברת באותו מסלול.

00:04:41.680 --> 00:04:43.020
אחת עשויה להמתין למלאי.

00:04:43.020 --> 00:04:44.820
אחרת עשויה כבר להמתין במחסן.

00:04:45.000 --> 00:04:47.380
שלישית עשויה להזדקק לשלב חיוב לאחר המסירה.

00:04:47.500 --> 00:04:51.360
האפליקציה עוקבת אחר המצב הזה, כך שהצוות רואה יותר מרק, ההזמנה התקבלה.

00:04:51.500 --> 00:04:54.100
הם יכולים לראות בדיוק איפה ההזמנה נמצאת במסעה.

00:04:54.200 --> 00:04:56.360
הנה החלק שאנשים לפעמים מפספסים.

00:04:56.360 --> 00:04:58.900
ניהול הזמנות חכם לא משתלט על כל עבודה.

00:04:59.060 --> 00:05:05.060
הוא לא הופך פתאום למסע חליקות של עובדי המחסן לרשת המשלוחים של השליח או למערכת החיוב של צוות הכספים.

00:05:05.060 --> 00:05:08.360
האפליקציות המחוברות הללו עדיין מבצעות את עבודתן המקצועית.

00:05:08.520 --> 00:05:11.060
ניהול הזמנות חכם מנהל את המעברים ביניהן.

00:05:11.160 --> 00:05:15.900
הוא מקבל את הבקשה, בודק את המסלול, מעביר את העבודה הלאה ואז ממתין לעדכון הבא.

00:05:15.900 --> 00:05:21.860
כעת, בואו נעקוב אחר הזמנה אחת לאורך הדרך הזו, כי מסע ההזמנה הופך את כל הרעיון לקל הרבה יותר להבנה.

00:05:21.960 --> 00:05:24.700
חוקי מסע ההזמנה הם אלו שמכוונים את העבודה.

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

00:05:31.220 --> 00:05:37.100
החנות המקוונת קולטת את ההזמנה, שם הלקוח, כתובת המשלוח, שורות ההזמנה והבחירה במשלוח.

00:05:37.300 --> 00:05:41.360
ספק מעביר את ההזמנה לניהול הזמנות חכם ומסע ההזמנה יכול להתחיל.

00:05:41.480 --> 00:05:48.560
לפני שמישהו מנסה למלא אותה, המערכת מאמתת את ההזמנה כדי לוודא שכל המידע הדרוש למסע קיים ותואם את חוקי החברה.

00:05:48.560 --> 00:05:53.960
היא בודקת את כותרת ההזמנה עבור פרטי לקוח ומשלוח. היא בודקת כל שורה עבור מוצר וחמות.

00:05:54.100 --> 00:05:59.340
היא מאשרת של הכתובת, יש מספיק מידע למשלוח ומבדת שההזמנה עומדת בחוקי ערוץ המחירות הזה.

00:05:59.500 --> 00:06:03.880
הבדיקה הראשונה הזו מונעת ממידע שגוי להמשיך הלאה לפני שהוא גורם לבעיות.

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

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

00:06:17.400 --> 00:06:22.400
השורש לעבודה הזו נמצא בתהליך תזמור. הביטוי הזה נשמע טכני, אבל הוא פשוט.

00:06:22.560 --> 00:06:29.880
תהליך תזמור הוא מפה חזותית שאומרת לניהול הזמנות חכם מה צריך לקרות כשהמידע מגיע ואירועים חוזרים ממערכות מחוברות.

00:06:30.020 --> 00:06:32.640
אתם יוצרים את המפה הזו סביב התהליך העסקי שלכם.

00:06:32.820 --> 00:06:35.440
תהליך הזמנה בסיסי עשוי להתחיל כאשר מגיעה הזמנה חדשה.

00:06:35.440 --> 00:06:39.440
היא מאמתת את הכותרת ואת השורות. היא שולחת את ההזמנה לקבלת החלטות ביצוע.

00:06:39.580 --> 00:06:42.720
לאחר מכן, היא שולחת את הזמנת הביצוע למערכת המחוברת הנכונה.

00:06:42.880 --> 00:06:46.500
ברגע שהעבודה מגיעה לשלב הנכון, היא יכולה לשלוח פרטי הזמנה לספק חיוב.

00:06:46.640 --> 00:06:48.200
לכל פעולה יש תפקיד ברור.

00:06:48.380 --> 00:06:51.100
עימות כותרת הזמנה בודק את פרטי ההזמנה העיקריים.

00:06:51.280 --> 00:06:54.440
עימות שורת הזמנה בודק את המוצרים והכמויות הפרטניים.

00:06:54.640 --> 00:06:58.500
שליחה לביצוע מעבירה את הזמנת הביצוע לספק שמטפל בעבודה זו.

00:06:58.500 --> 00:07:01.780
שליחה לחשבונית מעבירה את פרטי ההזמנה לספק החיוב

00:07:01.780 --> 00:07:04.440
השמות נשמעים כמו תוויות על לוח בקרה במפעל

00:07:04.440 --> 00:07:08.360
וזה שימושי כי כל תווית אומרת לך בדיוק מה קורה באותה נקודה בתהליך

00:07:08.360 --> 00:07:11.720
אבל עסק אמיתי זקוק לעיתים קרובות ליותר מקו ישר אחד

00:07:11.720 --> 00:07:16.180
אולי הזמנות מהאתר עוקבות אחר נתיב אחד בעוד שלקוחות עסקיים עוקבים אחר נתיב אחר

00:07:16.180 --> 00:07:18.520
אולי סוג מסוים של מוצר דורש אישור מיוחד

00:07:18.520 --> 00:07:21.400
אולי הזמנה יכולה להתקדם רק עם הצעד הראשון מצליח

00:07:21.400 --> 00:07:24.340
ניהול הזמנות חכם כולל תנאים לסוג כזה של בחירה

00:07:24.340 --> 00:07:27.000
תנאי יוצר נתיב של כן ונתיב של לא

00:07:27.000 --> 00:07:30.800
אם הפעולה הקודמת מצליחה ההזמנה יכולה להמשיך דרך נתיב הכן

00:07:30.800 --> 00:07:34.140
אם היא נכשלת התהליך יכול לכוון את ההזמנה לנתיב אחר

00:07:34.140 --> 00:07:38.360
זה לא פותר כל בעיה בעצמו אבל זה נותן לתהליך תגובה מתוכננת

00:07:38.360 --> 00:07:40.720
במקום להשאיר לצוות לגלות שגיאה במקרה

00:07:40.720 --> 00:07:41.820
יש גם מפצלים

00:07:41.820 --> 00:07:45.680
מפצל שולח את התהליך ליותר מנתיב אחד על בסיס כללים שאתה מגדיר

00:07:45.680 --> 00:07:49.240
אתה עשוי להשתמש באחד כזה כאשר הזמנות ממקורות נפרדים דורשות בדיקות שונות

00:07:49.240 --> 00:07:51.400
או כאשר חלקים שונים בעבודה זקוקים למסלולים שונים

00:07:51.400 --> 00:07:53.920
חלק מהנתיבים המפוצלים יכולים להתחבר שוב מאוחר יותר

00:07:53.920 --> 00:07:55.440
בעוד שאחרים ממשיכים בכוחות עצמם

00:07:55.440 --> 00:07:58.260
פעולות מותאמות אישית מכסות עבודות הייחודיות לעסק

00:07:58.260 --> 00:08:01.220
אולי לחברה יש מערכת ייצור משלה או מערכת שותפים

00:08:01.220 --> 00:08:03.120
שאינה מחוסה על ידי פעולה סטנדרטית

00:08:03.120 --> 00:08:05.840
פעולה מותאמת אישית יכולה לחבר את השלב הזה לתהליך ההזמנה

00:08:05.840 --> 00:08:09.720
כך שהמסלול עדיין מציג את התהליך המלא במקום להסתיר חלק אחד במיילים או בעבודה ידני

00:08:09.720 --> 00:08:11.820
בואו נחזור להזמנת שני הפריטים שלנו

00:08:11.820 --> 00:08:15.960
המערכת מקבלת אותם מהאתר ובודקת את פרטי הלקוח, הכתובת ושורות המוצרים

00:08:15.960 --> 00:08:18.680
ההזמנה מגיעה לאחר מכן לשלב החלטת הביצוע

00:08:18.680 --> 00:08:20.980
אם שני הפריטים יכולים לעקוב אחר אותו מסלול

00:08:20.980 --> 00:08:24.080
התהליך יכול לשלוח את בקשת הביצוע הלאה כיחידה אחת

00:08:24.080 --> 00:08:26.180
אם הכללים של החברה דורשים תוצאה אחרת

00:08:26.180 --> 00:08:27.900
ההזמנה יכולה לקחת נתיב אחר

00:08:27.900 --> 00:08:30.400
אולי שני הפריטים דורשים בקשות ביצוע נפרדות

00:08:30.400 --> 00:08:32.520
אולי ההזמנה דורשת בחירת משלוח אחרת

00:08:32.520 --> 00:08:33.720
התהליך לא מנחש

00:08:33.720 --> 00:08:37.820
הוא עוקב אחר הכללים שהעסק יצר והאירועים שהמערכות המחוברות מחזירות

00:08:37.820 --> 00:08:39.300
החלק האחרון הזה חשוב

00:08:39.300 --> 00:08:41.120
ניהול הזמנות חכם יכול לכוון עבודה

00:08:41.120 --> 00:08:44.180
אך המערכות המחוברות מדווחות בחזרה ככל שהעבודה מתקדמת

00:08:44.180 --> 00:08:46.800
ספק השירות למימוש הזמנות יכול לקבל את הבקשה

00:08:46.800 --> 00:08:49.460
ספק שירותי החיוב יכול לקבל את פרטי ההזמנה

00:08:49.460 --> 00:08:52.320
האירועים האלו שומרים על התקדמות ההזמנה לאורך התהליך.

00:08:52.440 --> 00:08:55.140
לכן, האפליקציה אינה מערכת חלופית ענקית אחת.

00:08:55.260 --> 00:08:59.400
זהו סט של כללים המחבר בין מומחים ומקצה לכל מערכת את העבודה הדרושה לה בזמן הנכון.

00:08:59.540 --> 00:09:01.340
החנות המקוונת קולטת את ההזמנה.

00:09:01.480 --> 00:09:03.380
מערכת המימוש מטפלת במימוש ההזמנה.

00:09:03.520 --> 00:09:05.420
מערכת החיוב מטפלת בחיוב הלקוח.

00:09:05.620 --> 00:09:08.440
ניהול הזמנות חכם מנהל את המסלול שבין המשימות האלה.

00:09:08.440 --> 00:09:12.680
האחראים על תהליך ההזמנות יכולים לעצב את התהליכים האלו ישירות באפליקציה.

00:09:12.880 --> 00:09:15.120
הם לא צריכים לכתוב קול נתיב כקוד מסורתי,

00:09:15.400 --> 00:09:18.440
והם לא צריכים לבקש ממנהל אית לשנות קול כלל עסקי.

00:09:18.620 --> 00:09:22.120
זה נותן לצוות שרשרת ההספקה דרך למדל את התהליך שהם באמת צריכים.

00:09:22.260 --> 00:09:24.300
ובכל זאת, שינויים כאלה דורשים זהירות.

00:09:24.480 --> 00:09:27.680
תהליך תזמור נשאר במצב לא פורסם בזמן שאתה בונה ובודק אותו.

00:09:27.840 --> 00:09:30.640
בשלב הזה, נתונים נכנסים לא עוברים דרך התהליך.

00:09:30.640 --> 00:09:34.820
ברגע שאתה מפרסם אותו, התהליך ופעולותיו מופעלים כשנתונים נכנסים למערכת.

00:09:34.920 --> 00:09:38.000
אחרי הפרסום, לא ניתן לערוך את התהליך שפורסם באופן ישיר.

00:09:38.140 --> 00:09:40.640
אם העסק דורש שינוי, הצוות יכול לעצור את התהליך המפורסם,

00:09:41.340 --> 00:09:42.880
מה שמחזיר אותו למצב לא פורסם.

00:09:43.000 --> 00:09:46.240
הם יכולים לערוך את התהליך, ואז לפרסם את הגרסה החדשה כשהיא מוכנה.

00:09:46.380 --> 00:09:50.160
המבנה הזה דוחף צוותים לבדוק את המסלול לפני שהזמנות חיות עוברות דרכו.

00:09:50.280 --> 00:09:52.980
מסלול עובד רק אם הוא יודע איזה מלאי באמת זמין.

00:10:00.640 --> 00:10:02.780
הנה אמת פשוטה וברורה.

00:10:02.940 --> 00:10:05.900
אתה לא יכול לממש הזמנה אם אתה לא יודע שיש לך את המלאי.

00:10:06.040 --> 00:10:07.080
זה נשמע מובן מעיליו.

00:10:07.200 --> 00:10:10.200
אבל מלאי יכול להתחבא במחסן, בחנות, במקום של שותף,

00:10:10.340 --> 00:10:12.180
או בין ישויות משפטיות שונות באותה חברה.

00:10:12.260 --> 00:10:15.660
כשכל מיקום מנהל ספירה משלו, אתה לא יכול לענות על השאלה הבסיסית.

00:10:15.840 --> 00:10:17.500
מה אני יכול להבטיח ללקוח הזה עכשיו?

00:10:17.640 --> 00:10:22.520
נירות מלאי נותנת לניהול הזמנות חכם תצוגה חיה של כל המלאי הזה לאורך רשת ההספקה שלך.

00:10:22.520 --> 00:10:24.900
תחשוב על זה כמו לוח מלאי במרכז הפצה.

00:10:25.000 --> 00:10:27.500
במקום להתקשר לכל מדף ולבקש ממישהו לבדוק,

00:10:27.700 --> 00:10:31.100
תהליך ההזמנה מסתכל על תצוגה אחת משותפת שכל המערכות שלך מזינו.

00:10:31.260 --> 00:10:33.820
כעת, רק בגלל שפריט מופיע כמלאי במקום מסוים,

00:10:34.040 --> 00:10:35.640
זה לא אומר שהוא יכול לממש כל הזמנה.

00:10:35.800 --> 00:10:38.200
מוצר עשוי להיות במחסן אבל כבר להיות מוזמן,

00:10:38.420 --> 00:10:41.220
או שהוא נמצא בחנות שיכולה למכור מקומית אבל לא יכולה לשלוח,

00:10:41.480 --> 00:10:44.520
או שהוא פשוט רחוק מדי כדי לעמוד בהבטחת המשלוח שהלקוח בחר.

00:10:44.520 --> 00:10:49.340
יש הבדל גדול בין מלאי שקיים אי אפשרו לבין מלאי שיכול לממש את ההזמנה הזו כרגע.

00:10:49.420 --> 00:10:52.640
תארו לעצמכם לקוח שקנה מעיל באינטרנט ורוצה אותו מחר.

00:10:52.760 --> 00:10:55.100
במחסן הראשי שלכם לא נותר אף פריט במלאי.

00:10:55.220 --> 00:10:56.540
ללא נתוני מלאי עדכניים,

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

00:10:59.920 --> 00:11:02.440
ואז המחסן יקבל בקשה למוצר שהוא לא יכול לשלוח,

00:11:02.660 --> 00:11:04.460
והלקוח יגלה זאת רק לאחר התשלום.

00:11:04.620 --> 00:11:06.360
זה מייצר עבודה מיותרת לכולם.

00:11:06.360 --> 00:11:07.840
אם מידע מלאי מקושר,

00:11:08.040 --> 00:11:11.540
ניהול הזמנות חכם רואה שבמחסן הראשי אין מעיל להזמנה זו,

00:11:11.740 --> 00:11:12.920
אך בחנות סמוכה יש.

00:11:13.080 --> 00:11:14.700
אם החנות הזו תומכת במשלוחים,

00:11:14.840 --> 00:11:16.080
היא יכולה להשלים את ההזמנה.

00:11:16.180 --> 00:11:17.740
אם הלקוח בחר באיסוף עצמי,

00:11:17.880 --> 00:11:19.520
אותה חנות הופכת לנקודת האיסוף.

00:11:19.660 --> 00:11:22.120
ההחלטה מתחילה בתצוגה טובה יותר של המלאי.

00:11:22.240 --> 00:11:24.300
עבור חברה עם מספר ישויות משפטיות,

00:11:24.520 --> 00:11:26.300
תצוגה זו מכסה את המלאי בכולן.

00:11:26.480 --> 00:11:28.080
זה משנה כשפועלים ביותר ממדינה,

00:11:28.080 --> 00:11:29.600
אזור או יחידה עסקית אחת,

00:11:29.780 --> 00:11:32.020
והמלאי לא נמצא תחת מערכת רישום אחת בלבד.

00:11:32.140 --> 00:11:34.760
תהליך ההזמנה משתמש בנתוני מלאי בזמן אמת

00:11:34.760 --> 00:11:36.380
כשהוא מחליט באיזה מסלול לבחור.

00:11:36.540 --> 00:11:38.560
מחסן, חנות או מקור מלאי אחר

00:11:38.560 --> 00:11:40.840
עדיין מנהלים את רשומות המלאי של עצמם.

00:11:41.020 --> 00:11:43.220
נירות המלאי מביאה את המספרים העדכניים

00:11:43.220 --> 00:11:44.740
לתהליך ההזמנה הרחב,

00:11:44.800 --> 00:11:46.780
שבו חוקי המילוי יכולים להשתמש בהם.

00:11:46.920 --> 00:11:49.860
זה עוזר להימנע מהבטחות המבוססות על נתוני האתמול

00:11:49.860 --> 00:11:51.800
ונותן לשירות הלקוחות תשובה ברורה

00:11:51.800 --> 00:11:53.980
כשמישהו שואל אם פריט עדיין יגיע בזמן.

00:11:54.140 --> 00:11:57.100
במקום לחפש בכמה מערכות ולקוות שהמידע תואם,

00:11:57.360 --> 00:11:59.120
צוות ההזמנות רואה את מצב המלאי

00:11:59.120 --> 00:12:00.360
שהוביל לבחירת המילוי.

00:12:00.480 --> 00:12:02.740
כמובן, ראיית כל המיקומים האפשריים

00:12:02.740 --> 00:12:03.820
לא עונה על כל שאלה.

00:12:03.960 --> 00:12:06.400
ייתכן שתמצאו את הפריט בחמישה מיקומים שונים.

00:12:06.640 --> 00:12:08.940
אחד קרוב ללקוח, אחר עם יותר מלאי,

00:12:08.940 --> 00:12:11.460
ושלישי שמאפשר לשלוח את שני המוצרים יחד.

00:12:11.620 --> 00:12:13.620
מישהו או משהו עדיין צריכים לבחור.

00:12:13.620 --> 00:12:16.820
התפקיד הזה שייך לאופטימיזציה של מילוי הזמנות.

00:12:18.100 --> 00:12:19.340
מילוי הזמנות

00:12:19.340 --> 00:12:22.820
אופטימיזציה, בחירת המקום הטוב ביותר

00:12:22.820 --> 00:12:24.160
למשלוח מתוך המילוי.

00:12:24.460 --> 00:12:27.180
אופטימיזציה משווה בין המיקומים האפשריים להזמנה

00:12:27.180 --> 00:12:29.900
ובוחרת אחד על סמך חוקים שהחברה שלכם קובעת.

00:12:30.000 --> 00:12:31.780
במילים פשוטות, זה עונה על השאלה

00:12:31.780 --> 00:12:33.560
מאיפה ההזמנה הזאת צריכה להגיע.

00:12:33.560 --> 00:12:35.320
הכי טוב לא תמיד אומר הכי קרוב.

00:12:35.460 --> 00:12:37.440
ייתכן שבחנות הקרובה ביותר יש את הפריט,

00:12:37.620 --> 00:12:39.160
אך משלוח משם עשוי לעלות יותר.

00:12:39.160 --> 00:12:42.620
מחסן רחוק יותר עשוי להחזיק כבר את שני הפריטים מוכנים להריזה יחד,

00:12:42.780 --> 00:12:44.100
ומיקום אחר עשוי להחזיק מלאי,

00:12:44.260 --> 00:12:46.080
אך לא לעמוד בתאריך היעד שהלקוח בחר.

00:12:46.180 --> 00:12:48.780
כל חברה צריכה להחליט מה היא רוצה שהחוקים יעדיפו.

00:12:48.900 --> 00:12:51.480
יש עסקים שמציבים את מהירות המשלוח בראש סדר העדיפויות.

00:12:51.680 --> 00:12:53.700
אחרים רוצים לשמור על עלויות משלוח נמוכות.

00:12:53.880 --> 00:12:56.040
חברה עשויה גם לרצות להגן על מלאי החנות

00:12:56.040 --> 00:12:57.500
עבור לקוחות שמגיעים פיזית,

00:12:57.660 --> 00:12:59.520
או להימנע מפיצול הזמנה לכמה חבילות

00:12:59.520 --> 00:13:00.540
אלא אם אין ברירה אחרת.

00:13:00.660 --> 00:13:04.580
ניהול הזמנות חכם משתמש בהסטרטגיות מילוי המשקפות את הבחירות הללו.

00:13:04.700 --> 00:13:07.100
חישבו על זה כמו על בחירת מסלול לרכב משלוחים.

00:13:07.220 --> 00:13:09.320
הדרך הקצרה ביותר לא תמיד היא המהירה ביותר,

00:13:09.440 --> 00:13:12.260
בגלל עומסי תנועה, עבודות בכביש או עצירות שמעקבות את ההגעה.

00:13:12.360 --> 00:13:13.000
באופן דומה,

00:13:13.120 --> 00:13:16.480
המבנה הקרוב ביותר לא תמיד יניב את תוצאת ההספקה הטובה ביותר,

00:13:16.700 --> 00:13:18.080
כאשר משקללים עלויות מלאי,

00:13:18.080 --> 00:13:19.780
הבטחות שירות ואפשרויות משלוח.

00:13:19.780 --> 00:13:22.320
נחזור ללקוח שקנה שני פריטים באינטרנט.

00:13:22.460 --> 00:13:25.300
לחנות שנמצאת במרחק עשר דקות יש את הפריט הראשון.

00:13:25.420 --> 00:13:27.120
במחסן נמצאים שני הפריטים,

00:13:27.320 --> 00:13:28.100
אך הוא מרוחק יותר.

00:13:28.340 --> 00:13:31.020
אם החנות תשלח את הפריט הראשון והמחסן את השני,

00:13:31.240 --> 00:13:34.160
הלקוח עשוי לקבל שתי חבילות שיעמדו במועד ההספקה,

00:13:34.420 --> 00:13:35.940
אך זה גם מעלה את עלויות המשלוח.

00:13:36.120 --> 00:13:38.720
ייתכן שהמחסן מסוגל לשלוח את שני הפריטים יחד.

00:13:38.720 --> 00:13:40.860
אם הוא עדיין יכול לעמוד במועד ההספקה המובטח,

00:13:40.860 --> 00:13:43.400
חבילה אחת מאותו מיקום עשויה להיות הבחירה הטובה יותר.

00:13:43.580 --> 00:13:46.620
הכלל יכול לתת עדיפות לפחות משלוחים ולעלות משלוח נמוכה יותר.

00:13:46.800 --> 00:13:49.680
אך אם משלוח למחר חשוב יותר משליחת שני הפריטים יחד,

00:13:49.860 --> 00:13:54.000
המערכת עשויה לבחור בחנות עבור פריט אחד ובמחסן עבור השני זוהי הזמנה מפוצלת.

00:13:54.100 --> 00:13:56.300
הזמנה מפוצלת לא אומרת שהמערכת נכשלה.

00:13:56.300 --> 00:14:00.940
זו יכולה להיות בחירה מתוכננת כאשר אף מיקום בודד לא יכול לספק את ההזמנה כולה בצורה הנכונה.

00:14:00.940 --> 00:14:04.820
העסק מחליט מתי פיצול הוא הגיוני באמצעות אסטרטגיית ההספקה שהוא קובע.

00:14:04.960 --> 00:14:07.920
אותה חשיבה תומכת בשיטת קנה אונליין שלח מהחנות.

00:14:08.140 --> 00:14:12.700
לקוח מבצע הזמנה באתר, אך לחנות קרובה יש את המלאי המתאים והיא יכולה לשלוח אותו במהירות.

00:14:12.880 --> 00:14:16.600
לכן החנות הופכת למקור ההספקה, למרות שהלקוח מעולם לא ביקר בה.

00:14:16.600 --> 00:14:19.620
זה תומך גם בשיטת קנה אונליין אסוף בחנות.

00:14:19.780 --> 00:14:25.000
המערכת משתמשת במידע על מלאי ומיקום כדי למצוא חנות שיכולה להכין את ההזמנה לאיסוף,

00:14:25.000 --> 00:14:30.040
והלקוח מקבל אפשרות לאיסוף מקומי בעוד החברה מנתבת את ההזמנה למקום הנכון.

00:14:30.420 --> 00:14:34.400
הבחירות האלו לא חייבות להיות מנוהלות בנפרד בתוך כל ערוץ מחירה.

00:14:34.540 --> 00:14:41.000
ללא תהליך קבלת החלטות משותף להספקה, אתר אינטרנט, זירת מסחר ומוקד שירות עשויים להזדקק לכללי ניתוב משלהם.

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

00:14:47.300 --> 00:14:51.640
אופטימיסיית הספקה מרכזת את תהליך קבלת ההחלטות הזה במקום אחד בתוך מסע ההזמנה.

00:14:51.740 --> 00:14:56.640
האתר ממשיך לקבל הזמנות, זירת המסחר ממשיכה לקבל הזמנות, והחנות ממשיכה למכור מוצרים.

00:14:56.640 --> 00:15:01.560
אך החברה יכולה לשנות את אופן בחירת מיקום ההספקה מבלי לבנות מחדש חוקים בכל ערוץ,

00:15:01.840 --> 00:15:07.200
מה שמעניק לך יותר שליטה כשהמלאי זז, הבטחות ההספקה משתנות או כשנוצרת אפשרות הספקה חדשה.

00:15:07.200 --> 00:15:13.260
עם זאת, אסטרטגיית ההספקה יכולה להשוות מיקומים רק אם המידע הדרוש מגיע מהמערכות שאחראיות עליו.

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

00:15:20.100 --> 00:15:22.280
עבודת החיבור הזאת תלויה בספקים.

00:15:23.120 --> 00:15:25.940
ספקים וחיבורים, הדלתות אל תוך הבניין.

00:15:26.100 --> 00:15:31.180
כדי שניהול הזמנות חכם יוכל לבצע את עבודתו, הוא זקוק לדרך אמינה לתקשר עם כל מה שמסביבו.

00:15:31.180 --> 00:15:33.000
ספקים הם מה שגורם לזה לקרות.

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

00:15:39.220 --> 00:15:43.020
המידע זורם לשני הכיוונים, כך שאף אחד לא צריך להעתיק שום דבר ידני.

00:15:43.140 --> 00:15:45.160
דמיינו בעניין עם דלתות הספקה רבות.

00:15:45.340 --> 00:15:47.880
דלת אחת מקבלת הזמנות מהחנות המקוונת שלכם.

00:15:48.040 --> 00:15:50.080
אחרת מתחברת למערכת המלאי שלכם.

00:15:50.260 --> 00:15:52.840
שלישית שולחת עבודה למחסן או לשותף משלוחים.

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

00:15:57.520 --> 00:16:00.120
מייקרוסופט בונה חלק מהמחברים האלו בעוצמה.

00:16:00.260 --> 00:16:02.040
הם קוראים להם ספקים ממקור ראשון.

00:16:02.200 --> 00:16:10.080
הם מחברים ניהול הזמנות חכם עם אפליקציות כמו Dynamics 365 Supply Chain Management, Dynamics 365 Commerce או Dynamics 365 Finance.

00:16:10.320 --> 00:16:15.280
שירותי המלאי והמימוש בתוך ניהול הזמנות חכם משתמשים גם הם בספקים אלו כדי להחליף נתונים.

00:16:15.480 --> 00:16:17.820
כעת, סביר להניח שכבר יש לכם מערכות אחרות.

00:16:18.020 --> 00:16:20.080
זה המקום שבו ספקים חיצוניים נכנסים לתמונה.

00:16:22.840 --> 00:16:26.440
מערכת המסחר האלקטרוני הקיימת שלכם, זירת מסחר, חברת לוגיסטיקה או מערכת מחסן.

00:16:26.560 --> 00:16:28.880
הנקודה היא לא לכפות עליכם סט אחד של אפליקציות.

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

00:16:32.560 --> 00:16:35.920
מאחורי הקלעים, הספקים האלה משתמשים במחברי Power Automate.

00:16:36.100 --> 00:16:40.300
לפאור פלטפורם יש מעל 200 מחברים מוכנים מראש, כך שיש לכם הרבה נקודות התחלה.

00:16:40.460 --> 00:16:43.880
ואם אף אחד מהם לא מתאים, אתם או השותף שלכם יכולים לבנות ספק משלכם.

00:16:43.880 --> 00:16:46.280
כל אפליקציה המחוברת עדיין מבצעת את העבודה שלה.

00:16:46.340 --> 00:16:48.440
החנות המקוונת שלכם תופסת את הרכישה.

00:16:48.540 --> 00:16:50.320
מערכת המלאי עוקבת אחרי המלאי.

00:16:50.460 --> 00:16:52.600
שותף מימוש אורז ומספק את ההזמנה.

00:16:52.740 --> 00:16:54.540
מערכת חיוב מטפלת בכשפים.

00:16:54.740 --> 00:16:58.120
ניהול הזמנות חכם מתאם את ההודעות והצעדים הבאים בין כולם.

00:16:58.360 --> 00:17:00.220
ברגע שהמערכות האלו משתפות עדכונים,

00:17:00.480 --> 00:17:03.100
העסק שלכם יכול לראות מה קורה לאורך כל תהליך ההזמנה.

00:17:03.260 --> 00:17:05.900
אין יותר צורך לרדוף אחרי מידע במסקים נפרדים.

00:17:06.760 --> 00:17:08.640
תובנות והתמונה הגדולה.

00:17:08.720 --> 00:17:12.940
המידע המשותף הזה נותן לכם תמונה ברורה הרבה יותר של עבודת ההזמנות שלכם.

00:17:13.060 --> 00:17:18.120
ניהול הזמנות חכם כולל לוחות מכוונים של PowerBee שמביאים מדדי הזמנות ומימוש למקום אחד.

00:17:18.320 --> 00:17:20.960
שירות לקוחות יכול למצוא הזמנות שהפסיקו להתקדם.

00:17:21.120 --> 00:17:23.940
תפעול יכול לזהות מסלולים חסומים או עיכובים במימוש.

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

00:17:27.360 --> 00:17:30.440
ללא המבט הזה, עיכוב עלול להיראות כמו בעיה מבודדת.

00:17:30.440 --> 00:17:39.140
אבל כשהנתונים יחד, הצוות שלכם עשוי לשים לב שהרבה הזמנות מועטות אצל שותף מימוש ספציפי או שאפשרות משלוח מסוימת יוצרת יותר חריגות מהצפוי.

00:17:39.320 --> 00:17:43.680
לוח המכוונים לא פותר את הבעיה בעצמו, אבל הוא עוזר לאנשים לדעת בדיוק איפה לחפש.

00:17:43.860 --> 00:17:45.500
חישבו שוב על בניין המשרדים.

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

00:17:56.580 --> 00:18:00.220
לכל חלק יש תפקיד שונה, אך ההזמנה היא זו שמחברת ביניהם.

00:18:01.520 --> 00:18:04.460
לסיכום, הזמנה אחת, מסע אחד מתואם.

00:18:04.580 --> 00:18:06.780
תודה שהצטרפתם אליי לטיפ הידע הזה.

00:18:06.780 --> 00:18:12.540
ניהול הזמנות חכם ממפה נתיב ישיר אחד לאורך כל התהליך שלכם, החל מהקליטה הראשונית ועד לחיוב הסופי.

00:18:12.660 --> 00:18:15.700
הרשמו בפלטפורמת הפודקסטים המועדפת עליכם וצפו בפרק הבא.

00:18:15.820 --> 00:18:19.960
אתם תראו בדיוק כיצד דיינמיקס 365 ופאוור פלטפורם מטפלים בעבודה שמאחורי הקלעים.