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

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

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

היום אנחנו הולכים לפרק את זה לשפה פשוטה. הנה ההגדרה הפשוטה ביותר. זהו יישום ענן שלוקח, הזמנה ומנחה אותה דרך כל המערכות שהחברה כבר משתמשת בהן, מרגע הגעת ההזמנה ועד לסיום הביצוע והחיוב. תחשבו על תחנת רכבת עמוסה. רכבות מגיעות מכיוונים שונים, נושאים זקוקים לרציפים שונים, חלק מהחיבורים מהירים, אחרים צריכים להמתין. Intelligent Order Management פועל כמו חדר הבקרה של התחנה. הוא לא נוהג ברכבת ולא מוכר את הכרטיס, אבל הוא רואה את כל המסלול ואומר לכל מערכת מה לעשות הלאה. מייקרוסופט בנתה את Intelligent Order Management על גבי Dataverse. Dataverse הוא בסיס הנתונים המשותף שעומד מאחורי יישומי Dynamics 365 וPower Platform רבים. במילים פשוטות, הוא מעניק ליישומים עסקיים מקום אחד ופורמט אחד להיחסון מידע. זה אומר שהזמנה לא מקבלת משמעות שונה לחלוטין בכל מסך ומערכת. הבסיס המשותף הזה עוזר, אבל לא צריך לקנות כל יישום אחר של Dynamics 365 כדי להשתמש ב-Intelligent Order Management. חברה עשויה להריץ את Dynamics 365 Finance או Supply Chain Management.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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