מחקר של MIT (פרויקט NANDA, 2025), שבדק מאות הטמעות GenAI בארגונים, מצא נתון שאמור לשנות את סדר היום של כל ועדת השקעות: מערכות AI שנבנו עם גורם חיצוני הגיעו להטמעה מוצלחת בשיעור כפול לעומת מערכות שפותחו בתוך הארגון.
פי שניים. לא בגלל שהמפתחים בחוץ חכמים יותר. בגלל משהו שכל מנכ"ל מכיר מצוין: תמריצים.
למה פיתוח פנימי נתקע
ניהלתי ארגונים 25 שנה, וישבתי בעשרות ישיבות שבהן מנהל מערכות מידע הציג "מערכת שנפתח בפנים". אני מכיר את התסריט בעל פה, והוא כמעט תמיד נגמר אותו דבר. הסיבות מבניות, לא אישיות:
- לצוות הפנימי אין דדליין אמיתי. הפרויקט מתחרה על זמן מול תקלות פרודקשן, דרישות רגולציה ומשימות שוטפות - והוא תמיד מפסיד. "עוד רבעון" הופך לעוד שנה.
- זה לא המקצוע שלהם. צוות IT ארגוני מצוין בתחזוקת מערכות ליבה. עולם ה-AI מתחלף כל חצי שנה - מודלים, כלים, שיטות עבודה. מי שלא חי את זה יומיום בונה על סמך מה שהיה נכון לפני שנה.
- אין מי שיגיד "זה מספיק טוב, משיקים". בפיתוח פנימי אין רגע של אמת מול ספק שצריך לעמוד בחוזה. יש שיפורים אינסופיים, ואין תאריך שבו מישהו משלם מחיר על אי-עמידה.
- הפרויקט הוא יתום פוליטי. הוא לא של אף אחד בהנהלה, ולכן כשצריך להכריע בין תכונות, אף אחד לא מכריע.
התוצאה מוכרת מדוח מבקר המדינה מיוני 2026: 68% מפרויקטי ה-AI בישראל תקועים בפיילוט. חלק גדול מהם - פיתוחים פנימיים שאף אחד לא העז להרוג ואף אחד לא הצליח לסיים.
למה גורם חיצוני מגיע לקו הסיום
הצד השני של אותו מטבע:
- מיקוד. גורם חיצוני נשכר לדבר אחד. הוא לא נשאב לתקלות של מערכת הליבה.
- חוזה עם מספר. כשמדד ההצלחה חתום מראש - בייסליין, יעד, תאריך - יש למישהו סיבה כלכלית לסיים.
- ניסיון מצטבר. מי שבנה מערכות דומות בחמישה ארגונים כבר שילם את שכר הלימוד על הטעויות. אתם לא צריכים לשלם אותו שוב.
- מהירות. לאורך הקריירה ראיתי ארגונים מחכים שנתיים למערכת מסיסטם-אינטגרטור. היום אני בונה בעצמי מערכות מקצה לקצה - פלטפורמת גיוס ארצית עם מנוע התאמה חכם, מערכת בדיקת תאימות רגולטורית, בוט קולי שמנהל שיחות אמיתיות - בסדרי גודל של שבועות, לא שנים. זה לא כישרון מיוחד; זו שיטת עבודה שמנצלת את מה ש-AI באמת יודע לעשות היום, בידיים של מי שעושה רק את זה.
ויש גם חשבון פשוט של עלות. בבנצ'מרקים בענף, המעבר מפיילוט לפרודקשן עולה פי 2.5 עד 4 מהפיילוט עצמו - וזה כשהוא מצליח. פיתוח פנימי שנמרח שנה וחצי עולה לכם משכורות של צוות שלם, פלוס עלות ההזדמנות של כל מה שהצוות הזה לא עשה בינתיים, פלוס הסיכון שבסוף לא יהיה מוצר בכלל. ההשוואה הנכונה היא אף פעם לא "עלות ספק מול עלות שעות פנימיות" - אלא "עלות תוצאה מול עלות ניסיון".
מתי בכל זאת לבנות בפנים
הכלל של "פי שניים" הוא סטטיסטיקה, לא חוק טבע. יש שלושה מצבים שבהם דווקא נכון לבנות בפנים:
- כשהתהליך הוא הליבה התחרותית שלכם. אם האלגוריתם הוא המוצר - היכולת חייבת לשבת בבית, כי מי שמחזיק אותה מחזיק את העסק.
- כשיש לכם כבר צוות מוצר שמשחרר. לא צוות IT - צוות שמוציא גרסאות למשתמשים אמיתיים כל שבוע. ארגון כזה יכול לספוג עוד יכולת. רוב הארגונים בישראל הם לא זה.
- כשהנתונים באמת לא יכולים לצאת. וגם כאן דיוק חשוב: הפתרון הנכון הוא לרוב בנייה חיצונית על התשתית שלכם, לא פיתוח פנימי. אני, למשל, מריץ תמלול שיחות לקוחות על מכונה מקומית בדיוק מהסיבה הזאת - המידע לא עוזב את הארגון, אבל מי שבנה את זה הוא גורם חיצוני ממוקד.
המודל שעובד: בונים בחוץ, מחזיקים בפנים
הדילמה "לבנות או לקנות" היא מלכודת, כי היא מציגה שתי אפשרויות גרועות: פיתוח פנימי איטי או תלות נצחית בספק. יש דרך שלישית, והיא זו שאני ממליץ עליה להנהלות:
גורם חיצוני בונה את המערכת הראשונה - מהר, עם מדד חתום, בפרודקשן. ובמקביל הוא מכשיר צוות פנימי קטן שמקבל את הבעלות: להפעיל, לתחזק, להרחיב. אחרי שהמערכת הראשונה עובדת ומחזירה כסף, לארגון יש גם תוצאה וגם יכולת. ככה נשארים עם הידע בבית, בלי לשלם את מחיר הלמידה על הפרויקט הקריטי הראשון.
ושלוש שאלות שכדאי לשאול כל גורם חיצוני לפני שחותמים: מה המערכת האחרונה שבנית שרצה היום בפרודקשן, ואצל מי; על איזה מדד אתה מוכן לחתום מראש; ומה קורה ביום שאני רוצה את המפתחות אצלי בפנים. מי שמגמגם באחת מהשלוש - חסך לכם עכשיו הרבה כסף.
זה בדיוק מה שהייתי דורש כמנכ"ל, וזה בדיוק מה שאני מציע היום כמומחה שבונה בעצמו.
רוצים לראות איך זה נראה אצלכם? שלחו לי תהליך אחד כואב, ואני אחזור אליכם עם דמו.
