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)

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

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

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

השאלה שהיחידה הזו עונה עליה: למה ארכיטקט נתונים משרטט את מה שמקיף את ה-org לפני שהוא מתכנן את ה-org?

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

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

שרטטו קודם את מפת המערכות

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

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

Salesforce היא לעיתים קרובות לא מערכת הרשומה

קחו ארגון נפוץ מאוד: Salesforce ועוד ERP, מערכת לתכנון משאבי הארגון כמו SAP או Oracle, שמריצה כספים, מוצרים, מלאי, רכש ואספקה. עכשיו שאלו שאלה פשוטה: איפה הלקוח חי?

זה יכול להיות Salesforce, ה-ERP, או שניהם, וכאן זה נהיה מעניין. אנשי מכירות עשויים לעבוד על לקוחות פוטנציאליים כחשבונות (Accounts) ב-Salesforce, בזמן שה-ERP מנפיק את מספר הלקוח הרשמי ברגע שהם הופכים ללקוחות משלמים. מוצרים ומחירים? כנראה ה-ERP. מלאי? כמעט אף פעם לא Salesforce. הזמנות עשויות להיקלט ב-Salesforce ולהיות מסופקות ב-ERP; חשבוניות מגיעות מה-ERP; השירות חי ב-Salesforce; האנליטיקה מתחלקת בין דוחות Salesforce לבין מחסן נתונים. פתאום מודל הנתונים היפה שלנו ב-Salesforce הוא לא מודל הנתונים של הארגון. הוא חלק אחד ממנו.

האינטגרציה שאני רואה שוב ושוב

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

הזרימות האלה הן לא סתם אינטגרציות. הן אומרות לי איפה הארגון מאמין שהאמת חיה.

חצים חד-כיווניים מלחיצים אותי

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

זו השאלה שאני שואל על כל חץ: במה הזרימה הזו תלויה? החץ ברמה הגבוהה שאתם רואים צריך בדרך כלל זרימות חזרה שעוד לא שרטטתם.

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

הארגון לא הגיע בבת אחת

מפות מערכות נהיות מסובכות בין השאר כי אף אחד לא בנה אותן בבת אחת. הנתונים הגיעו בגלים. קודם קבצים: רשומות בפורמט קבוע, ואחר כך קבצים מופרדים כמו CSV. אחר כך מסדי נתונים רלציוניים לנתונים תפעוליים. אחר כך מחסני נתונים כדי לאחד אותם לניתוח. אחר כך מסדי נתונים NoSQL למסמכים, לזוגות מפתח-ערך ולגרפים שלא יושבים יפה בטבלאות. אחר כך אגמי נתונים לכמויות עצומות של נתונים גולמיים וחצי-מובנים, ו-lakehouses שמשלבים את השניים. זרמי אירועים, כמו Kafka או ה-event bus של Salesforce, מזיזים נתונים ברגע שהם קורים במקום באצוות ליליות. ועכשיו פדרציה, שבה לא צריך להעתיק נתונים למקום אחד לפני שפלטפורמה אחרת יכולה להשתמש בהם.

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

מערכות שונות קיימות מסיבות שונות

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

פרק 3 שאל איפה הנתונים האלה צריכים לחיות? עבור org אחד. ברמת הארגון, אותה שאלה גדלה: לפעמים Salesforce היא הבעלים של הנתונים, לפעמים היא שומרת עותק, לפעמים רק הפניה, ולפעמים הם בכלל לא צריכים להיות אצלה.

ליבה, מחוץ לליבה ו-Hyperforce

יש עוד גבול שצריך להבין: אפילו “Salesforce” היא לא סביבת ריצה אחת ומסד נתונים אחד. בפרק 3, על הליבה (on core) התייחס למקום שבו הנתונים יושבים: על השולחן שלכם, באובייקטים של ה-org עצמו. כאן אותן מילים מתארות איפה מוצר רץ. תשמעו ארכיטקטים משתמשים בשתי המשמעויות.

היסטורית, סביבת הריצה Core אירחה את רוב הפלטפורמה. היום Salesforce מתארת פלטפורמה של מאות שירותים עצמאיים מונעי מטא-דאטה, כש-Core נשארת מערכת הרשומה היחידה למטא-דאטה של האפליקציות (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). לכן תשמעו ארכיטקטים אומרים שיכולת מסוימת רצה על הליבה או מחוץ לליבה.

