إبقاء البيانات السيئة خارجًا

🌐 متاح أيضًا بـ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)

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 2 من 6 في فصل جودة البيانات وحوكمتها، الفصل 5 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: الحوكمة تُصمَّم داخل الـ org · التالي: اعرف بياناتك

السؤال الذي تجيب عنه هذه الوحدة: كيف تجعل البيانات جيدة، وتُبقيها كذلك؟

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

«جيد بما يكفي» تعريف تجاري

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

امنع الأخطاء المكلفة

ليس كل حقل سيئ يستحق الاهتمام نفسه. أهتم أكثر بالأخطاء التي لها عواقب لاحقة. العميل المكرر يعني تاريخَي مبيعات، وتاريخَي خدمة، ومجموعتين من جهات الاتصال، ومعرّفين خارجيين، وتكاملين يزامنان الشركة نفسها، ونسختين في مستودع البيانات وفي Data 360، وفي النهاية وكيلًا يقرر أي العميلين هو الحقيقي. هذا أغلى بكثير من خطأ مطبعي في وصف. لذا لا تبدأ بـ «كيف نتحقق من كل حقل؟». ابدأ بـ أي البيانات السيئة تُحدث أكبر مشكلة تجارية أو معمارية؟ وضع أقوى الضوابط هناك.

مفتوح أم مغلق؟

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

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

لكن الإغلاق التام يفشل أيضًا. التقى المندوب عميلًا مرتقبًا غير موجود في ERP ويريد فتح فرصة، ونموذج الحوكمة يقول «لا حساب لك». فينتظر ثلاثة أيام حتى ترد المالية، أو يربط الفرصة بالحساب الخطأ، أو يحتفظ بالعميل المرتقب في حقل ملاحظات أو في جدول بيانات. حمينا نموذج البيانات وأضررنا بالعمل.

الطريق الوسط: نوع سجل مؤقت

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

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

نوع سجل لكل تدفق

ضع التدفق كله في صورة واحدة وسترى لماذا ينجح هذا. العملاء والمنتجات يدخلون من ERP. والفرص وبنودها تخرج وتصبح طلبات في ERP. والحسابات؟ بعضها يدخل، وبعضها يخرج. لذا فإن نمطًا شائعًا رأيته عبر عمليات تنفيذ كثيرة هو نوعا سجل على الحساب (Account)، واحد لكل اتجاه. حساب Sales يولد في Salesforce: ينشئه المندوبون، ويعدّلونه، ويبيعون له، وحين يصبح عميلًا يُرسَل إلى ERP. وحساب ERP (سمّيته Customer، أو ببساطة SAP) يولد في ERP ويدخل عبر التكامل. لا أحد ينشئ نوع السجل هذا إلا التكامل، وحقوله الخاصة بالبيانات الرئيسية (الاسم القانوني، والعناوين، وشروط الدفع) للقراءة فقط بالنسبة للمستخدمين. نوع السجل يخبرك في أي اتجاه يتدفق السجل، فيكون اتجاه الإدارة الرئيسية للبيانات ظاهرًا على السجل نفسه.

Click to enlarge

نوع سجل لكل تدفق: حسابات Sales تخرج، وحسابات ERP تدخل.

هذا لا يلغي الحالة الصعبة. يحوّل مندوبٌ عميلًا محتملًا لشركة Steve’s Plumbing، لكن Steve’s Plumbing موجودة بالفعل بوصفها حساب ERP، ولسبب ما لم يلتقطها فحص التكرار. الآن أنت تدمج، وتعيد ربط السجلات الفرعية بأب جديد، وتقرر أي سجل يبقى (الفصل 6، الوحدة 3).

ولا تتعلق بنوع السجل نفسه. عادةً أتجنب أنواع السجلات ما لم تكن هناك حجة قوية لها. استخدمتها هنا لأنه، قبل Dynamic Forms، كان نوع السجل هو الذي يختار تخطيط الصفحة، وكان أحد التخطيطات يعرض حقول ERP للقراءة فقط. مع Dynamic Forms، يمكن لقواعد الظهور أن تُظهر الحقول وتُخفيها بحسب قيمة حقل ما، ويمكن أن يكون الحقل للقراءة فقط في صفحة معينة، وSalesforce نفسها تقول إن Dynamic Forms تقلل عدد تخطيطات الصفحات وأنواع السجلات التي تحتاجها (Break Up Your Record Details with Dynamic Forms (opens in a new tab)؛ Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). لكن «للقراءة فقط» في صفحة يعني للقراءة فقط في تلك الصفحة: الـ API، أو تحميل البيانات، أو التكامل لا يزال بإمكانه الكتابة في الحقل. الفرض الحقيقي هو الأمان على مستوى الحقل أو قاعدة تحقق؛ والتحقق في واجهة المستخدم ليس تحققًا من البيانات (الفصل 3، الوحدة 9). لا تزال أنواع السجلات تستحق مكانها حين يحتاج نوعا الحساب إلى قيم قوائم اختيار أو عمليات عمل مختلفة. ما يهم فعلًا هو أن يقول حقلٌ ما بوضوح من أين جاء السجل: مفتاح ERP نفسه، أو علامة بيانات رئيسية، أو قائمة اختيار للمصدر. ثم اجعل قابلية التعديل تتبع ذلك الحقل.

Click to enlarge

من مؤقت إلى محكوم: المبيعات تبدأ البيع فورًا؛ والإجراء المرجعي المعتمد وحده يجعل السجل محكومًا.

احمِ السجل المحكوم

