שיבוץ טכנאים בשטח: אילוצים קשים מול העדפות רכות, זמן נסיעה כמשך אמיתי, חלונות שעות והסמכות, ולמה לוח אפשרי שניתן להסביר עדיף על לוח אופטימלי.
עיקרי הדברים
- זמן נסיעה אינו מרחק. שתי קריאות במרחק 9 ק"מ זו מזו הן 14 דקות בשעה 11:00 ובקלות 35 דקות בשעה 16:30, ולוח שמחשב מרחק בלבד יקרוס בדיוק בשעות העומס.
- מיומנות והסמכה הן אילוץ קשה שמסנן מועמדים לפני שמחשבים משהו, ולא ניקוד שאפשר לפצות עליו בזמן נסיעה קצר.
- אופטימליות אינה היעד. פותר הניתוב של OR-Tools פועל עם אסטרטגיית פתרון ראשוני ומטה-היוריסטיקה של חיפוש מקומי ועם מגבלת זמן, ומחזיר את הפתרון הטוב ביותר שמצא עד שהזמן נגמר.
- כל שיבוץ נושא הסבר קצר: למה הטכנאי הזה, למה בשעה הזאת. בלי זה כל שינוי ידני נראה שרירותי ומוקדן פשוט יעקוף את המערכת.
- יום שנשבר ב-11:40 אינו מקרה קצה אלא מצב תפעולי רגיל. השאלה היחידה היא כמה קריאות מזיז השיבוץ מחדש, לא האם הוא מזיז.
לוח שיבוץ לצוות שטח נבנה משני סוגי כללים בלבד: אילוצים קשים שאסור להפר, כמו הסמכה וחלון זמן שהובטח ללקוח, והעדפות רכות שכדאי לקיים, כמו קיצור נסיעה. מטרת המערכת אינה למצוא את הלוח הזול ביותר, אלא לוח אפשרי לביצוע שאפשר להסביר לטכנאי ולמוקדן בלי שאיש יצטרך לפתוח את הקוד.
מה חייב להיות מוגדר לפני שמשבצים משהו
שיבוץ אינו יכול להיות טוב יותר מהנתונים שמזינים אותו. אלה השדות שבלעדיהם כל אלגוריתם ייתן תוצאה שנראית סבירה ואינה ניתנת לביצוע.
| שדה בקריאה | דוגמת ערך | מה קורה בלעדיו |
|---|---|---|
| חלון זמן מול הלקוח | 09:00-13:00 | המערכת משבצת ב-15:00 ומישהו מתקשר להתנצל |
| משך מוערך | 75 דקות | הלוח מלא במונחי קריאות וריק מבחינת שעות |
| מיומנות נדרשת | מזגנים מיני-מרכזיים | נשלח מי שקרוב, לא מי שיודע |
| הסמכה נדרשת | עבודה בגובה | קריאה שלא ניתן לבצע בהגעה |
| ציוד נדרש | מנוף קטן | הטכנאי מגיע ונוסע חזרה למחסן |
| כתובת מדויקת | הבנים 7, כניסה ב, רעננה | זמן נסיעה מחושב ליעד שגוי |
| עדיפות | SLA - היום | קריאות דחופות נדחקות לסוף היום |
| גישה לאתר | שוער עד 16:00 | הטכנאי מגיע ולא נכנס |
השדה שנוטים לוותר עליו הוא "משך מוערך", והוא בדיוק זה שהופך לוח לבלתי אפשרי. יום עם שמונה קריאות אינו יום עמוס או ריק - זה תלוי לגמרי אם הן בנות 30 דקות או 110 דקות.
למה זמן נסיעה הוא האילוץ ששובר לוחות תמימים?
כי הוא אינו תכונה של הקריאה אלא של הזוג. משך הנסיעה קיים רק בין קריאה א' לקריאה ב', בשעה מסוימת, לרכב מסוים - ולכן אי אפשר לשמור אותו על הקריאה עצמה.
- הוא תלוי בסדר. אותן חמש קריאות בסדר שונה יכולות להסתכם ב-70 דקות נסיעה או ב-160.
- הוא תלוי בשעה. נסיעה שנמשכת 14 דקות בצהריים תימשך זמן ארוך בהרבה אחרי 16:00 באזורים עירוניים. מטריצת נסיעות שחושבה פעם אחת לכל היום מתארת יום שלא קיים.
- הוא נבלע בחישוב. רבע שעה נסיעה שלא נספרה בין שמונה קריאות היא שעתיים חסרות ביום עבודה - כלומר קריאה וחצי שנפלו.
- הוא כולל דברים שאינם נהיגה. חניה, מציאת הכניסה, מעלית, המתנה לשוער. עדיף לקרוא לזה חיץ ולהגדיר אותו במפורש מאשר לגלות אותו כאיחור.
הדרך המעשית היא לחשב את זמן הנסיעה כמשך בין שתי נקודות בשעת יציאה משוערת, ולהוסיף חיץ קבוע לכל עצירה. שני המספרים האלה גלויים ללוח, ואפשר לכוון אותם לפי מה שקרה בפועל בחודש שעבר.
אילוץ קשה מול העדפה רכה
ההפרדה הזאת היא כל ההבדל בין מערכת שאפשר לסמוך עליה למערכת שמייצרת קריאות בלתי אפשריות:
- אילוצים קשים: הסמכה תקפה, מיומנות נדרשת, שעות העבודה של הטכנאי, חלון הזמן שהובטח ללקוח, קיבולת הרכב, וזמינות ציוד ייחודי. הפרה של אחד מאלה פוסלת את הפתרון.
- העדפות רכות: קיצור נסיעה כוללת, איזון עומס בין טכנאים, שמירה על אותו טכנאי אצל לקוח מוכר, וצמצום זמן מת. אלה נכנסים לפונקציית העלות ומתחרים זה בזה.
הכשל הנפוץ הוא להפוך אילוץ קשה להעדפה עם משקל גבוה. זה עובד עד ליום עמוס, ואז המערכת "מחליטה" ששווה לשלוח טכנאי בלי הסמכת עבודה בגובה כי הוא היה קרוב ב-12 דקות. אילוץ קשה חייב לסנן מועמדים לפני החישוב, לא להתחרות בתוכו.
למה לוח אפשרי שניתן להסביר עדיף על לוח אופטימלי
בעיות ניתוב עם חלונות זמן, מיומנויות וקיבולת אינן נפתרות לאופטימום בזמן סביר בגדלים תפעוליים, וגם אין בכך צורך. ספריית הניתוב של OR-Tools ממחישה את הגישה: בוחרים אסטרטגיה לפתרון ראשוני, למשל PATH_CHEAPEST_ARC, מוסיפים מטה-היוריסטיקה של חיפוש מקומי כמו GUIDED_LOCAL_SEARCH, ומגדירים מגבלת חיפוש. התיעוד מציין שמגבלות החיפוש מפסיקות את הפותר לאחר שהגיע למגבלה שהוגדרה, כגון משך זמן מרבי או מספר פתרונות. בפועל, בלי מגבלת זמן החיפוש פשוט ימשיך.
מכאן נובעות שלוש החלטות תכנוניות:
- הגדירו תקציב זמן מפורש לחישוב הלוח, למשל 20 שניות לשיבוץ יום שלם. התוצאה היא הפתרון הטוב ביותר שנמצא בזמן הזה, ולא "הפתרון".
- אל תבטיחו חיסכון באחוזים. אפשר להשוות את הלוח שהמערכת ייצרה ללוח שנבנה ידנית באותו יום, וזה מספר אמיתי. "חיסכון של 30% בנסיעות" הוא הבטחה שאין לה מקור.
- הריצו את אותו קלט פעמיים. אם התוצאה משתנה בין הרצות, קבעו זרע קבוע - מוקדן שרואה לוח אחר בכל רענון מפסיק להאמין למערכת.
ההסבר חשוב לא פחות מהתוצאה. לכל שיבוץ מוצמד משפט קצר: "נבחר בגלל הסמכת עבודה בגובה, 18 דקות נסיעה מהקריאה הקודמת, בתוך חלון 09:00-13:00". משפט כזה הופך שינוי ידני לדיון על נתון ולא על תחושה.
קשור: אוטומציה של קביעת תורים, ממשק חגים ישראלי לצורכי תזמון, דוח יומי מהשטח ב-WhatsApp.
מה קורה כשהיום נשבר ב-11:40?
זהו המבחן האמיתי. נניח יום עם שלושה טכנאים ו-11 קריאות. בשעה 11:40 קריאה שהוערכה ב-60 דקות מתארכת ל-150, כי המנוע שהוזמן אינו הדגם הנכון.
- מזהים את החריגה מוקדם. הטכנאי מדווח "מתארך" מהאפליקציה, ולא מגלים זאת כשהוא לא מגיע ליעד הבא ב-12:15.
- מקפיאים את מה שכבר התחיל. קריאה בביצוע אינה זזה. שיבוץ מחדש שמזיז טכנאי שכבר באתר הוא מה שגורם לצוות להפסיק לפתוח את האפליקציה.
- משבצים מחדש רק את מה שנפגע. שתי הקריאות הבאות של אותו טכנאי, ולא כל 11. שיבוץ מלא מחדש בכל שינוי מייצר יום שאיש אינו יכול לעקוב אחריו.
- בודקים מי עדיין עומד באילוצים הקשים. קריאה שדורשת הסמכה שיש רק לטכנאי אחד אינה זזה לאחר, גם אם הוא פנוי.
- מודיעים ללקוח לפני שהחלון נשבר, לא אחרי. חלון 13:00-17:00 שנודע עליו ב-12:50 הוא עדכון; אותו עדכון ב-17:10 הוא תלונה.
- מסמנים מה נדחה למחר ומכניסים אותו לתחילת הלוח, אחרת קריאה שנדחתה פעם אחת נדחית שוב.
מה רואה הטכנאי ומה רואה הלקוח
- הטכנאי רואה רשימה סדורה של היום, עם כתובת, חלון, משך מוערך והציוד שנדרש - ולא מפה שממנה צריך להסיק סדר.
- הוא רואה גם את זמן הנסיעה שהמערכת הניחה. פער חוזר בין ההנחה למציאות הוא הנתון שמכייל את החיצים.
- הלקוח מקבל חלון ולא שעה מדויקת, וכל שינוי בחלון נשלח כשהוא קורה.
- שינוי ידני של מוקדן נשמר עם סיבה. אחרי חודש, רשימת הסיבות היא רשימת האילוצים שחסרים במערכת.
מקורות
שאלות נפוצות
כמה זמן לפני שמריצים שיבוץ צריך להיות ידוע המשך המוערך?
המשך צריך להיות מוגדר ברמת סוג העבודה מראש, ולא להיות מוזן בכל קריאה. הדרך המעשית היא טבלת משכים לפי סוג קריאה ולפי סוג לקוח, שמתעדכנת מהנתונים בפועל - כלומר מהפער בין מה שהוערך למה שנמדד. בלי עדכון כזה, הטבלה מתיישנת בתוך חודשיים.
האם כדאי לתת לטכנאים לבחור קריאות בעצמם?
בחירה חופשית מייצרת בדיוק את הבעיה שהשיבוץ נועד לפתור: הקריאות הקלות והקרובות נלקחות והשאר נשארות. מודל ביניים שעובד הוא שיבוץ אוטומטי עם אפשרות להחליף קריאה בין שני טכנאים, בכפוף לאותם אילוצים קשים. ההחלפה נרשמת, כך שאפשר לראות אילו קריאות אף אחד אינו רוצה.
מה עושים כשלטכנאי אחד יש הסמכה שאין לאיש אחר?
מסמנים זאת כסיכון תפעולי ולא כפרט טכני. במונחי שיבוץ, כל קריאה שדורשת את ההסמכה הזו הופכת לצוואר בקבוק שקובע את כל היום. הפתרון אינו בתוכנה אלא בהכשרה, אבל התוכנה היא זו שיכולה להראות כמה קריאות בחודש נחסמו כך. זהו נתון שמצדיק תקציב הכשרה.
האם אפשר לשבץ בלי חישוב זמן נסיעה אמיתי?
אפשר, ובעסק שכל הקריאות שלו ברדיוס קטן זה אפילו סביר. ברגע שיש שני אזורים או שעות עומס, הערכה קבועה של "20 דקות בין קריאות" תייצר יום שנראה תקין בבוקר ומתפרק אחרי הקריאה השלישית. הסימן המובהק לכך הוא איחורים שמצטברים לאורך היום ולא מתפזרים.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.