1. תקציר מנהלים

משרד התחבורה מתמודד עם תופעת השתמטות מתשלום (Fare Evasion) בתחבורה הציבורית, המסתכמת בהפסד שנתי מוערך של כ-400 מיליון ₪. התופעה הוחמרה בשנים האחרונות עקב שינויים מבניים: מעבר לעלייה מכל הדלתות, ביטול תשלום אצל הנהג, והכנסת אפליקציות תיקוף עצמי.

אנו, 200Apps (מאאתיים אפליקציות בע"מ), מציעים פתרון המתמקד בשיפור יעילות האכיפה הקיימת - אפליקציית מפה חכמה לפקחים, שתאפשר תעדוף אכיפה סלקטיבית מבוסס נתונים. הפתרון מתבסס על מקורות מידע הקיימים כבר במערכות המשרד והמפעילים, ומתאים לפריסה כפיילוט מהיר.

גישה זו של "אכיפה סלקטיבית מונחית נתונים" (Data-Driven Enforcement) מיושמת כבר בערים כמו לונדון, סן פרנסיסקו וברצלונה, עם תוצאות מוכחות של הפחתת התחמקות.

---

2. רקע ותיאור הבעיה

2.1 מצב קיים - אמצעי תיקוף ותשלום

אמצעי	טכנולוגיה	אופן פעולה
כרטיס רב-קו	Calypso (שבב חכם)	הנחה על ולידטור - ניכוי אוטומטי
אפליקציות (Moovit, רב-פס, Pango, Cello)	סריקת QR + לחיצה אקטיבית	סריקת QR בכניסה - לחיצת אישור ידנית
זוזו (ZUZU) - צה"ל	אפליקציה ייעודית	זהה לאפליקציות אזרחיות
תעודת שוטר / שב"ס	Calypso (שבב מוטמע)	הנחה על ולידטור
כרטיס אשראי Contactless	EMV (פיילוט)	קירוב כרטיס לולידטור

2.2 הכאבים - מה הוביל להחמרת התופעה

כאב 1: הנהג חדל להיות "שומר סף"

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

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

כאב 2: תיקוף באפליקציות - "אני ממתין למבקר"

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

כאב 3: למפעיל אין אינסנטיב לאכוף

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

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

כאב 4: פערי מידע - "אנחנו לא יודעים מי לא שילם"

קיימים שני מקורות מידע נפרדים: ספירות נוסעים (APC) - חיישנים באוטובוס (דיוק כ-97-98%) ונתוני תיקוף (AFC) - מהולידטורים ומהאפליקציות. ההצלבה ביניהם חושפת את הפער, אך הנתונים מגיעים בעיכוב של עד 3 ימים.

כאב 5: אכיפה יקרה ולא ממוקדת

פקחים עובדים היום ב"שיטת דיג" - עולים על אוטובוסים באקראי. אין להם מידע על אילו קווים/אוטובוסים יש שיעור אי-תיקוף גבוה.

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

כאב 6: פגיעה בתכנון התחבורה

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

כאב 7: מחאה ציבורית כגורם מעודד

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

---

3. פרסונות (Personas)

פרסונה 1: יוסי - פקח שטח

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

פרסונה 2: מיכל - מנהלת אכיפה אזורית

פרמטר	ערך
גיל / תפקיד	45, מנהלת צוות פקחים (8-12 פקחים)
כאב עיקרי	אין לה כלי לנתב פקחים בצורה חכמה. מסתמכת על ניסיון ותחושה
ציטוט	"אני יודעת שקו 480 בעייתי, אבל אין לי נתונים להוכיח את זה."

פרסונה 3: אריה - מנהל אגף במשרד התחבורה

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

פרסונה 4: דני - נוסע אופורטוניסטי

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

פרסונה 5: שרה - נוסעת שלא מתקפת (לא בכוונה)

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

---

4. נתונים ומספרים

מדד	ערך	מקור
עלות הפעלת תח"צ שנתית	כ-20 מיליארד ₪	וובינר משרד התחבורה
פדיון שנתי מתיקופים	כ-2.5 מיליארד ₪	וובינר משרד התחבורה
שיעור אי-תיקוף מוערך	כ-20%	ניתוח פנימי של משרד התחבורה
הפסד שנתי מוערך	כ-400 מיליון ₪	וובינר משרד התחבורה
מספר מפעילים	כ-15	וובינר משרד התחבורה
מספר אשכולות	44	וובינר משרד התחבורה
דיוק מערכת ספירת נוסעים	97-98%	וובינר משרד התחבורה
עיכוב נתונים למערכות	עד 3 ימים	וובינר משרד התחבורה

נתוני השוואה בינלאומיים

עיר / רשות	שיעור התחמקות	הפסד שנתי	מקור
לונדון (TfL)	3.4%	>£130M	TfL Revenue Protection Strategy, 2025
סן פרנסיסקו (Muni)	9.5% (מינימום)	כ-$19M	מחקר POP, 2011
ישראל (הערכה)	כ-20%	כ-400M ₪	משרד התחבורה

שיעור ההתחמקות בישראל גבוה פי 2-6 מערים מובילות בעולם - מה שמחזק את הצורך בפתרון ממוקד ואת פוטנציאל ה-ROI.

---

5. הפתרון המוצע

5.1 סקירה כללית

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

5.2 עקרון הפעולה

נתוני ספירת נוסעים (APC)  ──┐
                              ├──> חישוב % אי-תיקוף לפי קו ──> דירוג צבעוני ──> מפת פקחים
נתוני תיקופים (AFC) ────────┘

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

בהמשך (כשהמערכות יסתנכרנו בזמן אמת): הצבע ישקף את המצב בפועל באוטובוס הספציפי באותו רגע.

5.3 מערכת דירוג צבעוני

צבע	סף אי-תיקוף	משמעות לפקח
● אדום	מעל 40%	עדיפות גבוהה - מומלץ מאוד לעלות ולבדוק
● כתום	10%-40%	עדיפות בינונית - שווה לבדוק אם בסביבה
● ירוק	פחות מ-10%	עדיפות נמוכה - אין צורך מיוחד בבדיקה

5.4 מסכים ראשיים

הינכם מוזמנים לצפות בפרוטוטיפ האינטראקטיבי:

📱 צפייה בפרוטוטיפ האינטראקטיבי

5.5 שיפורים עתידיים (Phase 2 - מחוץ לפיילוט)

שיפור	תיאור	תנאי
נוטיפיקציות Push	התראה כשאוטובוס "אדום" מתקרב לפקח	נתוני זמן אמת
ממשק מנהלים (Web)	דשבורד עם סטטיסטיקות, מיקום פקחים, heatmaps	-
נתוני זמן אמת	צבע פר-אוטובוס (לא רק פר-קו)	סנכרון מערכות מפעילים
דירוג פר-תחנה	זיהוי תחנות "חמות"	נתוני APC ברזולוציית תחנה
מערכת דיווח	הפקח מדווח תוצאות בדיקה - Feedback Loop	-

---

6. פתרונות דומים בעולם - תימוכין

6.1 לונדון - TfL: אסטרטגיית Revenue Protection מבוססת נתונים

מה עשו: Transport for London פיתחו אסטרטגיית אכיפה שמסווגת סוגי עבריינים (טעות כנה / אופורטוניסטי / מחושב / כרוני) ומשתמשת ב"שובל דיגיטלי" - ניתוח דפוסים לא סדירים בנתוני תיקוף - כדי להפנות אכיפה מותאמת לכל קטגוריה. המערכת מייצרת Risk Heatmaps ופריסת אכיפה דינמית.

תוצאות: שיעור התחמקות 3.4% (אפריל-דצמבר 2024); יעד להגיע ל-1.5% עד 2030.

6.2 ברצלונה - FGC + AWAAIT: זיהוי התחמקות + אכיפה סלקטיבית

מה עשו: FGC פרסו מערכת DETECTOR שמזהה אירועי התחמקות ושולחת התראות לפקחים בסמארטפון תוך כ-3 שניות.

תוצאות: ירידה של מעל 70% בהתחמקות בפיילוט.

6.3 סן פרנסיסקו - SFMTA: מיפוי Hotspots

מה עשו: סקר POP מערכתי שמיפה שונות בשיעורי התחמקות לפי קווים, זמנים, דלת עלייה ומיקום. שיעור התחמקות מינימלי 9.5%, שונות משמעותית בין קווים.

6.4 אורגון - סינתזת APC + AFC להערכת התחמקות

מה עשו: מסמך מדיניות של Oregon DOT הגדיר שניתן לסנתז נתוני ספירת נוסעים (APC) ונתוני תיקופים (AFC) כדי להעריך שיעורי התחמקות - בדיוק המודל שהפתרון שלנו מבוסס עליו.

סיכום תימוכין

פתרון / עיר	דמיון לפתרון שלנו	תוצאה עיקרית
TfL - לונדון	אכיפה מונחית נתונים + Heatmaps	ירידה ל-3.4%
AWAAIT - ברצלונה	התראות לפקחים + אכיפה סלקטיבית	-70% התחמקות
SFMTA - סן פרנסיסקו	מיפוי hotspots לפי קו/זמן	הוכחת שונות בין קווים
Oregon DOT	הצלבת APC/AFC	תיקוף מתודולוגי

---

7. טכנולוגיות נדרשות

7.1 צד לקוח (Mobile App)

רכיב	טכנולוגיה מומלצת	הערות
פלטפורמה	React Native / Flutter / Kotlin	Cross-platform iOS + Android
מפות	Google Maps SDK / Mapbox	תצוגת מפה עם Custom Markers צבעוניים
מיקום	Fused Location GPS	מיקום הפקח
ניווט	Deep link ל-Waze / Google Maps	ניווט לתחנה הקרובה
אימות	משתמש וסיסמה

7.2 צד שרת (Backend)

רכיב	טכנולוגיה מומלצת	הערות
API	Node.js	RESTful API
בסיס נתונים	MongoDB or Firebase Firestore	שאילתות גיאוגרפיות (אוטובוסים בטווח X מהפקח)
Cache	Redis	שמירת מיקומי אוטובוסים + דירוגי צבע
Hosting	AWS / GCP / Azure	Cloud

7.3 מקורות מידע - אינטגרציות

מקור	סוג נתון	אופן קבלה	תדירות
מערכת ספירות נוסעים (APC)	כמות עולים/יורדים	API / קבצים מהמפעילים	כל 1-3 ימים
מערכת תיקופים (AFC)	כמות תיקופים	API ממערכות משרד התחבורה	כל 1-3 ימים
GTFS-Realtime	מיקום אוטובוסים בזמן אמת	API של משרד התחבורה	זמן אמת
GTFS Static	נתוני קווים, מסלולים, תחנות	קבצי GTFS	עדכון תקופתי

---

8. היקף הפיילוט

8.1 פרמטרים

פרמטר	ערך
מספר אוטובוסים	5-20 (בהתאם לדרישת המשרד)
מפעיל	מפעיל אחד (ייבחר בתיאום עם המשרד)
קו / קווים	1-3 קווים מייצגים
אזור גיאוגרפי	מטרופולין אחד
מספר פקחים	5-10
משך הפיילוט	3 חודשים
תקציב	50,000 ₪

8.2 מדדי הצלחה (KPIs)

מדד	יעד	אופן מדידה
שיעור "תפיסה" בביקורת	עלייה של 30%+	השוואת תפיסות לפני ואחרי
כמות ביקורות יומית לפקח	עלייה של 20%+	דיווח פקחים
שביעות רצון פקחים	4/5 ומעלה	סקר
זמינות המערכת	99% ומעלה	ניטור טכני
דיוק הדירוג הצבעוני	85% ומעלה	השוואת צבע לתוצאות בדיקה בפועל

---

9. לוח זמנים

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

שלב	תיאור	משך	תאריך משוער
1. הגשת מענה	הגשה דרך זירת האתגרים	-	עד 25.02.2026
2. בחינה ובחירה	הערכת מענים ובחירת 3 זוכים	כ-4 שבועות	מרץ 2026
3. Discovery + עיצוב	עיצוב בסיסי המבוסס על המוקאפ	2-3 שבועות	אפריל 2026
4. פיתוח	Backend + App במקביל	3-4 שבועות	אפריל-מאי 2026
5. אינטגרציה ובדיקות	חיבור למקורות מידע, QA	שבוע	מאי 2026
6. פיילוט חי	פריסה לפקחים למספר אוטובוסים, ליווי, איסוף משוב	3 חודשים	יוני-אוגוסט 2026
7. סיכום	דוח תוצאות והמלצות להמשך	שבוע	ספטמבר 2026

1. תקציר מנהלים

משרד התחבורה מתמודד עם הפסד שנתי מוערך של כ-400 מיליון ₪ מהשתמטות מתשלום בתחבורה הציבורית. שיעור אי-התיקוף בישראל מוערך ב-כ-20% - פי 2–6 מערים מובילות בעולם.

אנו מציעים שירות בקרת תיקוף חצי-אוטומטי המבוסס על מצלמות CCTV הקיימות כבר באוטובוסים, בשילוב טכנולוגיית זיהוי פנים (Face Recognition) מול מאגר נוסעים ידוע. הפתרון מאפשר שליחת קנסות ישירות למפרים ללא נוכחות פקח פיזי באוטובוס.

הגישה: הוכחת היתכנות (PoC) ידנית עם השקעה מינימלית ← אימות עסקי וטכני ← אוטומציה מלאה.

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

---

2. רקע ותיאור הבעיה

2.1 מצב קיים - חולשות האכיפה

המעבר לעלייה מכל הדלתות ותיקוף עצמי יצר מצב שבו:

בעיה	תיאור	השפעה
הנהג חדל להיות "שומר סף"	אין נקודת בקרה בכניסה	נוסע עולה ללא תשלום
תיקוף באפליקציות ניתן לרמאות	סריקת QR ללא אישור עד הגעת פקח	"ביטוח" - משלם רק אם נתפס
אכיפה אקראית	פקחים עולים ב"שיטת דיג"	יעילות נמוכה, חיכוך מיותר
עיכוב בנתונים	APC/AFC מגיעים ב-3 ימים עיכוב	לא ניתן לפעול בזמן אמת
חוסר אינסנטיב למפעיל	הפדיון שייך למדינה	אין מוטיבציה לאכוף

2.2 הפער שהצעה 2 סוגרת

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

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

---

3. נתונים ומספרים

3.1 מדדי הבעיה

מדד	ערך	מקור
עלות הפעלת תח"צ שנתית	כ-20 מיליארד ₪	משרד התחבורה
פדיון שנתי מתיקופים	כ-2.5 מיליארד ₪	משרד התחבורה
שיעור אי-תיקוף מוערך	כ-20%	ניתוח פנימי
הפסד שנתי מוערך	כ-400 מיליון ₪	משרד התחבורה
גובה קנס	180 ₪	חוק עזר

3.2 השוואה בינלאומית

עיר / רשות	שיעור התחמקות	הפסד שנתי	מנגנון אכיפה
לונדון (TfL)	3.4%	>£130M	אכיפה מונחית נתונים
ברצלונה (FGC)	כ-5% (לפני)	-	מצלמות + AWAAIT DETECTOR
סן פרנסיסקו (Muni)	9.5%+	כ-$19M	סקרי POP
מוסקבה (Metro)	כ-2% (אחרי)	-	זיהוי פנים Face Pay
ישראל	כ-20%	כ-400M ₪	אכיפה אקראית

---

4. הפתרון המוצע - הצעה מס' 2

4.1 סקירה כללית

שירות בקרת תיקוף חצי-אוטומטי הפועל ב-4 שלבים:

שלב	תיאור	פירוט
1. מאגר נוסעים	בניית מאגר 300 פנים	תמונות מכרטיסי רב-קו
2. צפייה במצלמות	בחירת אוטובוס "אדום"	שידור CCTV חי או צפייה לאחר מעשה
3. זיהוי אוטומטי	Face Match	זיהוי פנים באמצעות Amazon Rekognition או דומיו
4. קנס	דוח בדואר	180 ₪ + תיעוד ראייתי - שליחה ידנית

4.2 שלב 1 - בניית מאגר נוסעים

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

4.3 שלב 2 - בחירת אוטובוס "אדום"

שיטה	תיאור
נתוני הצעה 1 / מאגרי מידע קיימים	אפליקציית הפקחים מזהה אוטובוסים "אדומים" (מעל 40% אי-תיקוף) או עבודה מול מאגרי המידע הקיימים. המטרה להתמקד באוטובוסים עם סיכויים גבוהים יותר לאי-תיקוף לצורך ייעול העבודה.
ניתוח היסטורי	הצלבת APC↔AFC - זיהוי קווים/שעות עם פער גבוה
דיווחי פקחים	מידע מהשטח על קווים בעייתיים

4.4 שלב 3 - צפייה וזיהוי

1. עובד בקרה צופה בשידור מצלמות CCTV של האוטובוס (חי או הקלטה)
2. העובד מזהה נוסע שנכנס ולא תיקף (לא ניגש לולידטור / לא הוציא טלפון)
3. העובד שומר צילום מסך / קליפ וידאו של הנוסע
4. התמונה מועברת למערכת זיהוי פנים לחיפוש במאגר

4.5 שלב 4 - שליחת קנס

תנאי	פירוט
התאמה חיובית	מערכת זיהוי הפנים מצאה התאמה עם רמת ביטחון ≥95%
בדיקת תיקוף (עתידי)	המערכת תבדוק מול מערכת התיקופים האם הנוסע שילם (למקרה שהתיקוף נעשה מחוץ לאוטובוס) - רלוונטי לאחר שמערכת התיקופים תעבוד בזמן אמת
אימות אנושי	עובד מוודא ויזואלית שהתמונות תואמות
שליחת דוח	קנס 180 ₪ נשלח בדואר לכתובת הרשומה - שליחה ידנית
תיעוד ראייתי	שמירת צילום + timestamp + מספר אוטובוס/קו

---

5. תימוכין - מקרי בוחן מהעולם

סיכום תימוכין

עיר	טכנולוגיה	גישה	תוצאה	רלוונטיות להצעה 2
מוסקבה	זיהוי פנים	תשלום פסיבי	350K+ משתמשים	הוכחת סקאלביליות
ברצלונה	Computer Vision	זיהוי אירוע ← פקחים	-70% התחמקות	מודל מצלמות ← אכיפה
דובאי	מצלמות + ToF	זיהוי באוטובוס	90%+ דיוק	PoC זהה - באוטובוסים
שנזן	זיהוי פנים	זיהוי + חיוב	300+ תחנות	סקאלביליות
לונדון	אנליטיקת וידאו	סיווג + Heatmaps	3.4% התחמקות	אנליטיקה מונחית נתונים
ניו יורק	AI Video	זיהוי אירועים	מיפוי hotspots	שילוב AI + מצלמות קיימות

---

6. ארכיטקטורה טכנית

6.1 זיהוי פנים - השוואת שירותים

שירות	ספק	עלות	דיוק	יתרון מרכזי
Amazon Rekognition	AWS	$0.001/match	99.7%+	Collection API מוכן, אינטגרציה AWS
Azure Face API	Microsoft	$0.001/match	99.6%+	אינטגרציה עם Video Indexer
Face++	Megvii	$0.0005/match	99.5%+	עלות נמוכה, מהירות גבוהה

המלצה לפיילוט: Amazon Rekognition

6.2 תשתיות

רכיב	טכנולוגיה	תפקיד
ממשק צפייה	מערכת קיימת	צפייה בשידור CCTV + ממשק בקרה
Backend	Python (FastAPI)	ניהול API, לוגיקת עסקית
בסיס נתונים	PostgreSQL / MongoDB / Firebase Firestore	אחסון נוסעים, הפרות, קנסות
אחסון תמונות	Cloudinary / AWS S3	תמונות ראייתיות + וידאו
תור משימות	Redis / SQS	תור זיהוי פנים
שליחת קנסות	ידני	עובד שולח קנסות לאחר אימות
ניטור	CloudWatch	מעקב ביצועים ושגיאות

6.3 מקורות מידע - אינטגרציות

מקור	סוג נתון	אופן גישה	שימוש
מצלמות CCTV באוטובוס	שידור וידאו חי או צפייה לאחר מעשה	גישה ל-DVR/NVR - מערכת קיימת	צפייה + לכידת תמונות
מערכת רב-קו	תמונות + פרטים	API / DB	בניית מאגר פנים
מערכת AFC	נתוני תיקוף	שימוש במערכת קיימת או בפתרון 1	אימות שהנוסע לא תיקף
GTFS-Realtime	מיקום אוטובוסים	שימוש במערכת קיימת או בפתרון 1	זיהוי האוטובוס הנצפה
מערכת APC	ספירות נוסעים	שימוש במערכת קיימת או בפתרון 1	חישוב שיעור אי-תיקוף

---

7. תהליך עבודה מפורט

7.1 תהליך PoC

     ┌──────────────────────────┐
     │  בחירת אוטובוס "אדום"    │
     │  (מהצעה 1 / ניתוח        │
     │   היסטורי / מאגר קיים)    │
     └────────────┬─────────────┘
                  │
                  ▼
     ┌──────────────────────────┐
     │  צפייה במצלמות CCTV      │
     │  (חי או הקלטה)           │
     └────────────┬─────────────┘
                  │
                  ▼
     ┌──────────────────────────┐
     │  נוסע עולה ולא מתקף?     │
     │                          │
     │  לא ◄────────────► כן    │
     └──────────────────────────┘
                           │
                           ▼
              ┌──────────────────────┐
              │  לכידת צילום מסך /   │
              │  קליפ וידאו          │
              └──────────┬───────────┘
                         │
                         ▼
              ┌──────────────────────┐
              │  זיהוי פנים          │
              │  (Rekognition)       │
              └──────────┬───────────┘
                         │
              ┌──────────┴───────────┐
              │                      │
         זוהה ✓                 לא זוהה ✗
              │                      │
              ▼                      ▼
  ┌────────────────────┐  ┌──────────────────┐
  │ אימות אנושי       │  │ שמירה לשיפור     │
  │ (התאמה ויזואלית)   │  │ מאגר (אופציונלי) │
  └──────────┬─────────┘  └──────────────────┘
             │
             ▼
  ┌────────────────────┐
  │ שליחת קנס 180 ₪   │
  │ ידנית + תיעוד     │
  └────────────────────┘

7.2 יום עבודה טיפוסי של עובד בקרה

שעה	פעולה
08:00	כניסה למערכת, בדיקת רשימת אוטובוסים "אדומים"
08:15	חיבור לשידור מצלמות של אוטובוס #1
08:15–09:00	צפייה בנוסעים עולים, לכידת תמונות מפרים
09:00	מעבר לאוטובוס #2
09:00–09:45	צפייה + לכידה
09:45–10:00	הפעלת זיהוי פנים, אימות ושליחת קנסות
...	חזרה על המחזור
16:00	סיכום יומי: X נלכדו, Y זוהו, Z קנסות נשלחו

תפוקה צפויה: 15–25 תמונות נלכדות ביום ← 5–10 זיהויים ← 3–7 קנסות

---

8. ניתוח כלכלי

8.1 עלויות חודשיות - PoC

סעיף	עלות חודשית	הערות
עובד בקרה (משרה מלאה)	10,000 ₪	כולל מעסיק; אפשרות לעובד מרוחק
Amazon Rekognition	כ-200 ₪	כ-5,000 חיפושים/חודש
AWS (S3 + Lambda + EC2)	כ-500 ₪	אחסון + עיבוד
גישה למצלמות CCTV	0 ₪	תשתית קיימת
סה"כ	כ-10,700 ₪/חודש

8.2 הכנסה צפויה

פרמטר	ערך	חישוב
גובה קנס	180 ₪	קבוע בחוק
ימי עבודה בחודש	22
תפיסות נדרשות לכיסוי עלות	2.7 ביום	10,700 ÷ 180 ÷ 22
תפיסות צפויות (שמרני)	5 ביום	מתוך 15-25 לכידות
הכנסה חודשית צפויה	כ-19,800 ₪	5 × 180 × 22
רווח חודשי נטו	כ-9,100 ₪	19,800 − 10,700

8.3 ROI

8.4 אפקט ההרתעה (Deterrence)

אפקט	הערכה
ירידה בהתחמקות מהרתעה	10–30% (על בסיס ברצלונה)
תוספת פדיון שנתית (10% ירידה)	כ-40 מיליון ₪
תוספת פדיון שנתית (20% ירידה)	כ-80 מיליון ₪

---

9. פרטיות, רגולציה ואתיקה

9.1 מסגרת חוקית

חוק / תקנה	רלוונטיות	דרישה
חוק הגנת הפרטיות, תשמ"א-1981	שימוש בתמונות ומידע אישי	הרשמה במאגרי מידע, מטרה מוגדרת
תקנות הגנת הפרטיות (אבטחת מידע)	אבטחת המאגר	הצפנה, גישה מבוקרת, תיעוד
GDPR (כ-benchmark)	עקרונות עיבוד מידע	Minimization, Purpose limitation
חוק עונשין - צילום ברה"ר	מצלמות באוטובוס	מותר - מרחב ציבורי + שילוט
פקודת סדר הדין הפלילי	הנפקת קנסות	עילה חוקית לדוח

9.2 עקרונות פרטיות מובנית (Privacy by Design)

עיקרון	יישום בפתרון
מידע מינימלי	רק נוסעים שכבר במאגר רב-קו; לא נאסף מידע חדש
מטרה מוגדרת	אכיפת תשלום בלבד - לא שימוש אחר
שמירה רק כשיש עילה	תמונות מפרים נשמרות; שאר התמונות נמחקות תוך 24 שעות
הצפנה	כל המידע מוצפן At-Rest ו-In-Transit
גישה מבוקרת	רק עובדי בקרה מורשים, עם Audit Log מלא
זכות ערעור	נוסע שקיבל קנס יכול לערער ולבקש בדיקה מחדש
שקיפות	שילוט באוטובוסים: "אוטובוס זה מנוטר לצורך אכיפת תשלום"

9.3 הבדלים מדגמי סין/רוסיה

היבט	סין/רוסיה	הפתרון שלנו
היקף	כל האזרחים	רק נוסעים רשומים ברב-קו (בשלב הראשון אלו שנעלה למאגר)
מטרה	ריבוי שימושים	אכיפת תשלום בלבד
שמירת מידע	ללא מגבלה	מחיקה תוך 24 שעות
פיקוח	ממשלתי מרכזי	Audit Log + DPIA + רגולטור
ערעור	לא קיים	זכות ערעור מלאה

---

10. היקף הפיילוט

10.1 פרמטרים

פרמטר	ערך
מספר אוטובוסים	5–10
קווים	1–2 קווים "אדומים"
מפעיל	מפעיל אחד
אזור	מטרופולין אחד
עובדי בקרה	1
גודל מאגר פנים	300
משך	3 חודשים
תקציב	50,000 ₪

10.2 מדדי הצלחה (KPIs)

מדד	יעד PoC	יעד פיילוט	אופן מדידה
תפיסות יומיות (ממוצע)	≥3	≥5	דיווח מערכת
דיוק זיהוי פנים	≥90%	≥95%	השוואת התאמות
False Positive Rate	<5%	<2%	בדיקה ידנית
כיסוי עלות	≥100%	≥150%	הכנסות vs. עלויות
זמן מקליטה ועד קנס	<24 שעות	<4 שעות	תיעוד מערכת
שביעות רצון עובד בקרה	≥3.5/5	≥4/5	סקר
ירידה בהתחמקות	-	≥15%	השוואת APC↔AFC

---

11. לוח זמנים

שלב	תיאור	תאריך משוער
1. הגשת מענה	הגשה דרך זירת האתגרים	עד 25.02.2026
2. בחינה ובחירה	הערכת מענים ובחירת זוכים	מרץ 2026
3. Discovery	פגישות, מיפוי גישה למצלמות	אפריל 2026
4. בניית מאגר	300 תמונות ל-Rekognition	אפריל 2026
5. פיתוח ממשק	צפייה + לכידה + זיהוי + קנסות	אפריל–מאי 2026
6. PoC	5 אוטובוסים, עובד אחד	מאי–יוני 2026
7. הערכת PoC	ניתוח תוצאות, Go/No-Go	יוני 2026
8. סיכום	דוח תוצאות והמלצות	אוגוסט 2026

---

12. סיכונים ומיטיגציות

סיכון	חומרה	הסתברות	מיטיגציה
איכות תמונה ממצלמות	גבוהה	בינונית	בדיקת איכות לפני הפיילוט; מצלמות HD
התנגדות רגולטורית	גבוהה	בינונית	DPIA מוקדם + שיתוף הרגולטור
התנגדות ציבורית	בינונית	גבוהה	שקיפות, שילוט, מטרה מוגדרת
דיוק נמוך	גבוהה	נמוכה	אימות אנושי כפול; סף 95%+
גישה למצלמות	גבוהה	בינונית	הסכם מראש עם המפעיל
עובדי בקרה	בינונית	נמוכה	עבודה מרחוק; שכר תחרותי
ערעורים	בינונית	בינונית	תיעוד ראייתי מלא
עקיפה (מסכה/כובע)	בינונית	בינונית	שיפור אלגוריתמים; זיהוי נוסף

---

13. שיפורים עתידיים

Phase 2 - אוטומציה מלאה

שיפור	תיאור	תנאי
זיהוי אוטומטי מלא	ללא התערבות אנושית	דיוק ≥98%, אישור רגולטורי
הורדת טעויות	המערכת בודקת מול מערכת הדיווח - אולי כן היה תיקוף והמערכת פספסה	דיווח בזמן אמת של נתוני תיקוף
מערכת הוליסטית	צפייה ← זיהוי ← קנס	סיום PoC בהצלחה
שילוב עם הצעה 1	"צפה במצלמות" מאפליקציית הפקחים	שתי ההצעות פעילות
הרחבה לתחנות	מצלמות בתחנות מרכזיות	התקנת מצלמות
API קנסות	חיבור למערכת קנסות המשרד	אישור משרד
Machine Learning	חיזוי מפרים מדפוסים	מספיק נתוני אימון

Phase 3 - הרחבה ארצית

1. תקציר מנהלים

משרד התחבורה מתמודד עם הפסד שנתי מוערך של כ-400 מיליון ₪ מהשתמטות מתשלום בתחבורה הציבורית. שיעור אי-התיקוף בישראל מוערך ב-כ-20% - פי 2-6 מערים מובילות בעולם.

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

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

---

2. רקע ותיאור הבעיה

2.1 מצב קיים - תהליך התיקוף בישראל

תהליך התיקוף הנוכחי מחייב את הנוסע לבצע פעולה אקטיבית בכל עלייה:

שלב	פעולה נדרשת	בעיה
1	לפתוח ארנק / להוציא טלפון	מסורבל, במיוחד בצפיפות
2	להניף כרטיס / לפתוח אפליקציה	דורש פעולה פיזית
3	לחכות לאישור בולידטור	תור, לחץ, עיכוב
4	לוודא שהתיקוף נקלט	לא תמיד ברור

2.2 הכאבים - למה אנשים לא מתקפים

סיבה	תיאור	אחוז מוערך
שכחה / חוסר תשומת לב	"פשוט שכחתי"	כ-30%
תהליך מסורבל	"יותר מדי שלבים"	כ-25%
אופורטוניזם	"אף אחד לא בודק"	כ-20%
בעיות טכניות	"האפליקציה לא עבדה"	כ-15%
חוסר הבנה	"לא ידעתי שצריך" (תיירים)	כ-10%

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

2.3 ההזדמנות - מה אם התיקוף היה אוטומטי?

מצב קיים (ידני):
נוסע עולה ← פותח ארנק ← מניף כרטיס ← מחכה לאישור
= 4 פעולות, 15-30 שניות, חיכוך גבוה

הפתרון המוצע (אוטומטי):
נוסע עולה ← מקבל נוטיפיקציה ← לוחץ "אשר"
= 1 פעולה, 2 שניות, חיכוך אפסי

---

3. נתונים ומספרים

3.1 נתוני אי-תיקוף בישראל ובעולם

מדד	ערך	מקור
עלות הפעלת תח"צ שנתית	כ-20 מיליארד ₪	משרד התחבורה
פדיון שנתי מתיקופים	כ-2.5 מיליארד ₪	משרד התחבורה
שיעור אי-תיקוף מוערך	כ-20%	ניתוח פנימי
הפסד שנתי מוערך	כ-400 מיליון ₪	משרד התחבורה
גובה קנס	180 ₪	חוק עזר

3.2 השוואה בינלאומית

עיר / רשות	שיעור אי-תיקוף	מנגנון	הערות
לונדון (TfL)	3.4%	Oyster + Fare Capping	שילוב תמריצים + אכיפה
ניו יורק (MTA)	כ-10% (ירד מ-14%)	OMNY + Fare Capping	שילוב אכיפה + דיגיטציה
שוויץ/אירופה (FAIRTIQ)	נמוך מאוד	CIBO + Best-Price	131M נסיעות/שנה
אוסנבריק (YANiQ)	נמוך	CIBO + BLE Beacons	פיילוט עם ביקונים
ישראל	כ-20%	תיקוף ידני + אכיפה אקראית	פי 2-6 מערים מובילות

3.3 ראיות מהעולם - השפעת גבייה דיגיטלית על הכנסות

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

מערכת	מודל	תוצאות מתועדות	מקור
FAIRTIQ / HAVAG	CIBO + Best-Price	עלייה של 20% בהכנסות ממכירת כרטיסים (p<0.05)	HAVAG Trial, גרמניה
FAIRTIQ / Vorarlberg	CIBO + Best-Price	עלייה של 40% בשימוש שנה-על-שנה	Vorarlberg, אוסטריה
סטוקהולם	כרטוס דיגיטלי	אי-תיקוף ירד מ-3.1% ל-2.3%; תיקוף במעבורות עלה מ-58% ל-89%	SL Stockholm Report
Visa Survey	Contactless Payment	70% מרשויות התחבורה דיווחו על ירידה בהונאות	Visa Transit Survey 2023
דנמרק / Rejsekort	CIBO via FAIRTIQ	66% אימוץ ב-18 חודשים; 90% דיווחו על שיפור בחוויה	Rejsekort / FAIRTIQ
YANiQ (אוסנבריק)	CIBO + BLE Beacons	3,600 הורדות ב-3 חודשים, דיוק 95%+	Stadtwerke Osnabruck

שורה תחתונה: אין עדיין מחקר בודד שמראה "BIBO הוריד אי-תיקוף ב-X%". אבל הנתונים מראים עלייה של 20-40% בהכנסות, אימוץ מהיר, ולוגיקה כלכלית חזקה: כשהתשלום אוטומטי, קל וזול - אנשים משלמים. הפיילוט שלנו נועד בדיוק לאמת את ההנחה הזו בשטח הישראלי.

---

4. הפתרון המוצע - הצעה מס' 3: גבייה אוטומטית עם ביקונים

4.1 סקירה כללית - BIBO + אישור נוסע

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

	BIBO מלא (אוטומטי)	BIBO + אישור (שלנו)	CIBO (ידני)
פעולת נוסע	שום דבר	אישור נוטיפיקציה	לחיצה "התחל" באפליקציה
זיהוי עלייה	BLE Beacons	BLE Beacons	GPS בלבד
בעיות	False positives	אין - הנוסע מאשר	נוסע שוכח ללחוץ
חוויה	"קסומה" אבל בעייתית	"המערכת דואגת לי"	"אני צריך לזכור"
מוכח?	פיילוטים בלבד	YANiQ, FAIRTIQ	FAIRTIQ: 131M/שנה

4.2 שלב 1 - זיהוי עלייה: ביקונים באוטובוס מזהים את הטלפון

פרמטר	ערך
טכנולוגיה	BLE Beacons (Bluetooth Low Energy) - תקן iBeacon / Eddystone
מיקום התקנה	3 ביקונים לאוטובוס (כניסות + אמצע)
טווח זיהוי	5-10 מטר (ניתן לכוונן)
זמן זיהוי	פחות מ-2 שניות
צריכת סוללה (ביקון)	2-3 שנים ללא החלפה
צריכת סוללה (טלפון)	מינימלית - BLE Scanning ברקע

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

4.3 שלב 2 - נוטיפיקציה: "עלית לקו X, לאשר נסיעה?"

פרמטר	ערך
זמן הופעה	תוך 5-10 שניות מעלייה לאוטובוס
סוג נוטיפיקציה	Rich Notification עם כפתורי פעולה
Timeout	5 דקות - אם לא הגיב, שליחת תזכורת
תזכורות	עד 2 תזכורות, בהפרש של 3 דקות
אם לא אושר	הנסיעה לא נרשמת - אין רישום ללא אישור מפורש

4.4 שלב 3 - אישור הנוסע: לחיצה אחת מאשרת את הנסיעה

כשהנוסע לוחץ "אשר":

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

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

---

5. תימוכין - מקרי בוחן מהעולם

5.4 סיכום תימוכין

עיר/מערכת	מודל	תוצאה	רלוונטיות להצעה 3
YANiQ (אוסנבריק)	CIBO + BLE Beacons	95%+ דיוק	ביקונים - הוכחת טכנולוגיה
Siemens ALLFA	BIBO מלא	פיילוט בלבד	אישור נוסע פותר false positives
לונדון (Oyster)	Fare Capping	3.4% אי-תיקוף	Fare Capping עובד
ניו יורק (OMNY)	Fare Capping	-30% אי-תיקוף	Fare Capping מוריד
דנמרק (Rejsekort)	CIBO	90% שביעות רצון	חוויית משתמש טובה

---

6. ארכיטקטורה טכנית

6.1 תרשים מערכת

BLE BEACONS (באוטובוס)
       [BLE #1] [BLE #2] [BLE #3]
            |       |       |
            +-------+-------+
                    |
                    | BLE Signal
                    v
           +----------------+
           | Passenger      |           HTTPS
           | Smartphone     | ----------------------+
           |                |                       |
           | - BLE Scanner  |                       v
           | - GPS Tracker  |              +------------------+
           | - Notifications|              |  BACKEND CLOUD   |
           +----------------+              |                  |
                                           | - Trip Engine    |
                                           | - Beacon Manager |
                                           +--------+---------+
                                                    |
                                                    v
                                            +-------------+
                                            | Passenger   |
                                            | App         |
                                            |             |
                                            | - History   |
                                            | - Trips     |
                                            +-------------+

6.2 רכיבי חומרה - BLE Beacons

פרמטר	מפרט
תקן	BLE 5.0 - iBeacon / Eddystone
טווח שידור	5-10 מטר (ניתן לכוונן)
חיי סוללה	2-3 שנים (CR2477 / CR2450)
עמידות	IP67 (עמיד למים ואבק)
טמפרטורה	-20 עד +60 מעלות
גודל	כ-5x5x1.5 ס"מ
עלות ליחידה	כ-80-120 ₪
התקנה	הדבקה/ברגים - ללא חיווט, ללא חשמל
כמות לאוטובוס	3 יחידות
כמות לפיילוט	45 יחידות (15 אוטובוסים x 3 ביקונים)
עלות כוללת לפיילוט	כ-5,400 ₪

6.3 רכיבי תוכנה

רכיב	טכנולוגיה	תפקיד
אפליקציית נוסע	React Native	BLE scanning, נוטיפיקציות, GPS tracking, אישור נסיעה
שרת Backend	Node.js / Python	Trip Engine, Beacon Manager, API
בסיס נתונים	PostgreSQL	נסיעות, נוסעים, היסטוריה
Cache	Redis	Active trips, Beacon status, Session
מנוע מיקום	GPS + Accelerometer + BLE	זיהוי עלייה (BLE)
Push Notifications	Firebase Cloud Messaging	נוטיפיקציות עלייה, תזכורות

6.4 אינטגרציה עם רב-קו

שלב	אינטגרציה	תיאור
פיילוט	אפליקציה עצמאית	ללא אינטגרציה - סימולציית תשלום (ללא גבייה בפועל)
שלב 2	API לרב-קו דיגיטלי	חיוב ישירות מרב-קו דיגיטלי
שלב 3	אינטגרציה מלאה	חלק ממערכת HopOn / רב-קו הדור הבא

6.5 תפקיד 200Apps

200Apps מפתחת, מתפעלת ומתחזקת את כל התשתית הטכנולוגית:

תוצר	תיאור	טכנולוגיה
אפליקציית נוסע (MVP)	BLE scanning, נוטיפיקציות, אישור נסיעה, GPS tracking, היסטוריה	React Native
Trip Engine	ניהול נסיעות - זיהוי עלייה, אישורים	Node.js / Python
Beacon Manager	ניהול ביקונים - רישום, סטטוס סוללה, מיפוי לאוטובוסים	API

---

7. תהליך עבודה מפורט

7.1 חווית נוסע (User Journey)

07:15  דנה הולכת לתחנת אוטובוס. האפליקציה רדומה ברקע.

07:20  קו 5 מגיע. דנה עולה לאוטובוס.
       ← הביקון מזהה את הטלפון שלה
       ← נוטיפיקציה: "עלית לקו 5 לכיוון ת"א. לאשר?"
       ← דנה לוחצת "אשר" (בלי לפתוח אפליקציה)
       ← "נרשמת בהצלחה! נסיעה טובה"

07:50  דנה עולה לקו 89.
       ← נוטיפיקציה: "עלית לקו 89 לכיוון הרצליה. לאשר?"
       ← לחיצה "אשר"

17:30  חוזרת - קו 89 + קו 5
       ← "עלית לקו 89. לאשר?" ← "אשר"
       ← "עלית לקו 5. לאשר?" ← "אשר"

7.2 חווית פקח

הפקח (באמצעות אפליקציית הצעה 1) יכול לראות:

מצב	תצוגה לפקח	פעולה
נוסע אישר נסיעה	✓ ירוק - "נסיעה מאושרת"	אין צורך בפעולה
נוסע לא אישר	✗ אדום - "אין אישור"	בדיקה ידנית / קנס
נוסע ללא אפליקציה	? אפור - "לא במערכת"	בדיקת רב-קו רגילה

---

8. ניתוח כלכלי

8.1 עלויות פיילוט (תקציב 50,000 ₪)

סעיף	הערות
אפיון UX/UI	מסכי אפליקציה
רכישת BLE Beacons	45 יחידות (15 אוטובוסים x 3)
פיתוח אפליקציית נוסע (MVP)	React Native, BLE, נוטיפיקציות, GPS
פיתוח Backend	API, DB, Trip Engine, Beacon Manager
בדיקות שטח + QA	התקנת ביקונים + בדיקות על קו הפיילוט (15 אוטובוסים)
ניהול פרויקט	200Apps PM

8.2 ROI צפוי

תרחיש	עלייה בתיקוף	תוספת פדיון חודשית
שמרני	5% (מ-80% ל-85%)	כ-26,000 ₪
בינוני	10% (מ-80% ל-90%)	כ-52,000 ₪
אופטימי	15% (מ-80% ל-95%)	כ-78,000 ₪

8.3 מודל עסקי לאחר פיילוט

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

---

9. פרטיות, רגולציה ואתיקה

9.1 מידע שנאסף

סוג מידע	פירוט	בסיס חוקי	שמירה
אירועי נסיעה	קו, תחנת עלייה/ירידה, זמן	חוזה שירות	90 ימים
מיקום (בנסיעה בלבד)	GPS - רק כשנסיעה פעילה	הסכמת משתמש	מחיקה בסוף הנסיעה
פרופיל נוסע	שם, טלפון	הסכמה מפורשת	כל עוד חשבון פעיל
נתוני BLE	UUID ביקון, עוצמת אות	לגיטימי	לא נשמר

9.2 עמידה ברגולציה ישראלית

חוק / תקנה	רלוונטיות	עמידה
חוק הגנת הפרטיות, תשמ"א-1981	שימוש במידע אישי	רישום מאגר מידע, מטרה מוגדרת
תקנות הגנת הפרטיות (אבטחת מידע)	אבטחת המידע	הצפנה At-Rest + In-Transit
GDPR (כ-benchmark)	עקרונות עיבוד	Data Minimization, Purpose Limitation
PCI-DSS	רלוונטי בשלב תשלום בפועל (לא בפיילוט)	Tokenization (בעתיד)

9.3 הסכמת משתמש

עיקרון	יישום
Opt-in מפורש	ההרשמה לאפליקציה וולונטרית לחלוטין
אישור כל נסיעה	הנוסע מאשר כל נסיעה - אין רישום ללא אישור
שקיפות מלאה	הנוסע רואה היסטוריית נסיעות
מיקום רק בנסיעה	GPS פעיל רק במהלך נסיעה מאושרת
זכות מחיקה	ביטול חשבון ומחיקת כל הנתונים בכל עת
ללא זיהוי פנים	אין שום שימוש בביומטריה (בניגוד להצעה 2)
ללא מעקב	אין מעקב מיקום כשהנוסע לא בנסיעה

---

10. היקף הפיילוט

10.1 פרמטרים

פרמטר	ערך
קווי אוטובוס	קו אחד (גוש דן)
סוג תעריף	תעריף קבוע (לא משתנה) - הפיילוט יופעל על קווי אוטובוס עם תעריף אחיד
אוטובוסים מצוידים בביקונים	15
ביקונים	45 יחידות (15 אוטובוסים x 3 ביקונים)
נוסעי בטא (יעד)	100-500
מפעיל	מפעיל אחד
אזור	מטרופולין אחד
תשלום בפועל	לא - סימולציה בלבד ("שילמת" ללא גבייה)
משך הפעלה	3 חודשים
תקציב	50,000 ₪

10.2 KPIs

מדד	יעד	אופן מדידה
דיוק זיהוי עלייה (BLE)	98%+	נוטיפיקציות vs. עליות בפועל
שיעור אישור נוטיפיקציות	85%+	אושרו / נשלחו
False Positive Rate	פחות מ-3%	נדחו ("לא עליתי")
שביעות רצון נוסעים	4/5+	סקר
שיעור תיקוף בקווי הפיילוט	עלייה של 10%+	APC-AFC לפני/אחרי
הורדות אפליקציה	200+	מערכת
חיסכון ממוצע לנוסע	5+ ₪/יום	מערכת

10.3 קריטריונים להצלחה

קריטריון	סף מעבר להרחבה
שביעות רצון נוסעים	3.5/5+
שיעור אישור נוטיפיקציות	80%+
עלייה בשיעור תיקוף	5%+
אין בעיות פרטיות/רגולציה	כן
100+ נוסעים פעילים	כן

---

11. לוח זמנים

שלב	תיאור	משך	תאריך משוער
1. הגשת מענה	הגשה דרך זירת האתגרים	-	עד 25.02.2026
2. בחינה ובחירה	הערכת מענים ובחירת זוכים	כ-4 שבועות	מרץ 2026
3. Discovery	פגישות, בחירת קווים, מיפוי אוטובוסים	2 שבועות	אפריל 2026
4. אפיון + UX/UI	עיצוב בסיסי המבוסס על המוקאפ	2 שבועות	אפריל 2026
5. רכישת ביקונים	הזמנה, קבלה, בדיקה	שבוע	אפריל 2026
6. פיתוח	אפליקציה + Backend	4 שבועות	מאי 2026
7. התקנה + בדיקות	התקנת ביקונים באוטובוסים, QA	שבוע	יוני 2026
8. פיילוט חי	הפעלה עם נוסעי בטא למספר אוטובוסים, ניטור, אופטימיזציה	3 חודשים	יוני-אוגוסט 2026
9. הערכה וסיכום	ניתוח תוצאות, דוח מסכם, המלצות	שבוע	ספטמבר 2026

---

12. סיכונים ומיטיגציות

סיכון	חומרה	הסתברות	מיטיגציה
דיוק BLE נמוך - ביקון מזהה אנשים שלא עלו	גבוהה	בינונית	כיוונון טווח; אישור נוסע מבטל false positives; מספר ביקונים ליתירות
אימוץ נמוך - נוסעים לא מורידים אפליקציה	גבוהה	בינונית	קמפיין השקה; שילוב באפליקציות קיימות בשלב 2
צריכת סוללה - BLE scanning מרוקן	בינונית	נמוכה	BLE 5.0 חסכוני; Scanning חכם (רק ליד תחנות)
חוסר שיתוף פעולה מפעילים	גבוהה	בינונית	גיבוי משרד התחבורה; הדגמת ערך; התקנה פשוטה
נוסעים לא מגיבים לנוטיפיקציה	בינונית	בינונית	עד 2 תזכורות; timeout - לא נגבה; שיפור UX
גניבת/השחתת ביקונים	נמוכה	נמוכה	התקנה מוסתרת; עלות החלפה נמוכה; התראה אוטומטית
תחרות עם אפליקציות קיימות	נמוכה	בינונית	אינטגרציה (לא תחרות); SDK לשותפים; ערך ייחודי

---

13. שיפורים עתידיים

Phase 2 - הרחבה

שיפור	תיאור	תנאי
אינטגרציה עם Moovit / רב-פס	SDK שמוסיף BIBO לאפליקציות קיימות	הסכמי SDK
הרחבה ל-20+ קווים	כיסוי מטרופולין שלם	הצלחת פיילוט
ביקונים ברכבת	הרחבה לרכבת קלה/כבדה	שיתוף פעולה
API לרב-קו	חיוב ישירות מרב-קו דיגיטלי	אישור משרד
תמיכה בתעריפי נסיעה שונים	תמיכה בקווי אוטובוס עם תעריפי נסיעה שונים - הנוסע יבחר את אורך הנסיעה	הרחבת הפיילוט

Phase 3 - BIBO מלא (שדרוג ללא אישור)

שיפור	תיאור	תנאי
BIBO אוטומטי לחלוטין	ביטול שלב האישור - חיוב אוטומטי	דיוק 99%+, אישור רגולטורי
UWB (Ultra-Wideband)	דיוק מיקום של סנטימטרים	ירידת מחירי חומרה
Multi-modal	אוטובוס + רכבת + מונית שיתופית	אינטגרציה ארצית
AI Prediction	חיזוי נסיעות וצרכי נוסעים	מספיק נתוני אימון
Dynamic Pricing	הוזלה בשעות שקטות	אישור רגולטורי
Carbon Credits	נקודות על חיסכון פחמן	שיתוף ESG

---

נספח א' - שילוב הצעה 1 + הצעה 2 + הצעה 3

אסטרטגיה משולבת

הצעה 1: ניתוב פקחים חכם           ← לתפוס מי שלא שילם (מקל)
הצעה 2: בקרת מצלמות               ← לקנוס מרחוק (מקל)
הצעה 3: גבייה אוטומטית + ביקונים   ← שלא יצטרכו לתקף ידנית (מניעה)
                                      |
                    ירידה דרמטית באי-תיקוף

כיצד שלוש ההצעות פועלות יחד

	הצעה 1 - פקחים	הצעה 2 - מצלמות	הצעה 3 - BIBO + אישור
גישה	אכיפה ממוקדת	אכיפה מרחוק	מניעה - תיקוף אוטומטי
מטרה	לתפוס מי שלא שילם	לקנוס מרחוק	להסיר הצורך בתיקוף ידני
מנגנון	מקל (stick)	מקל (stick)	מניעה - תיקוף אוטומטי
השפעה על "שוכח"	לא רלוונטי	לא רלוונטי	"המערכת מזכירה לי"
השפעה על "מסורבל"	לא רלוונטי	לא רלוונטי	"לחיצה אחת במקום 4 שלבים"
השפעה על אופורטוניסט	"ייתפסו אותי"	"ייקנסו אותי"	"המערכת דואגת לי"

השפעה מצטברת

שיעור אי-תיקוף נוכחי:                         כ-20%
                                                  |
אחרי הצעה 1 (אכיפה ממוקדת):                     v
צמצום של כ-25%                                    15%
                                                  |
+ הצעה 2 (אכיפה מרחוק):                          v
צמצום נוסף של כ-20%                               12%
                                                  |
+ הצעה 3 (גבייה אוטומטית):                        v
צמצום נוסף של כ-40%                                7%
                                                  |
                                                  v
                                   יעד: פחות מ-10% (כמו ניו יורק)
                                   שאיפה: פחות מ-5% (כמו לונדון)

חישוב תוספת פדיון - 3 הצעות יחד

תרחיש	ירידה באי-תיקוף	תוספת פדיון שנתית	עלות כוללת	ROI
שמרני	מ-20% ל-14%	כ-150 מיליון ₪	כ-150,000 ₪	100,000%
בינוני	מ-20% ל-10%	כ-250 מיליון ₪	כ-150,000 ₪	166,000%
אופטימי	מ-20% ל-7%	כ-325 מיליון ₪	כ-150,000 ₪	216,000%

הערה: ה-ROI הגבוה נובע מכך שעלויות הפיילוט (כ-150,000 ₪ לשלוש הצעות) זניחות ביחס להפסד השנתי (כ-400 מיליון ₪). אפילו שיפור של אחוז אחד בתיקוף שווה כ-25 מיליון ₪ בשנה.