איך משווים הצעות מחיר לפרויקט Salesforce בלי ליפול במחיר הנמוך

למה הצעות ל-Salesforce כמעט אף פעם אינן ברות השוואה

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

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

השוואה מתחילה אפוא בנרמול, לא בטבלת מחירים.

שיטת נרמול בשישה צעדים

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

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

3. תמחרו את החסר. לכל רכיב שאינו נכלל בהצעה, השתמשו בעלות מהצעה אחרת כאומדן והוסיפו אותו.

4. יישרו הנחות. מספר משתמשים, מהדורה, שנות היסטוריה, מספר יחידות עסקיות, שפות.

5. יישרו תקופת אחריות. תקופה שונה שווה כסף. הפרש של חודשיים ייצוב הוא רכיב עלות אמיתי.

6. חשבו עלות ממוצעת לשעה ותמהיל צוות בכל שלב, לא בסך הכול.

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

הרכיבים שנעלמים מהצעות — ומגיעים בחשבון

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

מהשוואת מחיר להשוואת עלות תלת-שנתית

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

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

דגלים אדומים בהצעה

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

דוגמה להמחשה: חברת אנרגיה מתחדשת

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

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

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

מה עושים עם הפער שנשאר

אחרי נרמול נשאר בדרך כלל פער אמיתי. תרגמו אותו לשאלות ולא להנחות:

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

תשובות לשאלות האלה מבדילות בין ספק שתמחר בזול כי הוא יעיל לבין ספק שתמחר בזול כי לא הבין.

החיבור להחלטה הסופית

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

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

הצעד הבא

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