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

כתבה: עו"ד אסנת סרוסי פירסטטר, שותפה, ראש מחלקת היי-טק וטכנולוגיה במשרד ליפא מאיר ושות', עורכי דין

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

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

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

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

התשובה הגיעה בשיחת טלפון מהלקוח: "צריך להיפגש".

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

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

סגירת קצוות

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

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

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

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

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

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

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

אין "אמת אחת"

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

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

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

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

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

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

זהו מאמר אינפורמטיבי בלבד ואין לראות בו ייעוץ משפטי.