استراتيجية الـ 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 في فصل فهم بيانات المؤسسة، الفصل 4 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: ارسم خريطة الأنظمة · التالي: خريطة أنظمة Steve Trucking

السؤال الذي تجيب عنه هذه الوحدة: org واحد أم عدة، وأين يعمل؟

عندما أدرّس المرشحين لشهادة CTA، أقول لهم إن أكبر قرار في السيناريو يأتي في أول خمس أو عشر دقائق: مع كم مؤسسة Salesforce (org) نتعامل؟ org واحد كبير؟ مؤسسات org إقليمية لأمريكا الشمالية وEMEA وAPAC؟ مؤسسات org منفصلة لوحدات أعمال منفصلة؟ org خاص لدولة لها قواعدها الخاصة؟ ومرتبط بذلك مباشرةً: أين تعمل تلك المؤسسات؟

هذه ليست تفاصيل إدارية. إنها تغيّر مكان عيش البيانات، والتكاملات، والتقارير، والهوية، وكيف يصل الناس حول العالم إلى النظام. لهذا أتعامل مع استراتيجية الـ org كقرار على مستوى خريطة الأنظمة، ولهذا أتخذه أولًا.

ابدأ بـ org واحدة

موقفي الأولي بسيط: ابدأ بـ org واحد. ليس لأن الـ org الواحد صحيح دائمًا، بل لأنني أحتاج إلى سبب لإضافة آخر. الـ org الواحد يعطيني مكانًا واحدًا لبيانات العملاء المشتركة، ونموذج أمان واحدًا، ومكانًا واحدًا للنشر، ومجموعة واحدة من التكاملات، ومكانًا واحدًا للتقارير. والـ org الواحد لا يزال قادرًا على دعم وحدات أعمال ودول وعمليات وأنواع سجلات وتطبيقات ونماذج مشاركة وتجارب مختلفة.

لذا لا أضيف org لأن أوروبا تفعل الأشياء بطريقة مختلفة قليلًا، أو لأن قسمًا ما له عملية مبيعات خاصة به، أو لأن وحدات الأعمال لا تحب بعضها. هذه متطلبات، لا حدود org. السؤال هو: ما القوة التي تكفي لتبرير org آخر؟

لتعدد الـ org ثمن

قسّم org واحدًا إلى ثلاثة (أمريكا الشمالية، وأوروبا، وآسيا والمحيط الهادئ) ولن تكون قد رسمت ثلاثة صناديق أنيقة؛ بل خلقت أسئلة جديدة. أين يعيش العميل العالمي؟ ماذا لو كان يعمل في منطقتين: نسختان، وأيهما تملكه؟ كيف يُعدّ أي أحد التقارير على المستوى العالمي؟ هل يتكامل ERP مع الثلاثة، وهل يتلقى مستودع البيانات ثلاث تغذيات، وهل يتصل مزوّد الهوية بالثلاثة؟ هل ننشر الوظائف نفسها ثلاث مرات ونحافظ على تطابق ثلاثة نماذج بيانات؟ إذا احتاج وكيل إلى رؤية عالمية لعميل، فأي org يسأل؟

عُد إلى خريطة الأنظمة من الوحدة 4. صندوق Salesforce الواحد يصبح ثلاثة، وكل سهم يُعاد رسمه. تعدد الـ org ليس خطأ. لكنه ليس مجانيًا أبدًا.

ابحث عن حدود حقيقية

ما الذي يمكن أن يبرر org آخر؟ حدود حقيقية بما يكفي لتشكيل المعمارية: موطن البيانات، والتنظيم، والفصل القانوني، ونماذج تشغيل مختلفة حقًا، واستحواذ لم يندمج بعد، وقيد استضافة إقليمي، وحوكمة مختلفة جدًا، وأحيانًا الحجم أو العزل. القائمة ليست كاملة. الفكرة هي التمييز بين «هذه المجموعات مختلفة» و**«هذه المجموعات تحتاج إلى حدّ معماري»**. والمعيار الثاني أعلى بكثير.

