לבנות או לקנות ב-2025: המסגרת שמנהלי טכנולוגיה ישראלים באמת משתמשים בה

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

חמשת הקריטריונים שבאמת קובעים

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

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

תנו ציון 1 עד 5 לכל קריטריון. מעל 18 — נוטה לבנייה. מתחת ל-13 — נוטה לרכישה. ההחלטות המעניינות גרות בטווח 13–18, ושם רוב הצוותים טועים.

מתי בנייה היא התשובה הנכונה

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

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

מתי רכישה היא התשובה הנכונה — גם אם לא בא לכם לשמוע

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

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

אם אתם בונים ב-2025 מערכת טיקטים פנימית, מערכת דיווח שעות פנימית או שירות feature flags פנימי — עצרו. תקנו.

המסלול ההיברידי שרוב הצוותים מפספסים

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

איך לקבל את ההחלטה ב-90 דקות

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

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

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