משוואת Build vs. Buy השתנתה: למה חברות יבנו יותר תוכנה בעצמן

ב-15 השנים האחרונות הייתה עצה אחת שכמעט תמיד הייתה נכונה:

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

צריך CRM? תקנו.

מערכת לניהול פרויקטים? תקנו.

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

כנראה כבר קיים SaaS שעושה את זה.

ובצדק.

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

אבל AI מתחיל לשנות את הכלכלה שמאחורי ההחלטה הזאת.

לא כי SaaS עומד להיעלם.

הוא לא.

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

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

זה משנה את הדרך שבה תוכנה בתוך ארגון יכולה להיראות.

ראינו את זה קורה אצל אחד הלקוחות שלנו

הרעיון הזה לא התחיל כתיאוריה.

הוא הגיע מתוך משהו שראינו אצל אחד הלקוחות שלנו.

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

אלה לא היו מוצרים של סטארטאפ.

לא הייתה שום כוונה למכור אותם.

אלה היו פשוט כלים שהחברה הייתה צריכה.

Workflow אחד כאן.

ממשק פנימי שם.

דרך לארגן מידע.

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

לפני כמה שנים, רוב הרעיונות האלה בכלל לא היו נבנים.

ההצדקה העסקית לא הייתה מסתדרת.

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

ולבעיה פנימית קטנה, התשובה הייתה בדרך כלל:

"תעשו את זה באקסל."

או:

"בטח יש SaaS שעושה בדיוק את זה."

עכשיו החישוב הזה משתנה.

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

מודל התוכנה הישן אילץ ארגונים להתאים את עצמם לכלי

רוב מוצרי ה-SaaS נבנו סביב הנחה הגיונית:

אלפי חברות סובלות פחות או יותר מאותה בעיה.

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

המודל הזה יצר כמה מחברות התוכנה המצליחות בעולם.

אבל כל מי שהטמיע תוכנה בארגון יודע מה קורה אחר כך.

התהליך שלכם לא בדיוק מתאים ל-CRM.

תהליך האישור דורש עוד שלושה שלבים.

הצוות מחזיק אקסל נוסף כי ה-ERP לא כולל את השדה שחסר לכם.

מישהו מעתיק מידע ידנית ממערכת למערכת.

מנהל רוצה דוח, אבל כדי להפיק אותו צריך לייצא שלושה קבצי CSV.

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

ובסוף מתקבל משהו כמו:

SaaS + אקסלים + וואטסאפ + מיילים + עבודה ידנית + ידע שיושב בראש של אנשים.

המערכת עובדת.

אבל הארגון התאים את עצמו למערכת.

AI משנה את הכלכלה של תוכנה מותאמת אישית

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

השינוי הוא שהמאמץ שנדרש כדי להפוך צורך עסקי למערכת שעובדת הולך ויורד משמעותית.

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

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

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

זה כמובן לא אומר שתוכנה פשוט "בונה את עצמה".

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

אבל הרף השתנה.

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

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

השאלה כבר לא תהיה "האם אנחנו יכולים לבנות את זה?"

יותר ויותר, התשובה תהיה כן.

השאלות הקשות יותר הופכות להיות:

מה בכלל כדאי לבנות?

מה נכון לאוטומט?

מה עדיף לקנות?

איפה באמת כדאי להשתמש ב-AI?

אילו תהליכים צריכים להישאר אנושיים?

איך כל הדברים האלה מתחברים למערכות שכבר קיימות בארגון?

וזה החלק במהפכת ה-AI שלדעתנו עדיין לא מקבל מספיק תשומת לב.

ככל שהבנייה נעשית קלה יותר, הפיתוח עצמו הופך לפחות ופחות לצוואר הבקבוק.

צוואר הבקבוק עובר להבנת הארגון.

מישהו עדיין צריך להבין איך העסק באמת עובד.

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

מישהו צריך להבין למה ה-CRM הקיים לא מייצג חלק קריטי בתהליך המכירה.

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

ומישהו צריך להחליט אם הפתרון הנכון הוא:

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

האפשרויות הטכנולוגיות מתרחבות.

האתגר האמיתי הוא לבחור נכון.

לכל חברה תהיה שכבת תוכנה משלה

כאן זה מתחיל להיות מעניין.

דמיינו חברה של 50 עובדים בעוד כמה שנים.

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

אחד מטפל ב-onboarding.

אחד מכין מידע לפני פגישות עם לקוחות.

אחד בודק מסמכים לפני שליחה.

אחד עושה התאמות חשבונאיות.

אחד מפיק דוחות הנהלה.

אחד מנטר רווחיות של פרויקטים.

אחד מכיר את נהלי החברה ועונה לעובדים.

אחד מתזמר תהליך שעובר דרך ארבע מערכות שונות.

כל אחד מהכלים האלה אולי קטן יחסית.

אבל יחד הם יוצרים משהו הרבה יותר גדול:

שכבת התוכנה הפרטית של החברה.

אפשר לחשוב על זה כמעט כמו App Store פנימי.

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

SaaS לא הולך להיעלם

חשוב לדייק כאן.

אנחנו לא טוענים שסוף עידן ה-SaaS הגיע.

במקרים רבים, לקנות מערכת קיימת עדיין יהיה הרבה יותר נכון.

אף חברה לא צריכה לבנות ספק מייל משל עצמה.

רוב החברות לא צריכות לבנות מערכת הנהלת חשבונות.

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

אבל החוק הישן היה:

תקנו אלא אם ממש אין ברירה וחייבים לבנות.

החוק החדש עשוי להפוך ל:

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

