התשובה הקצרה
ההחלטה בין CRM ל-Data 360 אינה "איפה יש מקום" אלא "מי צורך את הנתון ובאיזה קצב". CRM בנוי סביב רשומה שמישהו פותח, עורך ומקדם בתהליך. Data 360 בנוי סביב זרם אירועים שמאוחד לפרופיל ומשמש לפילוח, ניתוח והפעלה.
כשמערבבים בין השניים מקבלים אחת משתי תוצאות: CRM כבד עם מיליוני רשומות שאיש לא נוגע בהן, או שכבת נתונים עשירה שאף אחד לא פועל לפיה כי היא לא מגיעה לזרימת העבודה.
חלוקה מעשית
| סוג מידע | היכן | נימוק |
|---|---|---|
| לקוח, איש קשר, הזדמנות, Case | CRM | מנוהל ידנית, מניע תהליך והרשאות |
| שלב מכירה, משימות, אישורים | CRM | אוטומציה ותפעול יומיומי |
| קליקים, צפיות, שימוש במוצר | Data 360 | נפח גבוה, לא מנוהל ידנית |
| היסטוריית טרנזקציות מה-ERP | Data 360 (או גישה וירטואלית) | נפח, ומקור אמת חיצוני |
| פרופיל מאוחד וזהות חוצת מערכות | Data 360 | תפקידו לאחד מזהים |
| ניקוד, פילוח, המלצה | מחושב ב-Data 360, מוצג ב-CRM | חישוב בנפח, שימוש בזרימת עבודה |
השורה האחרונה היא העיקרון המרכזי: מחשבים במקום שיש בו נפח, מציגים במקום שיש בו החלטה.
מבחן ארבע השאלות
לפני שמכניסים נתון ל-CRM שואלים: האם מישהו עורך אותו ידנית? האם אוטומציה או Validation מסתמכות עליו? האם הוא נדרש בדוח תפעולי שוטף? האם הוא משפיע על הרשאות או בעלות? אם התשובה לכל הארבע היא לא, הנתון כמעט תמיד שייך לשכבת האיחוד.
הכיוון ההפוך תקף גם הוא: נתון שנשמר רק ב-Data 360 אבל נדרש לקבלת החלטה בזמן אמת חייב מנגנון החזרה - שדה מסכם, תצוגה, או פעולה - אחרת הוא לא ישפיע על התוצאה העסקית.
נפח, ביצועים ועלות
CRM מתומחר ומתוכנן סביב רשומות עסקיות. הכנסת אירועי התנהגות אליו משנה את פרופיל העומס: עדכונים המוניים מאטים, בניית דוחות נעשית כבדה, וגיבוי וסביבות בדיקה גדלים. Data 360 מתוכנן לקצב הזה ומתומחר לפי צריכה - מה שמחייב תשומת לב אחרת: שאילתות רחבות וזרימות מיותרות מייצרות עלות שוטפת.
בשני המקרים ההיגיינה זהה: להעביר רק את מה שיש לו צרכן, ולהגדיר Retention לכל זרם. הדיון בהעתקה מול גישה מרוחקת מפורט בZero Copy ו-Federation.
הרשאות: הפער שקל לפספס
מודל ההרשאות של CRM עשיר ומדויק ברמת רשומה ושדה. שכבת איחוד עובדת אחרת - היא בנויה לניתוח, והחשיפה שלה מתנהלת בכללי גישה ובמסכות. ארגון שמעביר נתון רגיש לשכבת האיחוד בלי לתכנן זאת עלול ליצור נראות רחבה יותר ממה שקיים ב-CRM.
הכלל: כל זרם שמכיל מידע רגיש מקבל החלטת חשיפה מפורשת לפני ההזרמה, ולא אחריה.
תרחיש: קמעונאי שהעביר הכול ל-CRM
רשת קמעונאית העבירה שלוש שנות היסטוריית רכישות - כ-40 מיליון שורות - לאובייקט מותאם ב-CRM, מתוך רצון ש"למוכר תהיה תמונה מלאה". התוצאה: זמני טעינה ארוכים במסך הלקוח, עדכונים לילייים שחרגו מהחלון, ודוחות שכשלו בפסקי זמן.
בבנייה מחדש נשארו ב-CRM ארבעה ערכים נגזרים בלבד: תאריך רכישה אחרונה, סכום 12 חודשים, קטגוריה מובילה, וסימון סיכון נטישה. ההיסטוריה המלאה עברה לשכבת האיחוד, עם קישור לתצוגה מפורטת לפי דרישה.
מסך הלקוח נטען מהר, המוכרים קיבלו את מה שהם באמת שאלו עליו, והפילוח השיווקי דווקא השתפר - כי הוא רץ על נתונים שכולם באותו מקום ולא רק על אלה שהצליחו להיכנס ל-CRM.
סיכונים נפוצים ופעולות מניעה
| סיכון | כיצד הוא נראה בפועל | פעולת מניעה |
|---|---|---|
| הכל ב-CRM | ביצועים, עלות וזמני טעינה | ערכים נגזרים במקום היסטוריה גולמית |
| הכל בשכבת האיחוד | תובנות שלא מגיעות לזרימת העבודה | מנגנון החזרה: שדה, תצוגה או פעולה |
| אין Retention | נפח שגדל בלי בעלים | מדיניות שמירה לכל זרם |
| הרשאות לא מתוכננות | חשיפת מידע רגיש בניתוח | החלטת חשיפה לפני ההזרמה |
| זהות לא מאוחדת | פרופיל מפוצל לאותו לקוח | כללי Identity Resolution מוגדרים |
כיצד מודדים הצלחה
| תחום | מה מודדים | קצב בדיקה |
|---|---|---|
| ביצועים | זמן טעינת מסך לקוח ועדכונים המוניים | חודשי |
| איחוד | אחוז פרופילים מאוחדים בהצלחה | חודשי |
| הפעלה | פילוחים ופעולות שנוצרו מהנתון בפועל | רבעוני |
| עלות | צריכה מול תקציב לפי זרם | חודשי |
תכנון החלוקה בין CRM לשכבת האיחוד מתבצע במסגרת שירות אינטגרציות ודאטה.
Checklist להחלטה
- ☐ מיפוי זרמי נתונים לפי נפח וקצב עדכון
- ☐ מבחן ארבע השאלות לכל זרם
- ☐ הוגדרו הערכים הנגזרים שיוצגו ב-CRM
- ☐ קיים מנגנון החזרה מהאיחוד לזרימת העבודה
- ☐ כללי Identity Resolution כתובים
- ☐ החלטת חשיפה לכל זרם עם מידע רגיש
- ☐ מדיניות Retention לכל זרם
- ☐ אומדן עלות צריכה לגל הראשון
- ☐ נבחר Use Case אחד להוכחת ערך
- ☐ נקבע בעלים לכל זרם נתונים
מקורות מקצועיים
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – אינטגרציות ודאטה — https://hpi.pro/integrations-data