مصدر واحد للحقيقة لكل سمة

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

السؤال الذي تجيب عنه هذه الوحدة: ماذا يعني «مصدر واحد للحقيقة» فعلًا؟

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

الحقيقة تنتمي إلى السمة

المبدأ الأول للبيانات الرئيسية هو: المرجعية تُحدَّد لكل سمة، لا لكل سجل. قد يعيش الحساب في Salesforce دون أن يكون Salesforce هو المرجع المعتمد لكل حقل فيه. سبعة حقول على سجل واحد، ومرجعيتان:

السمة	النظام المرجعي المعتمد
الاسم القانوني، وعنوان الفوترة، ومعرّف العميل في ERP، وحد الائتمان	ERP
مسؤول الحساب، وعلامة الحساب الاستراتيجي، ومستوى النجاح	Salesforce

سجل واحد؛ والحقيقة موزّعة. وهذا طبيعي. عبارة «نظام السجل = Salesforce» لا تصف ذلك. أما نموذج المرجعية فيصفه.

أين تُنشأ، وأين تُحرَّر، وأين يُرجَع إليها، وبأي سرعة؟

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

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

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

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

نظام السجل، ونظام التفاعل، والنظام المرجعي

مفردات الفصل 4 تساعد هنا. نظام السجل (system of record) يحتفظ بالنسخة المعتمدة. ونظام التفاعل هو المكان الذي يعمل فيه الناس بها. والنظام المرجعي يوفّر بيانات يستخدمها نظام آخر لكنه لا يملكها. يمكن أن يكون Salesforce نظام التفاعل لعلاقة العميل بينما يبقى ERP نظام السجل لسماته القانونية والمالية. هذا ليس ضعفًا في المعمارية؛ بل هو المعمارية. والخطأ أن نتظاهر بأن نظامًا واحدًا يجب أن يملك كل شيء كي يبدو المخطط أبسط.

السجل الذهبي الهجين

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

اجعل المرجعية مرئية

لذلك أجعل المرجعية الخارجية واضحة في المخطط. إن كان SAP يتحكم في حقل، يحصل الحقل على بادئة: sap_Customer_Number، وsap_Credit_Status، وsap_Legal_Name. إنها الفكرة نفسها التي رأيناها في بادئة erp_ في الفصل 4. استخدم اسم النظام حين تكون المرجعية محددة ومستقرة، وبادئة عامة حين يكون المعنى أهم من مورّد اليوم. المهم أن يرى من يقرأ النموذج بعد ستة أشهر: هذا ليس مجرد حقل آخر في Salesforce؛ نظام آخر يملك هذه القيمة. لا تجعل الناس يعيدون اكتشاف المرجعية بالهندسة العكسية للتكاملات.

ابنِ خريطة المرجعية

للبيانات الرئيسية المهمة، أريد خريطة مرجعية (authority map): لكل سمة أساسية، من يُنشئها، ومن يملك قرار العمل بشأنها، وأيّ نظام هو المرجعي المعتمد، ومن أو ما الذي يحق له تغييرها. أربعة أسئلة مختلفة:

السمة	يُنشئها	مالك العمل	النظام المرجعي المعتمد	يحق له تغييرها
الاسم القانوني	المالية	المالية	ERP	عملية المالية
حد الائتمان	المالية	المالية	ERP	فريق الائتمان
مسؤول الحساب	عمليات المبيعات	المبيعات	Salesforce	إدارة المبيعات
مستوى الدعم	عمليات الخدمة	الخدمة	Salesforce	إدارة الخدمة
الموافقة	العميل	الخصوصية	منصة الموافقة	العميل، أو عملية معتمدة

لاحظ أن مالك العمل والنظام المرجعي المعتمد ليسا الشيء نفسه. النظام لا يملك السياسة؛ الناس يملكونها. والنظام يخزّن النتيجة ويفرضها. هذا هو الفصل 5 مرة أخرى: المالكون يضعون السياسة؛ والمعماريون يفرضونها.

