التسلسلات الهرمية والبيانات ثنائية الاتجاه

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

السؤال الذي تجيب عنه هذه الوحدة: كيف تدير بيانات يصونها أكثر من نظام؟

المعمارية السهلة: ERP يملك العميل، وSalesforce يحصل على نسخة، وانتهى الأمر. المؤسسات الحقيقية ليست بهذه النظافة. ERP يملك العميل القانوني وSalesforce يملك علاقة المبيعات؛ وقسم يعيش في SAP، وقسم مستحوَذ عليه في ERP آخر؛ والعملاء المحتملون لا يوجدون إلا في Salesforce. ثم يريد أحدهم أن يحدّث مستخدمو Salesforce حقلًا يتحكم فيه ERP، فتبدأ الأسهم بالإشارة في الاتجاهين. وكما أقول حين أدرّس هذا: «أصعب شيء هو التكاملات ثنائية الاتجاه.» ليس لأن إرسال البيانات في الاتجاهين صعب تقنيًا، بل لأنه حين يشارك النظامان في التغيير، عليك أن تكون دقيقًا للغاية بشأن المرجعية.

البيانات ثنائية الاتجاه لا تعني مرجعيتين

ERP يملك عنوان الفوترة، المنسوخ إلى Salesforce. يعرف مندوب من العميل أنه تغيّر، وتريد الجهة المعنية أن يحدّثه دون مغادرة Salesforce. معقول. الآن تتدفق البيانات ERP → Salesforce وSalesforce → ERP. هل صار Salesforce شريكًا في ملكية عنوان الفوترة؟ لا. اتجاه التكامل لا يحدد المرجعية. المندوب لا يغيّر نسخة Salesforce. معماريًا، هو يطلب تغيير القيمة المعتمدة. أنت لا تغيّر حقل ERP؛ بل تطلب تغييره. Salesforce هو الواجهة؛ وERP لا يزال المصدر الرئيسي.

وهذا يغيّر التصميم. لو كان Salesforce يملك الحقل، لكان الأمر حفظًا وانتهى. أما إن كان ERP يملكه، فـ «الحفظ» يعني أن يرسل Salesforce العنوان المقترح، فيتحقق منه ERP ويقبله، ويحدّث مصدره الرئيسي، ويعيد القيمة المعتمدة. عندها فقط تكون القيمة المحكومة قد تغيّرت: طلب ← تحقق ← قبول ← نشر، لا «حدّث النظامين وتمنَّ أن يبقيا متزامنين».

Click to enlarge

التكامل ثنائي الاتجاه لا يُنشئ مرجعية ثنائية الاتجاه.

حين يقول المصدر الرئيسي لا

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

الحلقات والتصادمات

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

ثم التصادمات. لقد قابلت واحدًا في الفصل 5: مندوب يطلب Steve’s Plumbing LLC بينما يكتب أحدهم في ERP الاسم Steve’s Plumbing L.L.C. (احمِ السجل المحكوم). وإليك آخر. يقترح Salesforce العنوان 125 Main Street؛ وفي اللحظة نفسها تقريبًا يغيّره مستخدم في ERP إلى 130. أيهما يفوز؟ لا توجد إجابة تقنية عالمية. ربما يفوز ERP دائمًا لأنه يملك الحقل؛ وربما يذهب طلب Salesforce إلى قائمة مراجعة؛ وربما يفوز التغيير المقبول الأخير؛ وربما يرفض ERP أي تحديث تغيّرت قيمته الابتدائية. هذا تزامن، لكن تحته قرار مرجعية، ولا نمط تكامل يستطيع إنقاذك إن لم يقرر أحد من يحق له إجراء التغيير المعتمد.

والحقل الواحد هو الحالة البسيطة. فالعنوان شارع ومدينة ورمز بريدي. يرسل Salesforce شارعًا جديدًا بينما غيّر ERP المدينة للتو. هل تمرر الشارع وحده؟ أم تعامل العنوان على أنه معاملة واحدة، فتنتقل الحقول كلها معًا أو لا ينتقل أيٌّ منها، وترفض التغيير كله؟ قرّر أيّ الحقول تنتقل كمجموعة قبل أول تصادم، لا بعده.

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

التسلسلات الهرمية بيانات رئيسية أيضًا

