פיתוח אתר שיתוף רכבים מקצה לקצה על 1C-Bitrix

מדוע פיתוח אתר קרשרינג נתקע באינטגרציות

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

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

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

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

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

אפקט מדיד: הזמנות, תעריפים, השבתות, תמיכה

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

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

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

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

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

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

אפשרויות השקה: לשכור, להתאים או לבנות

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

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

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

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

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

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

מארז האספקה: אזורים אישיים, אינטגרציות, נהלים

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

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

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

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

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

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

מה שינו

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

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

מה התוצאה

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

מה עושים אם ההזמנות והתעריפים כבר מנוהלים במערכת מוכנה?

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

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

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

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

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

שאלות נפוצות על הארכיטקטורה והתמיכה בשירות

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

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

מה קורה אם הקשר עם הרכב אבד במהלך הנסיעה?

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

כיצד מתומחרת נסיעה שנקטעה?

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

מי אחראי לניטור הצי ולתמיכה לאחר ההשקה?

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

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

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

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

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

בשלב הבא העבודה מתנהלת בשלבים, וכל אחד מסתיים בתוצאה ניתנת לבדיקה:

• אנליטיקה של תרחישים — מפת מסלולי המשתמש: הזמנה, פתיחת הרכב, סיום ההשכרה, מצבים שנויים במחלוקת והחזרים.
• תכנון הארכיטקטורה — סכמת נתונים, תפקידים והרשאות, פורמטי חילופין עם הטלמטריה והתשלומים.
• הרכב הצוות לפי ההיקף: אנליסט, מפתחי צד שרת על 1C-Bitrix, מפתח מובייל, בודק תוכנה, מהנדס תשתיות — מצטרפים בשלב שלהם, ולא «כל הצוות בבת אחת».
• פיתוח האזור האישי וממשק הניהול של הצי — עם הדגמות ביניים כל שבועיים.
• אינטגרציות ולקוח מובייל — תשלום, טלמטריה, ניהול מסמכים, התראות.
• בדיקות עומס ובדיקות תרחישים — הזמנות במקביל, נכונות החיובים, התנהגות בעת ניתוק הקשר עם הרכב.
• השקה וליווי — העברה למעגל הפרודקשן, ניטור, נוהל התאמות.

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