זה היה חשוב הרבה לפני שהפלטפורמה התפצלה לשירותים. כשאני שואל כיתה למה Salesforce קנתה את SteelBrick לתמחור והצעות מחיר ולא את Apttus, התשובה שאני מחפש פשוטה: SteelBrick נבנתה 100% על הליבה. Flows ו-triggers חיים בליבה, אז מוצר שנבנה שם מקבל איתו את המטא-דאטה, ההתאמות האישיות והאוטומציה של הפלטפורמה. מוצר הצעות המחיר הזה פינה מאז את מקומו ל-Revenue Cloud, אבל הלקח לא. ואז יש קרוב לליבה (near-core), ו-Data 360 הוא הדוגמה שאני משתמש בה. Data 360 הוא לא ליבה. ה-tenant שלו מחוץ לליבה: הנתונים והמנגנונים שמעבדים אותם רצים ב-lakehouse משלו, לצד מסד הנתונים הרלציוני של ה-org ולא בתוכו (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). אבל המסכים שבהם אתם מגדירים אותו ושולטים בו מוצגים על הליבה, ב-org. אז הניסוח הכי מדויק שאני יכול לתת: מנוהל על הליבה, מתארח מחוץ לליבה. שום חלק מהנתונים או מהעיבוד לא רץ בפועל ב-Core; הממשק ב-Core שולט ב-tenant שמחוץ לליבה. ואז, כמובן, יש את כל מה שמחוץ לליבה כי הוא בכלל לא Salesforce.

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

ואז יש את Hyperforce: התשתית של Salesforce שנבנתה לענן הציבורי ומוגדרת כקוד, במקום מרכזי הנתונים המסורתיים שלה עצמה, ונותנת ללקוחות יותר בחירה לגבי המקום שבו הנתונים שלהם נמצאים (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). זה חשוב, ויחידה 5 חוזרת לזה. אבל ארכיטקטורת תשתית היא לא ארכיטקטורת נתונים ארגונית. העברת org לענן הציבורי לא אומרת לכם מי הבעלים של הלקוח, איפה המלאי חי, איפה האנליטיקה רצה, או אילו נתונים מותר להעביר מעבר לגבול. Hyperforce יכול לעצב חלק מההחלטות האלה, במיוחד את מקום האחסון. הוא לא מחליף את ההיכרות עם מפת המערכות.

מפת המערכות באה לפני הקופסה

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

Click to enlarge

שלב 1 מתוך 3: ה-org שאנחנו מתכננים, לבדו. מכאן הוא נראה כמו העולם כולו.

Click to enlarge

שלב 2 מתוך 3: מתרחקים. Salesforce היא מערכת אחת מתוך רבות (מודול 4 מלמד את הפריסה הזאת).

Click to enlarge

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

מפת המערכות משנה את מודל הנתונים

זו הסיבה שזה חשוב לארכיטקט נתונים. פרק 2 אומר שהלקוח הוא ישות חשובה. בסדר. ואז מפת המערכות אומרת שה-ERP הוא המערכת הסמכותית ללקוח. זה משנה את המודל הפיזי. Salesforce עדיין עשויה לשמור חשבון מקומי, כי אנשים משתמשים בו כל יום, אבל עכשיו אנחנו צריכים את המזהה של ה-ERP כ-External ID; אנחנו צריכים לדעת אילו שדות Salesforce רשאית לשנות (אני מסמן את השדות של ה-ERP בקידומת erp_, כמו שנראה ביחידה 3); כמה מהר מגיעים שינויים מה-ERP; האם Salesforce יכולה ליצור לקוח לפני שה-ERP יודע עליו; ומה קורה כששתיהן לא מסכימות. אלה לא שאלות אינטגרציה לאחר כך. הן שאלות של ארכיטקטורת נתונים, ומפת המערכות חשפה אותן.

הנה איך אחת מהן נושכת. איש מכירות ממיר ליד של חברת משקאות גדולה, יוצר את החשבון, סוגר את העסקה, והלקוח עובר ל-ERP. אבל החברה עשתה עסקים עם חברת המשקאות הזו כבר שנים, וב-ERP היא כבר קיימת. עכשיו יש שתיים. האם איש המכירות היה צריך בכלל להיות מסוגל ליצור את החשבון הזה? פרקים 5 ו-6 חוזרים לזה; מפת המערכות היא המקום שבו רואים את זה מגיע.

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

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

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

להרחבה

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).