מדוע אופטימיזציית AI של מסלולי משלוחים נשברת על נתונים אמיתיים
כשל קלאסי: האלגוריתם מפיק תוכנית יפה ל-40 מכוניות, ואחרי הצהריים הדיספטשר מערבב ידנית מחצית מהנסיעות. הסיבה היא שתכנון הנסיעות מחושב לפי גרף כבישים סטטי, בעוד שהמצב בפועל תלוי בחסימות, תנועה עונתית ומזג אוויר — דברים שפשוט אינם קיימים במודל הקלט.
הפער בין זמן הנסיעה המחושב לזמן הנצפה הוא בדרך כלל המקור הגדול ביותר לשגיאה, והוא גורר אחריו את כל השאר.
איכות נתוני הקלט מספקת את המנה השנייה של אי-התאמות. כתיבים שונים של כתובות, קואורדינטות לפי מרכז המבנה, היעדר קומה וכניסה — והנקודה על המפה נמצאת במקום שבו המכונית לא תוכל לעצור.
נרמול מאגר הכתובות, הצמדה לכניסות ושכבה נפרדת של מדידות היסטוריות של זמן פריקה נותנים יותר שיפור מאשר כל סיבוך של הפותר עצמו.
מגבלות על המטען וחלונות המשלוח מוסיפות קשיחות שאין להפר. משקל ומידות הארגז, תאימות בין קבוצות סחורה, פעולת המצנן, שעות הפעילות של הנקודה ומרווחי קבלה סגורים — כל צירוף כזה הופך את המשימה מ"למצוא נתיב קצר" ל"להיכנס לתוך קבוצה אפשרית".
כאן גם צפים צווארי הבקבוק של השיגור: אותו רכב נדרש לשני לקוחות עם חלונות בלתי תואמים, וצריך לחפש פתרון עם נסיגה.
תיקונים ידניים של הדיספטשר אינם חבלה אלא אות. הוא רואה הקשר שאינו קיים בנתונים: לקוח מבקש להגיע מוקדם יותר, אצל הנהג מסתיימת המשמרת, באתר היום הפריקה עד הצהריים.
אם התיקונים לא חוזרים למודל, אופטימיזציית מסלולי המשלוחים מתדרדרת: התוכנית הולכת ומדייקת על הנייר והולכת ומתרחקת מהחצר. בהמשך נבחן כיצד זה נסגר.
מה משתנה לאחר ההטמעה: אפקט במדדים מדידים
האפקט של אופטימיזציית המסלולים נמדד לא לפי תחושות אלא לפי מדדים שנלקחים על נתונים היסטוריים לפני ההתחלה וחוזרים על אותו היקף הזמנות לאחר ההשקה. להלן סט שאנו מתעדים בדוח עבור כל קו משלוחים.
- צמצום הקילומטראז' — סך הקילומטראז' על מספר נקודות דומה יורד ב-8–15%: הראוטר מרכיב שרשראות לפי זמן וגיאומטריה, ולא לפי סדר הגעת ההזמנות.
- נסיעות ריקות — שיעור הקטעים ללא מטען יורד, מפני שהעמסה חוזרת מתוכננת באותו מעבר ולא בשיחת טלפון נפרדת של הדיספטשר.
- שיעור האיחורים לחלונות המשלוח — נמדד לפי הכניסה בפועל לנקודה; חלונות קשיחים ועדיפויות לקוחות מוגדרים כאילוצים, ולכן התוכנית לא מתפוררת בפקק הראשון.
- העומס על הדיספטשר — הזמן לתיקונים ידניים מצטמצם משעות לדקות: המערכת בונה מחדש את היום כשחלון משתבש, והאדם מאשר את השינויים.
- אחידות העומס — הפיזור של מספר הנקודות והמשקל בין המכוניות מצטמצם, עומסי הקיצון בנסיעות נעלמים.
המדדים נאספים אוטומטית, ולכן האפקט נראה בדינמיקה שבועית ולא פעם אחת במצגת. את התוכנית מחשב ליבת החישוב על Google OR-Tools — היא עוברת על אפשרויות תחת האילוצים שהוגדרו ומחזירה כמה פתרונות שווי-ערך לבחירה.
מצבי עבודה: חישוב מחדש מקוון, חישוב באצווה, היברידי
את מצב התכנון בוחרים לא לפי טעם אלא לפי שני גדלים: באיזו תדירות מופיעות הזמנות חדשות במערכת וכמה יקר לשנות נסיעה שכבר סוכמה. חישוב מחדש של המסלול ברגע קבלת ההזמנה נותן קילומטראז' מינימלי, אבל כל שינוי צריך לאשר עם הנהג ועם הלקוח. חישוב באצווה בתדירות נמוכה זול יותר לתחזוקה, אך מגיב פחות טוב לזינוקי עומס באמצע היום.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חישוב מחדש מקוון של מסלולים | ההזמנות זורמות כל היום, חלונות המשלוח קצרים, הרכב הנקודות משתנה דינמית | נדרש פותר מהיר וערוץ קבוע אל הנהג; תיקונים תכופים מדי בתוכנית מבלבלים את המבצעים |
| חישוב נסיעות באצווה | ההזמנות נאספות מראש, המשלוח למחרת, צי מכוניות אחיד | אין תוכנית עד לרגע ההרצה; הזמנה דחופה באמצע היום שוברת נסיעות שכבר נבנו |
| תכנון היברידי | עיקר ההיקף מתוכנן מראש, אך בקביעות מופיעות השתלבויות דחופות | מסובך יותר להגדרה: נדרשים כללים מה בדיוק מותר לבנות מחדש ובאיזו תדירות |
בפועל, הבחירה במצב האופטימיזציה מצטמצמת לתדירות החישוב מחדש. אנחנו מודדים כמה הזמנות מגיעות לאחר תחילת המשמרת, איזה אחוז סירובים לנקודות שכבר הוקצו מקובל על חדר הבקרה ובאיזו מהירות הנהג מאשר משימה חדשה — לפי המספרים האלה המצב או מתקבע או משתנה.
תכנון היברידי נבנה כמעט תמיד על פיצול הנסיעה: שלד קשיח עם כתובות וחלונות זמן מקובע, והחלק החופשי — חריצים לא מלאים, נקודות בדרך — מחושב מחדש לפי אירוע.
תדירות החישוב מחדש הופכת לפרמטר ניתן להגדרה: אחת לשעה עבור הקו המתוכנן, מיידית עבור הזמנות דחופות, עם איסור לגעת בנסיעות שבהן הנהג כבר בדרך.
שלבי ההטמעה: מביקורת נתונים ועד מסירה לתפעול
ההטמעה מחולקת לשלבים קצרים עם תוצאה ניתנת לבדיקה לאחר כל אחד. הסדר אינו מקרי: אין להגדיר את כללי התכנון לפני שברור אילו אילוצים בכלל קיימים בנתונים, ואין טעם לבדוק את איכות התוכנית לפני שהדיספטשרים הסכימו עם לוגיקת החישוב.
- ביקורת נתוני המשלוחים. מייצאים את היסטוריית הנסיעות, כתובות הנקודות, חלונות הזמן של המקבלים, משקל ומידות המטען, סדרי העבודה של הנהגים. מחשבים את שיעור הכתובות ללא הצמדה גיאוגרפית מדויקת, ההזמנות ללא חלון והנקודות הכפולות — בדיוק הפערים האלה נותנים לוחות זמנים לא מציאותיים בחישוב.
- סכימת הפתרון. מגדירים מה מחשבת המערכת ומה נשאר לאדם: אילוצים קשיחים (כושר העמסה, זמן המשמרת, איסורי נסיעה) והעדפות רכות (לקוחות קבועים, עומס אחיד על המכוניות). מתעדים מה בדיוק אנחנו מייעלים — קילומטראז', מספר מכוניות או עמידה בחלונות.
- הגדרת כללי התכנון. את הכללים שהדיספטשר מחזיק בראש מתרגמים לאילוצים ומשקלים פורמליים. כל אחד נבדק לסתירה עם האחרים, זוגות שנויים במחלוקת מופרדים לפי עדיפויות, כדי שהחישוב לא "ייתקע" על תנאים סותרים.
- בדיקה על נסיעות היסטוריות. מריצים את התוכנית על תקופות שהסתיימו ומשווים למצב בפועל: קילומטראז', איחורים, מספר המכוניות המופעלות, שיעור התיקונים הידניים. את אי-ההתאמות מנתחים יחד עם הדיספטשרים, מדייקים את הכללים וחוזרים על המחזור עד שהסטיות הופכות למוסברות.
- הרצת ניסיון באתר אחד. סניף אחד או משמרת אחת עובדים במערכת במקביל לתכנון הרגיל: משווים את התוצאה בזמן אמת, מסירים את ההתנגדויות של הדיספטשרים לפני שמשנים את התהליך כולו.
- מסירה לתפעול. מוסרים את התצורה, הנהלים וסדר התיקונים הידניים, מלמדים את הדיספטשרים על המסלולים שלהם עצמם, מתעדים תפקידים והרשאות גישה. לאחר מכן — ליווי וכיוונון כללים לפי נתונים בפועל.
מה אנו מוסרים לידיים: תצורות, סכימות ונהלים
אנחנו מוסרים לא "קופסה שחורה" אלא מערכת שהצוות שלכם יכול לפתח ולתחזק בעצמו. כללי התכנון מוציאים לתצורה, ההרשאות מתוארות לפי תפקידים, ההתנהגות בעת תקלות מתועדת בנהלים — שינויים שגרתיים אינם דורשים פנייה למפתחים.
- תצורת כללי התכנון: עדיפויות לקוחות, חלונות זמן, כושר העמסה ותאימות כלי רכב, קנסות על הפרת חלון — נערכים בקובץ נפרד ללא בנייה מחדש של המערכת.
- סכימת זרימות הנתונים: מסלול ההזמנה ממערכת החשבונאות דרך בדיקת כתובות וחישוב מטריצת מרחקים ועד למסלול מוכן בממשק הדיספטשר — עם נקודות כשל וניסיונות חוזרים כאשר שירותים חיצוניים אינם זמינים.
- מדיניות גישה למערכת: תפקידי דיספטשר, לוגיסטיקאי, אנליטיקאי ומנהל, נראות לפי סניפים, יומן פעולות וסדר הענקת הרשאות.
- תיעוד הפתרון: מגבלות האלגוריתם, מדריך פרמטרים, סדר עדכון המפות ואזורי התעריפים.
- נוהל עבודת הדיספטשר: קבלת מסלול מחושב מחדש, טיפול בכתובות שלא זוהו, תנאים להעברת הזמנה לתכנון ידני.
- סט בדיקות ומדדים: תרחישי בדיקה על ימים היסטוריים, דוח על שיעור המסלולים שנבנו אוטומטית ועל הסטיות מהתוכנית.
את הערכה מוסרים יחד עם הדרכה של המומחים שלכם: עוברים על התצורה, מריצים תקלות אופייניות, ומתעדים למי לפנות בשאלות לגבי כל בלוק.
מקרה בוחן: צי משלוחים לאחר המעבר לתכנון נסיעות ב-AI
מקרה בוחן: מפיץ עם צי בבעלותו ושני מחסנים
נקודת המוצא
התכנון נשען על הדיספטשר: הוא אסף הזמנות, פיזר נקודות בין המכוניות בטבלה ופתר ידנית חפיפות בין חלונות משלוח. רק על תיקוני הבוקר הלכו כשלוש שעות, ואחרי הצהריים הופיעו הזמנות דחופות — וחלק מהנסיעות נבנה מחדש תוך כדי תנועה.
המכוניות נסעו דרך כל העיר, הקילומטראז' גדל, המשלוח בזמן עמד על כ-87%, וחלק מהנקודות הנהגים עברו שלא בדרך.
מה שינו ומה קיבלו
את המודל בנו על היסטוריית הנסיעות, זמני נסיעה בפועל וזמני המתנה בפריקה, והוסיפו אילוצים: חלונות משלוח, כושר העמסה, סדרי עבודה של הנהגים, עדיפויות לקוחות.
התוכנית מחושבת לכמה ימים קדימה ומחושבת מחדש לחלוטין כשמגיעה הזמנה דחופה — הדיספטשר רואה לא את כל הפריסה אלא רק את הנקודות שקלקלו אותה. תיקונים ידניים נותרו למקרים לא שגרתיים, אבל הפכו ממוקדים ולא יומיומיים.
- הקילומטראז' לנסיעה הצטמצם ב-18% באותו היקף הזמנות.
- מספר הנסיעות ירד ב-12%: חלק מהנקודות אוחדו ליציאה אחת.
- המשלוח בזמן עלה מ-87% ל-98%, איחורים באשמת התכנון כמעט נעלמו.
- זמן הדיספטשר לתיקון ידני — משלוש שעות לחצי שעה במשמרת.
- הסירובים בגלל חלונות משלוח שנזזו הצטמצמו בחצי.
פער כזה בין "לפני" ל"אחרי" נותן לא נוסחה בודדת אלא החיבור בין המודל למגבלות של צי אמיתי ולתהליך מובן של חישוב התוכנית מחדש.
במה שונה אופטימיזציה זורמת מחישוב מחדש באצווה
חישוב מחדש של מסלולים באצווה עובד בחלונות: ההזמנות מיוצאות ממערכת החשבונאות, הפותר מחשב מטריצת זמני נסיעה על כל המאגר ומחזיר תוכנית מוכנה בשלמותה. התוכנית יוצאת יציבה ומוסברת, אבל בתוך החלון המערכת לא רואה לא הזמנה חדשה ולא ביטול — הכל ממתין להרצה הבאה.
אופטימיזציה זורמת מחזיקה את המסלול חי: הזמנה או תקלה נכנסות לתור, רק הקטע המושפע מחושב מחדש, והעדכון מגיע לנהג בתוך שניות. מהירות התגובה לתקלה עולה, אבל המצב דורש משמעת בנוגע ליציבות המסלול הנמסר.
| קריטריון | חישוב מחדש באצווה | אופטימיזציה זורמת |
|---|---|---|
| מהירות התגובה לתקלה | עד החלון הבא של התוכנית | שניות, חישוב מחדש של הקטע המושפע |
| היקף הנתונים למחזור | ייצוא מלא של ההזמנות והמטריצה | רק הדלתא: הזמנה חדשה, שינוי סטטוס |
| יציבות המסלול | גבוהה, התוכנית לא משתנה בתוך החלון | נקבעת לפי ספי הזזה |
| החלפה עם מערכת החשבונאות | החלפה באצווה לפי לוח זמנים | אירועים וכתיבה חוזרת של סטטוסים |
היציבות היא הפשרה המרכזית. במצב הזורם אנחנו מקבעים נקודות שכבר נשלחו, מגבילים את מספר התמורות למסלול וקובעים סף הזזה: כל עוד הרווח בזמן הנסיעה נמוך מהסף, לא נוגעים בתוכנית. אחרת הנהג מקבל מסלול חדש כל כמה דקות ומפסיק לתת בו אמון.
ההחלפה עם מערכת החשבונאות מתבצעת בשני הכיוונים, ורק התדירות שונה. אצווה מתאימה כשההזמנות מגיעות בגלים; זרימה — כשהתגובה לתקלה ברגע נתון חשובה. לרוב מרכיבים היברידי: חלון הלילה בונה תוכנית בסיסית, ותיקוני היום מכניסים שינויים ממוקדים.
ספקות טכניים: נתונים, אינטגרציות ושליטת הדיספטשר
לפני ההשקה הלקוחות שואלים את אותן שאלות: מה לעשות עם נתונים חסרים על מצב הכבישים, כיצד להשתלב במערכת תכנון שכבר פרוסה והאם יישאר אישור ידני של המסלול אצל הדיספטשר.
מה לעשות אם הנתונים על מצב הכבישים חסרים?
אנחנו לא בונים תוכנית על מקור אחד. את לוחות הזמנים של הנסיעות והאילוצים ניקח ממערכת החשבונאות, את גרף הכבישים — ממפות פתוחות, למשל OpenStreetMap, ואת זמן הנסיעה בפועל צוברים מהיסטוריית ההזמנות שבוצעו.
במקום שאין נתונים, המערכת מחשבת לא "ממוצע עירוני" אלא טווח: התוכנית נבנית לפי הערכה שמרנית, והמצב בפועל מדייק את התחזית בנסיעות הבאות.
יש לנו כבר מערכת תכנון פרוסה — נצטרך להחליף אותה?
לא, האופטימייזר מתייצב לצד הקו הנוכחי. האינטגרציה עם מערכת החשבונאות מתבצעת דרך החלפת קבצים או ממשק תוכנה, והלוגיקה הפעילה של חלוקת ההזמנות נשארת עובדת. את המעבר עושים לפי קבוצות מכוניות: אם לפי זמן או קילומטראז' התוצאה גרועה יותר, הקבוצה חוזרת למצב הקודם בלי לעצור את המשלוחים.
האם הדיספטשר יוכל לערוך את המסלול ידנית?
כן, וזה חלק מהמערכת ולא עקיפה שלה. הגמישות של הכללים נקבעת לפי עדיפויות: מרווח הלקוח, משקל המטען, איסור פניות פרסה, מגבלות הנהג. הדיספטשר רואה מדוע המסלול התגבש דווקא כך, ויכול לקבע קטע — אישור ידני נשמר ככלל ונלקח בחשבון בחישובים הבאים.
נדון במשימה: מה נדרש לשלב הראשון
הערכת פרויקט משלוחים מתחילה לא בגישה למערכת התכנון שלכם אלא בייצוא נתונים ובתיאור האילוצים. מספיק לנו להבין אילו נתונים כבר קיימים, כיצד הם מובנים והיכן חישוב המסלולים ייתקל בכללי המחסן האמיתיים ולא במתמטיקה. ככל שנתוני הקלט מדויקים יותר, כך יש פחות הנחות בתוכנית השלב הראשון.
- ייצוא נסיעות היסטוריות מכמה שבועות: נקודות, זמן הגעה ויציאה, קילומטראז' בפועל, משקל ונפח ההזמנה.
- הרכב הצי: סוגי מכוניות, קיבולת לפי משקל ונפח, שיוך למחסנים, משמרות הנהגים — מזה תלוי אילו מסלולים בכלל אפשריים.
- חלונות משלוח לפי לקוחות וקבוצות: מרווחים קשיחים, סטיות רכות, הפסקות צהריים, איסור על פריקה בלילה.
- מגבלות על המטען: קטגוריות בלתי תואמות באותו ארגז, מצבי טמפרטורה, דרישות לקיבוע ולסדר הפריקה.
- כללי עדיפות: מי מקבל את ההזמנה ראשון כשחסרה מכונית, עבור מי הזזת זמן אינה קבילה.
- מאגר כתובות עם קואורדינטות, אזורים ומגבלות כניסה לתחבורה כבדה.
- תקני זמן להעמסה ולפריקה לפי סוגי נקודות — בלעדיהם המודל ממעיט באופן שיטתי במשך הנסיעה.
לפי הנתונים האלה אנחנו מרכיבים מודל חישובי, משווים אותו לנסיעות היסטוריות ומראים על ימים קונקרטיים היכן בדיוק הולכים לאיבוד קילומטרים וזמן. לאחר מכן חוזרים עם תוכנית השלב הראשון: מה מריצים באתר מוגבל, אילו מדדים מתעדים לפני ההתחלה וכיצד משווים את התוצאה לתכנון הידני הנוכחי. תארו את המשימה — נחזור עם הערכה ותוכנית.







