Salesforce Org אחד או Multi-Org? שיקולים לארגון רב-יחידתי

שלוש השאלות שקובעות אם צריך Multi-Org

הטעות הנפוצה היא לגשת לשאלה "Org אחד או כמה?" כשאלה טכנית של קיבולת או ביצועים. ברוב המקרים המענה הטכני קיים בתוך Org יחיד: Record Types, Profiles, Permission Sets ו-Sharing Rules מספיקים כדי להפריד בין יחידות עסקיות בלי לפצל את הסביבה עצמה. Salesforce תומך בעשרות אלפי משתמשים ומיליוני רשומות בתוך Org בודד — קיבולת כמעט לעולם אינה הסיבה האמיתית לפיצול.

השאלה שבאמת קובעת היא שאלה של עצמאות ארגונית, ומתפרקת לשלוש בדיקות:

1. עצמאות רגולטורית ממשית — האם יש דרישה חוקית או חוזית להפרדה פיזית של נתונים (למשל ישות משפטית נפרדת עם רגולציה מקומית שאוסרת שיתוף תשתית), להבדיל מהפרדה לוגית שאפשר להשיג ב-Sharing Model.
2. קצב שינוי בלתי תואם — האם יחידה עסקית אחת זקוקה למחזורי Release תכופים ומהירים בעוד אחרת דורשת יציבות מרבית וביקורת מחמירה, כך שכל Release משותף הופך לנקודת חיכוך מתמדת בין הצוותים.
3. מודל נתונים שמתנגש במקום, לא רק שונה — כאשר לאותה ישות (למשל "לקוח" או "הזמנה") יש הגדרת שדה חובה, זרימת אישור או מבנה יחסים שסותר פיזית בין היחידות, ולא רק שונה בתצוגה.

אם אף אחת מהשלוש לא מתקיימת באופן חד, הפתרון הנכון הוא Org אחד עם הפרדה לוגית. פיצול "ליתר ביטחון" יוצר עלות תפעולית קבועה — ניהול משתמשים כפול, רישוי כפול, ותחזוקת אינטגרציה כפולה — תמורת בעיה שאפשר היה לפתור בקונפיגורציה.

מטריצת החלטה: Org אחד מול כמה Orgs

השורה התחתונה: ברירת המחדל צריכה להיות Org אחד, ופיצול נבחר רק כשיש תשובה חיובית וברורה לאחת משלוש השאלות שלמעלה, לא כתגובה לחיכוך ארגוני זמני.

מה קורה בפועל כשמפצלים בלי סיבה מספקת

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

לכן אחד העקרונות המנחים בארכיטקטורת Salesforce הוא לבחון תחילה אם הצורך הארגוני ניתן למימוש בהרשאות ו-Sharing Rules בתוך Org אחד, ורק אחר כך לבחון פיצול.

מסלול מדורג למי שכבר נדרש לפצל

כאשר אחת משלוש הבדיקות אכן מתקיימת, הפיצול צריך להתבצע לפי סדר שמצמצם סיכון:

1. הגדירו מפתח זיהוי גלובלי לפני הפיצול

לפני יצירת Org שני, קובעים שדה מזהה אחיד (מספר ח.פ., Customer ID גלובלי או קוד דומה) שיאפשר בעתיד להתאים רשומות בין הסביבות. בלי זה, כל ניסיון עתידי לאחד תמונת לקוח יתבסס על התאמת שם וכתובת, שמייצרת שגיאות בהיקף גדול.

2. בחרו דפוס אינטגרציה לפי כיוון וקצב הנתונים

אם מדובר בעדכון תקופתי לצורכי דיווח בלבד, מספיק ETL מתוזמן. אם נדרשת ראייה בזמן אמת (למשל בדיקת אשראי חוצה-יחידות), נדרש API סינכרוני עם טיפול בכשל וב-Retry. הבחירה בדפוס הלא-מתאים היא הגורם המרכזי לכך שאינטגרציות Cross-Org נשברות תחת עומס — הרחבה בנושא בדפוסי אינטגרציה Salesforce.

3. תכננו זהות והרשאות גישה מראש

משתמשים שעובדים בשני Orgs (למשל מנהלי חשבונות גלובליים) דורשים פתרון Identity שמנוהל פעם אחת ולא שני משתמשים נפרדים עם שני Password. תכנון SSO בין Orgs מונע מצב שבו כל שינוי בהרשאות משתמש מבוצע ידנית בשתי סביבות — הנושא מפורט בארכיטקטורת SSO וזהות ב-Salesforce.

4. בדקו את גבולות ה-API לפני שהאינטגרציה חיה בייצור

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

5. הגדירו Owner ותהליך Governance משותף לשני ה-Orgs

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

תרחיש להמחשה: קבוצת ביטוח עם שתי חטיבות

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

הצעה ראשונית הייתה לפצל ל-Org נפרד לכל חטיבה, אבל בבדיקה מול שלוש השאלות התברר שרק הקצב הרגולטורי (בדיקה 2) מתקיים באמת — מודל הלקוח והמוצר לא התנגשו (בדיקה 3 שלילית), ולא הייתה דרישת הפרדה פיזית של נתונים (בדיקה 1 שלילית). הפתרון שנבחר היה Org אחד עם שני "מסלולי שחרור" נפרדים בתוך אותה סביבה — Sandbox ייעודי ותהליך אישור נפרד לחטיבת ביטוח החיים, תוך שימוש במודל נתונים משותף ל-Customer 360 אחד. הפיצול המלא נחסך, וכך גם עלות התחזוקה הכפולה שהיה נדרש לשאת לאורך שנים.

סיכונים נפוצים ואיך מונעים אותם

• פיצול "זמני" שנשאר לצמיתות — Sandbox שהופך לסביבת ייצור בלי שעבר בקרת אבטחה. מונעים בכך שכל Org עם נתוני לקוח אמיתיים עובר תהליך אישור Governance רשמי, ללא יוצא מן הכלל.
• רשומות כפולות ללא מפתח משותף — נוצר כאשר הפיצול קורה לפני שהוגדר מזהה גלובלי. מונעים בקביעת השדה המשותף כתנאי מקדים לפיצול, לא כשלב מאוחר.
• מכסת API שמתמלאת בשעת עומס — קורה כשהאינטגרציה בין Orgs מתוכננת לפי נפח ממוצע ולא נפח שיא. מונעים בבדיקת עומס לפני העלייה לייצור ובניית מנגנון Backoff.
• סחיפת סטנדרטים בין Orgs — קורה כשאין Owner יחיד לארכיטקטורה המשותפת. מונעים בהגדרת ועדת Governance קטנה שמאשרת שינויי מבנה נתונים בשני הצדדים.
• דיווח ניהולי לא אמין — קורה כשמנסים לחשב KPI חוצה-ארגון ישירות מתוך Salesforce בלי שכבת איחוד. מונעים בהקמת שכבת BI ייעודית מהיום הראשון של הפיצול, לא כפרויקט תיקון מאוחר.

סיכום

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