Click to enlarge

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

المرجعية تتغير عبر دورة الحياة

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

النسخة ليست مرجعية

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

الثقة تحتاج إلى أكثر من قيمة

«عنوان الفوترة: 123 Main Street.» هل ينبغي أن تثق به؟ أريد إشارات ثقة: من أين جاء، ومتى أُكِّد آخر مرة، وأيّ نظام زوّد به، ومن أو ما الذي غيّره آخر مرة: شخص، أم تكامل، أم وكيل؟ والآن يقول ERP إنه 123 Main Street، ويقول Salesforce إنه 125، ويقول ملف أحد الشركاء «123 Main St., Suite 200». أيّها الصحيح؟ لا تُجب بـ «استخدم الأحدث». ربما. لكن «الأحدث» قاعدة بحد ذاتها، تفترض أن من غيّره آخر مرة يستحق أن يفوز. قد يكون هذا صحيحًا، وقد يكون كارثيًا. الوحدة 3 تتناول ذلك. الثقة تأتي من المرجعية ومن مصدر البيانات وتاريخها، لا من العثور على حقل مملوء.

Steve Trucking: حقيقة مَن هذه؟

يرسل شريك التجزئة (Retail Partner) توصيلة، وتختبئ في تلك المعاملة الواحدة عدة حقائق. مرجع طلب الشريك هو للشريك؛ تحتفظ به Steve Trucking لمطابقة التحديثات، لكنها لا تصبح مصدره الرئيسي. وحالة التوصيلة (وصلت، سُلِّمت، رُكِّبت، استثناء) هي لـ Steve Trucking؛ يستلمها الشريك، لكن استلام الحالة لا يجعل الشريك المرجع المعتمد لما حدث على الشاحنة. والمستلم (Recipient) هو عميل الشريك. يزوّد الشريك بالاسم والعنوان والهاتف وملاحظات التوصيل لأن Steve Trucking تحتاج إليها لتوصل. وهذا لا يجعل Steve Trucking المصدر الرئيسي لهوية ذلك الشخص، وهذا التمييز هو ما يحسم تصميم المستلم في نقطة التحقق.

Click to enlarge

توصيلة واحدة، ومرجعيتان.

أين تعيش البيانات ومن يملك حقيقتها سؤالان مختلفان. يمكن لـ Salesforce أن يحتفظ برقم العميل في ERP دون أن يملكه؛ ويمكن لـ Snowflake أن يحتفظ بحالة التوصيلة دون أن يكون مصدرها التشغيلي الرئيسي؛ ويمكن لمنصة بيانات العملاء أن توحّد الهويات دون أن تملك كل سمة. ويستطيع الوكيل أن يقرأ الثلاثة كلها، وهذا بالتأكيد لا يسمح له بأن يقرر أيّها الصحيح.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. الوكلاء يحوّلون مرجعية السمة إلى قاعدة تنفيذ. يرى الإنسان عنوان فوترة خاطئًا فيعرف «هذا يأتي من SAP؛ لا ينبغي أن أغيّره هنا». أما الوكيل الذي يُطلب منه «حدّث عنوان فوترة العميل» فلن يعرف ذلك ما لم نصمّم له. إنه يحتاج إلى خريطة المرجعية نفسها التي لدى المعماري: الوصول إلى حقل لا يجعل ذلك الحقل المكان الصحيح للكتابة.

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

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

المصدر الواحد للحقيقة لا يعني org واحدًا، ولا ERP واحدًا، ولا منصة MDM واحدة، ولا سجلًا عملاقًا واحدًا. بل يعني أن المعمارية تستطيع، لكل معلومة محكومة، أن تقول أين القيمة المعتمدة، وأن كل نظام آخر يعرف كيف يتصرف بناءً على ذلك. هذا ليس مصدرًا واحدًا للحقيقة. إنه معمارية للحقيقة.

للاستزادة

• Salesforce Architects، Data 360 Architecture (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).