العلاقات يمكن أن تكون بيانات رئيسية أيضًا. شركة أم عالمية لها منطقتا أمريكا الشمالية وأوروبا، ولكلٍّ منهما شركات تابعة في الدول: التسلسل الهرمي نفسه يحمل معنى. من الأم؟ أيّ شركة تابعة تقع تحت أيّ كيان قانوني؟ أيّ الحسابات تتجمع تحت العميل العالمي؟ هذا يحرّك التقارير، والمناطق، والتسعير، والعقود، والتعرّض الائتماني، والخدمة، والوصول إلى البيانات، والتحليلات. قد يكون التسلسل الهرمي بأهمية السجلات التي فيه، ويحتاج إلى الحوكمة نفسها. (الاختبار يذكر إدارة التسلسلات الهرمية؛ ومن السهل نسيانها.)

في Salesforce، تُبنى التسلسلات الهرمية للحسابات بحقل Parent Account (الحساب الأب). يعرض عرض التسلسل الهرمي في Lightning حتى 2,000 حساب، ولا يعرض إلا ما يحق للمستخدم رؤيته؛ والحسابات الشخصية غير مدعومة في التسلسل الهرمي؛ وAccount Site (موقع الحساب) يميّز بين مواقع الشركة (Considerations for Using Account Hierarchy (opens in a new tab)). لكن حقل Parent Account لا يجيب عن السؤال المعماري: من يملك التسلسل الهرمي؟

معلومة للاختبار. اعرف أساسيات التسلسل الهرمي للحسابات: يُبنى بحقل Parent Account؛ ويعرض عرض Lightning حتى 2,000 حساب، لا يظهر منها إلا ما يستطيع المستخدم رؤيته؛ والحسابات الشخصية غير مدعومة؛ وAccount Site يميّز بين مواقع الشركة.

تسلسل هرمي واحد، ومصادر رئيسية عدة

من خبرتي، التسلسلات الهرمية موزّعة المرجعية. كيانات أمريكا الشمالية تأتي من SAP، وكيانات أوروبا من ERP آخر، والعملاء المحتملون الجدد يُبنون في Salesforce، وشركة تابعة مستحوَذ عليها لم تُرحَّل بعد. من يملك التسلسل الهرمي؟ يعتمد على الفرع. كل ERP يتحكم في فرعه؛ وSalesforce يتحكم في علاقات العملاء المحتملين حتى يتحولوا. هذه معمارية مشروعة، ما دام الجميع يعرف أين الحدود. قرّر لكل فرع.

Click to enlarge

يمكن تحديد مرجعية التسلسل الهرمي فرعًا فرعًا.

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

قد يكون للشركة عدة تسلسلات هرمية صحيحة: قانوني، وفوترة، ومبيعات، وخدمة، وجغرافي. الشركة الأم العالمية توقّع العقد، والمناطق تحصل على الخدمة كلٌّ بمفردها، والفوترة تمر عبر كيان مالي مشترك، والمبيعات تُدار حسب المنطقة. أيها التسلسل الهرمي الحقيقي؟ كلها؛ فهي تجيب عن أسئلة مختلفة. الخطأ هو افتراض أنه يجب أن يكون هناك واحد. ينبغي أن تكون هناك مرجعية واضحة لكل نوع من العلاقات: مبدأ السمة من الوحدة 1، مطبَّقًا على العلاقات.

وليست كل علاقة أب-ابن بيانات رئيسية. تجميع توصيلات اليوم على مسار واحد علاقة، لكنها علاقة معاملات، حدث تشغيلي. أما التسلسل الهرمي للعملاء فيصف علاقة عمل دائمة. كلاهما يبدو أب-ابن في النموذج؛ لكنهما لا يتشاركان دورة الحياة. اسأل ما الذي تعنيه العلاقة وكم يدوم ذلك المعنى.

العميل الواحد في نظامَي ERP

حين أدرّس هذا أسأل القاعة: من عمل مع عميل لديه Salesforce واحد وأكثر من ERP؟ ترتفع الأيدي في كل مرة. اسأل لماذا، فتجد أن أنظمة ERP مقسّمة جغرافيًا (واحد لأمريكا الشمالية، وواحد لأوروبا)، أو وظيفيًا (شركة سباكة تشتري شركة كهرباء، وتحتفظ كلٌّ منهما بـ ERP الخاص بها)، أو تاريخيًا فحسب: استُحوذ على النشاط، ولم يرحّله أحد بعد.

خذ Steve’s Plumbing عميلًا. إنها تعمل في أمريكا الشمالية، فلدى ERP أمريكا الشمالية سجل عميل لها. ثم تفتح مكتبًا في ميونخ، فيُنشئ ERP أوروبا سجل عميل خاصًا به، برقم عميل خاص به. الشركة نفسها، وسجلان، ومعرّفان. كيف أمثّل ذلك في org واحد في Salesforce؟ رأيت ثلاث طرق.

