המערכות סביב Salesforce

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 3 מתוך 6 בפרק הבנת נתוני הארגון, הפרק הרביעי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: סוגי הנתונים בארגון · הבא: שרטטו את מפת המערכות

השאלה שהיחידה הזו עונה עליה: מה מקיף את Salesforce, ואיזה תפקיד כל מערכת ממלאת?

היחידה הקודמת מיינה את הנתונים. עכשיו אני רוצה לשים אותם איפשהו, וכאן ארכיטקטים של Salesforce נכנסים לצרות. אנחנו מכירים את Salesforce, אז נתוני לקוח הם Account, נתוני הזמנה הם Order, מסמכים הם Files, אנליטיקה היא Reports. אבל הארגון לא קנה את Salesforce כדי להחליף את כל השאר שיש לו. ייתכן שיש ERP שמריץ את הכספים והאספקה, מחסן נתונים עם שנים של היסטוריה, פלטפורמת אינטגרציה, ספק זהויות, מערכות של שותפים, פלטפורמת אירועים, פלטפורמת MDM, ו-Data 360 שמחבר כמה מהן. העבודה היא לא לשנן טכנולוגיות. היא להבין איזה תפקיד יש לכל מערכת.

אל תתחילו משם המוצר

“יש לנו SAP” לא אומר לי מספיק. גם לא Snowflake, MuleSoft, Tableau או Data 360. אני רוצה לדעת מה המערכת הזו עושה בארכיטקטורה הזו: אילו נתונים בבעלותה, מה היא קוראת, מה היא משנה, מי משתמש בה, מה תלוי בה, מה קורה כשהיא למטה. לשתי חברות יכולים להיות בדיוק אותם מוצרים וארכיטקטורות שונות לגמרי.

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

• מערכת רשומה (system of record): המקום שבו מתוחזקת הגרסה הסמכותית של משהו.
• מערכת מעורבות (system of engagement): המקום שבו אנשים עושים את העבודה.
• מערכת ייחוס (system of reference): המקום שאליו מערכת פונה בשביל מידע שהיא צריכה אבל לא מחזיקה בבעלותה.
• מערכת תובנות (system of insight): המקום שבו נתונים מתחברים כדי למדוד, לנתח ולחזות.

פלטפורמה אחת יכולה למלא כמה תפקידים, והתפקידים שונים לפי הנתונים. Salesforce עשויה להיות מערכת הרשומה לפניות, מערכת המעורבות לנציגי השירות, וצרכנית של נתוני מוצרים שה-ERP הוא הבעלים שלהם. אז כשמישהו אומר “Salesforce היא מערכת הרשומה שלנו”, השלימו את המשפט: מערכת רשומה של מה?

ה-ERP: לבק-אופיס יש כוח משיכה

ה-ERP הוא המערכת שתמצאו ליד Salesforce הכי הרבה, והוא מריץ כספים, מלאי, רכש, אספקה וחיוב. הדפוס מיחידה 1 (לקוחות ומוצרים נכנסים, הזמנות יוצאות) פירושו שה-ERP הוא הבעלים של המוצרים, אבל אנשי המכירות עדיין צריכים אותם ב-Salesforce. בסדר: הביאו אותם פנימה. אבל העתקת נתונים לא מעבירה בעלות. עותק הוא לא סמכות.

העמדה שלי: נתונים שה-ERP הוא הבעלים שלהם נקראים מקומית ונכתבים תחת בקרה. משתמשי Salesforce מקבלים את הנתונים במקום שבו הם עובדים, אבל Salesforce לא משנה את מה שה-ERP מחזיק. ואני הופך את זה לגלוי בסכמה: השדות של ה-ERP נושאים קידומת erp_, כמו erp_Product_Number__c, כך שכל מי שקורא את האובייקט יודע מי הבעלים של כל שדה, ושצריך להיזהר כשמשנים אותו. הקידומת לא אוכפת כלום; הרשאות, אימות ודפוס האינטגרציה עושים את זה. היא מבטאת כוונה, והיא מפת הסמכות (authority map) שהפכה לגלויה.

מחסן הנתונים, אגם הנתונים וה-Lakehouse

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

