דשבורד תכנון וקבלת החלטות
כל התוכנית, בלי ללכת לאיבוד במסמך
בחרו את תחום העבודה, פתחו שלב או טבלה בהקלקה וקבלו את הפירוט הרלוונטי. התוכן משקף את תוכנית העבודה ואת מסמך הקווים ליצירת המכרז ולפיתוח המערכת.
3,000–3,500משתמשים ישירים
15–20מובילי שינוי מומלצים
5 חלופותמבנה פתרון ופיתוח
8 שלביםמהאפיון ועד בקרה ושיפור
תוכנית העבודה
הדרך מהאפיון ועד השיפור המתמשך
השלבים משלבים טכנולוגיה, העברת נתונים, הדרכה, תקשורת, בקרה וניהול שינוי. שלב ד׳ מופיע במסמך הפיתוח הייעודי.
00תקציר מנהליםמטרת המהלך ועקרונות הבחירה
- להחליף את מערכות הליבה בדרך מסודרת, ברורה ובהשתתפות המשתמשים.
- המהלך נוגע ל־3,000 עד 3,500 משתמשים ישירים ולעשרות אלפי משתמשים עקיפים.
- לבחון את כלל האפשרויות ולבחור באופן מקצועי לפי צורכי הארגון, ניהול הסיכונים והתקציב.
- בהתאם לכך, מומלץ לבחון מערכת קיימת ויציבה, עם התאמות ושכבת AI שאפשר לבקר ולהרחיב בהדרגה, לצד יתר החלופות.
- להתבסס על שירותי ענן ואחסון קיימים, ללא הקמת שרתים ייעודיים, בכפוף לאבטחה, זמינות וגיבוי.
- שימוש בכלי AI עשוי לצמצם עד כ־35% מהמאמץ במשימות פיתוח מסוימות; אין זו הבטחה לחיסכון זהה בתקציב או בזמן הכולל.
- ההצלחה תלויה גם בהעברת נתונים, ממשקים, ממשל, הדרכה, תמיכה וניהול השינוי.
- העלייה לאוויר תהיה הדרגתית, עם פיילוט, בקרה ותוכנית חזרה במקרה של כשל.
יעדמטרת התוכניתמה אנחנו רוצים להשיג
- להוביל מעבר מסודר וברור למערכות החדשות.
- לערב את המשתמשים כבר בשלב האפיון.
- לצמצם התנגדויות ולחזק את תחושת השותפות.
- להבטיח הדרכה, תמיכה ובקרה לאורך כל הדרך.
- לשלב חשיבה חדשנית ושימוש אחראי בבינה מלאכותית.
היקףהיקף השינוימשתמשים, תהליכים והרגלי עבודה
- 3,000 עד 3,500 משתמשים ישירים: עובדי האיגוד, אגודות, שופטים ומאמנים.
- עשרות אלפי משתמשים עקיפים: שחקנים, הורים ואוהדים.
- השינוי כולל מערכות, תהליכי עבודה, הרגלים, הרשאות, מידע ושירות.
- האתגר המרכזי הוא לגרום לאנשים לאמץ את המערכת, לא רק להתקין אותה.
א׳השקה ואפיון צרכיםשיתוף המשתמשים ובניית בסיס הדרישות
הודעת פתיחה
- מכתב מיו״ר האיגוד לעובדים, למנהלי האגודות, לשופטים ולמאמנים.
- הסבר קצר על מטרת הפרויקט, החשיבות שלו ולוח הזמנים הכללי.
- הבהרה שהמשתמשים שותפים לתהליך ויכולים להשפיע על המערכת.
מפגש פתיחה לעובדי האיגוד
- מפגש של כ־3 שעות, רצוי מחוץ למשרדי האיגוד.
- הצגת שתי מערכות שונות בגישה ובאופן העבודה ודוגמאות לתהליכים מתקדמים.
- חלוקת דפי עבודה והגדרת הקשיים, הצרכים והדרישות של כל מחלקה.
- אפשרות מעשית: חדר ישיבות בקומה ה־61 במגדלי עזריאלי, כולל ארוחת בוקר וכיבוד, בעלות משוערת של 2,000–2,500 ₪.
מפגשים עם בעלי עניין
- מפגשים ייעודיים עם מנהלים ונציגים מהאגודות, סגל השופטים ומאמנים.
- הצגת מערכות נוספות לצורך השראה וריכוז צרכים, קשיים, חששות והצעות.
תוצר השלב
- מסמך צרכים מרוכז לפי מחלקות וקבוצות משתמשים.
- חלוקה לדרישות חובה, דרישות חשובות ושיפורים רצויים.
- רשימת תהליכים לביטול, קיצור או אוטומציה ורשימת נקודות סיכון למעבר.
ב׳גיבוש המכרז ובחירת הספקדרישות, תרחישים ובדיקת ניסיון
- לכתוב את המכרז על בסיס הצרכים שעלו מהשטח.
- להגדיר מה המערכת צריכה לאפשר, ולא רק איך הספק יבצע זאת.
- להגדיר תכולה, ממשקים, העברת נתונים, הרשאות, אבטחת מידע ומודל ענן ואחסון.
- להגדיר הדרכות, תמיכה, זמני תגובה, מדדי הצלחה ולוחות זמנים.
- לבחון ספקים דרך תרחישים אמיתיים מחיי האיגוד וניסיון בהטמעת מערכות לאלפי משתמשים.
ג׳תכנון מפורט והכנת הארגוןמשתמשים, הרשאות, נתונים והדרכה
- למפות את כל קבוצות המשתמשים והתהליכים שלהם.
- להגדיר הרשאות ובעלי אחריות.
- להחליט אילו נתונים עוברים ואיך בודקים אותם.
- לבנות תוכנית הדרכה ותמיכה ולפרסם לוח זמנים ברור.
- להכין את המשתמשים לשינוי בתהליכי העבודה, לא רק ללימוד המערכת.
ד׳פיתוח, התאמות ובדיקותמפורט במסמך הייעודי לפיתוח המערכת
השלב כולל פיתוח והתאמה לפי האפיון, גרסאות מוקדמות, בדיקות ליבה ורכיבי AI, פיילוט ותיקונים לפני הרחבת השימוש.
רוחבימסלולי עבודה שחוצים את כל הפרויקטנתונים, ממשקים, ענן, ממשל ואבטחה
העברת נתוניםמיפוי, ניקוי כפילויות, בדיקות איכות ואישור לאחר ההעברה.
מפת ממשקיםכל המערכות המחוברות לליבה, אחריות ותדירות העברת מידע.
תשתיות וענןענן ואחסון קיימים ומנוהלים; ביצועים, זמינות, גיבוי, DR, ניטור ו־SLA.
מעבר וחזרהתוכנית מעבר, קריטריונים לאישור ותוכנית חזרה במקרה של כשל.
סגירת המערכת הישנהלוח זמנים, היסטוריה, הרשאות צפייה ועבודה מקבילה לפי הצורך.
ממשל הפרויקטועדת היגוי, מנהל פרויקט, בעלי מוצר וסמכויות אישור.
תיקון 13 ואבטחת מידע
- למפות ולסווג מידע, לרבות מידע על קטינים ומידע בעל רגישות מיוחדת, ולקבוע את הדרישות החלות על המאגר.
- להגדיר מטרות שימוש, הרשאות, צמצום מידע, תקופות שמירה ומחיקה.
- להגדיר בעלי שליטה ומחזיקים, ספקי משנה, מיקום המידע והעברתו מחוץ לישראל.
- ליישם הרשאות לפי תפקיד, MFA, הצפנה, תיעוד פעולות, ניטור, גיבוי ובדיקות שחזור.
- לבצע סקר סיכונים ובדיקות חדירות, לקבוע נוהל טיפול ודיווח ולבחון צורך בממונה הגנת פרטיות.
ה׳סדנאות AI וחשיבה חדשניתשימוש מעשי, אחראי ומבוקר
- לקיים סדנאות לעובדי האיגוד, נציגי האגודות, שופטים ומאמנים.
- להכיר שימושי AI מעשיים לסיכום, ניסוח, ניתוח מידע, דוחות וייעול.
- לאתר פעולות ידניות שניתן לצמצם או להפוך לאוטומטיות.
- להדריך על פרטיות, אבטחה, בדיקת אמינות ואחריות אנושית.
- כל מחלקה תבחר תהליך אחד ותציע כיצד לשפר אותו בעזרת המערכת או AI.
ו׳מובילי שינויגרעין מומלץ של 15–20 מובילים
- להקים גרעין של כ־15 עד 20 מובילי שינוי המייצגים את עובדי האיגוד, האגודות, השופטים, המאמנים והאזורים.
- למנות אנשי קשר נוספים ביחידות ובאגודות גדולות לפי הצורך.
- לקיים מפגש חשיבה חודשי לאורך הפרויקט.
- לחשוף את הקבוצה לגרסאות מוקדמות, להעביר משוב ולסייע בהסברת השינוי.
- לאתר משתמשים הזקוקים לליווי נוסף.
ז׳הדרכה, הטמעה ועלייה לאווירפיילוט, הרחבה ותמיכה
- להתאים הדרכות לקבוצות משתמשים ולרמות ידע שונות ולתרגל בסביבת ניסוי.
- להכין מדריכים, סרטוני הסבר ומפגשי שאלות ותשובות.
- לעלות לאוויר בהדרגה: פיילוט ולאחריו הרחבה בשלבים.
- לתגבר תמיכה בתקופת ההשקה ולהפעיל מוקד, טופס תקלות ושאלות נפוצות.
- לקיים הדרכות רענון לאחר העלייה לאוויר.
ח׳בקרה ושיפורשימוש, תקלות, שביעות רצון ושיפור
- לעקוב אחרי השתתפות בהדרכות, שימוש במערכת ועבודה עצמאית.
- לעקוב אחרי תקלות, זמני טיפול ושביעות רצון.
- לבדוק ירידה בעבודה ידנית, בכפילויות ובטעויות ולאסוף הצעות שיפור.
- לסכם מצב אחרי שלושה ואחרי שישה חודשים ולעדכן את תוכנית העבודה.
KPIמדדי הצלחה מוצעיםיעדים מספריים ייקבעו לאחר האפיון ובפיילוט
אימוץ והדרכההשלמת הכשרה, משתמשים פעילים ושיעור השלמת תהליכים.
יעילות ואיכותזמני טיפול, עבודה ידנית, טעויות, כפילויות ודיוק הנתונים.
שירות ויציבותזמינות, תקלות קריטיות, זמני תגובה, פתרון ושביעות רצון.
רכיבי AIדיוק לפי מקרה שימוש, שיעור התערבות אנושית ועלות למקרה שימוש.
עיקרוןעקרונות מנחיםאיך מנהלים את השינוי נכון
שיתוף מהאפיוןהסבר לכל שינוישפה פשוטההתנסות לפני עלייה
התנגדות היא טבעיתתמיכה לאחר ההשקההצלחות מדידותתקשורת רציפה
קווים ליצירת המכרז ולפיתוח המערכת
חלופות, טווחים, עלויות ודרישות פיתוח
ההשוואה מפרידה בין שימוש ב־AI ככלי של צוות הפיתוח לבין יכולות AI שפועלות כחלק מהמוצר.
חשוב: זהו מסמך תכנון ראשוני. טווחי הזמן והעלות תלויים בתכולת המוצר, בהתאמות, בממשקים, באיכות הנתונים, באבטחה ובהיקף רכיבי ה־AI. עלויות הענן והחיובים המשתנים אינם כלולים. כל החלופות כפופות לדרישות תיקון 13 ולדרישות פרטיות ואבטחת מידע שייקבעו באפיון ובמכרז.
בסיסהנחות עבודה והבהרותמה עומד מאחורי ההשוואה
- כיום ניתן לבצע חלק מכתיבת הקוד באמצעות כלי AI, גם כאשר הקוד אינו נכתב ידנית שורה־אחר־שורה בידי מתכנת. זהו כלי בתהליך הפיתוח בלבד ואינו מעיד שלמערכת יהיו יכולות AI. לכן יש להבחין בין AI שכותב או מסייע בכתיבת קוד לבין AI שפועל כרכיב במוצר הסופי. הצוות המפתח נותר אחראי לתכנון, לבדיקה ולאישור הקוד.
- רכיב AI במוצר יכול לפעול בבק־אנד, בממשק המשתמש או בשניהם.
- בכל החלופות אפשר להשתמש בכלי AI לכתיבת קוד, תיעוד ובדיקות. הצמצום האפשרי הוא עד כ־35% מהמאמץ במשימות מסוימות, אך אין פירוש הדבר חיסכון דומה בזמן הכולל או בעלות. פיתוח בסיוע AI מחייב בקרות נוספות מעבר לתהליך הפיתוח הרגיל, ובהן אימות תוצרים, סקירת קוד אנושית, בדיקות איכות ואבטחה, בדיקת רישיונות וזכויות, תיעוד ועקיבות.
- אם ספק מציג פיתוח באמצעות AI, אין להסתפק בהצהרה כללית. יש לבקש מתודולוגיה כתובה המפרטת: באילו משימות ובאילו כלים נעשה שימוש ב־AI; כיצד נשמרים המידע והסודיות; מי בודק ומאשר את הקוד; אילו בקרות איכות, אבטחה ורישוי מבוצעות; כיצד מתועדים מקורו של הקוד והשינויים בו; למי שייכות הזכויות בקוד; מי אחראי לתקלות ולתחזוקה; ומהו החיסכון נטו המוכח במאמץ, בזמן ובעלות לעומת נקודת בסיס של פיתוח רגיל.
- בתהליכי ליבה כמו רישום, זכאות, שיבוצים ותשלומים יש להעדיף כללים דטרמיניסטיים, תיעוד מלא ובקרה אנושית.
- כל החלופות מניחות ענן ואחסון קיימים ומנוהלים. עלויות ענן וקומפיוט נוספות יתומחרו בנפרד.
- הזמן הכולל הוא משך קלנדרי משוער עד השלמת העלייה לאוויר; שלבים חופפים ולכן אין לחבר את כל השורות.
- הליך מקדים של 3–6 חודשים הוא יעד תכנון ועלול להתארך בשל מכרז, שאלות ספקים, משא ומתן או אישורים.
13תיקון 13, פרטיות ואבטחת מידעדרישות מחייבות לכל החלופות ולרכיבי AI
מיפוי, סיווג ועקרונות פרטיות
- למפות ולסווג את המידע שהמערכת תעבד, לרבות מידע על קטינים ומידע בעל רגישות מיוחדת, ולקבוע את הדרישות החלות בהתאם לסוג המידע, היקפו ואופן השימוש בו.
- להגדיר לכל תהליך מטרת שימוש ברורה, מינימום מידע נדרש, מורשי גישה, תקופת שמירה, מחיקה ותיעוד פעולות.
- לבחון במסגרת האפיון את חובות האיגוד לפי תיקון 13 לחוק הגנת הפרטיות ותקנות הגנת הפרטיות (אבטחת מידע), לרבות הצורך בממונה הגנת פרטיות.
ספקים, ענן והסכמים
- להגדיר בהסכם את תפקידי האיגוד והספק בעיבוד המידע, אחריות כל צד, ספקי משנה והסיוע במימוש זכויות נושאי המידע.
- להגדיר את מיקום המידע והגיבויים, תנאי העברה מחוץ לישראל, החזרת המידע ומחיקתו בסיום ההתקשרות.
- לאסור שימוש בנתוני האיגוד לאימון מודלים או לכל מטרה אחרת ללא אישור מפורש ומתועד.
בקרות אבטחה ופיתוח מאובטח
- ליישם הרשאות לפי תפקיד, עקרון הרשאה מזערית, MFA, הצפנה בתעבורה ובאחסון, הפרדת סביבות, תיעוד פעולות וניטור.
- להשתמש בסביבת הפיתוח בנתונים סינתטיים או בנתונים שעברו אנונימיזציה מתאימה; אין להזין מידע אמיתי לכלי AI ציבוריים או לא מאושרים.
- לבצע לפני העלייה לאוויר ובאופן תקופתי סריקות קוד ותלויות, בדיקות API, בדיקות חדירות ותיקון ממצאים לפי חומרה.
- להגדיר גיבוי, בדיקות שחזור, התאוששות מאסון, המשכיות תפעולית ונוהל טיפול ודיווח על אירועי אבטחה.
דרישות ייעודיות לרכיבי AI
- רכיב AI במערכת הפעילה יעבד מידע אישי רק לצורך מוגדר, במינימום הנדרש ובסביבה מאושרת, ללא שמירה או אימון מעבר למוסכם.
- לבדוק דליפת מידע, prompt injection, הרשאות יתר, שימוש לא מורשה במקורות מידע ותיעוד פעולות הרכיב.
- להגדיר בקרה אנושית, רמת דיוק נדרשת, אפשרות עצירה וחזרה לתהליך ידני בתהליכים קריטיים.
תנאי קבלה ובקרה
- לדרוש מהספק מסמכי ארכיטקטורה ואבטחה, סקרי סיכונים, דוחות בדיקה, זמני תגובה לאירועים והוכחות לעמידה בדרישות.
- להפוך סגירת ממצאי אבטחה קריטיים וגבוהים לתנאי לעלייה לאוויר ולתשלום באבן הדרך הרלוונטית.
5חמש חלופות הפתרוןממערכת קיימת ועד פיתוח ייעודי עם AI
T1השוואת מבנה הפתרון ורכיבי AIמהות, מיקום AI, נתונים ובקרה
| פרמטר | קיימת ללא AI מהותי | קיימת עם AI תפעולי מובנה | קיימת עם שכבת AI ייעודית | פיתוח ייעודי ללא AI במוצר | פיתוח ייעודי עם AI במוצר |
|---|---|---|---|---|---|
| מהות הפתרון | מוצר מדף עם הגדרות והתאמות | מוצר מדף שבו AI פועל בבק־אנד, בממשק או בשניהם | ליבה קיימת בתוספת שכבת AI לצורכי האיגוד | מערכת ייעודית עם ליבה דטרמיניסטית | מערכת ייעודית עם ליבה יציבה ושכבת AI מבוקרת |
| AI בתהליך הפיתוח [1] | אפשרי; תלוי בספק ובמשימה | אפשרי; אינו מעיד על יכולות המוצר | אפשרי בהתאמות ובפיתוח השכבה | פוטנציאל לצמצום של עד כ־35% במשימות מתאימות | פוטנציאל לצמצום של עד כ־35% במשימות מתאימות |
| מיקום AI במוצר [2] | ללא רכיבים מהותיים | בק־אנד, ממשק משתמש או שניהם | שכבה חיצונית או משולבת סביב הליבה | אין דרישה ל־AI במוצר | בק־אנד, ממשק משתמש או שניהם |
| התאמת AI לנתוני האיגוד [3] | לא נדרש | לרוב הגדרות; לעיתים כוונון מוגבל | לפי מקרי השימוש שהוגדרו | לא נדרש | לפי מקרי השימוש והנתונים |
| בקרה אנושית | בקרות מערכת רגילות | חובה בתהליכים קריטיים | חובה, כולל עצירה וחזרה לידני | כללי ליבה דטרמיניסטיים | חובה, כולל תיעוד החלטות ונתיב חלופי |
[1] כלי AI בפיתוח אינם מעידים על יכולות AI במוצר; עלות הכלים והקומפיוט בתקופת ההקמה תפורט בהצעת הספק.
[2] AI במוצר כולל שימוש ישיר וגם פעילות אוטומטית בבק־אנד.
[3] האיסור על נתונים אמיתיים בכלי AI ציבוריים או לא מאושרים חל בשלב הפיתוח והבדיקות. בהפעלה ניתן לעבד מידע רק למטרה מוגדרת, בסביבה מאושרת ובהסכם מתאים.
T2השוואת בעלות, תלות וגמישותקוד, ספק, התאמה ותחזוקה
| פרמטר | קיימת ללא AI מהותי | קיימת עם AI תפעולי | קיימת + שכבת AI | פיתוח ייעודי ללא AI | פיתוח ייעודי עם AI |
|---|---|---|---|---|---|
| בעלות על הקוד [1] | ללא בעלות מלאה; תלות ברישיון | ללא בעלות מלאה; תלות בספק ובמודלים | בעלות חוזית על השכבה, לא על הליבה | בעלות על הקוד הייעודי לפי המכרז | בעלות על הקוד הייעודי; מודלים חיצוניים מוחרגים |
| תלות בספק | גבוהה | גבוהה עד גבוהה מאוד | גבוהה בליבה ובינונית בשכבה | בינונית, בכפוף לתיעוד והעברת ידע | בינונית עד גבוהה בשל מודלים ושירותי AI |
| רמת התאמה | בינונית | בינונית עד גבוהה | גבוהה | גבוהה | גבוהה מאוד |
| גמישות עתידית | לפי מפת הדרכים של הספק | לפי הספק ומגבלות רכיבי AI | גבוהה בשכבה, מוגבלת בליבה | גבוהה | גבוהה אך מורכבת יותר לתחזוקה |
[1] הבעלות תחול על קוד ותוצרים ייעודיים שהוגדרו בחוזה. מוצר מדף, קוד קודם, קוד פתוח, מודלים ושירותי צד שלישי כפופים לרישיונותיהם. יש לדרוש קוד מקור, תיעוד וזכות להעביר תחזוקה.
T3השוואת לוחות זמניםעד השלמת העלייה לאוויר
| פרמטר | קיימת ללא AI | קיימת עם AI תפעולי | קיימת + שכבת AI | פיתוח ייעודי ללא AI | פיתוח ייעודי עם AI |
|---|---|---|---|---|---|
| הליך מקדים עד חתימה [1] | 3–6 חודשים | 3–6 חודשים | 3–6 חודשים | 3–6 חודשים | 3–6 חודשים |
| מחתימת ההסכם עד השלמת העלייה [2] | 12–18 חודשים | 12–21 חודשים | 16–24 חודשים | 20–28 חודשים | 22–30 חודשים |
| מתחילת ההליך עד השלמת העלייה [2] | 15–24 חודשים | 15–27 חודשים | 19–30 חודשים | 23–34 חודשים | 25–36 חודשים [3] |
| אפיון ותכנון | 3–4 | 3–5 | 4–6 | 4–6 | 5–7 |
| סביבות, הרשאות ואבטחה | 1–2 | 1–2 | 2–3 | 2–3 | 2–3 |
| פיתוח והתאמות | 4–7 | 4–8 | 7–11 | 12–18 | 14–20 |
| נתונים וממשקים | 3–6 | 4–7 | 5–8 | 5–9 | 6–10 |
| בדיקות AI | לא נדרש | 2–4 | 3–5 | לא נדרש | 4–6 |
| בדיקות מערכת ופיילוט | 3–5 | 4–6 | 5–7 | 5–7 | 6–9 |
| הדרכה, הטמעה וייצוב | 3–5 | 3–5 | 3–5 | 4–6 | 4–7 |
[1] יעד תכנון; מכרז, שאלות ספקים, משא ומתן או אישורים עלולים להאריך אותו.
[2] משך קלנדרי משוער. שלבים מתקיימים בחלקם במקביל, ולכן אין לחבר את כל השורות.
[3] מניח תכולה מוגדרת, עבודה מקבילה והטמעה מדורגת.
T4השוואת עלויות, סיכונים והתאמהמעטפת תכנון ראשונית בלבד
| פרמטר | קיימת ללא AI | קיימת עם AI תפעולי | קיימת + שכבת AI | פיתוח ייעודי ללא AI | פיתוח ייעודי עם AI |
|---|---|---|---|---|---|
| עלות הקמה והטמעה [1] | 3–6 מיליון ₪ | 4–8 מיליון ₪ | 6–12 מיליון ₪ | 7–14 מיליון ₪ | 12–25 מיליון ₪ |
| תפעול שנתי בסיסי [1] | 0.8–1.5 מיליון ₪ | 1.2–2.5 מיליון ₪ | 1.5–3 מיליון ₪ | 1.2–2.5 מיליון ₪ | 2–4 מיליון ₪ |
| תלות ברישוי ובצריכת AI [2] | גבוהה ברישוי | גבוהה ברישוי ובצריכת AI | גבוהה בליבה ובצריכת AI | נמוכה עד בינונית | בינונית; תלויה במודלים ובשימוש |
| ודאות העלות | בינונית עד גבוהה | בינונית | בינונית עד נמוכה | נמוכה עד בינונית | נמוכה |
| רמת סיכון | נמוכה עד בינונית | בינונית | בינונית עד גבוהה | גבוהה | גבוהה עד גבוהה מאוד |
| רזרבה תקציבית | 10%–15% | 15%–20% | 20%–30% | 20%–35% | 25%–40% |
| מתאים כאשר | המוצר נותן מענה לרוב הדרישות | המוצר מתאים ורכיבי AI בשלים | הליבה מתאימה ונדרש AI ייחודי | אין פתרון קיים מספק | אין פתרון מתאים ויש הצדקה ל־AI |
[1] הסכומים לפני מע״מ ואינם אומדן מחייב. עלויות ענן בפועל אינן כלולות.
[2] בחלופות AI יש לתמחר בנפרד שימוש בפיתוח ושימוש שוטף במוצר, לרבות טוקנים, API ו־GPU.
T5כלכלת טוקנים וקומפיוטעלויות משתנות שאינן כלולות בטווחים
| פרמטר | קיימת ללא AI | קיימת עם AI תפעולי | קיימת + שכבת AI | פיתוח ייעודי ללא AI | פיתוח ייעודי עם AI |
|---|---|---|---|---|---|
| מרכיבי החיוב [1] | רישוי וענן: CPU, אחסון, בסיסי נתונים ותעבורה | רישוי + טוקנים, API או סוכנים | רישוי ליבה + טוקנים, API, GPU, מאגר וקטורי ותעבורה | CPU, אחסון, בסיסי נתונים, ניטור ותעבורה | טוקנים, API, GPU, מאגר וקטורי, אימון, ניטור ותעבורה |
| עלות קומפיוט נוספת [1] | נמוכה עד בינונית; לפי היקף השימוש | בינונית ומשתנה; לא בהכרח כלולה ברישיון | בינונית עד גבוהה; לפי תדירות, מודל והקשר | בינונית; לפי הארכיטקטורה והיקף השימוש | עשויה להיות גבוהה ותנודתית |
| הכללה בטווחי העלות [2] | לא נכלל; נדרש מחירון ענן | לא נכלל; נדרש מחירון ענן ו־AI | לא נכלל; נדרש מחירון ענן ו־AI | לא נכלל; נדרש מחירון ענן | לא נכלל; נדרשים תרחישי שימוש ומחירון |
| מדדי בקרה ותקציב | CPU, זיכרון, אחסון, תעבורה ועלות למשתמש | טוקנים, קריאות, עלות למקרה ומכסה חודשית | מדדי AI + שעות GPU, אחסון וקטורי ותעבורה | CPU, זיכרון, אחסון, תעבורה ועלות למודול | טוקנים, GPU, אימון, אחסון וקטורי ועלות למקרה |
[1] קומפיוט כולל שימוש ב־AI בפיתוח ובבדיקות וכן הפעלת AI במוצר למשתמשים או בבק־אנד; כל סוג יתומחר בנפרד.
[2] יידרשו מחירון, תרחישי שימוש, תחזית גידול ותקרות חיוב.
ד׳פיתוח, התאמות ובדיקותהשלב המקצועי המלא
- לפתח ולהתאים את המערכת לפי האפיון המאושר ולהציג גרסאות מוקדמות למשתמשים.
- לבדוק תהליכים, הרשאות, נתונים, דוחות ועבודה במחשב ובטלפון.
- לבדוק בנפרד את ליבת המערכת ואת רכיבי ה־AI, כדי שתקלה ב־AI לא תשבית תהליך ליבה.
- ברכיבי AI להגדיר דיוק נדרש, תיעוד, בקרה אנושית, עצירה וחזרה לתהליך ידני.
- לבדוק תרחישים חריגים ותקלות, להפעיל פיילוט, לקבל משוב ולתקן לפני הרחבה.
AIדרישות לשימוש ב־AIבפיתוח ובמוצר
- החיסכון האפשרי במאמץ אינו קבוע ואינו הבטחה לחיסכון בתקציב או בזמן הכולל.
- קוד שנכתב בעזרת AI דורש ארכיטקטורה, סקירות קוד ובקרת איכות.
- בפיתוח לא מזינים לכלים ציבוריים או לא מאושרים נתונים אמיתיים, במיוחד של קטינים.
- בהפעלה, רכיב AI יעבד מידע רק לצורך מוגדר, במינימום הנדרש ובסביבה מאושרת.
- יש לדרוש מספקים פירוט תוצרים, שעות, אבני דרך ואחריות.
חוזהדרישות למכרז ולהסכםקוד, אבטחה, פרטיות ועלויות
- להגדיר בעלות האיגוד על הקוד והשכבה הייעודיים, כולל מקור, תיעוד, סכמות ופריסה.
- להחריג ולפרט מוצר מדף, קוד קודם, קוד פתוח, מודלים ושירותי צד שלישי.
- תיעוד מלא ובדיקות אוטומטיות כתנאי לתשלום בכל אבן דרך.
- בדיקות אבטחה: קוד ותלויות, API, חדירות ורכיבי AI, לרבות דליפת מידע, prompt injection והרשאות יתר.
- להסדיר תפקידי האיגוד והספק, ספקי משנה, זכויות נושאי מידע, שמירה, מחיקה ודיווח.
- לאסור שימוש בנתוני האיגוד לאימון מודלים ללא אישור מפורש.
- להבטיח מסירה מסודרת של הקוד והידע כך שספק אחר יוכל להמשיך בתחזוקה.
- לפרט עלויות ענן, טוקנים, API, GPU, אימון, אחסון וקטורי וניטור ולהגדיר תקרות והתראות.
KPIמדדי הצלחה וקבלהערך בסיס ויעד ייקבעו לאחר האפיון ובפיילוט
אימוץ והדרכהמשתמשים שהוכשרו, משתמשים פעילים והשלמת תהליכים.
יעילות ואיכותזמני טיפול, עבודה ידנית, טעויות, כפילויות ודיוק ההעברה.
שירות ויציבותזמינות, תקלות קריטיות, תגובה, פתרון ושביעות רצון.
רכיבי AIדיוק, שיעור תיקונים, התערבות אנושית ועלות למקרה שימוש.
✓המלצותסדר הבחינה המומלץ
- לבחון את כלל החלופות באופן מקצועי לפי התאמה לצורכי הארגון, סיכונים, תקציב ותלות בספק.
- במסגרת הבחינה, לתת משקל לחלופה של מערכת קיימת ויציבה עם התאמות ושכבת AI ייעודית.
- להעדיף ליבה יציבה עם AI שאפשר לבקר, לעצור ולהרחיב בהדרגה.
- לבחון פיתוח מחדש רק אם אין מערכת קיימת שנותנת מענה מספק.
- להפריד במכרז בין רישוי, התאמות, הטמעה ותחזוקה ולהגדיר אבני דרך ובקרה.
- לאשר שימוש ב־AI רק בכלים שעומדים בדרישות פרטיות ואבטחת מידע.
- לשמור על בקרה אנושית ברישום, שיבוצים, זכאות ותשלומים.