פיתוח מערכת AI לניהול צי רכב Fleet Management

ניהול צי רכב ב-AI: איפה מאבדים את השליטה על המכוניות

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

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

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

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

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

מה משתנה לאחר ההטמעה: אפקטים לפי מדדים מדידים

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

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

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

פורמטים של הטמעה: ענן, קו עצמי, תכנית היברידית

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

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

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

שלבי ההטמעה: מביקורת נתונים ועד מסירה לתפעול

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

1. סקירת מקורות. מצליבים את מפתחות הרכב, הנהגים והנגררים, ומנתחים פערים בין המערכות. התוצאה — רשימת מקורות עם הערכת התאמה ורשימת חסרים שאותם משלימים לפני האימון.
2. תרשים זרימת נתונים. מתכננים את מסלול הרשומה מהרכב ועד לשכבות התצוגה: תדירות, פורמט, העשרה במפתחות, עומק ההיסטוריה. התרשים מראה אובדנים בניתוק תקשורת, כפילויות נסיעות ואי-סנכרון זמנים.
3. הגדרת כללים ומודלים. מגדירים אירועי יעד — צריכת דלק יתרה, סטייה מהמסלול, השבתה, סיכון שחיקה — וספי הפעלה לצי מסוים. הגרסאות מתועדות: אפשר להשוות להתנהגות קודמת ולחזור אחורה.
4. בדיקה על נתונים היסטוריים. מריצים את הלוגיקה על הנתונים שנצברו: כמה אירועים מאושרים, כמה מתגלים כשווא. את הספים קובעים לפני ההשקה, כדי שהדיספצ'ר לא ישקע בהתראות.
5. הרצת פיילוט על חלק מהצי. מחברים קבוצת רכבים מוגבלת, מצליבים עם תדלוקים בפועל, תיקונים ודוחות מסלול, ומשווים לקבוצת ביקורת. כאן עולים פערים שאינם נראים בהיסטוריה.
6. קבלת התוצאה. מתעדים את שיעור הנסיעות שזוהו, השהיית הנתונים, דיוק התחזית והיקף האירועים שעובדו. מעבירים תיעוד, מלמדים את הדיספצ'רים ומשאירים נוהל תמיכה.

מה נשאר אצל הלקוח: תצורות, תרשיםים, נהלים

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

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

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

מקרה בוחן: צי משלוחים עירוני — השבתות וצריכה לפני ואחרי

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

מה היה ומה שינו

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

מדדים לפני ואחרי

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

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

במה שונה תחזית לפי טלמטריה מתזכורות לפי קילומטרז'?

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

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

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

הנתונים נלקחים ממה שכבר מותקן ברכב: מסוף טלמטרי, חיישני מפלס ולחץ. את הזרימה לוקחים מפלטפורמות טלמטריה (למשל Wialon) או ישירות, מביאים לתכנית אחידה ורק אז בונים את המודל.

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

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

ספקות טכניים נפוצים לפני תחילת הפרויקט

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

להלן ארבע שאלות שצוותי הנדסה שואלים בתדירות הגבוהה ביותר.

מה יקרה אם הנתונים מגיעים חלקיים?

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

מי בתוך החברה יקבל גישה לנתוני הצי?

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

האם אפשר להשיק את הפרויקט בשלבים?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

מה לשלוח ומה ננתח בדיון על המשימה:

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

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