الجغرافيا ليست تلقائيًا استراتيجية org

«نعمل في 30 دولة، إذن نحتاج إلى 30 org.» لا. الجغرافيا تهم عندما تجلب متطلبًا معماريًا. يمكن لشركة أن يكون لديها مستخدمون في أنحاء العالم كله على معمارية مشتركة واحدة. لذا لا أعدّ الدول؛ بل أسأل عمّا يأتي معها. أين يجوز تخزين البيانات؟ وأين يجوز معالجتها؟ هل هناك قيود على نقل البيانات الشخصية عبر الحدود؟ وعود تعاقدية بشأن موطن البيانات؟ هل تحتاج منطقة ما إلى خدمة Salesforce أو استضافة مختلفة؟ «لدينا مكتب في ألمانيا» لا يكفي وحده.

الاستضافة جزء من الرسم

هنا تجعل المنصة الحديثة خريطة الأنظمة أكثر إثارة. Hyperforce يشغّل Salesforce على بنية تحتية سحابية عامة في مناطق حول العالم، مما يمنح العملاء خيارًا وتحكمًا أكبر في مكان إقامة بياناتهم (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). لذا عندما أسمّي صندوقًا «Salesforce، أوروبا»، فقد يكون لذلك الموقع أهمية.

لكن كن دقيقًا. اختيار مكان عيش الـ org ليس وعدًا بأن كل بايت من كل خدمة يبقى هناك. تطلب Salesforce من العملاء مراجعة وثائق الثقة والامتثال الخاصة بـ Hyperforce، بما في ذلك المعالجين الفرعيين الإضافيين للخدمات التي يشترونها (المصدر نفسه). لذا لا تقل «نحن على Hyperforce في الدولة X، إذن كل شيء يبقى في الدولة X». اعرف الخدمات التي تستخدمها فعلًا، وأي متطلب تلبّيه. ولاحظ ما الذي تختاره: المنطقة، لا السحابة التي تحتها. يعمل Hyperforce على AWS، ومع Google Cloud اعتبارًا من أواخر 2026، وSalesforce هي التي تقرر أي مزوّد يقع عليه الـ org؛ والعميل الذي لديه سبب تنظيمي موثّق لتجنّب أحدهما يتحدث إلى فريق حسابه (المصدر نفسه).

لا تلعب دور المحامي

وهنا أيضًا يحتاج المعماريون إلى معرفة دورهم. إذا قال أحدهم: «قانون الخصوصية الأوروبي يتطلب org منفصلًا»، فلن أقبل ذلك دون تمحيص. ولن أنصّب نفسي محاميًا للشركة وأعلن أنه لا يتطلب ذلك. سأسأل: ما المتطلب المحدد الذي نلبّيه؟ مكان تخزين البيانات، أم مكان معالجتها، أم النقل عبر الحدود، أم من يستطيع الوصول إليها لأغراض الدعم، أم عقد، أم سياسة داخلية؟ ثم أعمل مع فرق الخصوصية والأمن والامتثال والشؤون القانونية لتحويل ذلك المتطلب إلى معمارية. لا تختلق متطلبات قانونية، ولا تتجاهلها. ترجِمها.

حين تحصل أوروبا على org خاصة بها

إليك حدًّا أراه في سيناريوهات حقيقية. شركة لها حضور كبير في الولايات المتحدة وحضور كبير في أوروبا: قاعدتا عملاء كبيرتان، وعمليتا مبيعات وخدمة، وبرنامج خصوصية أوروبي مبني حول اللائحة العامة لحماية البيانات (GDPR). اللائحة لا تقول «تحتاج إلى org منفصل في Salesforce». إنها تضع قواعد للبيانات الشخصية، بما في ذلك متى يجوز نقلها خارج الاتحاد الأوروبي (GDPR, Chapter V (opens in a new tab)). لكن هذه الشركة، بالعمل مع فريقي الخصوصية والشؤون القانونية لديها، تقرر أن البيانات الشخصية لعملائها الأوروبيين ينبغي أن تعيش في org مستضاف في أوروبا، يديره فريقها الأوروبي، تحت حوكمتها الأوروبية. هذا متطلب حقيقي، وهو متطلبهم، لا متطلبي.