بمجرد أن يعود العميل من ERP، يصبح معرّفه في ERP، واسمه القانوني، ومعرّفه الضريبي، وتفاصيل فوترته سماتٍ محكومة. هل ينبغي للمندوب تغييرها؟ ليس إذا كان ERP يملكها. هذه سياسة الوحدة 1 التي تحتاج إلى نقطة فرضها: معرّف ERP للقراءة فقط، والهوية القانونية مضبوطة، بينما يظل المندوب يعدّل المنطقة البيعية، وملاحظات العلاقة، وتصنيفات Salesforce الخاصة. الهدف ليس حسابًا لا يُمَس. بل خطًّا واضحًا بين البيانات التي يملكها Salesforce والبيانات التي يشير إليها Salesforce. (البادئة erp_ من الفصل 4 تجعل هذا الخط مرئيًا في المخطط.)

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

أصعب ما في الأمر التدفقات ثنائية الاتجاه. لنقل إن مندوبًا يحتاج إلى تغيير الاسم القانوني في ERP من Steve’s Plumbing إلى Steve’s Plumbing LLC. وفي الدقائق الخمس نفسها، يغيّره شخص في ERP إلى Steve’s Plumbing L.L.C. تغيير مَن يُعتمد؟ إليك طريقة التفكير: إذا كان الحقل يُدار رئيسيًا في ERP، فأنت لا تغيّر الحقل، بل تطلب تغييره. قرّر ماذا يحدث حين يتصادم الطلب: ERP يُعتمد، أو يُرفض الطلب إذا تغيرت القيمة في الأثناء، أو ينتظر شخصًا يحسمه. وقرّر ما إذا كانت الحقول المترابطة تنتقل معًا بوصفها تغييرًا واحدًا أم واحدًا تلو الآخر. يتعمق الفصل 6 في التصادمات (الحلقات والتصادمات).

أوقف التكرارات عند الباب

التكرارات تتراكم. التقط واحدًا قبل إنشائه فتكون مشكلة صغيرة. واعثر عليه بعد عامين، وقد تعلّقت به من الجهتين فرص، وحالات، وجهات اتصال، وفواتير، وتكاملات، وتحليلات، فتكون مشكلة كبيرة. غطّت الوحدة 7 من الفصل 3 الآليات (قواعد المطابقة، وقواعد التكرار، وExternal IDs الفريدة)، لذا لن أعيد شرحها. سؤال الحوكمة هو أين يجب أن نمنع التكرار، وأين سنتسامح معه ونحسمه لاحقًا؟ عميل محتمل عابر من التسويق يمكنه التعايش مع الغموض. أما عميل محكوم من ERP له معاملات مالية فلا يمكنه ذلك.

وحّد ما تقرؤه الآلات

النص الحر رائع للبشر ومريع حين يتعين على نظام تفسيره. ضع Arizona وAZ وAriz. وPhoenix area وSouthwest في حقل يقود توجيه المسارات، فتكون لديك مشكلة جودة. إذا كانت قيمة ما تقود الأتمتة، أو التكامل، أو التقارير، أو الأمن، أو الإسناد، أو إجراء وكيل، ففكّر مليًّا في مدى ضرورة أن تكون قياسية. ليس كل حقل نصي يصبح قائمة اختيار، لكن ميّز بين المعلومات التي يقرؤها الناس والمعلومات التي تتخذ الآلات قراراتها بناءً عليها. الثانية تستحق ضبطًا أقوى.

لا تدع الحقول الإلزامية تصنع بيانات مزيفة

نقرر أن حقلًا ما مهم فنجعله إلزاميًا. المستخدم لا يعرف الجواب، والنظام لا يسمح له بالمتابعة، فيكتب N/A أو Unknown أو 999999 أو test@test.com. الحقل مكتمل؛ والبيانات هراء. قبل أن تجعل شيئًا إلزاميًا، اسأل هل يعرفه المستخدم فعلًا في تلك اللحظة. إن لم يكن، فاجعله إلزاميًا في مرحلة لاحقة من العملية، أو دع نظامًا آخر يوفّره، أو استخدم الحالة المؤقتة، أو قدّم خيار Unknown صريحًا حين يكون «غير معروف» جوابًا مشروعًا. قاعدة التحقق تستطيع فرض سياسة. لكنها لا تستطيع أن تجعل أحدًا يعرف ما لا يعرفه.

كل حدّ للبيانات يحتاج إلى قرار جودة

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

Click to enlarge

كل حدّ للبيانات يحتاج إلى قرار جودة.

البيانات التاريخية مختلفة

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

قِس ما سيتصرف أحد بناءً عليه

الحوكمة لا تنتهي أبدًا، لذا تحتاج أن ترى متى تتراجع الجودة: معدلات تكرار ترتفع، وسجلات أكثر في العزل، ورفض أكثر من التكاملات، وقيم بديلة وهمية تنتشر، وطلبات تجاوز أكثر، وتقارير لم تعد تتطابق. لكن لا تبنِ 150 مقياسًا وتتجاهل 143 منها. بالنسبة لـ Steve Trucking، ربما تكون: توصيلات بلا مرجع شريك صالح، وتوصيلات بلا عنوان صالح للاستخدام، ومراجع طلبات مكررة، ورسائل شركاء مرفوضة، وحسابات عالقة في الحالة المؤقتة. لوحة معلومات مليئة بالدوائر الخضراء لا تعني أن البيانات جيدة. قِس ما هو أحدٌ مستعد للتصرف بناءً عليه.

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

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

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

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

للاستزادة

• Salesforce Help، Things to Know About Duplicate Rules (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).
• Salesforce Help، Break Up Your Record Details with Dynamic Forms (opens in a new tab) وRequired and Read-Only Fields in Dynamic Forms (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).