تطوير المنظومة الرقمية في السعودية: ما الذي يُطلب منك إثباته ولمن

تطوير المنظومة الرقمية في السعودية: ما الذي يُطلب منك إثباته، ولمن؟

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

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

جدول الجهات والالتزامات

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

وسطران يستحقان التوضيح لأن الخطأ فيهما مكلف.

الأول: من يتحمّل الالتزام. ضوابط الحوسبة السحابية تُلزم المزوّد والمشترك معًا في نطاق انطباقها، فالتزاماتك لا تنتقل بالتعاقد مهما نصّ العقد. اسأل مزوّدك عن النسخة التي بُني عليها التصميم، وما الذي يقع عليك أنت.

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

ما الذي يتغيّر في مواصفات نظامك

يُترجَم الجدول أعلاه إلى ستة بنود تُكتب في المواصفات قبل التعاقد. وكتابتها في هذه المرحلة أقل كلفة من إضافتها بعد اعتماد المعمارية:

1. سجل بيانات شخصية. قائمة بأنواع البيانات الشخصية التي يحفظها النظام وأين، تُنتَج من النظام لا من ذاكرة أحد.
2. تقييد الوصول بالدقة التي يتطلّبها نوع البيانات. «من يرى الشاشة يرى كل ما فيها» يكفي لبيانات ولا يكفي لأخرى. حدّد أي الحقول حسّاس فعلًا في نظامك، واطلب تقييدًا على مستوى الحقل حيث يلزم ذلك — لا كقاعدة عامة لكل شاشة، فذلك يرفع الكلفة بلا مقابل.
3. سجل أحداث صالح للتدقيق. يُسجّل من فعل ماذا ومتى، ولا يمكن تعديله من داخل التطبيق.
4. مسار لطلبات صاحب البيانات. إجراء مُنفَّذ في النظام للعثور على سجلات شخص واحد والاستجابة لطلب يخصّه ضمن مدة معقولة.
5. سياسة احتفاظ قابلة للتطبيق. مدة احتفاظ لكل نوع بيانات، ينفّذها النظام تلقائيًا لا مذكرة داخلية.
6. استرجاع مُختبَر. نسخ احتياطي مع اختبار استرجاع دوري موثّق — فالنسخة التي لم تُختبَر لا تكفي وحدها لإثبات إمكانية الاسترجاع.

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

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

الطبقات الأربع، وأي جهة تمسّ كل طبقة

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

من الأخطاء الشائعة البدء بطبقة القنوات لأنها المرئية، بينما قد يقع القرار الذي يؤثر في نتيجتها ضمن طبقتي البيانات والأنظمة. موقع جميل فوق بيانات متناقضة يعرض التناقض بشكل أسرع.

وتفاصيل الطبقة الأولى في السحابة والبنية التحتية، والثالثة والرابعة في تطوير البرمجيات المخصصة.

ثلاثة أخطاء تجعل الالتزام أغلى مما يجب

الأول: معالجة الالتزام بعد اعتماد المعمارية. إضافة التحكّم على مستوى الحقل أو سجل التدقيق إلى نظام مكتمل قد تتطلّب إعادة تصميم، لا مجرد إضافة ميزة. ما تفعله: اجعل الستة بنود في شروط القبول، واجعل مراجعة المستشار النظامي على التصميم لا على النظام المسلَّم.

الثاني: الاكتفاء بالسياسات المكتوبة. وجود الوثيقة لا يثبت وحده أن الضابط مطبَّق. ما تفعله: لكل سياسة، حدّد ما الذي يُنتجه النظام كدليل — تقرير، أو سجل، أو إعداد قابل للعرض.

الثالث: افتراض أن التعاقد ينقل الالتزام. ضوابط الحوسبة السحابية تنطبق على المزوّد والمشترك معًا. ما تفعله: اكتب في العقد من يُنتج أي دليل لأي ضابط، لا من «يتحمّل المسؤولية» بعبارة عامة.

كيف تتحقق من مزوّد في هذا الجانب تحديدًا

أربعة أسئلة تساعدك على تقييم مستوى المزوّد:

• أي الضوابط بالتحديد بُني عليها هذا التصميم، وكيف نُثبت تطبيق كل واحد منها؟
• أين تُعالَج مسألة توطين البيانات في تصميمكم، وعلى أي أساس؟
• ما الذي سيُنتجه النظام كدليل على ضبط الوصول وسجل الأحداث؟
• من يُنتج أي دليل بعد الإطلاق — نحن أم أنتم — وأين ذلك في العقد؟

كيف تقرأ الإجابات: الإجابة العامة عن السؤال الأول («نتبع أفضل الممارسات») لا تكفي لإثبات أن التصميم بُني على ضابط بعينه — فاطلب اسم الضابط ورقمه. والإجابة غير الدقيقة عن السؤال الثاني — مثل إحالة التوطين إلى ضوابط الحوسبة السحابية وحدها — قد تشير إلى معرفة غير محدّثة. أما السؤال الرابع فيساعد على تقليل نزاع محتمل بعد الإطلاق حول الجهة المسؤولة عن إنتاج الدليل.

القرارات المجاورة، وأين تُتخذ

• ما الذي أشتريه وما الذي يحدد سعره؟ دليل خدمات التحول الرقمي.
• أي فئة حلول تعالج العَرَض الذي أراه؟ دليل حلول التحول الرقمي.
• أي أنظمتي يُبقى ويُستبدَل ويُوقَف؟ دليل التحديث الرقمي.
• من يملك أي قرار بعد التغيير؟ دليل نموذج التشغيل الرقمي.

كيف تعمل ألف ياء

الدور الذي تؤدّيه ألف ياء في هذا الجانب هو الترجمة: من التزام منطبق إلى متطلب مكتوب في مواصفات النظام قابل للاختبار عند التسليم — لا إصدار رأي في الانطباق نفسه، فذلك عمل المراجعة النظامية والمستشار القانوني.

ومسألة من يُنتج أي دليل بعد الإطلاق تُحدَّد في كل ارتباط، لأنها لا تنتقل بالتعاقد وحده. ونماذج من الأعمال في أعمالنا، ونطاق العمل في التحول الرقمي المؤسسي.

وهذا المقال لا يغني عن مراجعة نظامية: نطاق انطباق كل متطلب على منشأة بعينها يعتمد على نشاطها وبياناتها.

الخطوة التالية

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

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