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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימו את כל אבני הבניין האלה יחד, והתמונה המלאה מתחילה להופיע איפה זה מתאים ומה זה לא עושה. אז, איפה ניהול הובלה באמת חי? הוא שייך לתוך Dynamics 365 Supply Chain Management שרץ על אפליקציות Finance and Operations. זה הבית שלו. הנה למי זה מתאים. עסקים הזקוקים לדרך מובנית לתכנן משלוחים נכנסים, משלוחי לקוחות יוצאים והעברות מלאי בין אתרי החברה, תוך שימוש ברשומות מובילים, טבלאות תעריפים וכללי התענה משלהם. כעת, בואו נבהיר נקודה נפוצה של בלבול. Business Central הוא שונה. Business Central אינו כולל את מודול ניהול ההובלה המובנה הזה. אם אתם עובדים עם Business Central וזקוקים לתכנון הובלה, עליכם להשתמש במערכת ניהול הובלה חיצונית. זהו הגבול.

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