10 טעויות נפוצות בהטמעת CRM ו-Salesforce וכיצד להימנע מהן

איך לקרוא את הרשימה הזאת

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

1. מתחילים מרשימת פיצ'רים במקום מתהליך

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

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

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

2. אין בעל תהליך יחיד

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

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

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

3. דוחפים החלטות ארכיטקטוניות לסוף

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

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

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

4. מייבאים את החוב של המערכת הישנה

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

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

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

5. מודדים התקדמות בסטוריז שנסגרו

הסימן: הדוח השבועי מציג אחוזי השלמה גבוהים, אבל אף אחד עדיין לא הצליח להריץ תהליך שלם מקצה לקצה.

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

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

6. שדות חובה כתחליף למשמעת נתונים

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

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

מניעה: חובה מוטלת רק על שדה שנדרש להחלטה בנקודה שבה הוא נשאל. שדות שנדרשים בהמשך התהליך מחויבים בהמשך התהליך.

7. בונים אוטומציה לפני שהתהליך יציב

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

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

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

8. UAT שמתבצע על ידי מי שבנה

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

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

מניעה: בדיקות מבוצעות על ידי אנשי התהליך, על נתונים שדומים לנתוני אמת, ובאחריות מוגדרת לאישור או דחייה.

9. הדרכה כאירוע חד פעמי

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

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

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

10. אין בעלות אחרי Go Live

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

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

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

עלות התיקון לפי שלב

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

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

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

מה לעשות עם הרשימה

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