זאת החלטה כספית, לא החלטה טכנולוגית
מאת אופק לוגסי, מייסד קבוצת הורייזן
התחושה מוכרת לכל מי שמשלם על חמישה עד שבעה מנויים חודשיים לפי משתמש: מערכת לניהול לקוחות, מערכת משימות, מערכת הזמנות, כלי דוחות ועוד אחד או שניים שנוספו בדרך. מרגישים שוכרים ולא בונים. הבעיה היא שזאת תחושה, וההחלטה שנגזרת ממנה עולה כסף אמיתי, לכאן או לכאן. לכן המאמר הזה עושה את החישוב שאף בית תוכנה לא יעשה עבורך, כי התוצאה שלו לרוב לא משרתת אותו.
שלב ראשון: כמה אתה באמת משלם היום
רוב בעלי העסקים לא יודעים לענות על זה. הם יודעים לומר "בערך 3,000 בחודש" וזה בדרך כלל רחוק מהמציאות, כי חלק מהמנויים יורדים מכרטיס אשראי פרטי, חלק נגבים שנתית וחלק נקנו על ידי מנהל שכבר לא עובד בעסק. לפני כל שיחה עם בית תוכנה, תכין דף אחד עם חמש עמודות בלבד.
- שם המערכת ומי בעסק אחראי עליה.
- מספר המשתמשים שמשלמים עליהם היום.
- המחיר למשתמש לחודש, ובאיזה מטבע.
- תאריך החידוש ואם הוא חודשי או שנתי.
- מתי המחיר עלה בפעם האחרונה ובכמה.
העמודה החמישית היא זאת שמפתיעה. כשאתה מסתכל על שנה אחת, העלאת מחיר נראית זניחה. כשאתה מסתכל על חמש שנים, היא מכפילה את הבסיס. זאת בדיוק אותה מלכודת שמתוארת במאמר על הוצאות שצומחות מהר יותר מההכנסות, רק שכאן היא לובשת מדים של טכנולוגיה ולכן אף אחד לא מעז לערער עליה.
שלושת המכפילים שהופכים מנוי קטן להוצאה גדולה
מנוי לפי משתמש הוא לא הוצאה קבועה. הוא הוצאה שצומחת לפי שלושה מכפילים שפועלים בו זמנית: מספר המשתמשים שגדל כשהעסק גדל, מדרגת החבילה שקופצת כשאתה מגיע לתקרה של אחסון או של מספר רשומות, והעלאת המחיר התקופתית של הספק. אם אתה מתמחר את זה כהוצאה קבועה בדוח שלך, יש לך בעיה לפני שדיברנו בכלל על פיתוח. שווה לקרוא את ההסבר על הפער בין עלות קבועה לעלות משתנה, כי סיווג שגוי כאן מעוות לך את הרווחיות של כל מוצר.
מכפיל רביעי, שקט יותר: חשיפה למטבע. חלק גדול מהכלים מתומחרים בדולר, ואתה משלם בשקלים לפי שער היום. זה אומר שההוצאה החודשית שלך זזה בלי שאף אחד קיבל החלטה. אם המספר גדול מספיק, זה כבר לא עניין של רכש אלא עניין של ניהול סיכונים.
שלב שני: מה באמת נכלל בעלות פיתוח
כשבעל עסק שואל כמה עולה לפתח מערכת, הוא בדרך כלל מצפה למספר אחד. בפועל יש שני מספרים נפרדים לגמרי, והבלבול ביניהם הוא מקור הכישלון הכספי של רוב הפרויקטים האלה.
המספר החד-פעמי כולל אפיון מדויק של התהליך, עיצוב חוויית משתמש, פיתוח, בדיקות, העברת הנתונים הקיימים מהמערכות הישנות, והטמעה אצל העובדים. העברת הנתונים היא הסעיף שהכי מזלזלים בו והכי מתפוצץ: המידע שלך יושב היום בשבעה מקומות בפורמטים שונים, ומישהו צריך לנקות אותו.
המספר השוטף הוא מה שכולם שוכחים. אחרי שהמערכת עלתה, יש לך תשתית ענן שמשלמים עליה כל חודש, גיבויים, אבטחת מידע ועדכוני אבטחה, תמיכה ותיקוני תקלות, ושינויים שנדרשים כשספק חיצוני מחליף ממשק או כשרגולציה משתנה. מערכת ייעודית לא מתחזקת את עצמה. מי שמוכר לך אותה כהוצאה חד-פעמית, מוכר לך חצי מהאמת.
הסעיף שלא מופיע בשום הצעת מחיר
תלות באיש אחד. אם המערכת נכתבה על ידי מפתח עצמאי אחד, ובעוד שנתיים הוא עובר לעבודה אחרת או פשוט מעלה מחיר, אין לך אלטרנטיבה. זה לא סיכון טכנולוגי, זה סיכון עסקי מובהק, והוא מתנהג בדיוק כמו תלות בספק יחיד בשרשרת אספקה. השאלות שצריך לשאול מראש הן פשוטות: למי שייך הקוד, איפה הוא מאוחסן, מי עוד מכיר אותו, ומה קורה ביום שבו הקשר איתו נגמר. אם התשובות מעורפלות, המספר בהצעה לא מעניין.
נקודת האיזון: הנוסחה עצמה
הנוסחה שאני עובד איתה היא משפט אחד: מספר השנים לכיסוי שווה לעלות הפיתוח החד-פעמית, חלקי ההפרש בין עלות המנויים השנתית לבין עלות התחזוקה השנתית של המערכת שלך.
שים לב למכנה, כי שם הכול נשבר. אם התחזוקה השנתית מתקרבת לעלות המנויים השנתית, המכנה מתכווץ לאפס והתשובה שואפת לאינסוף. במילים פשוטות: אין נקודת איזון, וכל דיון על פיתוח הוא בזבוז זמן.
לא אתן כאן מחירון, כי אין דבר כזה. במקום זה נעבוד ביחסים, כדי שתוכל להציב את המספרים שלך ואת ההצעה שקיבלת בפועל.
קח את ההוצאה השנתית שלך על כלל המנויים. נניח שההצעה לפיתוח שקיבלת גדולה ממנה פי חמישה, ושהתחזוקה השנתית של מערכת משלך תיקח כ-80% מאותה הוצאה שנתית. מה שנשאר במכנה הוא כחמישית מההוצאה השנתית, והכיסוי נמתח על עשרות שנים. זאת לא החלטה גבולית, זאת החלטה ברורה לקנות מדף.
עכשיו שלש את מספר המשתמשים. ההוצאה על המנויים משלשת את עצמה, כי היא נגזרת ממספר המשתמשים. ההצעה לפיתוח כמעט לא זזה, כי היא נגזרת מהמורכבות של התהליך ולא ממספר האנשים שיפתחו אותו כל בוקר, והתחזוקה נשארת באותו סדר גודל. המכנה קופץ פי עשרה ומעלה, והכיסוי מתקצר לשנתיים עד שלוש. אותה מערכת בדיוק, החלטה הפוכה לגמרי.
זאת כל התובנה: הפיתוח לא מתייקר לפי מספר המשתמשים, המנוי כן. לכן המשתנה שמכריע את ההחלטה הוא לא כמה מתוחכמת המערכת, אלא כמה אנשים בעסק שלך פותחים אותה כל בוקר. מי שרוצה לראות איך בונים ניתוח כזה בצורה מסודרת, אותו היגיון בדיוק עובד בבדיקת כדאיות כלכלית לפני פתיחת סניף חדש: הוצאה חד-פעמית מול חיסכון שוטף, על פני אופק זמן מוגדר.
שלושת התנאים שחייבים להתקיים יחד
נקודת איזון מספרית היא תנאי הכרחי אבל לא מספיק. ראיתי מספיק מקרים שבהם החישוב יצא יפה והפרויקט עדיין נכשל, כי אחד משלושת התנאים האלה לא התקיים.
תנאי ראשון: המשתמשים גדלים
אם מספר המשתמשים שלך קפוא, אין מנוע שיסגור את הפער. אתה מממן היום כדי לחסוך סכום שלא גדל. אם לעומת זאת אתה צופה גידול משמעותי במספר האנשים שייגעו במערכת בשלוש השנים הקרובות, כל משתמש שמתווסף משפר לך את התשואה על הפיתוח במקום להרע אותה.
תנאי שני: אופק של חמש שנים לתהליך
לא לעסק, לתהליך. השאלה היא לא אם העסק יתקיים בעוד חמש שנים, אלא אם התהליך שאתה מקבע בקוד ייראה אותו דבר. אם אתה באמצע שינוי מודל עסקי, נכנס לקו מוצר חדש או שוקל מיזוג, אתה עומד לשלם על מערכת שתתאים לעסק שכבר לא קיים.
תנאי שלישי: התהליך באמת ייחודי
זה התנאי שהכי הרבה אנשים נכשלים בו, כי כולם משוכנעים שהם עובדים אחרת. השאלה המדויקת היא אחרת: האם התהליך הזה הוא מקור היתרון התחרותי שלך, או שהוא פשוט מה שהתרגלת אליו. ההבדל מעשי לגמרי. אם מוצר מדף מכסה שמונים אחוז מהצורך והפער הוא הרגל, שנה את ההרגל. אם הפער הוא בדיוק הדבר שבגללו לקוחות בוחרים בך, שם יש הצדקה אמיתית. לפני שמחליטים, כדאי לעשות עבודת ייעול תהליכים מסודרת. ברוב המקרים מגלים שהתהליך עצמו צריך תיקון, ואז מערכת חדשה רק הייתה מקבעת את הבלגן בבטון.
מתי פיתוח ייעודי הוא טעות, וזה רוב הזמן
אני מעדיף להגיד את זה באופן ישיר, גם כשזה לא נוח: ברוב הפניות שמגיעות אלי בנושא הזה, התשובה הנכונה היא לא לפתח. הנה הסימנים שאומרים את זה מיד.
- הכאב הוא מחיר, לא יכולת. אם אתה בורח מהמנוי כי הוא יקר ולא כי הוא לא עושה את העבודה, הפתרון הוא משא ומתן מול הספק, מעבר לחבילה שנתית או סגירת רישיונות שלא בשימוש. תתחיל ממציאת דליפות הכסף שמצטברות לאורך השנה, לפני שאתה משקיע שקל בפיתוח.
- אתה רוצה מערכת אחת שתעשה הכול. זאת בקשה שנשמעת הגיונית ומייצרת את הפרויקטים היקרים והכושלים ביותר.
- עוד לא ניסית מוצר מדף ברצינות. אם יישמתם מוצר בחצי כוח ונטשתם, המערכת לא הייתה הבעיה.
- אין בעסק מישהו שיהיה אחראי על הפרויקט. פיתוח דורש איש קשר מהעסק שיחליט החלטות שבועיות. בלעדיו, בית התוכנה מחליט בשבילך והתוצאה תהיה מערכת שאף אחד לא רצה.
- התזרים לא סובל הוצאה חד-פעמית כזאת. החלטה נכונה בעיתוי שגוי היא החלטה שגויה.
אם השאלה שלך היא בעצם איזה מוצר מדף לקנות ובאיזו רמה, זה דיון אחר לגמרי ויש לו מאמר נפרד על בחירת מערכת ERP ותוכנה פיננסית לעסק. אל תערבב בין שתי ההחלטות, הן לא נפתרות באותו שולחן.
איך מממנים את זה, אם ההחלטה יצאה לפתח
פיתוח הוא הוצאה חד-פעמית גדולה מול חיסכון שמתפרס על שנים. זאת בדיוק ההגדרה של פער תזרימי, וזאת הסיבה שהרבה פרויקטים נכונים כלכלית נתקעים באמצע. שלוש נקודות מעשיות.
ראשית, תפצל את התשלום לאבני דרך שקשורות לתוצרים ולא לתאריכים. תשלום שיוצא לפי לוח זמנים קלנדרי מעביר את כל הסיכון אליך.
שנית, תחליט מראש מאיזה מקור הכסף מגיע. הוצאה כזאת לא אמורה לאכול את כרית הביטחון התזרימית שלך. אם אתה שוקל מימון חיצוני, כדאי להבין מה הבנק בודק בתהליך פתיחת קו אשראי לעסק, וכשיש הצעה על השולחן לעבור על צ׳קליסט הבדיקות לפני חתימה על הלוואה עסקית. הריבית היא חלק מעלות הפרויקט, ומי שלא מכניס אותה לחישוב נקודת האיזון מרמה את עצמו. בעסקים שבהם הבנק מסרב או מאט, יש מסלולי אשראי והנדסת מימון נוספים שצריך לבחון לפני שמוותרים על הפרויקט או לפני שמממנים אותו מהתזרים השוטף.
שלישית, תגדיר מראש איך נראית הצלחה במספרים. לא "המערכת עובדת" אלא שעות עבודה שנחסכו, ימי גבייה שהתקצרו או טעויות שנעלמו. חישוב עלות שעת עבודה אמיתית בעסק הוא מה שהופך חיסכון בזמן למספר שאפשר להכניס לטבלה. בלי זה, בעוד שנתיים לא תדע אם ההשקעה החזירה את עצמה.
מה לעשות בשבוע הקרוב
תכין את טבלת המנויים, תכפיל אותה בחמש שנים עם הנחת גידול סבירה במשתמשים, ותציב את התוצאה מול הנוסחה. אם המספר שיוצא הוא יותר מארבע שנים לכיסוי, סגרת את הנושא וחסכת לעצמך פרויקט. אם הוא פחות משלוש שנים ושלושת התנאים מתקיימים, זה הזמן לדבר על פיתוח מערכת ייעודית בהתאמה אישית עם מי שיודע לתמחר גם את התחזוקה ולא רק את הבנייה.
אם המספר נפל באמצע, בין שלוש לארבע שנים, אל תחליט לפי תחושה. זה בדיוק המקום שבו צריך החלטה מבוססת נתונים ולא אינטואיציה, ובמקרים האלה אני ממליץ לעשות את הבדיקה מול מי שמכיר את המספרים שלך לעומק. זה חלק ממה שמנהל כספים עושה בפועל בשירות ניהול כספים במיקור חוץ: להעמיד את ההוצאה הגדולה מול התזרים ומול שאר ההשקעות שמחכות בתור, ולהגיד בכנות מה נדחה. אגב, אם מה שאתה באמת מחפש זה שקיפות על המספרים ולא מערכת חדשה, לפעמים הטמעת דשבורד ניהולי מעל הכלים הקיימים פותרת את הכאב בשבריר מהעלות, ואת הרובד הזה של כלים חכמים מכסה סדרת המדריכים על AI וניהול כספים.
ההחלטה הזאת לא נמדדת בכמה מתקדמת המערכת. היא נמדדת בכמה כסף נשאר לך בסוף השנה החמישית.
שאלות נפוצות
כמה עולה לפתח מערכת לעסק בישראל?
אין מספר אחד, והמחיר נגזר ממורכבות התהליך ולא ממספר המשתמשים. מה שכן אפשר לדרוש מכל בית תוכנה הוא פירוק לשני מספרים נפרדים: העלות החד פעמית של אפיון, פיתוח, העברת נתונים והטמעה, והעלות השנתית של תשתית, אבטחה, תמיכה ושדרוגים. הצעה שמציגה מספר אחד בלבד היא הצעה חסרה.
מתי משתלם לפתח תוכנה ייעודית במקום לשלם מנוי חודשי?
כשההפרש בין עלות המנויים השנתית לעלות התחזוקה השנתית מכסה את הפיתוח תוך כשלוש שנים, וכששלושת התנאים מתקיימים יחד: משתמשים שגדלים, תהליך יציב לחמש שנים ותהליך שהוא באמת ייחודי לעסק. חסר תנאי אחד, החישוב לבדו לא מספיק.
למה התחזוקה השוטפת כל כך קריטית בחישוב?
כי היא נכנסת למכנה של הנוסחה. ככל שהתחזוקה השנתית מתקרבת לעלות המנויים השנתית, ההפרש מתכווץ ומספר השנים לכיסוי מזנק. שתי מערכות באותו מחיר בנייה יכולות להיות החלטה נכונה והחלטה אסונית, רק בגלל הפער בעלות התחזוקה שלהן.
מה קורה אם המפתח שבנה את המערכת נעלם?
זה הסיכון הגדול ביותר בפיתוח ייעודי וצריך לנטרל אותו בחוזה. תוודא שהקוד שייך לך, שהוא מאוחסן במקום שאתה שולט בו, שיש תיעוד קריא ושיותר מאדם אחד מכיר את המערכת. בלי ארבעת הסעיפים האלה, אתה קונה תלות ולא נכס.
אפשר לממן פיתוח מערכת באשראי עסקי?
כן, וזאת שאלה שצריך לשאול לפני שמתחילים ולא באמצע. הבנק בוחן הוצאה כזאת כמו כל השקעה: מה התשואה, מה לוח הזמנים ומה קורה אם הפרויקט מתעכב. חשוב לזכור שעלות המימון היא חלק מעלות הפרויקט, ולכן היא חייבת להיכנס לחישוב נקודת האיזון לפני החתימה ולא אחריה.
ההחלטה הזו כמעט תמיד מוכרעת על נייר אחד: ההצעה שקיבלת מול מה שאתה משלם היום, על פני אופק זמן שאתה מגדיר. אם אתה רוצה לעבור על החישוב הזה עם מי שמסתכל עליו מצד המספרים ולא מצד הפיתוח, אפשר לתאם פגישה ולהעמיד את ההצעה מול הנתונים שלך.