תפגשו שלושה סוגים של מאגרים אנליטיים. מחסן נתונים (data warehouse) מחזיק נתונים מובנים שהוכנו לניתוח. אגם נתונים (data lake) מחזיק הרבה יותר נתונים, ביותר צורות, לעיתים קרובות גולמיים. Lakehouse משלב את השניים: אחסון בסגנון אגם עם ניתוח בסגנון מחסן. הכירו אותם, כי הם מופיעים במפות מערכות. אבל הניסיון שלי הוא שlakehouses ו-data mesh הם עדיין נישה בפרויקטים של Salesforce. מפת המערכות הטיפוסית היא CRM, ERP, מחסן נתונים ושכבת אינטגרציה, ועוד פלטפורמות איפה שהעסק באמת צריך אותן. למדו את הארכיטקטורה; אל תרדפו אחרי אוצר המילים.

האנליטיקה חיה איפה שהנתונים חיים

זו אחת העמדות הכי נחרצות שלי: המקום שבו האנליטיקה חיה הולך אחרי המקום שבו הנתונים חיים. אם הדוח צריך רק חשבונות, הזדמנויות ואנשי מכירות, הכול על הליבה: דוחות ולוחות מחוונים סטנדרטיים. ואז העסק מבקש להוסיף חשבוניות מה-ERP. ואז עלות מוצר. ואז חמש שנים של הזמנות ממחסן הנתונים. ואז פעילות באתר. בשלב מסוים, לגרור את כל זה ל-CRM התפעולי רק כדי לדווח עליו מפסיק להיות הגיוני. ברגע שמאגרי נתונים אחרים מעורבים, פלטפורמת אנליטיקה הופכת להכרחית: Tableau (כולל Tableau Next, שבנוי על Data 360), או CRM Analytics איפה שהוא כבר בשימוש. היא חיונית כשנתוני Salesforce מתמזגים עם מחסן נתונים. הדרישה לא סתם נהייתה מסובכת יותר; מפת המערכות שינתה את המקום שבו צריך לענות על השאלה. אז אני אף פעם לא מתחיל ב”איזה כלי אנליטיקה?” אני מתחיל באיפה הנתונים?

אני שואל מועמדים ל-CTA את אותו דבר: “איזה מהתרשימים שלי פותר את זה בצורה יפה? מפת המערכות.” אם הכול אצלכם על הליבה, השתמשו בדוחות. אם יש לכם נתונים במאגרים אחרים, אני רוצה לראות פלטפורמת אנליטיקה. מפת המערכות עונה על שאלת הדיווח לפני שמישהו פותח בונה דוחות. (שמות המוצרים משתנים; הפרק על Data 360 מכסה איפה האנליטיקה של Salesforce עומדת היום.)

MDM: מי הלקוח הזה, באמת?

עכשיו נניח שמידע על לקוחות חי ב-Salesforce, ב-ERP, במסחר המקוון, בפלטפורמת מועדון לקוחות ובמערכת של שותף, וכל אחת חושבת שהיא יודעת מי הלקוח. כאן נכנס ניהול נתוני אב (master data management): לקבוע ולמשול בזהות הסמכותית של נתוני מפתח בין המערכות. אבל MDM הוא לא “מסד נתונים ראשי של לקוחות”. השאלות הקשות הן איזו מערכת רשאית ליצור את הלקוח, אילו מאפיינים כל מערכת מחזיקה בבעלותה, איך מוצאים כפילויות, איזה מזהה שורד, ומה קורה כשמערכות לא מסכימות. פרק 6 עוסק כולו בזה. כאן, זהו את התפקיד: אם קיימת פלטפורמת MDM, היא עשויה להיות סמכות קריטית בין Salesforce לבין שאר הארגון.

שכבת האינטגרציה והאירועים

חברו כל מערכת ישירות לכל מערכת אחרת, ומפת המערכות הופכת לספגטי מהר מאוד. בגלל זה לארגונים יש שכבת אינטגרציה: ESB (enterprise service bus) או iPaaS (integration platform as a service). MuleSoft הוא זה שתפגשו הכי הרבה במפות מערכות של Salesforce. הוא מתווך, כך שכל אפליקציה לא צריכה להבין כל אפליקציה אחרת.

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

ולא כל אינטגרציה היא מערכת A שקוראת למערכת B. לפעמים משהו קורה (הזמנה נוצרת, משלוח משנה סטטוס, משאית חוצה לתוך אזור), אירוע מתפרסם, ומי שמתעניין מגיב. גם לאירועים בתנועה יש תשתית: יכולות האירועים של Salesforce עצמה, event bus ארגוני, מערכות הודעות אחרות. שרטטו את המנגנונים שנושאים את הנתונים, לא רק את מסדי הנתונים.

