מו"מ לרכישת תוכנה מחייב תכנון לטווח ארוך. נושא זה הינו אחד התחומים החמים והחשובים כיום בתעשייה. עסקה שעל פניה נראתה מעולה בזמן החתימה, יכולה להתברר ככישלון חרוץ לאחר שנתיים.
רבות מהעסקאות נכשלות בשל חוסר ניסיון/הבנה של השותפים למו"מ, אי הקפדה על בחינה תקופתית של התאמת תנאי הרישיון למציאות בשטח, חוסר תשומת לב לפרטי הרישיון ולמשמעותם.
מטרת המאמר היא להציע צעדים שיש לנקוט כדי להגדיל את התמורה על ההשקעה ברכישת תוכנה חדשה.
שינוי מבני בארגון, המביא לעצמאות של יחידת ה IT ברכישות של חומרה ותוכנה מחייב הקניית ידע למנהלי יחידה זו לגבי ההשלכות הצפויות שיש לרכישת תוכנה על שאר הארגון.
השינויים התכופים בטכנולוגיות והמעבר לשימוש במיקור חוץ לא נידונים מספיק ואינם נלקחים לרוב בשיקולי החתימה על הסכמי שימוש בתוכנות חדשות.
בתחילת המו"מ אנשי המכירות של ספק התוכנה הם אלה שנותנים את הטון ומדגישים במיוחד את עניין המוצרים והמחיר. עניינים אחרים כמו התאמת המוצר יותר טוב ללקוח והשפעות ארוכות טווח אינם מקבלים תשומת לב ראויה. מצד שני הבאת אנשי מקצוע נוספים לדיונים תייקר מאוד את המו"מ מבחינת הספק ולכן על אנשי המכירות לדאוג לכתובות מקצועיות ברורות אצלם בארגון לכל שאלה מהצד הרוכש.
לפני כניסה למו"מ חדש:
על הארגון לערוך ניתוח מעמיק של כל ספק פוטנציאלי לפני כניסה למו"מ עימו שיכלול:
חוסן כלכלי, מיצובו בשוק, חשיבות המוצר בתוך תיקו העסקי של הספק, שותפים בולטים בתעשייה ושביעות רצון של לקוחותיו.
הערכת סיכונים חייבת גם היא להעשות:
עד כמה חשוב הספק לארגון? (אסטרטגי/טקטי?), איזה סוג חוזה צפוי להחתם?, מהו סדר הגודל של ההתחייבות הכספית הצפוייה? לכמה זמן? עד כמה זמינים המשאבים הדרושים לקיום העסקה?
בדיקה חוזרת של שני הסעיפים האחרונים חייבת להערך כל שנה וזאת כדי לצפות עליה בסיכון העסקה בשל שינוי במצבו הכספי של הספק או בפקטור אחר (לדוגמה, הספק מספק טכנולוגיה ייחודית ללא אפשרות להחלפה) ולהערך בהתאם כדי להגן על ההשקעה.
הכניסה למו"מ:
ארגונים שמכינים שיעורי בית לפני כניסה למו"מ משיגים עסקאות טובות יותר.
לפני פרסום המכרז יש לקבוע בתוך קבוצת המו"מ הנחות לגבי תרחישים עתידיים שעלולים להשפיע על העסקה (ניתוח "מקרים ותגובות" בעגה הצבאית) ולקבוע תגובות מתאימות. כך יש להערך לשינויים משמעותיים בגודל הארגון לאחר החתימה על העסקה, כישלון אפשרי של הפרוייקט, שינויים מקרו כלכליים וכיו"ב. כל הצעה של ספק תמויין להצעה "טובה", בינונית" או "גרועה" לפי התנהגותו הצפוייה בכל תרחיש.
פרסום בקשה להצעות (RFI) עדיף לעשות בין מספר ספקים שנמצאים בתחרות אחד מול השני.
טיוטת ה RFP צריכה לקחת את כל אלה בחשבון. אם היא מנוסחת כראוי היא יכולה לשמש כלי מיון מעולה של ההצעות השונות.
דגשים למו"מ:
הכרות מעמיקה עם שיטת התמחור שנוקט הספק כדי למנוע עלויות לא צפויות בהמשך הדרך. שינוי שיטת התמחור –צריך להעשות בהתראה מינימלית, אשר תאפשר הערכות הארגון בהתאם. במידה והתמחור מבוסס על נפח השימוש או התועלת המופקת ממנו (VALUE-BASED), יש לדאוג להגדיר את קהילת המשתמשים כך שיכללו בה רק אותם עובדים, אשר באמת זקוקים לתוכנה ועושים בה שימוש.
יש לגדר מראש עד כמה שניתן את עלויות השירות והתחזוקה. יש להכיר ולעגן בחוזה את מנגנון השינוי בשיטת החיוב עבור שירות משנה לשנה (הצמדות למיניהן, אינפלציה וכו').
הגדרות היקף השימוש בתוכנה –יש לדאוג להכללת חברת האם והחברות הבנות לקהילת המשתמשים בתוכנה (אם יש בכך צורך). הארגון יכול לנהל מו"מ גם עבור חברה בשליטתו בשיעור של 30%.
במהלך המו"מ יש לתת את הדעת להוצאת שירותים שונים מהארגון למיקור חוץ ולהוסיף לחוזה סעיף המתיר את השימוש בתוכנה גם לקבלן המשנה.
שדרוג לגרסאות חדשות של התוכנה –הרבה חברות תוכנה מתייחסות לגרסאות חדשות של אותם מוצרים כמוצרים חדשים. ארגון שרוכש תוכנה צריך לדרוש הכללת שדרוג התוכנה בעלויות החוזה. פשרה מקובלת היא תשלום "דמי שדרוג" מופחתים במקום רכישה בעלות מלאה של הגרסה החדשה. יש לדאוג מראש למקרים בהם הספק נותן שם חדש למוצר ודורש דמי רישוי מלאים תוך טענה שזהו מוצר חדש.
כלומר יש לנסות להוסיף סעיף שמדבר על כל ש"הספק מתחייב לדאוג לפונקציונליות שהוגדרה גם במקרה שמדובר על שינוי שם המוצר."
כל אלה הן סוגיות קריטיות שיש לטפל בהן בעת חתימה על חוזה רכישה של תוכנה חדשה.
צוות המו"מ:
צוות המו"מ צריך לכלול ראש צוות בעל ידע מעמיק בכל הנושאים הרלוונטים לעסקה וכן בעל/ת סמכות לקבלת החלטות בסדר הגודל הרלוונטי.
הצוות עצמו צריך לכלול נציגים של הייעוץ המשפטי של הארגון, נציג מחלקת הרכש, נציג מחלקת ה IT ונציג המחלקה הכלכלית.
ככלל, ככל שהיקף העסקה גדול יותר מבחינה כלכלית ואשר עשויות להיות לו השלכות ארוכות טווח על הארגון, כך יצורפו לצוות יותר חברים. מצד שני, ריבוי חברים בצוות המו"מ יכול להקשות על קבלת החלטות מהירה וכן מייקר את עלות המו"מ.
דגשים נוספים:
אין לחתום על עסקה, גם לא על "תקופת הרצה" לתוכנה ללא הסדרה בכתב של כל התנאים בחוזה.
רצוי מאוד לערוך תקציר של עיקרי ההסכם. תקציר כזה יכול לייעל מאוד את ההתמצאות של המשתמשים בנקודות החשובות של ההסכם ללא צורך של כל הנוגעים בדבר לקרוא את כולו.
לסיכום, רוב הכישלונות ברכישת תוכנות חדשות נובעים מהסיבות הבאות:
-לא מוקדש מספיק זמן למו"מ;
-לצוות המו"מ משובצים אנשים בעלי כישורים שאינם מתאימים לביצוע עסקה בסדר הגודל המבוקש;
-לא נערך מעקב תקופתי אחר הסכמים שנחתמו.
רכש התוכנה לפי CPU או לפי CORE - נושא זה טופל בכניסה אחרת בבלוג.
מבט על השוק הישראלי:
בישראל באופן כללי המחירים תחרותיים לעומת ארה"ב ואירופה. זאת מכיוון שכ"א בישראל זול יחסית ולכן במקרים מסוימים ישנה אופציה לבצע פיתוח פנימי ולא לרכוש את מוצר התוכנה.
בישראל במקרים רבים ישנה אפשרות למשווק (שלעיתים אינו חברת בת) ל"עצום עיין" מבחינת מספר הרישיונות או אופן השימוש בהם. אך מצד שני יש לזכור שלעיתים עקב הרוחק הפיזי ישנה פגיעה ברמת השירות.
מצד שני ישנם מקרים בהם העלויות בישראל יקרות יותר – לדוגמה בחלק ממוצרי ה- MF.
בישראל בולטת גם הדומיננטיות של חברת מיקרוסופט אשר לקוחות רבים בישראל (90% בישראל לעומת כ- 60% בעולם) משדרגים את תוכנת מיקרוסופט במסגרת Enterprise Agreement.