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 في فصل فهم بيانات المؤسسة، الفصل 4 من دورة Data Architect. كل وحدة قائمة بذاتها. التالي: أنواع بيانات المؤسسة
السؤال الذي تجيب عنه هذه الوحدة: لماذا يرسم معماري البيانات ما يحيط بمؤسسة Salesforce (org) قبل أن يصمّم الـ org؟
عندما أدرّس المرشحين لشهادة CTA، يكون الواجب بعد اليوم الأول هو نفسه دائمًا. اقرأ السيناريو. ابدأ خريطة الأنظمة من لوحة فارغة. وبعد ذلك فقط جرّب رسم نموذج البيانات. لا الكائنات، ولا تفاصيل التكاملات: خريطة الأنظمة. أريد أن أرى ما يحيط بـ Salesforce قبل أن نقرر ما الذي ينتمي إلى داخله.
هذا تغيير في المنظور لكثير من محترفي Salesforce. إذا أمضيت مسيرتك المهنية مسؤولًا عن النظام (admin) أو مطوّرًا، فإن Salesforce هو مركز عالمك بطبيعة الحال. تفتح Setup، وتُنشئ الكائنات، وتبني التدفقات (flows)، وتكتب Apex، وتدمج الأنظمة الأخرى داخل Salesforce. يبدو أن كل شيء يبدأ من الـ org. أما المعماري فعليه أن يُرجع الكاميرا إلى الخلف، لأن Salesforce في المؤسسة نظام واحد بين أنظمة كثيرة، وكثيرًا ما لا يكون هو النظام الذي يملك البيانات.
ارسم خريطة الأنظمة أولًا
Section titled “ارسم خريطة الأنظمة أولًا ”بنى الفصل 2 النموذج المنطقي، وسأل الفصل 3 كيف يعيش على Salesforce. والآن سأجعل المشكلة أكبر. قبل أن أقرر ما الذي ينبغي أن يملكه Salesforce، أريد أن أفهم المؤسسة من حوله. ما الأنظمة الموجودة بالفعل؟ أين يُنشأ العملاء، وتُعرَّف المنتجات، وتبدأ الطلبات، وتُصدر الفواتير؟ أين تعيش الهوية؟ أين تجري التحليلات، وأين تُحفظ المستندات، وأين يقبع التاريخ؟ ما الأنظمة التي تحتاج إلى بيانات Salesforce، وعلى أي الأنظمة يعتمد Salesforce؟
هذه الأسئلة تغيّر المعمارية. لذا أبدأ من لوحة فارغة، وأضع Salesforce في الوسط، وأرسم كل ما حوله. تُظهر الوحدة 4 بالضبط كيف أرتّب ذلك. أما الآن، فالدرس ببساطة: لا تصمّم الـ org قبل أن تفهم العالم الذي عليه أن يعيش فيه.
Salesforce ليس غالبًا نظام السجل
Section titled “Salesforce ليس غالبًا نظام السجل ”خذ مؤسسة شائعة جدًا: Salesforce مع نظام ERP، أي نظام تخطيط موارد المؤسسة مثل SAP أو Oracle، يدير المالية والمنتجات والمخزون والمشتريات وتنفيذ الطلبات. والآن اطرح سؤالًا بسيطًا: أين يعيش العميل؟
قد يكون في Salesforce، أو في ERP، أو في كليهما، وهنا يصبح الأمر مثيرًا. قد يعمل مندوبو المبيعات على العملاء المحتملين كحسابات في Salesforce، بينما يُصدر ERP رقم العميل الرسمي بمجرد أن يصبحوا عملاء يدفعون. المنتجات والأسعار؟ على الأرجح ERP. المخزون؟ تقريبًا لا يكون في Salesforce أبدًا. قد تُلتقط الطلبات في Salesforce وتُنفَّذ في ERP؛ والفواتير تأتي من ERP؛ والخدمة تعيش في Salesforce؛ والتحليلات مقسّمة بين تقارير Salesforce ومستودع بيانات. وفجأة لم يعد نموذج بيانات Salesforce الجميل لدينا هو نموذج بيانات المؤسسة. إنه جزء واحد منه.
التكامل الذي أراه مرارًا وتكرارًا
Section titled “التكامل الذي أراه مرارًا وتكرارًا ”أكثر تكامل شيوعًا أراه يسير هكذا: العملاء والمنتجات والأسعار تتدفق إلى Salesforce من ERP، والطلبات تتدفق خارجًا. ضع مكانه SAP أو Oracle أو أي ERP آخر؛ الشكل هو نفسه. ERP يملك السجل الذهبي للعميل والمنتج، لذا تأتي تلك التدفقات من اليمين، إلى Salesforce. والمبيعات تُغلق الصفقة في Salesforce، لذا يبدأ الطلب هناك ويعود إلى ERP ليُنفَّذ ويُفوتَر ويُقيَّد محاسبيًا.
هذه التدفقات ليست مجرد تكاملات. إنها تخبرني أين تعتقد المؤسسة أن الحقيقة تعيش.
الأسهم أحادية الاتجاه تقلقني
Section titled “الأسهم أحادية الاتجاه تقلقني ”كلما رأيت تكاملًا ليس فيه إلا تدفق واحد، بدأ القلق يساورني. على المستوى العام، يرسم أحدهم سهمًا واحدًا: الطلبات من Salesforce إلى ERP. حسنًا. والآن انظر أعمق. كيف أستطيع إرسال طلب إلى ERP إذا كنت لا أعرف عملاءه أو منتجاته أو أسعاره؟ يجب أن يرتبط الطلب بعميل يعرفه ERP بالفعل، ويجب أن يكون كل سطر SKU يبيعه ERP بالفعل. لا أستطيع إرسال بند لمنتج غير موجود على الطرف الآخر. لذا قبل أن يعمل سهم الطلب ذاك، يجب أن توجد تدفقات عكسية، تسير في الاتجاه الآخر.
هذا هو السؤال الذي أطرحه على كل سهم: على ماذا يعتمد هذا التدفق؟ السهم العام الذي تراه يحتاج عادةً إلى تدفقات عكسية لم ترسمها بعد.
انظر أعمق بعد، وستجد رحلة العودة. يرسل Salesforce طلبًا. ثم ماذا؟ هل قُبل أم رُفض؟ هل شُحن، أو شُحن جزئيًا، أو أُلغي؟ هل صدرت فاتورته؟ هل يحتاج أحد في Salesforce إلى المعرفة؟ ربما لا. لكن كان على أحدهم أن يسأل. إن لم يعد شيء، فلا بأس. أخبرني لماذا.
المؤسسة لم تصل دفعة واحدة
Section titled “المؤسسة لم تصل دفعة واحدة ”تصبح خرائط الأنظمة معقّدة جزئيًا لأن أحدًا لم يبنِها دفعة واحدة. جاءت البيانات في موجات. الملفات أولًا: سجلات بتنسيق ثابت، ثم ملفات محدَّدة بفواصل مثل CSV. ثم قواعد البيانات العلائقية للبيانات التشغيلية. ثم مستودعات البيانات لجمعها معًا من أجل التحليل. ثم قواعد بيانات NoSQL للمستندات وأزواج المفتاح والقيمة والرسوم البيانية التي لا تستقر بسهولة في الجداول. ثم بحيرات البيانات لكميات هائلة من البيانات الخام وشبه المهيكلة، والـ Lakehouses التي تجمع بين الاثنين. تدفقات الأحداث، مثل Kafka أو ناقل الأحداث في Salesforce، تنقل البيانات لحظة حدوثها بدلًا من الدفعات الليلية. والآن الاتحاد (federation)، حيث لا يلزم نسخ البيانات إلى مكان واحد قبل أن تتمكن منصة أخرى من استخدامها.
التقنية ليست الفكرة بعد. الفكرة هي: الموجة الجديدة نادرًا ما تجعل القديمة تختفي. ادخل مؤسسة كبيرة وستجدها كلها في آن واحد: قواعد بيانات علائقية، وERP، وSalesforce، ومستودع بيانات، وبحيرة، وملفات تُودَع عبر SFTP، وواجهات API، وتدفقات أحداث، وجدول البيانات الذي لا يزال أحدهم يرسله بالبريد الإلكتروني كل جمعة، والنظام الوحيد الذي يخشى الجميع لمسه لأن الشخص الذي بناه تقاعد قبل ست سنوات. هذه هي المؤسسة التي تصمّم معماريتها، لا تلك التي في كتيّب المنتج.
أنظمة مختلفة لأسباب مختلفة
Section titled “أنظمة مختلفة لأسباب مختلفة ”ولهذا أيضًا لا أبدأ أبدًا بسؤال «كيف ننقل كل البيانات إلى Salesforce؟» لماذا أريدها كلها هناك؟ قد يكون Salesforce أفضل مكان لموظفي المبيعات والخدمة للعمل مع العملاء. لكن ذلك لا يجعله نظام المالية، ولا مستودع بيانات المؤسسة، ولا مخزن بيانات القياس عن بُعد، ولا أرشيف المستندات، ولا موطن كل نقرة وقراءة GPS ومعاملة تاريخية أنتجتها الشركة على الإطلاق.
سأل الفصل 3 أين ينبغي أن تعيش هذه البيانات؟ لـ org واحد. وعلى مستوى المؤسسة، يكبر السؤال نفسه: أحيانًا يملك Salesforce البيانات، وأحيانًا يحتفظ بنسخة منها، وأحيانًا بمرجع إليها فقط، وأحيانًا لا ينبغي أن تكون لديه أصلًا.
النواة، وخارج النواة، وHyperforce
Section titled “النواة، وخارج النواة، و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% على النواة. التدفقات والـ triggers تعيش في النواة، لذا فالمنتج المبني هناك يحصل معه على البيانات الوصفية للمنصة وتخصيصاتها وأتمتتها. ومنذ ذلك الحين أفسح منتج التسعير ذاك المجال لـ Revenue Cloud، لكن الدرس بقي. ثم هناك القريب من النواة (near-core)، وData 360 هو المثال الذي أستخدمه. Data 360 ليس على النواة. المستأجر الخاص به خارج النواة: البيانات والآليات التي تعالجها تعمل في الـ Lakehouse الخاص به، بجوار قاعدة البيانات العلائقية للـ org لا داخلها (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). لكن الشاشات التي تستخدمها لإعداده والتحكم فيه تُعرض على النواة، في الـ org. لذا فأدق طريقة أستطيع أن أصوغها بها: يُدار على النواة، ويُستضاف خارجها. لا شيء من البيانات أو المعالجة يعمل فعليًا في Core؛ واجهة المستخدم على Core هي التي تتحكم في المستأجر خارج النواة. ثم هناك بالطبع كل ما هو خارج النواة لأنه ليس Salesforce أصلًا.
لا يهمني كثيرًا حفظ أي منتج يعمل أين هذا العام، لأن ذلك يتغير، بقدر ما تهمني العادة: الحدّ يمكن أن يؤثر في حركة البيانات، وزمن الاستجابة، والهوية، والتكامل، وموطن البيانات. لذا لا تفترض أن بيانات منتج ما تقبع بجوار سجلات الحساب لديك لمجرد أن المنتج يحمل اسم Salesforce. انظر إلى المعمارية الفعلية.
ثم هناك Hyperforce: بنية Salesforce التحتية المبنية للسحابة العامة والمعرَّفة ككود، بدلًا من مراكز البيانات التقليدية التي تملكها، مما يمنح العملاء خيارًا أوسع في مكان إقامة بياناتهم (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). هذا مهم، وستعود إليه الوحدة 5. لكن معمارية البنية التحتية ليست معمارية بيانات المؤسسة. نقل org إلى السحابة العامة لا يخبرك من يملك العميل، ولا أين يعيش المخزون، ولا أين تجري التحليلات، ولا أي البيانات يجوز لها عبور الحدود. يمكن لـ Hyperforce أن يشكّل بعض هذه القرارات، خصوصًا موطن البيانات. لكنه لا يغني عن معرفة خريطة الأنظمة.
خريطة الأنظمة قبل الصندوق
Section titled “خريطة الأنظمة قبل الصندوق ”إذن هذه هي العادة. يسلّمك أحدهم سيناريو. لا تبدأ ببناء حل Salesforce. اعثر أولًا على الأنظمة: ERP، ومزوّد الهوية، ومستودع البيانات، ومنصة التكامل، وأنظمة الشركاء، وقنوات العملاء، ومخازن المستندات. ثم اعثر على البيانات المتنقلة بينها: العملاء، والمنتجات، والطلبات، والفواتير، والمستندات، والأحداث، والهويات. ثم اسأل من يملك كلًّا منها. وبعد ذلك فقط قرّر ما الذي ينتمي إلى Salesforce. وإلا فأنت تصمّم صندوقًا دون أن تعرف بماذا يتصل.
الخطوة 1 من 3: الـ org الذي نصمّمه، وحده. من هنا يبدو كأنه العالم كله.
الخطوة 2 من 3: نبتعد قليلًا. Salesforce نظام واحد بين أنظمة كثيرة (الوحدة 4 تعلّم هذا التخطيط).
الخطوة 3 من 3: الأسهم الأولى. العملاء والمنتجات والأسعار داخلة من ERP، والطلبات خارجة: إنها تقول أين تعتقد المؤسسة أن الحقيقة تعيش.
خريطة الأنظمة تغيّر نموذج البيانات
Section titled “خريطة الأنظمة تغيّر نموذج البيانات ”لهذا يهم الأمر معماري البيانات. يقول الفصل 2 إن العميل كيان مهم. حسنًا. ثم تقول خريطة الأنظمة إن ERP هو النظام المرجعي المعتمد للعميل. هذا يغيّر النموذج المادي. قد يظل Salesforce يحتفظ بحساب محلي، لأن الناس يستخدمونه كل يوم، لكننا الآن نحتاج إلى معرّف ERP كـ External ID؛ ونحتاج إلى معرفة الحقول التي يجوز لـ Salesforce تغييرها (أُعلّم حقول ERP ببادئة erp_، كما سنرى في الوحدة 3)؛ ومدى سرعة وصول تغييرات ERP؛ وهل يستطيع Salesforce إنشاء عميل قبل أن يعرف به ERP؛ وماذا يحدث عندما يختلف الاثنان. هذه ليست أسئلة تكامل تُترك لوقت لاحق. إنها أسئلة معمارية بيانات، وخريطة الأنظمة هي التي كشفتها.
إليك كيف يلدغ أحدها. مندوب مبيعات يحوّل عميلًا محتملًا لشركة مشروبات كبيرة، ويُنشئ الحساب، ويفوز بالصفقة، ويذهب العميل إلى ERP. لكن الشركة تتعامل مع شركة المشروبات تلك منذ سنوات، وERP يعرفها بالفعل. والآن هناك اثنان. هل كان ينبغي أن يتمكن مندوب المبيعات من إنشاء ذلك الحساب أصلًا؟ يعود الفصلان 5 و6 إلى ذلك؛ وخريطة الأنظمة هي المكان الذي تراه فيه قادمًا.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- ما الأنظمة التي تحيط بـ Salesforce، وما الدور الذي يؤديه كل منها.
- أي نظام يملك كل نوع مهم من البيانات، قبل تقرير مقدار ما يحتفظ به Salesforce منها.
- ما الذي يتدفق إلى Salesforce، وما الذي يتدفق منه، وما الذي يعود.
- أي البيانات ينبغي لـ Salesforce أن يملكها، أو ينسخها، أو يشير إليها، أو يتّحد معها (federate)، أو يؤرشفها، أو يتركها وشأنها.
- أي حدود المنصة والبنية التحتية مهمة، بدلًا من افتراض أن كل ما يحمل علامة Salesforce يعيش في مكان واحد.
الانتقال من مطوّر إلى معماري لا يعني غالبًا تعلّم ميزة أخرى. إنه تعلّم متى تتوقف عن النظر إلى Salesforce: أرجِع الكاميرا إلى الخلف، واتبع البيانات، واعثر على من يملك الحقيقة، ثم عُد وقرّر ما ينبغي أن تكون عليه مهمة Salesforce.
للاستزادة
Section titled “للاستزادة ”- 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).