تسلسل هرمي للحسابات. Steve’s Plumbing هي الأم، وSteve’s Plumbing North America وSteve’s Plumbing Europe حسابان فرعيان، وكل فرع يمثل سجل ERP واحد. والمشكلة: الفرعان لم يعودا حقًا Steve’s Plumbing. إنهما Steve’s Plumbing وهي تمارس نشاطها في منطقة ما، وكما رأينا للتو، التسلسل الهرمي يحمل معنى.

حسابات نظيرة. حسابان جنبًا إلى جنب، لكلٍّ منهما حقل يقول إلى أيّ ERP ينتمي: رمز شركة، أو منطقة. لا شيء مخفي. والكلفة تظهر في التقارير: لترى Steve’s Plumbing حول العالم، تحتاج إلى شيء يقول إن هذين الحسابين هما الشركة نفسها.

حساب واحد، مع سجل فرعي لكل ERP. Steve’s Plumbing واحدة، وكائن فرعي فيه سجل لكل ERP يحمل معرّف العميل في ذلك ERP. نظاما ERP أو عشرة. يرى مندوبو المبيعات عميلًا واحدًا ويضعون طلبًا واحدًا؛ وخلف الكواليس تقرر التدفقات إلى أيّ ERP يذهب كل بند: أعمال الكهرباء إلى ERP الكهرباء، والسباكة إلى ERP السباكة. لكن عليك الآن أن تقرر أيّ ERP هو الأساسي للقيم المشتركة، كالاسم والعنوان، وماذا يحدث حين يوجد العميل في ERP دون الآخر.

Click to enlarge

عميل واحد في نظامَي ERP: ثلاث طرق لتمثيله في Salesforce.

اسأل كيف يبقون أنظمة ERP متزامنة

إذن أيّها؟ أولًا: كم من بنية ERP ينبغي أن يرى مندوبو المبيعات؟ إن كانوا يعرفون دائمًا أن أمريكا الشمالية وأوروبا نشاطان منفصلان، لأنهم يسجّلون الدخول إلى هذا ERP أو ذاك، فلا تخفِ ذلك عنهم. انقل تلك البنية إلى Salesforce كحسابات نظيرة. وإن أرادت الجهة المعنية Steve’s Plumbing واحدة أمام المبيعات، فأنت تنظر إلى حساب واحد مع سجل فرعي لكل ERP.

ثم السؤال الذي يحسم الأمر فعلًا، ولا يُحسم في Salesforce. أسأل العميل: كيف تبقون هذين السجلين متزامنين بين أنظمة ERP لديكم؟ لا أقصد الأشياء المحلية في كل ERP، كالرصيد؛ فتلك بيانات معاملات. أقصد البيانات الرئيسية: الاسم القانوني، والعناوين. إن كان لديهم فريق يبقي نظامَي ERP متزامنين، يمكننا جمعهما في حساب واحد. وإن لم يستطيعوا إبقاءهما متزامنين في أنظمة ERP الخاصة بهم، فكيف يتوقعون منا أن نبقيهما متزامنين في Salesforce؟ عندها تكون الحسابات نظيرة، أو تسلسلًا هرميًا.

تذكّر ما هو ERP. إنها أنظمة ضخمة تستغرق سنوات لتطبيقها، وتأتي بطريقتها الخاصة في إدارة البيانات الرئيسية. Salesforce لن يقودها. نحن لا نتحكم في أنظمة ERP. بل نتحكم في طريقة تمثيلها في Salesforce.

MDM في المنتصف

بعض العملاء حلّوا هذا بالفعل قبل وصولنا. شركة كبيرة، سنوات طويلة في السوق، وعدة أنظمة ERP: واجهوا هذه المشكلة قبل Salesforce بزمن طويل، ووضعوا منتج MDM مخصصًا في المنتصف ليتوسط بين أنظمة ERP. هذا هو MDM التعايش أو المركزي من الوحدة 2. الآن لا يوصل Salesforce نفسه بكل ERP. بل يشير إلى مكان واحد، محور MDM، ويحصل على تمثيل واحد للعميل. لكن لا تتوقع أن تصادف ذلك كثيرًا. فهذه تطبيقات كبيرة بحد ذاتها؛ وفي كل سنواتي لم أعمل مع واحد منها إلا مرتين أو ثلاثًا. وحتى مع المحور، قد تظل بحاجة إلى ذلك الكائن الفرعي، كي يعرف كل طلب إلى أيّ ERP يذهب.

Click to enlarge

MDM في المنتصف: Salesforce يشير إلى مكان واحد.

Steve Trucking: تسلسل هرمي لمن؟

