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

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

למה תחזוקה היא שאלה של כמה, לא של אם

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

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

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

מילון קצר

• תחזוקה שוטפת (Maintenance) - כל העבודה שנדרשת כדי שהמערכת תמשיך לעבוד כמו ביום ההשקה: עדכונים, תיקונים, ניטור, תמיכה.
• ריטיינר (Retainer) - תשלום חודשי קבוע תמורת בנק שעות, או תמורת התחייבות לזמינות ולזמני תגובה.
• SLA (Service Level Agreement) - הסכם רמת שירות: מה נחשב תקלה, באיזו חומרה, תוך כמה זמן מגיבים ותוך כמה זמן מתקנים.
• תלויות (Dependencies) - ספריות קוד ושירותים חיצוניים שהמערכת משתמשת בהם ולא נכתבו במיוחד בשבילה.
• תשתית (Infrastructure) - השרתים, מסד הנתונים, האחסון והרשת שהמערכת רצה עליהם.
• חוב טכני (Technical debt) - קיצורי דרך שנעשו בקוד ומצטברים לעבודה שצריך לעשות מאוחר יותר, בדרך כלל ביוקר.

על מה משלמים בפועל: תשעה סלי עלות

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

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

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

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

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

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

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

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

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

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

כללי אצבע: כמה אחוזים מעלות הפיתוח

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

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

לכן במקום להתחיל מאחוז, עדיף להתחיל מהרשימה: לעבור על תשעת הסלים, לשים ליד כל אחד הערכה שנתית, ורק אז לבדוק אם הסכום הכולל נראה סביר ביחס לעלות הבנייה. אם הוא יוצא נמוך בהרבה מ-10%, כנראה שכחתם משהו. אם הוא יוצא גבוה בהרבה מ-20%, כדאי לשאול למה, ולרוב התשובה נמצאת בפרק על הורדת החשבון.

ריטיינר, לפי שעה או בלי הסכם בכלל

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

ריטיינר חודשי

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

תשלום לפי שעה או לפי קריאה

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

בלי הסכם בכלל

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

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

מה קורה כשאף אחד לא מתחזק

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

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

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

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

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

מה הסכם תחזוקה צריך לכלול

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

• היקף. מה נכלל בתשלום הקבוע (עדכונים, ניטור, תיקונים, תמיכה, שיפורים קטנים עד היקף מסוים) ומה מתומחר בנפרד. במיוחד: האם שיפור קטן נחשב תחזוקה או פיתוח, ומי מחליט.
• רמות חומרה וזמני תגובה (SLA). תקלה שמשביתה את כל המערכת, תקלה שפוגעת בתהליך אחד, ובקשה רגילה: לכל אחת זמן תגובה וזמן טיפול משלה, ושעות פעילות מוגדרות. "נטפל בהקדם" הוא לא זמן תגובה.
• בנק שעות וצבירה. כמה שעות בחודש, מה קורה לשעות שלא נוצלו, ומה התעריף לשעות מעבר.
• גיבויים. תדירות, מיקום נפרד מהשרת, משך שמירה, ומי מבצע בדיקת שחזור ומתי. שורה אחת בהסכם שאומרת "בדיקת שחזור רבעונית עם דיווח" שווה יותר מכל השאר.
• ניטור והתראות. מה מנוטר, למי ההתראות מגיעות, ומה קורה עם התראה בלילה או בסוף שבוע.
• עדכונים מתוכננים. באיזו תדירות מעדכנים תלויות ואבטחה, ואיך מודיעים לכם לפני שדרוג שעלול לשנות משהו.
• בעלות. הקוד שלכם. הדומיין רשום על שמכם. חשבונות הענן, מסד הנתונים, שירותי ה-SMS והמייל, כולם על חשבון משתמש שלכם, עם גישה למפתח ולא להפך. זה הסעיף שהכי הרבה עסקים מגלים מאוחר מדי שאין להם.
• תיעוד ומסירה. תיעוד עדכני של המערכת והתשתית, ומה קורה בסיום ההסכם: תוך כמה זמן מועברים הגישות והחומרים למי שיחליף, ובאיזו עלות.
• דיווח. סיכום חודשי או רבעוני קצר: מה עודכן, מה תוקן, כמה שעות נוצלו, ומה מומלץ לשנה הבאה.

דוגמה: תקציב שנתי למערכת ניהול בינונית

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

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

אותה מערכת בגרסה רזה יותר, בלי SMS, בלי צוות שטח ועם עשרה משתמשים, הייתה נוחתת קרוב לקצה התחתון של הטווח. ואותה מערכת עם חיבור למערכת ERP ארגונית, דרישות זמינות של 24/7 ומידע רפואי או פיננסי הייתה חוצה את ה-20% בקלות, בעיקר בגלל דרישות ניטור, גיבוי ואבטחה מחמירות יותר.

שאלות לשאול לפני שחותמים

לפני שחותמים על הסכם תחזוקה, ועדיף עוד לפני שחותמים על הסכם הפיתוח, שווה לקבל תשובות כתובות על השאלות הבאות:

1. מה בדיוק כלול בתשלום החודשי, ומה אני אקבל עליו חשבונית נפרדת?
2. מה זמן התגובה לתקלה משביתה, בשעות פעילות ומחוץ להן?
3. מי מטפל במערכת שלי בפועל, ומה קורה כשהוא בחופשה או עוזב?
4. על שם מי רשומים הדומיין, השרת, מסד הנתונים והחשבונות של השירותים החיצוניים?
5. מתי בוצעה בפעם האחרונה בדיקת שחזור מגיבוי, ואיך אדע שהיא בוצעה?
6. באיזו תדירות מתעדכנות התלויות, ואיך אקבל דיווח על כך?
7. מה קורה לשעות שלא נוצלו בחודש שקט?
8. אם אחליט לעבור לספק אחר, מה אקבל, תוך כמה זמן ובאיזו עלות?
9. אילו שדרוגים גדולים צפויים בשנתיים הקרובות, וכמה הם עשויים לעלות מעבר לריטיינר?

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

איך מורידים את החשבון השנתי

ההחלטות שהכי משפיעות על עלות התחזוקה נעשות בזמן הבנייה, הרבה לפני שיש מה לתחזק.

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

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

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

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

שורה תחתונה

מערכת בהתאמה אישית עולה כסף גם אחרי שהיא באוויר, בדרך כלל בין 10% ל-20% מעלות הבנייה בכל שנה, ורוב הסכום הולך לאנשים ולא לשרתים. העלות הזו קיימת בכל מקרה; השאלה היא רק אם משלמים אותה בסכומים קטנים ומתוכננים או בהשבתה גדולה ולא מתוכננת. תקצבו אותה סל אחרי סל, דרשו הסכם שעונה על השאלות למעלה, ותוודאו שהקוד, הדומיין והחשבונות רשומים על שמכם.

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