אסטרטגיית ה-org היא החלטה ברמת מפת המערכות

🌐 זמין גם ב-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)

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

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

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

השאלה שהיחידה הזו עונה עליה: org אחד או כמה, ואיפה הוא רץ?

כשאני מלמד מועמדים ל-CTA, אני אומר להם שההחלטה הגדולה ביותר בתרחיש מגיעה בחמש או עשר הדקות הראשונות: עם כמה orgs של Salesforce יש לנו עסק? org אחד גדול? orgs אזוריים לצפון אמריקה, ל-EMEA ול-APAC? orgs נפרדים ליחידות עסקיות נפרדות? org מיוחד למדינה עם כללים משלה? ומיד קשור לזה: איפה ה-orgs האלה רצים?

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

התחילו מ-org אחד

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

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

לכמה orgs יש מחיר

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

חזרו למפת המערכות מיחידה 4. קופסת Salesforce אחת הופכת לשלוש, וכל חץ משורטט מחדש. ריבוי orgs הוא לא טעות. הוא אף פעם לא בחינם.

חפשו גבולות אמיתיים

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

גיאוגרפיה היא לא אוטומטית אסטרטגיית org

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

האירוח הוא חלק מהשרטוט

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

אבל היו מדויקים. הבחירה איפה org חי היא לא הבטחה שכל בייט של כל שירות נשאר שם. Salesforce אומרת ללקוחות לעבור על תיעוד האמון והציות של Hyperforce, כולל ספקי המשנה הנוספים (sub-processors) של השירותים שהם קונים (אותו מקור). אז אל תגידו “אנחנו על Hyperforce במדינה X, אז הכול נשאר במדינה X.” דעו באילו שירותים אתם באמת משתמשים, ואיזו דרישה אתם מספקים. ושימו לב מה אתם בוחרים: את האזור, לא את הענן שמתחתיו. Hyperforce רץ על AWS, ועל Google Cloud מסוף 2026, ו-Salesforce מחליטה על איזה ספק org יושב; לקוח עם סיבה רגולטורית מתועדת להימנע מאחד מהם פונה לצוות הלקוח שלו (אותו מקור).

אל תשחקו עורכי דין

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

כשאירופה מקבלת org משלה

הנה גבול שאני רואה בתרחישים אמיתיים. לחברה יש נוכחות משמעותית בארה”ב ונוכחות משמעותית באירופה: שני בסיסי לקוחות גדולים, שתי פעילויות מכירה ושירות, ותוכנית פרטיות אירופית שבנויה סביב GDPR. ה-GDPR לא אומר “אתם צריכים org נפרד של Salesforce”. הוא קובע כללים למידע אישי, כולל מתי מותר להעביר אותו אל מחוץ לאיחוד האירופי (GDPR, Chapter V (opens in a new tab)). אבל החברה הזו, יחד עם צוותי הפרטיות והמשפט שלה, מחליטה שהמידע האישי של הלקוחות האירופים שלה צריך לחיות ב-org שמתארח באירופה, מופעל על ידי הצוות האירופי שלה, תחת הממשל האירופי שלה. זו דרישה אמיתית, והיא שלהם, לא שלי.

עכשיו “org גלובלי אחד גדול” הוא כבר לא העדפה. יש גבול על מפת המערכות, Salesforce AMER ו-Salesforce EMEA, ואני חייב לשרטט אותו. וה-org השני אף פעם לא רק עוד קופסה.

Click to enlarge

שני orgs, AMER ו-EMEA. הענבר הוא מה שה-org השני מוסיף: לא עוד קופסה אחת, אלא כל חץ מחדש.

עברו שוב על החצים

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

שלושה מקומות מראים את המחיר הכי מהר:

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

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

אינטגרציה. org אחד: Salesforce, שכבת האינטגרציה, ה-ERP. שלושה orgs: שלושה חיבורים לשכבת האינטגרציה, אולי אחד מהם עם אירוח וקישוריות משלו, חלק מהזרימות משותפות, חלק אזוריות, חלק מהנתונים מותר להעביר וחלק לא. אפילו הרשת יכולה להשתנות: אם הארגון צריך קישוריות פרטית ייעודית ל-Hyperforce (על AWS, Salesforce ממליצה על AWS Direct Connect; אותן שאלות נפוצות של Hyperforce), כל org וכל אירוח על השרטוט הם עוד חיבור שצריך לתכנן. המקום שבו org רץ יכול לשנות את האופן שבו שאר הארגון מגיע אליו.

org אחד או כמה זו החלטה שמקבלים עכשיו, בהתחלה, על מפת המערכות. איך ה-orgs חולקים אחר כך נתונים (Salesforce Connect בין orgs, אינטגרציה ביניהם, Data 360) זו המכניקה, ופרק 14, org אחד או כמה? (coming soon), מכסה אותה.

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

אל תפצלו רק כדי שהקופסאות יהיו קטנות יותר

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

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

הפכו את ההחלטה לגלויה

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

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

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

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

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

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

להרחבה

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), פרק V (העברות של מידע אישי למדינות שלישיות) (באנגלית, נבדק ב-2026-10-14).