מה צריך להיות על השולחן ביום שאחרי האפיון
אפיון CRM נמדד בתוצרים שאפשר לעבוד לפיהם, לא בכמות הפגישות. אם בסוף השלב מנהל הפרויקט עדיין לא יכול לבנות תוכנית עבודה, המפתח עדיין לא יודע איזה אובייקט מחזיק את התהליך, ומנהל הנתונים עדיין לא יודע מאיפה מגיע הלקוח — האפיון לא הסתיים, גם אם המצגת אושרה.
המדריך הזה מגדיר שבעה תוצרים. לכל אחד יש קריטריון בשלות: משפט אחד שאפשר לענות עליו בכן או לא. מי שעונה "בערך" על יותר משניים מהם, נכנס לשלב הבנייה עם סיכון שכבר אפשר לתמחר. תמונת הרוחב של השלבים שאחרי האפיון מופיעה במדריך הטמעת Salesforce.
תוצר 1: מפת תהליכים ברמת החלטה
לא תרשים זרימה של כל לחיצה, אלא מיפוי של נקודות ההחלטה: מי מחליט, על סמך איזה מידע, מה קורה בכל ענף ומה קורה כשאין החלטה. רוב הכשלים בפרויקטי CRM לא נמצאים במסלול הרגיל אלא בענפים — עסקה שמוקפאת, לקוח שחוזר אחרי שנתיים, פנייה שנפתחה על ידי הלקוח הלא נכון.
קריטריון בשלות: אפשר לקחת עסקה אמיתית מהחודש האחרון ולעקוב אחריה על המפה מקצה לקצה בלי להיתקל בחור.
תוצר 2: מילון מונחים עסקי
זה התוצר שהכי מזלזלים בו והכי משלמים על היעדרו. "לקוח" פירושו דבר אחר בכספים ובמכירות. "פרויקט פעיל" פירושו דבר אחר בתפעול ובהנהלה. כל עוד ההגדרות לא כתובות, כל דוח יוצר ויכוח.
המילון צריך להכיל, לכל מונח: הגדרה במשפט, הישות ב-Salesforce שמייצגת אותו, השדה שקובע את הסטטוס, והמחלקה שמחזיקה את ההגדרה.
תוצר 3: מודל נתונים ליבתי מוכרע
בשלב האפיון לא בונים ERD מלא, אבל כן מכריעים את ארבע השאלות שיקרות לשינוי בדיעבד:
- האם הפעילות העסקית יושבת על Opportunity, על אובייקט מותאם או על שילוב, ומה היחס ביניהם.
- האם Account מייצג ישות משפטית, אתר פיזי או קבוצת רכש — ואיך מטפלים בהיררכיה.
- מה המפתח הייחודי שמזהה לקוח בין Salesforce למערכות הליבה.
- אילו נתונים היסטוריים נכנסים למערכת ואילו נשארים במקור.
קריטריון בשלות: אפשר לצייר על לוח את חמשת האובייקטים המרכזיים והקשרים ביניהם בלי לפתוח קובץ.
תוצר 4: מודל הרשאות וחשיפה
מודל ההרשאות נגזר מהשאלה מי אמור לא לראות מה, לא מהשאלה מי צריך לראות. שתי השאלות נראות זהות ומובילות לארכיטקטורות הפוכות. אפיון טוב מגדיר את ברירת המחדל הארגונית לכל אובייקט מרכזי, את מנגנון ההרחבה, ואת המקרים שמחייבים חשיפה חריגה.
| שאלה | מה בודקים באפיון | למה זה יקר לשנות אחר כך |
|---|---|---|
| ברירת מחדל לאובייקט | Private, Public Read או Read/Write | משפיע על כל מנגנון השיתוף מעליו |
| מבנה היררכיה | האם היררכיית התפקידים משקפת ניהול או גיאוגרפיה | שינוי דורש חישוב מחדש של גישה בכל הרשומות |
| חשיפה חוצת יחידות | צוותים משותפים, שיתוף ידני או קריטריון | קובע אם צריך לוגיקה ייעודית |
| נתונים רגישים | אילו שדות מוגבלים ולמי | שינוי בדיעבד חושף מידע שכבר נצפה |
תוצר 5: מפת מערכות ומקורות אמת
לכל ישות מרכזית צריך להיות מקור אמת יחיד ומוצהר, וכיוון סנכרון ברור. אפיון שמשאיר שתי מערכות "מעדכנות אחת את השנייה" יוצר קונפליקטים שיתגלו רק בייצור. המפה צריכה לכלול גם את התדירות ואת הסבילות לעיכוב: תהליך מכירה יכול לחיות עם סנכרון של חמש דקות, בקרת אשראי בדרך כלל לא.
תוצר 6: קריטריוני קבלה לתהליכי הליבה
זהו החיבור בין האפיון לבין הבדיקות. לכל תהליך ליבה נדרשים שלושה עד חמישה תנאי קבלה מנוסחים כתוצאה נצפית: "לאחר סגירת עסקה נוצרת הזמנה במערכת הליבה תוך חמש דקות, עם אותו מזהה לקוח". ניסוח כזה הוא גם דרישה, גם תסריט בדיקה וגם הגדרת סיום. בלי זה, שלב ה-UAT הופך לסבב הערות עיצוב.
תוצר 7: מדדי בסיס לפני השינוי
אי אפשר להוכיח שיפור בלי מדידה שנעשתה לפני. באפיון בוחרים שלושה עד חמישה מדדים ומודדים אותם בפועל במצב הקיים, גם אם המדידה ידנית וגסה. בחירת המדדים והדרך לחבר אותם לתועלת עסקית מפורטת במדריך ROI ומדדי הצלחה.
דוגמה להמחשה: רשת מרפאות פרטיות
התרחיש הבא הוא היפותטי ונועד להמחשה בלבד. רשת מרפאות עם שמונה סניפים ניגשה לפרויקט CRM כדי לרכז פניות מטופלים. באפיון התברר ששני סניפים מגדירים "פנייה חוזרת" אחרת: אחד סופר כל שיחה, השני סופר רק פנייה בנושא חדש. ההבדל נראה סמנטי, אבל הוא קבע אם המערכת צריכה אובייקט Case אחד עם היררכיה או שני אובייקטים נפרדים, והוא קבע את כל דוחות העומס של ההנהלה.
הצוות לא סגר את המחלוקת במסמך. הוא רשם החלטה פתוחה, הגדיר בעלים ברמת סמנכ"ל תפעול, ותאריך יעד לפני תחילת הבנייה. ההכרעה נפלה תוך שבועיים, והמודל נבנה פעם אחת. לו ההחלטה הייתה נדחית, היא הייתה מתגלה בשלב ה-UAT — אחרי שכבר נבנו מסכים ודוחות על הנחה שגויה.
סימני אזהרה לאפיון רדוד
- המסמך מתאר מסכים ושדות אבל לא מתאר מה קורה כשתהליך נכשל.
- אין אף החלטה מתועדת שנשקלו לה חלופות.
- כל הדרישות בעדיפות גבוהה.
- אין שם של אדם ליד אף תהליך, רק שם של מחלקה.
- מספר השדות המבוקשים במסך אחד עולה על עשרים וחמישה בלי שאיש בדק מי ממלא אותם.
הקשר בין אפיון רדוד לבין דפוסי הכשל שמופיעים בהמשך הפרויקט מפורט במדריך הטעויות הנפוצות, והשפעתו על לוח הזמנים מוסברת במדריך משך פרויקט Salesforce.
כשמדובר בהחלפת מערכת קיימת
כשהפרויקט מחליף CRM ותיק, האפיון מקבל משימה נוספת: להחליט מה לא עובר. מערכת ותיקה צברה שדות, אוטומציות ודוחות שאיש כבר לא משתמש בהם, והעתקה עיוורת שלהם מייבאת את החוב הישן לפלטפורמה חדשה. סדר הפעולות המומלץ במעבר כזה מפורט במדריך החלפת CRM ב-Salesforce.
איך יודעים שאפשר להתחיל לבנות
עברו על שבעת התוצרים ושאלו לכל אחד את שאלת הבשלות. אם ששה מתוך שבעה עונים כן, אפשר להתחיל בגל ראשון תוך ניהול הפער השביעי כסיכון מתועד. אם שלושה או יותר עונים "בערך", עדיף להאריך את האפיון בשבועיים מאשר לגלות את הפער אחרי שנבנו שלושה חודשי עבודה על גביו.
השלב הבא הטבעי הוא תרגום התוצרים לתוכנית גלים, עם החלטה מפורשת מה נכנס לגל הראשון ומה נדחה במודע.