لشريك التجزئة بنيته الخاصة: الشركة الأم، والأقسام الإقليمية، ومراكز التوزيع، والمتاجر. هل تملك Steve Trucking ذلك التسلسل الهرمي؟ لا؛ الشريك هو المرجع لتنظيمه الخاص. لكن قد تحتاج Steve Trucking إلى رؤيتها التجارية الخاصة للمواقع نفسها، من أجل العقود، وإدارة الحسابات، والخدمة، والتقارير، وربما حساب فرعي لكل مركز توزيع تحت الشريك. تسلسلان هرميان مشروعان، ومرجعيتان. سمِّهما، ولا تتظاهر بأن شجرة واحدة تمثل كل علاقة.

اجعل الحدود مرئية

كلما توزعت المرجعية، أريد أن يكون الحد مرئيًا: في تسمية الحقول، وبيانات السجل الوصفية، ومعرّفات النظام المصدر، والأذونات، وسلوك التكامل، والتوثيق. ما لا أريده هو مطوّر يقرأ خمسة تكاملات ليكتشف أن «قيم Parent Account هذه تأتي من SAP، إلا العملاء المحتملين، وإلا أوروبا». هذا ليس نموذج مرجعية قابلًا للصيانة. إن كان التسلسل الهرمي موزّع المرجعية، فوثّق التوزيع. وإن تغيّرت المرجعية عند التحويل، فوثّق التغيير. وإن كان Salesforce يستطيع طلب تغيير لكن لا يستطيع إجراءه، فاجعل ذلك واضحًا في التجربة.

في Salesforce، يبدأ ذلك بحقل واحد. يجب أن يكون هناك حقل يقول بوضوح إن هذه بيانات رئيسية: مفتاح ERP، أو علامة «بيانات رئيسية». اجعل قابلية تحرير الحقول تعتمد على ذلك الحقل، لا على نوع السجل؛ فمع Dynamic Forms لم تعد تحتاج إلى نوع سجل لعرض حقول ERP للقراءة فقط (الفصل 5، نوع سجل لكل تدفق). يمكنك السماح بإنشاء سجلات خارج المصدر الرئيسي، لكن راقب التعديلات.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. يقول عميل لوكيل: «غيّر عنوان الفوترة لدينا إلى 125 Main Street.» الحقل موجود هناك في Salesforce. هل ينبغي أن يحدّثه الوكيل؟ ليس إن كان ERP يملكه. الوكيل يحتاج إلى صلاحية كتابة، لا مجرد وصول إلى الحقل: ينبغي أن يجسّد إجراؤه المسار المعتمد، فيقدّم طلب تغيير ويقول «قدّمتُ التغيير للمعالجة»، لا أن يزعم كذبًا «حدّثتُ عنوان الفوترة لديك».

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

• هل التعديل في Salesforce يغيّر بيانات معتمدة، أم يطلب تغييرًا من النظام الذي يملكها.
• كيف تميّز التدفقات ثنائية الاتجاه بين التغييرات الأصلية وأصدائها، وكيف تتعامل مع الرفض والتصادمات والتأخر والفشل.
• من يملك كل تسلسل هرمي، فرعًا فرعًا إن لزم الأمر.
• للعميل الواحد المحفوظ في عدة أنظمة ERP: تسلسل هرمي، أو حسابات نظيرة، أو حساب واحد مع سجل فرعي لكل ERP، ويحسم ذلك مدى إحكام العميل لمزامنة أنظمة ERP لديه.
• هل التسلسلات الهرمية المتنافسة هي في الحقيقة علاقات مشروعة مختلفة: قانونية، وفوترة، ومبيعات، وخدمة.
• كيف تُجعل حدود المرجعية ومسارات الكتابة المعتمدة مرئية للمستخدمين والتكاملات والمطورين والوكلاء.

المرجعية المشتركة ليست المشكلة. المرجعية الملتبسة هي المشكلة. يمكن لعدة أنظمة ERP أن تدير فروعًا مختلفة، ويمكن لـ Salesforce أن يدير بعض السمات ويطلب تغيير أخرى، ويمكن لعدة تسلسلات هرمية أن تصف مؤسسة واحدة. كل ذلك يعمل، ما دمت تستطيع أن تقول لكل سمة وعلاقة مهمة من يملكها، ومن يحق له تغييرها، وأين يُجرى التغيير المعتمد، وماذا يحدث حين تختلف الأنظمة. وإن لم تستطع، فلن يصلح ذلك سهمٌ آخر ثنائي الاتجاه على المخطط.

للاستزادة

• Salesforce Help، Considerations for Using Account Hierarchy (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).