איך קורה שלקוחות פונים לבתי משפט בתביעות נגד ספקי ה-IT שלהם?

מה חשיבות של מסמך ה- SOW בפרויקט Turn-Key?

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

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

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

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

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

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

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

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

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

רונן שמחון

RS-IT