קיבלת מהעירייה את מסמכי המכרז. 60 עמודים, ובעמוד 41 סעיף שאומר שאתה אחראי על כל נזק, בלי תקרה.
יש לך מוצר שיתאים מצוין ללקוח גדול, כמו למשל גוף ציבורי דוגמת עירייה או משרד ממשלתי, או חברה ציבורית. אתה בטוח שתוכל לסגור את העסקה במחיר טוב שגם תרוויח ממנו לא רע. ובהתחשב במוניטין שלך אתה די בטוח שבסוף הלקוח יבחר בך מכל ההצעות שהוא יקבל. אז אתה שולח הצעה ללקוח, ומקבל את הסכם העסקה עם התנאים המסחריים שהלקוח רוצה. ומרוב עיזים אתה מרגיש שאתה בכפר נידח ביוון...
או יותר גרוע – פשוט חתמת על ההסכם מבלי להתעמק בו, ורק מאוחר יותר גילית שהעסקה בעצם לא רק שלא רווחית, אלא ממש מסכנת את הקיום של החברה שלך.
פתאום העסקה הזאת היא הרבה פחות מושכת עבורך, ואתה כבר לא בטוח שאתה רוצה בכלל להתקדם. אז חשוב שתבין שיש לרוב כמה דברים שחשוב לשים לב אליהם, ובהחלט לגיטימי ואף מקובל לשנות תנאים לא הגיוניים.
שים לב שבמכרז ציבורי, הרגע לשנות סעיפים הוא שלב שאלות ההבהרה, לפני הגשת ההצעה. הצעה עם הסתייגויות עלולה להיפסל. אז כדאי לעבור על הרשימה הזאת כבר כשאתה מוריד את מסמכי המכרז.
אז הנה רשימה כללית של תנאים מהותיים שחשוב שתשים אליהם לב, ואיך כדאי לך שהם יהיו בנויים. סעיפים 1, 9, 12, 13, ו-15 ממש יכולים לגמור לך את החברה.
אחריות ופיצויים
- אחריות לא מוגבלת על נזקים ללקוח – אז נכון שלגיטימי שאם גרמת ללקוח שלך נזקים תוך ביצוע השירותים, אתה צריך לפצות אותו על הנזקים האלה. אבל תמיד עד לגבול הגיוני.
כך למשל אין שום סיבה טובה שתפצה לקוח "על כל נזק שנגרם ללקוח בזמן ביצוע השירותים", כשמהמלל הזה אפשר להבין שאתה חייב לפצות על נזק שאתה בכלל לא גרמת. אתה לא אמור לפצות על נזקים שגרמו צדדים שלישיים שלא קשורים אליך, או בכלל עובדים של הלקוח. חשוב להבהיר כי יהיה פיצוי רק על נזקים שאתה או מישהו מטעמך בכלל אחראים עליהם, כאשר גוף ניטרלי מחליט שאתה אכן אחראי – למשל בורר מקצועי או ביהמ"ש.
מלבד נושא האחריות יש גם את נושא גובה הפיצוי – לפעמים כשהשירות ממש מסתבך, יש לך פוטנציאל לגרום לנזק מאוד משמעותי ללקוח. לפעמים אפילו פי כמה מהשווי של כל החברה שלך. וכמובן שאין לך באמת דרך להעריך מה הסיכוי לכזה נזק או לכמת אותו בחישובי התמורה שאתה מבקש על השירותים שלך. אז או שכל פעם תציג מחיר שלא משנה מה יקרה עדיין יהיה רווחי עבור החברה, או שתסכימו עם הלקוח מראש על רף עליון של הסכום אותו תשלם ללקוח במקרה הכי גרוע – לא כולל מקרים של פעולה מכוונת בזדון כמובן. נהוג לשים גבול פר מקרה של צורך לשלם פיצוי, וגבול נוסף של סה"כ הפיצויים שישולמו לכל המקרים במצטבר.
חברות הענק וחברות SaaS רבות בכלל מגבילות את גבול הפיצוי לתמורה שהן קיבלו בפועל מאותו לקוח ב-12 או אפילו ב-6 החודשים האחרונים, מלבד מקרים של הפרת קניין רוחני של צד שלישי.
כמובן שגם פה צריך דרך הוגנת לקבוע מה גובה הנזק שבכלל נגרם – אי אפשר להסתפק רק בטענה של הלקוח. אז נהוג להגביל לנזקים שניתן להראות לגבי למשל קבלות, וככל והלקוח נאלץ להוציא הוצאות כדי לתקן את הנזק אז רק הוצאות סבירות. וככל ויש מחלוקת – גם כאן מומלץ שההכרעה תיעשה בידי גוף ניטרלי דוגמת בורר מקצועי או ביהמ"ש.
ויש גם את נושא סוגי הנזקים עליהם הגיוני לקחת אחריות – אם שרפת ללקוח את חדר השרתים, הגיוני שתשלם על הציוד. פחות הגיוני שתשלם על טיפול פסיכולוגי לכלב של אחד העובדים שהריח מהמשרדים את העשן ולא הפסיק לנבוח שעה. כן נהוג לשלם על פגיעות בגוף או ברכוש. מאוד לא נהוג לשלם על נזקים עקיפים שאין אפשרות לכמת, כמו למשל פגיעה במוניטין של הלקוח או הפסד הזדמנויות עסקיות. אלו גם נזקים שיכולים להגיע לסכומים שיהפכו כל עסקה ללא כדאית.
- ערבות בנקאית לטובת הלקוח – חשש הגיוני של לקוחות הוא שהם קונים משהו מספק ומתכוונים להשתמש בו הרבה שנים, ואילו הספק נעלם אחרי תקופה קצרה, או נקלע לקשיים ומפסיק לספק את השירותים שהוא מכר ואין סיכוי לקבל ממנו את הפיצוי לו הוא מחויב לפי ההסכם כי לספק פשוט אין כסף לשלם.
כדי להימנע ממקרים כאלה לקוחות יכולים לבקש כחלק מתנאי מכרז שהספק יפקיד ערבות בנקאית, כך שאם הספק יהיה חייב כסף ללקוח יהיה תמיד ממה להיפרע. ערבות בנקאית יכולים לבקש גם לא כחלק ממכרז רשמי אלא בשלב לא פורמלי של הצעות מחיר, במיוחד כשמצד הלקוח יש מישהו שרגיל לתנאים של מכרזים. מבחינת הספק זה אומר שסכום מהותי הולך להיות סגור עכשיו בבנק כביטחונות, וכמובן צריך לשלם גם עמלת הקמה ועמלה שנתית שגם זה סכומים מהותיים בעסקה גדולה. מצב שבו התמורה מהלקוח הזה תיכנס בפועל לספק רק אחרי סיום תקופת ההסכם וכנראה גם אחרי תקופת האחריות שתימשך עוד כמה שנים אחרי סיום ההסכם.
כשלא מדובר במכרז זאת בקשה חריגה בדיוק בגלל הסיבה שרשמתי – כי זה פשוט לא הגיוני מבחינה כלכלית שספק יסכים לדחייה בפועל של התמורה לתקופה כל כך ארוכה. אם מדובר בסכום מהותי או אם יש ברירה אחרת, לא הייתי ממליץ לספק להסכים לתנאי שכזה.
כשכן מדובר בתנאי מכרז, כל מה שנותר לעשות זה לנהל משא ומתן על גודל הערבות, תקופתה, ותנאים למימוש.
- אחריות אישית של בעלי מניות ושל עובדים – אחת הסיבות העיקריות שאתה פועל דרך חברה זה שאם חס וחלילה יש חובות בקשר לפעילות, הם יהיו רק של החברה. אבל יש לקוחות שרוצים שאתה וכל בעלי המניות תישאו באחריות אישית כלפיהם. וגם שהעובדים שלך יישאו באחריות אישית.
זאת דרישה בהחלט לא מקובלת. ואם קיבלת השקעה אז בכלל, לא מכיר משקיע שיהיה מוכן לקחת אחריות אישית על חובות החברה בה הוא השקיע. גם קשה לי להאמין שעובדים יתלהבו במיוחד לקחת על עצמם אחריות כספית על התנהלות החברה. ההמלצה שלי שפשוט לא תסכים לתנאים כאלה. במיוחד ובמיוחד כאשר הלקוח דורש אחריות ללא הגבלה.
- התחייבות שהמוצר נקי מבאגים וטעויות – כן, יש לקוחות שדורשים שהתוכנה שלך תהיה ללא שום סוג של באג, ותישאר ככה לאורך כל תקופת ההסכם. ועם Uptime של 100%. יש אפילו מכרזים ממשלתיים שכוללים את התנאים המאוד חריגים האלה.
אז או שהצוות שלך אלו המתכנתים הכי טובים בעולם ובכלל בהיסטוריה של תכנות מחשבים, או שאתה מראש מסכים להיות בהפרה של ההסכם.
- דרישות לביטוח בסכומים מוגזמים עם פרמיה מאוד גבוהה – בדומה למקרה של ערבות בנקאית, גם פה לקוח רוצה לוודא שיהיה לו איך להיפרע ממך ככל ותצטרך לשלם לו פיצויים גבוהים, ולכן מתעקש שתיקח ביטוח על סכום מאוד גבוה – כמעט בוודאות הרבה יותר גבוה מהביטוח שכבר יש לך – שיעלה לך בתשלומי פרמיה מאוד גבוהים ויהפכו את העסקה להרבה פחות כדאית עבורך.
גם במקרה זה שים לב לא להסכים לתנאים בהם אתה לא מרוויח כמעט כלום מלבד סיכונים אפשריים כלפי הלקוח הזה.
רגולציה
- תשלום על עיצומים שהרשות להגנת הפרטיות מטילה בכלל על הלקוח – אם אתה מעבד מידע אישי עבור לקוח, יש כמובן חוקים ותקנות שחלים עליך כמחזיק מאגר מידע. בדיוק כמו שיש חוקים ותקנות שחלים על הלקוח בתור בעלי מאגר מידע.
הבעיה נוצרת כאשר לקוח רוצה שתפצה אותו על עיצומים שיוטלו עליו בידי הרשות להגנת הפרטיות בקשר לשירותים, מבלי להגביל את זה רק למקרים בהם נעשתה הפרה של החוק באשמתך.
הרי אין לך כמעט אף פעם שליטה לגבי סוג וכמות המידע שהלקוח מכניס למאגר המידע בו אתה מחזיק, ולרוב גם לגבי כמות ההרשאות ולזהות מקבלי ההרשאות בצד של הלקוח.
אז אם פשלה נגרמה בגלל הלקוח או מישהו מטעמו, לא הגיוני שאתה תישא באחריות על העיצומים שיוטלו על הלקוח.
פה גם נכנסות לתמונה ההגבלות עליהן כתבתי בס' 1 לגבי גובה הפיצוי וסוג הנזקים.
- עמידה בדרישות רגולציה החלות על הלקוח – הלקוחות שלך נדרשים לעמוד בסוגים שונים של רגולציה בגלל שהם סוג מסוים של גוף בסוג מסוים של פעילות. אותה רגולציה כמעט אף פעם לא חלה עליך כספק, וכמובן שאין לך מושג מה נדרש כדי לעמוד בה – גם ככה יש לך מספיק התחייבויות חוקיות משלך שאתה חייב לעמוד בהן. וכשאתה מתמחר את המוצר שלך, כמובן שאתה לוקח בחשבון רק את ההתחייבויות שחלות עליך באותו מועד.
אבל יש לקוחות שפשוט דורשים שתנקוט בכל הצעדים שיידרשו בעתיד כדי לעמוד בדרישות הרגולציה שחלות על הלקוח. על חשבונך כמובן. גם אם הרגולציה לא חלה עליך ישירות.
אז עכשיו מצפים ממך להיות מודע לרגולציה שחלה על הלקוח בכלל, להישאר מעודכן, להחליט אילו צעדים אתה נדרש לנקוט כדי שלדעת הלקוח תעמוד בדרישות הללו, ואז ליישם את אותם הצעדים. כמובן שיש לזה חתיכת עלות כספית, שכמעט בוודאות לא לקחת בחשבון כשהגשת את הצעת המחיר שלך.
אתה בהחלט רשאי לסרב לזה. ואם כבר, ככל והרגולציה החלה עליך משתנה ואתה נדרש להוצאות משמעותיות כדי לעמוד בה ולהמשיך להעניק שירותים ללקוח, כדאי מאוד שתהיה לך דרך לבזר את העלויות הללו בין הלקוחות – כי גם זה משהו שלא לקחת בחשבון כשתמחרת את השירותים שלך.
- "החברה עומדת בכל דרישות החוק" – המשפט הזה נראה מאוד סביר והגיוני, עד שמתחילים לחשוב מה הוא באמת אומר. בדרישות של איזה חוק בדיוק החברה אמורה לעמוד? של איזו מדינה?
כפי שכבר ציינתי, יש לקוחות שאמורים לעמוד בנטל רגולטורי מסוים, ומנסים להעביר את הנטל הזה לספקים שלהם. עם כל האחריות והעלויות הכרוכים בדבר.
שים לב שהלקוח לא יעמיס עליך את ההתחייבויות שלו. תסכים להתחייב שאתה עומד בחוקי מדינת ישראל החלים עליך ישירות, אבל מעבר לזה תיזהר לא להתחייב לדברים שאתה לא אמור להתחייב להם.
תמורה
- עיקוב וקיזוז תשלומים לפי שיקול דעתו הבלעדי של הלקוח – יש היגיון ברצונו של הלקוח לא לשלם את מלוא התמורה כאשר לדעתו הוא לא קיבל את מה שהזמין, או שלדעתו גרמת לו נזקים שאתה צריך לשלם עליהם פיצוי.
אבל זה עניין של איך יותר מעניין של מה. אם הלקוח מבקש לעקב תשלומים לפי שיקול דעתו הבלעדי, או לקזז כשלדעתו הבלעדית התקיים מקרה אשר דורש שיפוי, ואילו אתה מחויב להמשיך לעבוד בזמן שהלקוח מחליט האם לשלם לך את התמורה עליה סיכמתם – אתה בבעיה.
לגבי ביצוע השירות – אם מדובר במשהו שאו שהוא בוצע או שלא, כמו למשל הוסטינג של אתר או תפעול שרת, אין ממש מקום להתווכח האם השירות בוצע. או שהשרת עבד, או שלא. ואין סיבה לגיטימית לעקב תשלום על שירות שבוצע.
אם לעומת זאת מדובר בשירות שייתכן דיון לגבי איכות התוצר שלו, כמו למשל בניית תוכנה שהמפרט שלה לא היה מספיק מפורט ומשאיר מקום להרבה שיקול דעת לגבי אופן הביצוע, עדיף לך לחלק את זה לשלבי ביצוע כאשר הלקוח צריך לאשר כל שלב בנפרד לפני שמתקדמים לשלב הבא. ככה הלקוח יתקשה ברצינות לטעון בסוף שהמוצר זה לא מה שרצה, וגם כאן לא תהיה סיבה לגיטימית לעיקוב תשלומים.
בכל מקרה מומלץ לקבוע כי איחור לא מוצדק בתשלומים שווה לעצירת העבודה, וביטול ההסכם אם התשלומים לא מתחדשים תוך זמן קצר.
לגבי נושא הקיזוז – מותר לך פשוט לא להסכים לזה. או להסכים רק לקיזוז של סכומים של פיצוי שיש לשלמו לפי פסק-דין חלוט (שלא ניתן לערער עליו). הרבה ספקים מעדיפים את הגישה הזאת, והלקוחות בסופו של דבר מקבלים את העמדה הזאת.
- גידול בהיקף השירותים ללא הגדלת התמורה – בשילוב של מחיר קבוע והתחייבות כללית לספק שירותים ללקוח, יוצא שאם פעילות הלקוח גדלה משמעותית הספק בעצם מממן חלק מעלות הגידול הזה כי הוא ממשיך לתת שירותים לחברה עם יותר פעילות/יותר עובדים באותו מחיר ישן.
תדאג תמיד שהתמחור שלך יהיה מותנה במדדים הגיוניים כלשהם – תשלום פר משתמש, פר מחשב, פר כמות פעולות בחודש, פר שטח אחסון, וכו'.
- תמיד המחיר הכי טוב, כולל החזר רטרואקטיבי – לקוחות מסוימים מרגישים שהם עושים לך טובה ענקית בזה שהם מאפשרים לך בכלל לתת להם שירות, ולכן דורשים שלא רק שתיתן להם את המחיר הכי טוב שיש, אלא שגם תחזיר להם את ההפרש אם בעתיד תיתן למישהו אחר מחיר טוב יותר.
ההמלצה שלי היא פשוט לא להסכים לכזה תנאי חריג.
- הלקוח משלם רק אחרי שהוא מקבל כסף – זה נדרש לרוב כשאתה בעצמך ספק משנה לאינטגרטור גדול. בגדול זה אומר שאם הלקוח העיקרי לא משלם, הספק הראשי לא משלם לך. ואתה אפילו לא יודע על אילו תנאי תשלום הספק הראשי סגר עם הלקוח – האם זה למשל שוטף פלוס 120?
תבין מה המשמעות של זה עבורך, ואיך זה משפיע על תזרים המזומנים שלך, לפני שתסכים לתנאי שכזה. אם תסכים, הייתי ממליץ לפחות לוודא קודם מהם תנאי התשלום של הלקוח לספק הראשי, שאם האיחור בתשלום לא קשור לחלק שלך בפרויקט אז שהתשלום שלך לא יתעכב בכל מקרה, והייתי מבקש התחייבות של הספק הראשי שיפעל נגד הלקוח ככל וזה לא משלם מסיבה בלתי מוצדקת ובניגוד להתחייבות בהסכם.
קניין רוחני ובעלות
- בעלות הלקוח בכל הקוד ובמידע – לקוחות באופן מובן רוצים בעלות מלאה במוצר שנבנה במיוחד עבורם, ובמידע שנאסף מהשימוש שלהם במוצר (שזה בעצם מידע שהם מייצרים). עמדה כזאת לא מתחשבת במציאות של בית תוכנה בימינו – מחזור קוד.
לגבי זכויות בקוד - אין כמעט ספקים שבונים תוכנה בהזמנה מאפס, מבלי להשתמש בשום חלק של שום קוד מפרויקטים קודמים או אפילו בספריות קיימות של קוד פתוח. המחזור הזה הרי בעצם מאפשר לספקים להיות יותר יעילים ולספק את המוצר תוך זמן קצר יותר ובמחיר נמוך יותר.
ספק שמעניק ללקוח את כל הזכויות בכל הקוד של המוצר, לא רק שמוותר על האפשרות למחזר כל חלק מהקוד הזה בפרויקטים אחרים, אבל גם מעניק ללקוח זכויות בקוד שנמצא במוצרים של לקוחות אחרים, על כל הסיבוכים שבדבר. הרבה יותר הגיוני, גם אם זה לא מיטבי לספק, לתת ללקוח בעלות בקוד שנבנה במיוחד עבורו, כי שם לרוב נמצאת כל שכבת הקסטומטיזציה שהלקוח באמת צריך. כך הספק יוכל להמשיך ולמחזר חלקי קוד בפרויקטים אחרים, מבלי להעתיקם או להעניק למתחרים את החלק הספציפי בקוד שמיועד למערכות המסוימות של הלקוח.
לגבי בעלות במידע שהמוצר מייצר, צריך להבדיל בין מידע שנועד לתמיכה ושיפור של המוצר, לבין מידע שהמוצר נבנה לייצר עבור הלקוח – תוצר העבודה של המוצר. אין ספק שתוצר העבודה אמור להיות שייך בלעדית ללקוח. אבל ברור גם שמידע טכני על תפעול המוצר זה משהו שהספק חייב כדי להמשיך לשפר את המוצר או מוצרים דומים אחרים, וכנ"ל לגבי תמיכה. אז רק חשוב שהבידול הזה יהיה כתוב גם בהסכם.
כוח עליון
- חובה לספק שירותים גם בזמן מלחמה – כל הנושא של "כוח עליון" וההשפעה שלו על היכולת של ספק להמשיך לספק שירותים קיים בהסכמים מזה הרבה מאוד שנים. אבל בשנים האחרונות, כשישראל מצאה את עצמה בסבבי לחימה ארוכים יותר מכל מה שקדם להם מאז היווסדה, לקוחות מסוימים החלו להחריג מלחמה כאירוע כוח עליון שמאפשר דחיית ביצוע שירותים.
פירוש הדבר שספק מוצא את עצמו עם כמות מופחת של עובדים בגלל שהם במילואים, או אף המנכ"ל עצמו נמצא במילואים, או הכי גרוע – אם חס וחלילה עובדים נהרגו או נפצעו קשה בלחימה. אבל חייבים להמשיך ולתת שירותים ללקוח כאילו שלא השתנה שום דבר. כמובן שזה לא מציאותי.
אז שים לב שבהסכם שלך יהיה ברור שבמקרה של מלחמה ככל ותראה ללקוח שבאמת כמות משמעותית מכח האדם שלך נמצאים במילואים או לא זמינים מסיבה אחרת הקשורה ללחימה, ביצוע השירותים יידחה למשך תקופת הלחימה.
סיום ההסכם וגם אחרי זה
- הפסקת ההתקשרות בידי הלקוח מכל סיבה או תוך תקופה קצרה – לקוחות לא אוהבים להיות קשורים לספק, וכמובן מעדיפים את הגמישות של אפשרות להשתחרר מהסכם כשהנסיבות שלהם מצריכות את זה.
אבל כמובן שזה בעייתי לספק, שהשקיע זמן, כסף, ואנרגיה בכל התהליך של השגת הלקוח הזה וחתימה אתו על הסכם. במיוחד כשהספק נאלץ להשקיע כסף כדי לעמוד ברף הנדרש לעסקה. ברור שהספק מעדיף ודאות – חתמנו על הסכם לתקופה מסוימת ועכשיו אני רוצה להתרכז בביצוע השירותים שלי ולקבל עבורם את התמורה שסוכמה.
אז לרוב מאפשרים ללקוח לצאת באמצע הסכם רק בנסיבות קיצוניות – למשל כי הספק הפסיק לתקופה ארוכה את מתן השירותים ללא סיבה שמוסדרת בהסכם, או שרוב ההנהלה של הספק הורשעו בעבירות פליליות חמורות, או שהספק כבר לא עומד ברף הנדרש לביצוע השירותים (למשל לא עומד בדרישות הרגולציה ולא פועל לעמוד בדרישות). זה בהחלט לא מכל סיבה שתתחשק ללקוח.
וגם אז נהוג לתת לספק זמן סביר לתקן את הבעיה (ככל שניתן לתקנה) ולתת הודעה מוקדמת של תקופה יחסית ארוכה של 30-90 ימים, ולא לסיים מיידית. וכמובן שהספק יקבל תשלום מלא על כל השירותים שביצע עד למועד הסיום בפועל.
יש אפילו לקוחות שדורשים שהספק יבצע הליך העברה מסודר לספק אחר שמחליף אותו, ויעשה זאת ללא תמורה. שוב, זה אולי לגיטימי כאשר ההסכם מסתיים בגלל הפרה חמורה של הספק, אבל לא כאשר ההסכם מסתיים בגלל שהלקוח מצא ספק זול יותר או רוצה להעביר עסקה לחבר שלו או שפשוט תקופת ההסכם פגה והלקוח בחר לא לחדש.
- תמיכה בחינם אחרי סיום ההסכם – כן, יש לקוחות שחושבים שבגלל שהם קנו רישיון שימוש במוצר, הם צריכים לקבל תמיכה למוצר הזה כל עוד הם משתמשים בו, וללא עלות נוספת.
יש בזה אולי היגיון מסוים כאשר קונים רישיון למוצר לכל "תקופת החיים" שלו, אך עורכי דין יצירתיים שמים את התנאי הזה גם בהסכמים בהם הרישיון הוא לתקופה קבועה מראש.
שים לב שלא תסכים בטעות למצב שבו הסכם רכישת התוכנה בוטל בגלל אי תשלום, אבל אתה עדיין חייב להמשיך לספק תמיכה ללקוח הזה.
תמיכה
- תמיכה לתקופה לא מוגבלת – לקוחות שקונים רישיון לתוכנה ללא הגבלת זמן כמובן ירצו שתעניק תמיכה לאותו מוצר או אותה גרסת מוצר ללא הגבלת זמן, ובמחיר שאתה מבקש על התמיכה היום.
אבל אין לך שום דרך לחזות מה יהיה עוד שנתיים או חמש שנים. יכול להיות שתוציא גרסה חדשה לגמרי של התוכנה שדורשת ידע חדש לגמרי מאנשי התמיכה שלך. ויכול להיות שבכלל תרצה להפסיק לשווק את המוצר מכל מיני סיבות.
אם תסכים לדרישת הלקוח שתמיד יהיה מישהו שיעניק להם תמיכה, בהחלט יכול להיות מצב שבעתיד תהיה מחלקה שכל המטרה שלה זה רק להעניק שירותי תמיכה לאותו לקוח ולאותו מוצר ישן, ובמחירי הפסד. שים לב שלא תגיע למצב כזה.
פעילות המוצר והספק
- דרישות טכניות לא מתאימות לגרסת המוצר של הלקוח – יש לקוחות שאוהבים את הטמפלטים שלהם עד מאוד, ולא רואים באמת סיבה לשנות אותם גם כשהמוצר שהם רוכשים משתנה לגמרי. אהה, וההסכם שלהם כולל פרטים טכניים של המוצר במקום שזה יהיה בנספח מפרט ההזמנה. זה הכי בולט כשהלקוח מזמין שירות ענן באמצעות טמפלט שנועד להזמנת תוכנה On Prem.
ככה הספק מוצא את עצמו מחויב להפקיד קוד מקור של תוכנה שבכלל לא רצה על מחשבי הלקוח, להעביר לידי הלקוח בעלות בכל פיצ'ר שהלקוח ביקש כאשר המוצר בכלל רץ באופן אחיד עבור כל הלקוחות, מתחייב לעמוד בשלב התקנת המוצר כתנאי לתשלום תמורה כאשר המוצר בכלל לא מותקן, לאפשר גישה לשרתים עליהם נמצא המוצר לצורך בדיקה כאשר המוצר בכלל יושב על AWS, להתחייב ל-SLA שלא מתחשב בעובדה שהמוצר יושב על Azure וגם להם יש לפעמים תקלות, או מתחייב לשמר גרסה מסוימת של המוצר פעילה לאורך שנים כאשר כל המוצר בעצם מתעדכן אוטומטית עבור כל הלקוחות.
שים לב שדרישות הלקוח בכלל משקפות את המציאות של המוצר שלך, כי אחרת תהיה בהפרה מאוד מאוד מהר.
- בדיקות ביטחוניות של העובדים – כשאתה עובד עם משרד הביטחון או גופים ביטחוניים שונים, תיתקל לרוב בדרישות לבצע בדיקות ביטחוניות לגבי העובדים שלך. במקרים כאלה זה לגיטימי. זה פחות לגיטימי כשאתה מעניק למשל שירותי CRM למחלקת התברואה של עירייה. אבל כמו שכבר אמרתי, יש לקוחות שאוהבים את הטמפלטים שלהם ולא רוצים לשנות אותם.
שים לב שלא תסכים לדרישות שמעמיסות לך המון עלויות בקשר לעובדים שלך, או שיכולות בכלל למנוע מחלק מהעובדים לעבוד במתן שירותים לאותו לקוח.
- איסור מתן שירותים ללקוחות דומים – אם אתה עובד בתחום מסוים, אתה כמעט בוודאות מספק את אותם השירותים לכמה גופים/עסקים שעוסקים באותו תחום. במיוחד אם בנית את המוצר שלך במיוחד עבור סוג כזה של לקוח.
ואז אתה נתקל בדרישה חוזית של לקוח שאת סוג השירותים שלך לא תספק לשום גוף אחר שעוסק באותו תחום עיסוק כמו הלקוח הספציפי הזה. תנאי כזה בעצם מקטין לך בצורה דרסטית את שוק הלקוחות. ואם מדובר למשל בגוף ציבורי כמו משרד ממשלתי, אז בכלל לא ברור – האם הכוונה שאסור לך לעבוד עם שום גוף ציבורי אחר?
זה מסוג התנאים שמתאימים לסוג מסוים של נותני שירותים שתמיד בונים רק מוצרים לפי הזמנה, עבור לקוחות מסחריים. אם למשל הזמנת שירותים ממעצבי אתרי אינטרנט שעל הדרך למד המון על העסק שלך, אתה ממש לא רוצה שהוא מיידית אחריך יעבוד עם מתחרה ישיר שלך וישתמש בכל המידע שהוא קיבל עליך ועל הפעילות שלך. אבל זה ממש לא מתאים לכל מקרה של הזמנת שירותים או מוצר.
- קוד מקור בנאמנות עם תנאי שחרור מוגזמים – כשלקוח גדול קונה שירותים מחברה קטנה או חדשה למערכות חשובות או קריטיות, אחד החששות שלו הוא שהספק ייעלם. ואז הלקוח לא יכול לתקן שום תקלה שמתרחשת בתוכנה שלך, למרות שהמערכות שלו יכולות להיות מאוד תלויות בה.
בגלל זה בדיוק מבקשים לפעמים שקוד המקור של התוכנה שלך יופקד בנאמנות, ואז במקרים מסוימים הלקוח יוכל לקבל גישה לקוד המקור כדי שיוכל בעצמו לדאוג לתיקון תקלות כשזה נדרש.
הבעיות מתחילות כשהלקוח מבקש זכויות גישה מוגזמות לקוד המקור. למשל כשאתה מפסיק להעניק תמיכה כי הלקוח בהפרה של ההסכם או לא משלם את התמורה, או כי איחרת במענה ללקוח בכמה ימים כי עובד מפתח היה חולה או במילואים.
קוד המקור שלך זה כמובן משאב מאוד חשוב. אז תוודא שאם אתה מסכים לתת אליו גישה ללקוח, שזה באמת יהיה רק במקרים מוצדקים, ושהנאמן שאצלו הקוד יישמר ינקוט בצעדים הדרושים כדי לשמור את הקוד באופן בטוח.
- החלפת ספקי משנה רק לפי אישור של הלקוח – הרבה פעמים האיכות של השירותים שלך תלויה גם באיכות של ספקי המשנה שלך. ברור שאם התשתית שלך יושבת על AWS ותעבור לשירותי ענן של חברה קטנה במולדובה שכל השרתים שלה נמצאים שם, איכות השירותים שלך לא תהיה אותו דבר.
מצד שני לתת ללקוח וטו על כל החלפה של כל ספק משנה זאת דרישה פשוט מוגזמת. אני ממליץ לסכם שכל עוד ספק המשנה החדש מעניק שירותים שקשורים לשירותים שאתה מעניק ללקוח, ולדעתך המקצועית מעניק שירותים לפחות באותה רמה מקצועית ותפעולית כמו הספק הקודם, לא לגיטימי שהחלפת ספקי המשנה תהיה תלויה באישור הלקוחות שלך.
אחרת יכול להיות מצב שתרדוף אחרי לקוחות במשך חודשים רק כדי שיאשרו לך להחליף ספק משנה. ובכלל לא בטוח שהם יסכימו, ואז תהיה תקוע בלי יכולת לספק את השירותים שלך.
- מדיניות של הלקוח היא חלק מההסכם – אחת התשובות היותר נפוצות במו"מ כשצד לא יודע להסביר את ההיגיון מאחורי הדרישה שלו היא לומר "זאת המדיניות שלנו". יש גם לקוחות שמעלים את המדיניות הזאת על הכתב לצורכי התנהלות מול ספקים, ודורשים שבהסכם איתם יהיה כתוב שאתה כספק כפוף למדיניות הזאת. וכמובן שהלקוח שומר לעצמו את הזכות לשנות בעתיד את המדיניות לפי שיקול דעתו הבלעדי.
להסכים לתנאי כזה זה כמו לתת ללקוח צ'ק פתוח. אתה מראש מסכים שהוא יקבע לך איך להתנהל, בלי שום דרך להשפיע על מה הוא ידרוש ממך. גם אם היום המדיניות כוללת רק דברים הגיוניים או כאלה שלא משפיעים עליך, אין לך שום דרך לדעת מה יהיה כתוב שם מחר. אולי בכלל ללקוח יהיה בעלים חדש שירצה לקצץ בכל ההוצאות ויקבע שמהיום כל הספקים חייבים לתת ללקוח הזה 50% הנחה. כי ככה.
אז ההמלצה שלי היא לא להסכים להיות כפוף למדיניות כזאת בכלל, או לפחות לא להיות כפוף לשום תנאי שמשפיע על התנאים המסחריים או התפעוליים של העסקה.
- ביקורת במשרדים שלך עם התראה קצרה – יש מספר סוגי רגולציה או תקינה שיכולים לחייב לקוח לדרוש לפחות את האפשרות לבצע ביקורת אצלך במשרדים או באתר השרתים שלך (בהנחה שיש לך בכלל שרתים ושהתשתית שלך לא יושבת על שרתים של ספק אחר).
אבל חשוב לוודא שביקורת כזאת תתבצע בתנאים סבירים שלא יפריעו לפעילות שלך. אז לפחות שהיא תתקיים בשעות העבודה, עם התראה מספקת – לרוב 30-60 ימים מראש – ושהלקוח יחתום על התחייבות לסודיות לגבי המידע שהוא ילמד בביקורת שכזאת על הפעילות, הטכנולוגיה, והאבטחה שלך.
- אנשי מפתח שאסור להחליף – לפעמים לקוחות מתעקשים שאנשי מפתח מסוימים אצל הספק לא יוחלפו, בין אם מדובר בהגדרת תפקיד או אפילו בשם של עובד או בכיר ספציפי. ההנחה של הלקוח היא שאותם אנשי מפתח מסוימים יודעים איך לתפעל את המערכת ואם הם יעזבו זה יפגע בשירות שאתה כספק נותן ללקוח. כמובן שדרישה כזאת הרבה יותר מקובלת כאשר רוכשים חברה או פעילות שרווחיה תלויים בהישארות של עובדי מפתח מסוימים, וזה לא מנגנון שמתאים להסכם רכישת שירותים.
לך זה כמובן בעייתי כי אנשים עוזבים מקומות עבודה מכל מיני סיבות, ואתה לא יכול להתחייב שעובד מסוים ימשיך לעבוד בחברה בכל תקופת ההסכם.
ההמלצה שלי היא פשוט לא להסכים לתנאי שכזה. מקסימום אתה יכול להתחייב כי עובדים בכירים יוחלפו בעובדים בעלי רמת יכולות מקצועיות וידע שלא ייפלו מאלו של העובד שעזב, וזה בהחלט אמור להספיק ללקוח.
- איסור שימוש בקוד פתוח – יש לקוחות שמסיבותיהם שלהם לא מוכנים שבמערכת שלהם יהיו רכיבי קוד פתוח. דרישות אבטחה, או דרישות רגולטוריות, או שה-CTO ניסה פעם להגיש תיקון ל-kernel של לינוקס ודחו אותו ומאז הוא נשבע שלא יהיה יותר שום רכיב FOSS במערכת שלו. לא יודע.
כמובן שעדיף שהלקוח היה מציג את הדרישה הזאת ישר במסמכי המכרז, אבל מסיבות לא ברורות גילית על הדרישה הזאת רק כשקיבלת עותק מהסכם הלקוח אחרי שהגשת הצעת מחיר לפרויקט.
דרישה כזאת מתעלמת מהמציאות – המון בתי תוכנה היום משתמשים ברכיבי קוד פתוח, ולהגיש תוכנה ללקוח שבה צריך לבנות חלופות לכל רכיבי הקוד הפתוח בהם השתמשו בעבר הופך את העסקה לפשוט לא כדאית עבורך כספק.
אם אתה משתמש ברכיבי קוד פתוח במוצר שלך, שים לב גם לדרישות כאלה, ותבין למה אתה נכנס.
בינה מלאכותית
- איסור גורף על שימוש ב-AI – יש לקוחות שחוששים לזהם את המידע שלהם בתוצרי AI או לחרוג ממדיניות ה-AI הפנימית שלהם, ולכן דורשים מכל הספקים שלהם שלא יעשו כל שימוש בכל AI כלשהם.
אבל כמובן שזה לא תמיד הגיוני. בתי תוכנה ברובם עושים היום שימוש כלשהו בכלי בינה מלאכותית בתהליכי כתיבה, אפיון, בדיקה, או שלבים אחרים בפרויקט הקשורים לקוד שלהם. גם כאן מדובר בצעד שמאפשר עבודה מהירה ויעילה יותר, מה שמאפשר לך בתורו להציע ללקוח מחיר טוב יותר.
אם אחרי שנתת הצעת מחיר המבוססת על ההנחה שתוכל גם בפרויקט הזה להשתמש באותם כלי AI כרגיל, הלקוח אוסר על השימוש בכלים אחרי שכבר סגרתם על מחיר, אז אתה בסכנה שהפרויקט הזה יהיה הרבה פחות משתלם. וזה בהנחה שאתה בכלל עדיין מסוגל לייצר קוד ללא שום שימוש בבינה מלאכותית.
תיזהר מתנאי כזה בהסכם לקוח, ותבין מה ההשלכות שלו עבורך.
- אחריות על טעויות בתוצרים של AI – אם התוכנה שלך מייצרת תוצרים באמצעות AI, יש לקוחות שידרשו שתיקח אחריות על כל נזק שייגרם מטעות בתוצרים של אותו AI. גם למרות שאין לך שום שליטה בהמון גורמים הקשורים לתפעול של אותו AI, כגון תהליכי האימון שלו, המידע שהלקוח מכניס אליו, הפרומפטים שהלקוח כותב, החומרה עליה הלקוח מריץ את התוכנה, וכו'.
כמובן שמדובר בדרישה פשוט לא הגיונית ברוב המקרים בהם נעשה שימוש בבינה מלאכותית.
אם אתה מסכים לתנאי שכזה, שים לב לגודל האחריות שזה יוצר עליך. וגם פה הייתי ממליץ להכניס הגבלות מהסוג עליהן דיברתי בס' 1.
סיכום
אלו כמובן רק חלק מהדברים שראיתי בהסכמי לקוחות, כי אין גבול ליצירתיות של עורכי דין שלא מבינים את ההבדל בין חוזה רק לטובת הלקוח שלהם לבין חוזה שהצד השני מוכן לחתום עליו.
וכמובן שהמאמר הזה לא נותן פתרון מושלם לכל מקרה עליו דיברתי פה, כי תמיד צריך להבין את ההקשר ולראות את ההסכם במלואו.
ועדיין, אני מקווה שהצלחתי להסביר לפחות חלק מהנקודות החשובות להן צריך לשים לב בחוזים שלך עם לקוחות, כדי לא לצאת נפסד מעסקה שהיית בטוח שהיא טובה לחברה שלך.
הורדת מסמכי מכרז או קיבלת הסכם מלקוח גדול? שלח לי אותם לפני המועד האחרון לשאלות ההבהרה, ונקבע שיחה כדי לעבור על הסעיפים שכדאי לשנות.
גילוי נאות: מאמר זה מיועד להעשרת הידע ואינו מהווה ייעוץ משפטי. עמידה בדרישות החוק תלויה באופיין הספציפי של הפעילות והמערכות בחברתך.