الحوكمة تُصمَّم داخل الـ org
متاح أيضًا بـ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 في فصل جودة البيانات وحوكمتها، الفصل 5 من دورة Data Architect. كل وحدة قائمة بذاتها. التالي: إبقاء البيانات السيئة خارجًا
السؤال الذي تجيب عنه هذه الوحدة: ماذا تعني حوكمة البيانات للمعماري، ومن يفعل ماذا؟
حين يسمع الناس حوكمة البيانات، يفكرون في الاجتماعات: لجان، وسياسات، ومعايير، ووثيقة تشرح من يُفترض أن يفعل ماذا بالبيانات. قد يكون كل ذلك جزءًا من برنامج حوكمة. أما أنا، بوصفي معماريًا، فيهمني سؤال مختلف: أين تُفرَض السياسة؟
إذا قالت السياسة إن المالية وحدها يجوز لها تغيير حقل ما، فما الذي يفرض ذلك؟ وإذا قالت إن ERP يملك السجل القانوني للعميل، فما الذي يمنع شخصًا في Salesforce من تغييره؟ وإذا قالت إن الطواقم ترى عنوان المستلم لمحطاتها فقط، وفي يوم التوصيل فقط، فما الذي يجعل ذلك صحيحًا فعلًا؟ وإذا قالت احتفظ بهذا سبع سنوات، فما الذي يؤرشفه أو يزيله بعد السبع؟ السياسة التي لا نقطة فرض لها هي في الغالب أمنية. تصبح الحوكمة معمارية حين تُبنى تلك القرارات داخل النظام.
الحوكمة لا تنتهي أبدًا
Section titled “الحوكمة لا تنتهي أبدًا ”دعني أحسم هذا مبكرًا: أنت لا تُنهي الحوكمة. رأيتها تمضي في مدّ وجزر. تولي شركة ما اهتمامًا حقيقيًا بجودة البيانات، فتتحسن الأمور. ثم ينتقل الاهتمام إلى مكان آخر، فتتراجع الجودة. يدخل تكامل جديد الخدمة، وتغيّر وحدة عمل إجراءاتها، ويستورد أحدهم ملفًا، وتستحوذ الشركة على أخرى، ويبدأ وكيل بكتابة السجلات، فتتغير المشكلة من جديد. الهدف ليس حالة أسطورية يكون فيها كل سجل مثاليًا إلى الأبد. بل أن تبقى البيانات جديرة بالثقة بما يكفي للعمل، وأن تُبقي أسوأ البيانات السيئة خارجًا. هذا عمل مستمر.
حين يقف Salesforce وحده في الغالب، تعني الحوكمة تنظيف البيانات في مكان واحد. وحين يكون عقدة واحدة في خريطة الأنظمة من الفصل 4، تصبح أصعب، وأكثر ضرورة. الآن يعيش العميل في Salesforce، وفي ERP، وفي مستودع البيانات، وفي أنظمة الشركاء، وفي Data 360. من يملكه؟ من يستطيع تغييره؟ أي نسخة هي المرجعية المعتمدة، وأي السمات يجوز أن تنتقل، وكم من الوقت تُحفظ، ومن يُسأل حين تكون خاطئة؟ هذه ليست أسئلة إعداد. إنها أسئلة حوكمة تصبح إعدادًا.
مالك السجل ليس مالك البيانات
Section titled “مالك السجل ليس مالك البيانات ”ابدأ بكلمة مالك، لأن Salesforce يجعلها مربكة. افتح حسابًا فترى Owner: مندوب مبيعات مثلًا. هل يملك المندوب بيانات العميل؟ ليس بالضرورة. في Salesforce، السجل على كائن له مالك يملكه مستخدم أو قائمة انتظار (queue)؛ يحصل المالك على وصول كامل، ويقود المالك الإسناد والمشاركة عبر التسلسل الهرمي للأدوار وقواعد المشاركة (Sharing and Record Access Features (opens in a new tab)). هذه هي ملكية السجل: آلية من آليات المنصة.
أما مالك البيانات فشيء آخر: الشخص أو الوظيفة المسؤولة عن البيانات بوصفها أصلًا تجاريًا. قد تملك المالية المعلومات القانونية للعميل، والعمليات حالة التوصيل، والموارد البشرية بيانات الموظفين. بل إن Salesforce يمنحك مكانًا لتسجيل ذلك: حقل التصنيف Data Owner على كل حقل (Data Classification Metadata Fields (opens in a new tab)).
في Steve Trucking، قد يكون مالك حساب شريك التجزئة هو مدير المبيعات الذي يدير ذلك الشريك. لكن الهوية القانونية للشريك تحكمها المالية وتُدار رئيسيًا في نظام ERP المالي. المبيعات والخدمة والعمليات وبوابة الشركاء كلها تحتاج إلى الحساب؛ ولا شيء من ذلك يعني أن على مدير المبيعات تغيير الهوية القانونية للشريك بعد أن ثبّتتها المالية. رأيت فرقًا تنظر إلى حقل Owner وتفترض أنها حلّت مسألة ملكية البيانات. لم تحلّها. إسناد السجل ليس مساءلة تجارية.
المالك، والأمين، والقيّم
Section titled “المالك، والأمين، والقيّم ”ثلاثة أدوار في الحوكمة، وثلاث وظائف مختلفة.
مالك البيانات يضع السياسة. يجيب عن: ماذا تعني البيانات، ومن يجوز له إنشاؤها وتغييرها، وما الدقة المطلوبة منها، وكم تُحفظ، ومن يجوز له رؤيتها، وأي نظام هو المرجعي المعتمد، وماذا يحدث حين تكون خاطئة. لا ينبغي للمعماري أن يخترع تلك الإجابات. هذا من أكثر مواقفي رسوخًا: المالكون يضعون السياسة؛ والمعماريون يفرضونها. إذا قالت المالية إن الاسم القانوني لا يتغير إلا عبر إجراء ERP بعد أن يصبح العميل نشطًا، فهذا قرار حوكمة. وجعله صحيحًا آليًا هو عملي.
أمين البيانات يحافظ على سير الأمور. الأمين قريب من الصحة اليومية للبيانات: يراقب مؤشرات الجودة، ويحقق في التكرارات، ويحل الاستثناءات، وينسّق الإصلاحات، ويصون التعريفات، ويرصد العملية التي تظل تُنتج بيانات سيئة. وهناك مهمتان أخريان تقعان على الأمين. حين يختلف فريقان حول معنى حقل ما، أو من يملكه، أو من يجوز له رؤيته، يرفع الأمين الخلاف إلى المالك ويتابع القرار حتى يُنفَّذ. ويبني الأمين الثقافة البياناتية (data literacy): يساعد من يُدخلون البيانات ويستخدمونها على فهم معناها ولماذا توجد القواعد. يحتاج الأمين إلى أكثر من اسم على مخطط تنظيمي. يحتاج إلى وقت، ورؤية، وإجراءات، وصلاحية لإصلاح المشكلات. وإلا صار «أمين البيانات» المسؤولية الثامنة لشخص ما، يُنظر فيها مرة كل ربع سنة.
القيّم (custodian) يشغّل النظام. المسؤولون عن الإدارة، وفرق المنصة، وفرق الأمن: كل من يشغّل التقنية التي تخزّن البيانات وتعالجها. يقول المالك إن هذه الأدوار وحدها يجوز لها رؤيتها؛ ويشغّل القيّم الضوابط التي تجعل ذلك واقعًا. الأسماء أقل أهمية من توضيح كل مساءلة، وفي المؤسسة الصغيرة قد يرتدي شخص واحد قبعتين.
كيف يُدار البرنامج
Section titled “كيف يُدار البرنامج ”تأتي برامج الحوكمة عادة في ثلاثة أشكال. المركزي: فريق واحد يكتب السياسات والمعايير لكل نطاق. إنه متسق، وقد يصبح عنق زجاجة، بعيدًا عن الأشخاص الذين يؤدون العمل. الاتحادي (اللامركزي): كل نطاق، كالمالية أو المبيعات أو العمليات، يحكم بياناته ضمن بضع قواعد مشتركة. إنه قريب من العمل، لكن التعريفات تتباعد بين النطاقات. الهجين: فريق مركزي صغير يملك المعايير والتعريفات المشتركة، ومالكو النطاقات وأمناؤها يديرون بياناتهم. معظم المؤسسات التي رأيتها تنتهي في مكان ما ضمن الهجين. بالنسبة للمعماري، يجيب الشكل عن سؤال عملي واحد: من يعتمد السياسة قبل أن أفرضها، وأين تعيش التعريفات المشتركة؟
معلومة للاختبار. اعرف الطرق الثلاث لإدارة برنامج حوكمة، المركزي، والاتحادي (اللامركزي)، والهجين، وما يعنيه كل منها لمن يضع السياسة وأين تعيش التعريفات المشتركة.
اجعل مصفوفة RACI تستحق مكانها
Section titled “اجعل مصفوفة RACI تستحق مكانها ”تساعد مصفوفة RACI (من المسؤول عن التنفيذ Responsible، ومن المُساءَل Accountable، ومن يُستشار Consulted، ومن يُبلَّغ Informed)، لكن ليس جدول بيانات عملاقًا يُصنع لأن الحوكمة «تتطلب واحدًا». أريدها أن تجيب عن أسئلة معمارية، بدءًا بالأسئلة الثلاثة من الفصل 4 (الأسئلة الأربعة وراء الفئات): أين تُنشأ البيانات، وأين تُعدَّل، وأين يُشار إليها؟ هذه غالبًا أنظمة مختلفة. خذ منتجًا: ERP ينشئه، وSalesforce يشير إليه، والبوابة تعرضه، ومستودع البيانات يحلّله. الآن تغيّر جهة العمل معنى «المنتج النشط». أين يبدأ التغيير، ومن يعتمده، وكيف ينتشر، وأي النسخ للقراءة فقط؟ إن لم تستطع الإجابة، فليست لديك حوكمة بعد. لديك نسخ. ومصفوفة RACI الجيدة تكشف هذا الغموض بالضبط.
يجب أن تصبح الحوكمة آلية
Section titled “يجب أن تصبح الحوكمة آلية ”تقول جهة العمل إن المالية وحدها يجوز لها تغيير الاسم القانوني للعميل. لا أريد أن يكون الجواب المعماري «سنغطي ذلك في التدريب». التدريب يساعد؛ لكنه ليس فرضًا. ربما يكون الوصول على مستوى الحقل، أو قاعدة تحقق، أو حقلًا لا يكتبه إلا التكامل، أو إجراءً مضبوطًا بدل التعديل المباشر. تعتمد الآلية على المتطلّب، لكن لا بد من وجود واحدة:
| سياسة الحوكمة | من يقرر من المالكين | نقطة فرض ممكنة |
|---|---|---|
| ERP يملك الهوية القانونية للعميل | المالية | حقول للتكامل فقط، أذونات، تحقق |
| لا يرى البيانات الشخصية إلا من يحتاج إليها | الخصوصية، الأمن | المشاركة، الأذونات، الوصول إلى الحقول |
| معرّفات العملاء فريدة | مالك العمل | External ID فريد، قواعد التكرار |
| السجلات المحكومة لا تُنشأ يدويًا | مالك البيانات | الأذونات، الأتمتة، التكامل |
| للبيانات الحساسة فترة احتفاظ محددة | الخصوصية، الشؤون القانونية | إجراء احتفاظ أو حذف |
| يجب أن تكون التغييرات المهمة قابلة للإثبات | الامتثال | سجل تاريخ الحقول، مسار التدقيق |
| يبقى مصدر البيانات قابلًا للتعرف عليه | مالك البيانات | حقل للمصدر، بيانات وصفية لسلسلة النَّسَب |
أقول نقطة فرض ممكنة عن قصد. هذا ليس جدولًا لاختيار الميزات. إنه ترتيب التفكير: ما السياسة، ومن يملكها، وما الذي في المعمارية يجعلها صحيحة؟
المالكون يضعون السياسة؛ والمعماريون يفرضونها.
لا تعتمد على حسن السلوك
Section titled “لا تعتمد على حسن السلوك ”«لا تغيّر أبدًا معرّف العميل في ERP.» الجميع يعرف ذلك، إلى أن يفعلها أحدهم: عن طريق الخطأ، أو عبر تحميل بيانات، أو عبر الأتمتة، أو عبر تكامل، أو عبر وكيل. إذا كان تغييره سيضر ببيانات المؤسسة، فإن «من فضلك لا تفعل» ليست هي الضابط. ابنِ الضابط. ثِق، لكن تحقّق. الناس والتكاملات والأتمتة والذكاء الاصطناعي كلها تخطئ، لذا ينبغي أن تفترض المعمارية أن شيئًا ما سيحاول في النهاية ما تمنعه السياسة. ماذا يحدث عندها؟
الحوكمة تعبر حدود الأنظمة
Section titled “الحوكمة تعبر حدود الأنظمة ”عودة إلى خريطة الأنظمة. ERP يملك العميل؛ وSalesforce ومستودع البيانات ومنصة بيانات العملاء تحتفظ بنسخ؛ وشريك يحصل على جزء منه. على أي نظام تنطبق السياسة؟ عليها كلها. قد يمنع Salesforce بشكل صحيح تغيير الاسم القانوني بينما يسمح تكامل لنظام لاحق بالكتابة فوقه. وقد يحذف Salesforce بيانات شخصية لا يزال مستودع البيانات يحتفظ بها. وقد ينتهي حقل مصنّف حساسًا في Salesforce في حقل نصي غير مصنّف في مكان آخر. لا يمكن للحوكمة أن تتوقف عند حافة الـ org، لأن البيانات لا تتوقف عندها. لهذا جاء الفصل 4 أولًا: خريطة الأنظمة تخبرك إلى أي مدى يجب أن تصل الحوكمة.
احكم بما يكفي، لا كل شيء
Section titled “احكم بما يكفي، لا كل شيء ”الإخفاق المعاكس حقيقي بالقدر نفسه. نكتشف أن الحوكمة مهمة، فنغلق كل شيء: لا أحد يستطيع الإنشاء، وكل تغيير يحتاج إلى موافقة. البيانات محكومة، ولا أحد يستطيع أداء عمله. الحوكمة تعني الضابط المناسب للبيانات: محكم لبعضها، وخفيف لبعضها الآخر. بعض السجلات يمكن إنشاؤها بحرية، وبعضها يحتاج إلى موافقة؛ بعض الحقول يستطيع أي أحد تقريبًا تعديلها، وبعضها لا يعدّلها إلا التكامل. الوحدة التالية تتناول ذلك عمليًا بالضبط.
ولأن الحوكمة لا تنتهي أبدًا، يحتاج الفرض إلى تغذية راجعة. هل التكرارات في ازدياد؟ هل الحقول الإلزامية تمتلئ بالهراء؟ هل التكاملات تفشل، والمستخدمون يجدون طرقًا للالتفاف، والاستثناءات تتزايد، والأمناء يقضون اليوم كله على مشكلة واحدة؟ هذه المؤشرات تخبرك إن كان التصميم يعمل، وأحيانًا أن الضابط، أو السياسة، يحتاج إلى تغيير.
ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. للحوكمة مستهلك جديد: الوكيل. لا يزال مالك البيانات يقرر ما يجوز استخدامه وفيمَ؛ ولا يزال المعماري يجعل ذلك قابلًا للفرض. ما يتغير هو السرعة والنطاق. الوكيل يقرأ البيانات المحكومة ويجمعها ويتصرف بناءً عليها أسرع بكثير من الإنسان، لذا فإن السياسة الموجودة في وثيقة فقط تحمي أقل من ذي قبل.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- من المُساءَل عن كل نطاق بيانات مهم، وكيف يختلف ذلك عن ملكية السجل.
- من يتولى أمانة البيانات، ومن يشغّلها بوصفه قيّمًا عليها.
- أين تُنشأ البيانات المهمة، وأين تُعدَّل، وأين يُشار إليها، وأين تُدار رئيسيًا عبر خريطة الأنظمة.
- ما نقطة الفرض التي تجعل كل سياسة مهمة صحيحة آليًا.
- كيف تُظهر المعمارية ما إذا كانت الحوكمة تعمل، أو بدأت تتراجع.
حين أسمع متطلّب حوكمة، أترجمه. «ERP يملك هذا.» «هؤلاء الأشخاص فقط يمكنهم رؤية هذا.» «نحتاج إلى إثبات من غيّر هذا.» «احتفظ بهذا سبع سنوات.» وفي كل مرة: أرني نقطة الفرض. المعماري لا يقرر السياسة. نحن نصمم النظام الذي يفرضها. هناك تتوقف الحوكمة عن كونها وثيقة وتصبح معمارية.
للاستزادة
Section titled “للاستزادة ”- Salesforce Help، Sharing and Record Access Features (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).
- Salesforce Help، Data Classification Metadata Fields (opens in a new tab) (بالإنجليزية، تم التحقق في 2026-10-14).