המערכת שמפתחים שוכחים: זהות

יש קופסה אחת שאני תמיד רוצה במפת המערכות ומפתחים כמעט לא חושבים עליה: ספק הזהויות. מפתחים נכנסים ישר ל-sandboxes שלהם עם שם משתמש וסיסמה, אז הזהות בלתי נראית בזמן הבנייה. ואז מגיעים UAT או ייצור, ופתאום יש את הכניסה האחידה (single sign-on) של החברה לעובדים, אולי ספק שני לשותפים, כניסה דרך רשתות חברתיות ללקוחות. הזהות תמיד הייתה חלק מהארכיטקטורה. המפתח פשוט עוד לא ראה אותה.

ספק זהויות (IdP) הוא המערכת שמאמתת משתמש וקובעת את הזהות ש-Salesforce סומכת עליה. הוא שייך למפת המערכות מהיום הראשון, גם אם מגדירים אותו מאוחר יותר בצינור השחרורים, כי מי שיכול להיכנס קובע מי יכול להגיע לנתונים.

יש גם קמט מעשי: את הגדרות הזהות אפשר לפרוס, אבל לא לגמרי. הגדרות כניסה אחידה ב-SAML וספקי אימות הם סוגי Metadata API, אז הם עוברים בצינור (SamlSsoConfig (opens in a new tab)). אבל ה-consumer secrets של ספקי אימות כבר לא מוחזרים בתגובות של Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), ותעודות בדרך כלל שונות בין סביבות. תכננו את החלקים שעוברים ואת החלקים שלא.

Click to enlarge

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

איפה Data 360 יושב?

Data 360 מעלה שאלת שרטוט יפה. אני שם אותו מימין, מתחת ל-ESB או ל-MuleSoft. הסיבה היא החיבורים שלו: משתמשים אף פעם לא מתחברים אליו ישירות, בזמן שהוא מתחבר ישירות להרבה מערכות back-end. אז הוא שייך לצנרת הנתונים, שם הקווים האלה נשארים קצרים, לא בחוץ עם המשתמשים. שרטטו אותו כמו עוד מסך שאנשים נכנסים אליו, ואתם מספרים את הסיפור הלא נכון.

אדמינים וצוותי נתונים כן פותחים את המסכים של Data 360, אבל המסכים האלה נמצאים ב-org, על הליבה. ה-tenant שעושה את העבודה, הנתונים שלו והעיבוד שלו, רץ מחוץ לליבה. בגלל זה אני קורא לו קרוב לליבה (near-core): מנוהל על הליבה, מתארח מחוץ לליבה (יחידה 1 מסבירה את המונחים). השרטוט הולך אחרי ה-tenant: הוא יושב עם הצנרת, עם קו אחד חזרה ל-org שמנהל אותו.

מה שהוא עושה, במילים של Salesforce, כולל zero copy: טכנולוגיית פדרציית נתונים שמאפשרת לארגון לגשת לנתונים ולתשאל אותם בלי להעתיק אותם (Zero Copy (opens in a new tab)). היכולות והמחברים משתנים מהר, אז הפרק על Data 360 מכסה אותם כמו שצריך, במקום להפוך את היחידה הזו לסיור מוצר.

קראו את מפת המערכות כאחריות

כשאתם מסתכלים על מפת מערכות, אל תקראו את הלוגואים; קראו את תחומי האחריות. ה-ERP: מה בבעלותו? מחסן הנתונים: על אילו שאלות הוא עונה? פלטפורמת האינטגרציה: מה היא מזיזה? ה-IdP: את מי הוא מאמת? MDM: באיזו זהות הוא מושל? Data 360: מה הוא מחבר, ולשם מה? Salesforce: על מה היא באמת אחראית? ברגע שאתם יכולים לענות על אלה, לקופסאות יש משמעות, והחצים ביניהן נהיים הרבה יותר מעניינים. בהמשך, נשרטט אותם בכוונה.

מה הארכיטקט מחליט כאן

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

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

להרחבה

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce, Zero Copy (opens in a new tab) (דף מוצר, באנגלית, נבדק ב-2026-10-14).
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (באנגלית).