RFP להטמעת Salesforce: מבנה, שאלות ותוצרים שחייבים לדרוש

מה מסמך פנייה טוב אמור לייצר

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

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

תשעת החלקים של מסמך RFP ל-Salesforce

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

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

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

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

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

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

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

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

9. לוח זמנים למכרז. מועד שאלות, מועד תשובות, מועד הגשה, מועד הדגמות, מועד החלטה.

הנתונים שחובה לחשוף כדי לקבל תמחור אמיתי

שאלות שמפרידות בין ספקים

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

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

השאלה האחרונה היא מבחן טוב לאופי ההתקשרות. ספק שמתחמק ממנה מתכנן תלות.

מה לדרוש כתוצר בתוך ההצעה

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

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

מבנה תמחור אחיד — הכלי שמונע השוואת תפוחים לתפוזים

הגדירו בעצמכם את הטבלה שכל מציע חייב למלא:

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

דוגמה להמחשה: קופת גמל בינונית

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

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

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

טעויות נפוצות בכתיבת RFP

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

מה קורה אחרי ההגשה

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

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

הצעד הבא

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