וזה כבר עולם תוכנה אחר לגמרי.

ההזדמנות המעניינת היא לא להחליף כל מערכת SaaS.

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

הכלים הפנימיים שפשוט לא היה משתלם לבנות

קחו לדוגמה חברת שירותים מקצועיים.

כנראה לא תקום חברת SaaS גלובלית סביב הדרישה הבאה:

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

הבעיה הזאת ספציפית מדי כדי להפוך למוצר SaaS מצליח.

אבל עבור חברה מסוימת, היא יכולה להיות שווה המון כסף.

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

AI הופך אותן לראשונה לכדאיות כלכלית.

וכמעט לכל ארגון קיים יש עשרות בעיות כאלה.

לצד ההזדמנות, מגיע גם כאוס חדש

יש גם גרסה מסוכנת של העתיד הזה.

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

כעבור חצי שנה אתם עלולים למצוא:

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

אנחנו כבר מתחילים להיכנס לעידן של AI-powered Shadow IT.

לכן העתיד לא יכול להיות פשוט:

"כולם נהיים מפתחים."

חברות יצטרכו לאפשר בנייה מהירה, בלי לתת לתשתית שלהן להפוך לכאוס.

וזה דורש:

ארכיטקטורה.

Governance.

מערכת הרשאות.

Authentication משותף.

רכיבים שחוזרים בין מערכות.

ניטור.

תיעוד.

סטנדרטים של אבטחה.

בעלות ברורה.

ומישהו שרואה את התמונה המלאה.

אנחנו חושבים שסוג חדש של שותף טכנולוגי הולך להיווצר

וזה גם משנה את הדרך שבה אנחנו חושבים על Automation Flow.

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

פיתוח AI ואוטומציות.

ללקוח יש תהליך.

אנחנו מאוטמטים אותו.

ללקוח יש צורך במערכת AI.

אנחנו בונים אותה.

זה עדיין חלק מהעבודה שלנו.

אבל אנחנו מתחילים לחשוב שההזדמנות הגדולה יותר נמצאת במקום אחר.

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

זה מתחיל בהיכרות עמוקה עם הארגון.

וממשיך כל הזמן עם השאלות:

מה נכון לקנות?

מה נכון לאוטומט?

מה נכון לבנות?

מה AI צריך לעשות?

מה בני אדם צריכים לעשות?

ואיך כל הדברים האלה עובדים יחד?

חלק מהפתרונות יכולים לקחת יומיים.

חלק שלושה חודשים.

חלק יהיו AI Agents.

חלק כמעט בכלל לא ישתמשו ב-AI.

הטכנולוגיה היא רק האמצעי.

המטרה היא להסיר חיכוך מהארגון באופן מתמשך.

היתרון התחרותי לא יהיה כתיבת קוד

יש עוד מסקנה לשינוי הזה.

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

הערך עובר שכבה אחת למעלה.

להבין עסקים.

לתכנן מערכות.

לקבל החלטות ארכיטקטורה.

לזהות הזדמנויות עם ROI גבוה.

להתחבר לתשתיות קיימות ומבולגנות.

לטפל במקרי קצה.

אבטחה.

Adoption.

לדעת מתי לא להשתמש ב-AI.

ולהצליח לקחת משפט מעורפל כמו:

"החלק הזה בעסק פשוט משגע אותנו."

ולהפוך אותו למערכת פרודקשן שהעובדים באמת משתמשים בה.

AI יכול לייצר יותר ויותר מהיישום עצמו.

אבל מישהו עדיין צריך להבין מה בכלל צריך להתקיים.

ייתכן שזאת תהפוך ליכולת החשובה ביותר.

חברות שילמדו לבנות יעבדו אחרת

יש כאן גם השפעה רחבה יותר.

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

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

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

זה יוצר סוג חדש של חברה.

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

כשנוצר חיכוך, החברה יכולה לעצב מחדש את התהליך ולבנות סביבו את התוכנה שחסרה.

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

היא הופכת ליכולת שהארגון משתמש בה באופן רציף כדי לשפר את עצמו.

אנחנו חושבים שלשם העולם הולך.

שאלות נפוצות

האם AI יחליף SaaS?

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

למה לבנות תוכנה במקום להשתמש במערכת קיימת?

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

האם עובדים לא טכנולוגיים יכולים לבנות כלים פנימיים עם AI?

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

מהי שכבת AI ותוכנה פנימית?

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

מאיפה כדאי להתחיל?

לא מלבנות עשר אפליקציות.

מתחילים ממיפוי הארגון.

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

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

מעלים פתרון אחד.

לומדים ממנו.

ואז עוברים לבא.

---

כנראה שכבר היום יש אצלכם חמש אפליקציות שמחכות להיבנות

פשוט כרגע הן עדיין לא נראות כמו רעיונות לתוכנה.

הן נשמעות יותר כמו:

"כל יום ראשון מאיה יושבת שלוש שעות ועושה את זה ידנית."

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

"רק רוני יודע איפה המידע הזה נמצא."

"ה-CRM לא באמת יודע לטפל בחלק הזה של התהליך."

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

יותר ויותר, המשפטים האלה הופכים לדרישות תוכנה.

ב-Automation Flow אנחנו עובדים עם חברות בדיוק על השאלות האלה:

מה להשאיר כמו שהוא.

מה לאוטומט.

מה לקנות.

ומה סוף סוף שווה לבנות.

כי השאלה כבר לא רק האם החברה שלכם יכולה לבנות תוכנה.

השאלה היא מה הדבר הבא שכדאי לה לבנות.