مصدر الحقيقة في المؤسسة: من المسؤول عن العميل، المنتج، الطلب والدفع؟

الإجابة المختصرة

"مصدر الحقيقة" (Source of Truth) ليست مسألة تقنية، بل هي مسألة صلاحية: من هو المخول داخل المؤسسة لتحديد صحة قيمة معينة. عندما لا يتم اتخاذ هذا القرار بشكل صريح، فإنه يُتخذ ضمنيًا - من قبل من قام بكتابة آخر تكامل.

القاعدة الأساسية: تُحدد الملكية على مستوى الحقل، وليس على مستوى النظام. محاولة الإعلان بأن "نظام تخطيط موارد المؤسسات (ERP) هو مصدر الحقيقة للعميل" تنهار بمجرد أن يقوم قسم الخدمة بتحديث رقم هاتف في Salesforce، ثم يقوم التزامن الليلي بحذف التحديث.

ثلاثة أسئلة حاسمة للملكية

لكل كيان، ثم لكل مجموعة حقول، نسأل: أين تم إنشاء البيانات أولاً، من هو المخوّل تجارياً لتغييرها، ومن يتحمل المسؤولية عند الخطأ. في الحالات الثلاث، يجب أن تكون الإجابة اسم وظيفة، وليس اسم نظام. النظام يُشتق من الوظيفة.

عندما تشير الإجابات إلى وظيفتين مختلفتين، فهذه دائمًا تقريبًا علامة على دمج حقلين مختلفين في حقل واحد.

مصفوفة ملكية نموذجية

هذا الجدول هو الناتج. إنه موجز، وموجود في وثيقة واحدة، ويُختبر كل تكامل جديد مقابلها قبل كتابته.

الفصل بين العرض والصلاحية

يزول الكثير من التوتر بين الأنظمة عندما نفهم أن عرض البيانات لا يتطلب نسخها. الرصيد المستحق الذي يُعرض للبائع لا يجب أن يكون حقلاً في Salesforce يتم تحديثه كل ليلة؛ يمكن أن يكون عرضًا عن بُعد أو طبقة اتحاد (Federation).

كل حقل يتم نسخه يمثل التزامًا تشغيليًا: تزامن، فشل، تباين، ووقت. قبل النسخ، نسأل عما إذا كانت هناك حاجة إلى الأتمتة أو التقارير التاريخية عليه. إذا لم يكن الأمر كذلك - فمن الأفضل عرضه بدلاً من نسخه. يتوفر شرح موسع لهذا النهج في Zero Copy و Federation في Data 360.

التعارضات: اتخاذ القرار مسبقًا، وليس في الوقت الفعلي

حتى عندما تكون الملكية واضحة، تحدث حالات تحديث متزامن. هناك ثلاث قواعد ممكنة: أولوية النظام (المالك يفوز دائمًا)، ختم الوقت الأخير، أو وضع علامة للتعامل اليدوي. القاعدة الثالثة هي الأكثر أمانًا للحقول الحساسة - شريطة وجود قائمة انتظار مع مالك، وليس سجل يوميات يتراكم.

سيناريو: مؤسسة ذات حقيقتين لعنوان واحد

أدارت شركة خدمات بنية تحتية عنوان عميل في نظامين: ERP لأغراض الفواتير ونظام خدمة ميدانية لوصول الفنيين. وكلاهما كانا متزامنين مع Salesforce باتجاهين. وكانت النتيجة: عنوان يتبادل ذهابًا وإيابًا، وفنيون وصلوا إلى عنوان الفواتير.

لم يكن الحل في إصلاح التزامن بل في تفكيك الكيان. تم تعريف حقلين منفصلين - عنوان الفواتير بملكية نظام ERP، وعنوان الخدمة بملكية نظام الخدمة الميدانية - وكلاهما قراءة فقط في Salesforce، مع رابط لطلب التغيير موجه إلى المالك الصحيح. وانخفض عدد مكالمات الخدمة التي تم إغلاقها على أنها "عنوان خاطئ" بشكل ملحوظ في الربع التالي.

الدرس المستفاد: عندما "تتشاجر" الأنظمة على حقل، فغالبًا ما يكون الأمر متعلقًا ببيانات عمل مختلفة تحصل على نفس الاسم.

التنفيذ: من الوثيقة إلى الواقع

تحقق مصفوفة الملكية وجودها فقط إذا تم تطبيقها في ثلاث نقاط: أمان مستوى الحقل (Field-Level Security) الذي يمنع التعديل من الجانب غير المالك، ومستخدم تكامل بصلاحيات محدودة للحقول التي يملكها فقط، وتقرير شهري يعرض الحقول التي تم تحديثها خلافًا للسياسة. التقرير الثالث هو الذي يكشف عن عمليات التكامل القديمة التي لا يتذكرها أحد.

يتصل توثيق معنى كل حقل مباشرة بـ Data Mapping للترحيل.

المخاطر الشائعة والإجراءات الوقائية

كيف نقيس النجاح

يتم بناء مصفوفة الملكية وتطبيقها ضمن خدمات التكامل والبيانات.

قائمة مراجعة لتحديد مصدر الحقيقة

• ☐ قائمة بالكيانات الرئيسية في المؤسسة
• ☐ لكل كيان: أين تم إنشاؤه، من هو المفوض، من المسؤول عن الخطأ
• ☐ تم تحديد الملكية على مستوى الحقل أو مجموعة الحقول
• ☐ اتجاه تزامن واضح لكل مجموعة
• ☐ كل حقل منسوخ يفي بمعيار "لديه مستهلك"
• ☐ تم اختيار وكتابة قاعدة حل النزاعات
• ☐ توجد قائمة معالجة يدوية مع مالك و SLA
• ☐ أمان مستوى الحقل (Field-Level Security) يتوافق مع المصفوفة
• ☐ مستخدم التكامل مقيد بالحقول التي يمتلكها
• ☐ تقرير شهري عن انتهاكات السياسة

مصادر احترافية

• Salesforce Data 360 — https://www.salesforce.com/data/
• Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
• HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data