الآن لم يعد «org عالمي واحد كبير» مجرد تفضيل. هناك حدّ على خريطة الأنظمة، Salesforce AMER وSalesforce EMEA، وعليّ أن أرسمه. والـ org الثاني ليس أبدًا مجرد صندوق إضافي.

Click to enlarge

مؤسستا org، AMER وEMEA. الكهرماني هو ما يضيفه الـ org الثاني: ليس صندوقًا إضافيًا واحدًا، بل كل سهم من جديد.

تتبّع الأسهم من جديد

مع أكثر من org، تتبّع خريطة الأنظمة من جديد. هل يرسل ERP المنتجات إلى كل org؟ هل يرسل كل منها الطلبات عائدةً؟ أين يُدار العملاء كبيانات رئيسية، وهل يجوز لبياناتهم عبور المناطق؟ هل طبقة التكامل عالمية أم إقليمية؟ أي مزوّد هوية يسجّل دخول أي مستخدمين؟ إلى أين تذهب البيانات التحليلية؟

ثلاثة مواضع تُظهر الثمن أسرع من غيرها:

التقارير. يريد الرئيس التنفيذي خط مبيعات (pipeline) عالميًا. في org واحد، هذا تقرير في Salesforce. وفي ثلاثة، إنه مشكلة تقارير على مستوى المؤسسة: نكرّر البيانات، أم نرسلها إلى مستودع البيانات، أم نتّحد؟ ما مدى الحداثة المطلوبة، وهل تعرّف المؤسسات الثلاث «خط المبيعات» بالطريقة نفسها أصلًا؟ مكان التحليلات يتبع مكان البيانات، وإذا قسّمت البيانات التشغيلية عن قصد، فعليك أن تصمّم كيف تجتمع الرؤى من جديد.

البيانات الرئيسية. عميل عالمي يشتري في الولايات المتحدة وألمانيا واليابان. ثلاث مؤسسات org، إذن على الأرجح ثلاثة حسابات. كيف تعرف أنها الشركة نفسها؟ ما المعرّف العالمي، ومن يملكه؟ إذا غيّرت منطقة ما العنوان، فهل ينبغي أن ينتشر التغيير؟ أي السمات عالمية وأيها إقليمية؟ استراتيجية الـ org لا تحل مسألة الهوية؛ بل تغيّر مشكلة الهوية. وهذا هو الفصل 6.

التكامل. org واحد: Salesforce، وطبقة التكامل، وERP. ثلاث مؤسسات org: ثلاثة اتصالات إلى طبقة التكامل، وربما واحد منها باستضافته واتصاله الخاصين، وبعض التدفقات مشتركة، وبعضها إقليمي، وبعض البيانات مسموح لها بالعبور وبعضها لا. حتى الشبكة يمكن أن تتغير: إذا احتاجت المؤسسة إلى اتصال خاص مخصص إلى Hyperforce (على AWS، توصي Salesforce بـ AWS Direct Connect؛ في الأسئلة الشائعة نفسها عن Hyperforce)، فكل org واستضافة على الرسم اتصال آخر يجب التخطيط له. مكان عمل الـ org يمكن أن يغيّر طريقة وصول بقية المؤسسة إليه.

org واحد أم عدة قرار تتخذه الآن، في البداية، على خريطة الأنظمة. أما كيف تتشارك المؤسسات البيانات بعد ذلك (Salesforce Connect عبر المؤسسات، أو التكامل بينها، أو Data 360) فهي الآليات، ويغطيها الفصل 14، org واحد أم عدة؟ (coming soon).

إذا صمّمت نموذج البيانات ومعمارية التكامل بالكامل، ثم سمعت بعد ذلك فقط «بالمناسبة، يجب أن تكون هذه ثلاث مؤسسات org»، فأنت لم تُجرِ تعديلًا صغيرًا. لقد غيّرت المعمارية. لهذا يأتي القرار أولًا.

لا تقسّم لمجرد أن تصغّر الصناديق

الـ org الكبير يبدو معقدًا: وحدات كثيرة، وكائنات، ومستخدمون، وتكاملات. يقول أحدهم: «أليس من الأنظف أن يكون لكل فريق org خاص به؟» قد يصبح الرسم أنظف. أما المؤسسة فقد لا تصبح كذلك. لقد استبدلت بالتعقيد الداخلي تعقيدًا موزعًا: المزامنة، والبيانات المكررة، والهوية عبر المؤسسات، والتقارير العالمية، وعدة مسارات إصدار، وتكاملات وأتمتة مكررة، والحوكمة على كل ذلك. أحيانًا تظل هذه هي المقايضة الصحيحة. لكن المنفصل ليس هو نفسه البسيط.

والـ org الواحد ليس مجانيًا أيضًا. الحوكمة المشتركة تصبح أهم، والفرق يمكن أن تؤثر في بعضها، وحدود الأمان تحتاج إلى تصميم دقيق، ونموذج البيانات عليه أن يخدم مجموعات كثيرة، والإصدارات تحتاج إلى تنسيق، والقواعد الإقليمية قد تقيّد الجميع. لذا ليس الأمر «Steve يقول org واحد دائمًا». ميلي الأولي هو org واحد؛ ثم أبحث عن المتطلب القوي بما يكفي ليزحزحني عنه.

اجعل القرار مرئيًا

إذا كانت استراتيجية الـ org مهمة، فلا ترسم سحابة Salesforce عامة. ارسم مؤسسات الـ org وسمّها (AMER، وEMEA، أو أيًا كان الواقع)، ودوّن متطلب الاستضافة أو موطن البيانات وراء كل منها، وتتبّع الاتصالات. ينبغي لمعماري آخر أن يستطيع رؤية سبب وجود كل حدّ. إذا لم أستطع شرح سبب وجود ثلاثة صناديق Salesforce، فلم أُكمل القرار بعد.

تشغّل Steve Trucking org واحدًا، في الولايات المتحدة، ولا شيء في موجزها يستدعي آخر. لكن أبقِ هذه الوحدة في ذهنك للمشروع الختامي: استحواذ يصل ومعه org خاص به هو بالضبط نوع الحدّ الذي يختبر هذه الأسئلة.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. يستطيع وكيل أن يجعل حدّ الـ org غير مرئي للمستخدم. لكن تحت السطح، لا يزال على المعمارية أن تقرر أي org أو نظام يجوز للوكيل أن يسأله، وأي البيانات يجوز لها عبور المناطق، وأي إجابة هي المرجعية المعتمدة. يستطيع الذكاء الاصطناعي إخفاء التعقيد في التجربة؛ لكنه لا يزيل الحوكمة ولا الحدّ.

ما الذي يقرره المعماري هنا

• هل هناك سبب معماري حقيقي لأكثر من org، بدلًا من حل الاختلافات داخل org واحد.
• أين يعمل كل org، وأي متطلب يتعلق بموطن البيانات أو التنظيم أو التعاقد أو الأعمال يضعه هناك.
• أي البيانات يجوز لها عبور حدود الـ org والمناطق، وأين تكون البيانات الرئيسية مرجعية معتمدة، وكيف تعمل الهوية العالمية.
• كيف يتغير التكامل والهوية والتحليلات والتقارير عندما يصبح صندوق 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)، الفصل الخامس (نقل البيانات الشخصية إلى دول ثالثة) (بالإنجليزية، تم التحقق في 2026-10-14).