يُخطئ كثيرون حين يُقيّمون صعوبة دورة قياس التحول الرقمي لعام ٢٠٢٦ بعدد المعايير فحسب أو بحجم التغييرات الكبرى والمُعلنة. الحقيقة أن الجزء الأثقل أحياناً يأتي من تحديثات لا تستأثر بالعناوين، بل تختبئ في طيّات الوثيقة وتكشف عن نفسها للجهة المُدققة التي تتأمل كل معيار بعين المتخصص. وهذه التدوينة مخصصة لمدراء تقنية المعلومات وقادة التحول الرقمي الذين يريدون قراءة الوثيقة بعمق، والذين يدركون أن التحديثات “الفرعية” تُكلّف نقاطاً حقيقية مثلها مثل التحديثات الرئيسية. ثلاثة محاور تستحق وقوفاً تفصيلياً: اشتراط خطة التدقيق الداخلي على تقنية المعلومات وهو متطلب جديد مُضاف لم يكن موجوداً في الإصدار السابق، ومنظومة تنظيم البرمجيات مفتوحة المصدر التي توسّعت متطلباتها بشكل ملموس، وإشراك قيادات التحول الرقمي عبر توفير أدوات رقمية لهم وهو معيار يبدو بسيطاً لكنه يُخفق كثيرون في توثيقه.
Blog Body
أولاً: خطة التدقيق الداخلي على تقنية المعلومات، المتطلب الجديد الذي يُفاجئ أكثر الجهات استعداداً
ضمّت وثيقة الإصدار الخامس لعام 2026 متطلباً لم يكن موجوداً بوضوح في الإصدار الرابع وهو تطوير وتنفيذ خطة تدقيق داخلي على تقنية المعلومات وفقاً لضوابط حوكمة تقنية المعلومات الصادرة من الهيئة، مع وضع خطة معالجة لمخرجات هذا التدقيق واعتمادها من أصحاب الصلاحية.
لماذا هذا المتطلب وما الذي يعنيه عملياً؟
حوكمة تقنية المعلومات لا تعني فقط وجود سياسات وإجراءات، بل تعني أيضاً آلية مستقلة تُراجع مدى تطبيق هذه السياسات وتكشف الفجوات وتُنتج خطة معالجة. التدقيق الداخلي هو هذه الآلية. وإصدار 2026 يُضفي عليه طابعاً رسمياً بأن يُطلب إثبات خطة تدقيق مُعتمدة لا مجرد ادّعاء بأن التدقيق يجري.
والمعيار الذي يُعبّر عن هذا التطلب هو 5.12.2 تنفيذ ومتابعة أعمال إدارة الخدمات التقنية الذي أُضيف إليه في الإصدار الخامس البند السابع صراحةً بتطوير وتنفيذ خطة تدقيق داخلي على تقنية المعلومات وفق ضوابط الحوكمة، مع اشتراط اعتماد خطة المعالجة من أصحاب الصلاحية. ويُطلب إثباتها عبر إرفاق خطط التدقيق المعتمدة.
ما الفرق بين التدقيق الداخلي على تقنية المعلومات والمراجعة التشغيلية الاعتيادية؟
المراجعة التشغيلية تنظر في مؤشرات الأداء والتقارير الدورية وهي عمل إداري روتيني. أما التدقيق الداخلي فهو عملية مستقلة تفحص مدى التزام الممارسات الفعلية بالسياسات والضوابط المعتمدة، وتكشف الثغرات التي قد لا تظهر في التقارير الاعتيادية، ثم تُنتج مخرجات موثقة تُعالَج وتُعتمد من قيادة الجهة.
وبهذا المعنى، خطة التدقيق الداخلي على تقنية المعلومات تُجيب عن سؤال محوري: هل ما تُطبقه إدارة التقنية فعلاً يتطابق مع ما تقوله وثائقها وسياساتها؟ وهذا التحقق المستقل هو جوهر حوكمة تقنية المعلومات الناضجة التي يدفع إليها الإصدار الخامس.
كيف تُبنى خطة تدقيق داخلي قابلة للإثبات؟
تبدأ خطة التدقيق الداخلي بتحديد نطاق التدقيق وهو المجالات التقنية التي ستُراجع، وتحديد دوريته، وأسلوب تنفيذه سواء ذاتياً من داخل الجهة أو بمشاركة جهة مراجعة مستقلة. ثم تُحدد المرجعية التي يُقاس بها الامتثال وهي ضوابط حوكمة تقنية المعلومات الصادرة عن هيئة الحكومة الرقمية وأُطر أخرى كـ ISO 38500 للحوكمة و COBIT. وتنتهي الخطة بمرحلة المخرجات وهي التقرير الذي يُرفع لأصحاب القرار، وخطة المعالجة المعتمدة التي تُغلق الفجوات المكتشفة.
الجهة التي لا تمتلك اليوم خطة تدقيق داخلي مُعتمدة ومُوثقة تحتاج أن تشرع فوراً في تصميمها، لأن هذا المتطلب يستلزم وقتاً للتنفيذ والتوثيق، وهو لا يُستوفى بإعداد وثيقة قُبيل الإغلاق بل بتنفيذ دورة كاملة تُنتج أدلة استخدام وتقارير نتائج.
ثانياً: منظومة البرمجيات مفتوحة المصدر، توسّع جوهري في الإصدار الخامس
كان معيار البرمجيات مفتوحة المصدر موجوداً في الإصدار الرابع لكنه جاء أكثر هيكلية وتفصيلاً مع متطلبات كمية جديدة في الإصدار الخامس. والجهة التي استوفت المتطلبات القديمة لا تضمن استيفاء ما طُرح في 2026 دون مراجعة شاملة.
ما الذي يهدف إليه هذا المعيار؟
تسعى الهيئة من خلال هذا المعيار إلى تحقيق جملة من الأهداف الاستراتيجية المترابطة: تعزيز إعادة استخدام البرمجيات بين الجهات الحكومية بدلاً من بناء حلول متشابهة بشكل منفرد، والحدّ من الاحتكار التقني الذي ينشأ حين تُقيّد الجهة بمورد واحد لا يمكنها الخروج من دائرته بسهولة، ورفع الشفافية في كيفية بناء البرمجيات الحكومية وإدارتها.
المتطلبات الكمية الجديدة التي تُفاجئ كثيرين
أضاف الإصدار الخامس متطلبات أرقام لم تكن موجودة بهذا الوضوح من قبل، أبرزها:
تُلزَم الجهة بإيداع ما لا يقل عن 20% من البرمجيات المحصورة لديها في مستودع البرمجيات الحكومية، وهذا الرقم يعني أن الجهة يجب أن تُحصر برمجياتها أولاً ثم تُحدد منها ما يقع ضمن الـ20% المستهدفة وتُعدّ جدولاً زمنياً لرفعها.
كذلك تُلزَم الجهة بوضع خطة إيداع للبرمجيات مفتوحة المصدر للسنوات الثلاث القادمة لكافة البرمجيات التي طوّرتها داخلياً أو تعاقدت على تطويرها سواء مع موردين محليين أو دوليين.
ومن أكثر المتطلبات أثراً هو اشتراط استبدال البرمجيات المغلقة المصدر التي تتطلب رخصاً ببدائل مفتوحة المصدر أو بحلول من موردين خدمة محليين أو بمنتجات حكومية سحابية. وهذا يعني مراجعة الأنظمة القائمة وتقييم مدى إمكانية الاستبدال والتخطيط له.
الخطوات المتسلسلة التي تشترطها الوثيقة
تضع الوثيقة تسلسلاً صريحاً لآلية اتخاذ قرار الشراء أو التطوير، وهي ثلاث خطوات مترتبة لا يُمكن تجاوزها:
تبدأ بتقييم البرمجيات الحكومية المتوفرة في المستودع واستخدامها إن كانت تُلبي الحاجة، فإن تعذّر ذلك تنتقل إلى البحث عن برمجيات جاهزة مع إعطاء الأفضلية للبرمجيات الحرة مفتوحة المصدر بالتنسيق مع الهيئة، فإن لم يكن في الاثنين ما يُلبي الحاجة تُبني الجهة برمجياتها الخاصة.
هذا التسلسل ليس توجيهاً اختيارياً بل شرط يُثبته المعيار بعقود التطوير والمشتريات، ويُطلب إثباتاً بأن الجهة سلكت هذا المسار.
شروط التعاقد مع الموردين، تفاصيل تُكلّف أو تُكسب
يُضيف الإصدار الخامس اشتراطات تعاقدية صريحة يجب أن تنعكس في عقود تطوير البرمجيات: تسليم الشفرة المصدرية كاملةً مع وثائقها، وضمان حقوق غير محدودة تُتيح للجهة إعادة الاستخدام والتعديل والتوزيع بين الجهات الحكومية دون الحاجة للمورد الأصلي، والتأكيد على أن أي تطوير إضافي على برمجيات تجارية مُشتراة تؤول ملكيته أو حق استخدامه للحكومة. وإعطاء الأولوية في التعاقد للموردين الوطنيين المستوفين للمتطلبات الفنية.
أين تقع الجهات في فجوات هذا المعيار؟
تكشف التجربة الميدانية أن كثيراً من الجهات لديها عقود قائمة بُرمت دون هذه الاشتراطات، مما يعني أن البرمجيات المُستلمة لا تُرافقها شفرة مصدرية وأن الملكية ليست محسومة للجهة. وهذا ليس تقصيراً أخلاقياً بل نتيجة لعقود لم تُصَغ في ضوء هذه الضوابط. أما في عقود المستقبل، فلا عذر لتجاهلها.
وتجدر الإشارة إلى أن الجهات الأمنية والعسكرية تخضع لأحكام مختلفة تُستثنى بموجبها من بعض متطلبات البرمجيات مفتوحة المصدر حسب ما تُقرره أنظمتها الداخلية.
ثالثاً: إشراك القيادات وتمكينهم بالأدوات الرقمية
يبدو معيار استخدام الأدوات التقنية المساعدة في أداء أعمال الجهة (5.4.3) عند أول قراءة وكأنه اشتراط بسيط: وفّر للموظفين الأدوات والبرمجيات التي يحتاجونها. لكن حين يُقرأ مع معيار إشراك قيادات التحول الرقمي (5.5.3) تتّضح أهميته المؤسسية الحقيقية.
ماذا يشترط معيار تمكين القيادات بالأدوات؟
يُلزم المعيار الجهة بتوفير آلية واضحة لتلبية طلبات المنسوبين لأي برمجيات أو رخص داعمة للأدوات الرقمية التي يستخدمونها في أعمالهم اليومية، مع تنظيم ورش تدريبية أو دورات قصيرة على استخدام هذه الأدوات. والإثبات المطلوب هو صور الشاشات التي تُثبت تطبيق الآلية، وتقارير الورش والدورات.
قد يبدو هذا مُستوفىً تلقائياً في كثير من الجهات، لكن ما يكشفه تقارير القياس هو أن “الآلية” هي المحور الحساس لا الأداة بحد ذاتها. الجهة التي تُوفر الأدوات دون آلية موثقة تفشل في المعيار، والجهة التي تمتلك آلية لكنها لا تُطبقها تفشل أيضاً. والمطلوب مسار واضح ومُوثق يُثبت أن الطلب وصل، وأن الاستجابة جاءت، وأن المنسوب تدرّب على الأداة.
ماذا يشترط معيار إشراك القيادات؟
يُركّز معيار (5.5.3) على إشراك القادة المؤهلين في مجال التحول الرقمي ضمن اللجان الفاعلة وعمليات صنع القرار، مع تعيين القادة المؤهلين في مناصب قيادية حين تتاح الفرصة. والإثبات المطلوب قرارات تكوين اللجان التي تُظهر أسماء القادة المؤهلين كأعضاء، وقرارات التعيين عند توافرها.
هذا المعيار يُجسّد منطقاً جوهرياً: ليس كافياً تأهيل القيادات وتدريبها إذا لم تُستثمر هذه الكفاءات فعلياً في اتخاذ القرارات الرقمية داخل الجهة. فالتأهيل دون توظيف هو استثمار لا يُنتج عائداً مؤسسياً، وهو ما يرصده المعيار ويُقيّم الجهة عليه.
العلاقة بين معيار إشراك القيادات بالتحول الرقمي ومعايير تطويرهم
يُشكّل المحور 5.5 كاملاً منظومة متسلسلة: يبدأ بالتخطيط لتأهيل القيادات (5.5.1)، ثم تنفيذ خطة التأهيل ومتابعتها (5.5.2)، ثم إشراك هؤلاء القادة فعلياً (5.5.3)، وصولاً إلى الاستقطاب والتعاون في هذا المجال (5.5.4). والجهة التي تستوفي التأهيل لكن لا تُثبت الإشراك تفقد نقاطاً على خطوة هي امتداد طبيعي لما أنجزته.
رابعاً: تحديثات فرعية أخرى تستحق الانتباه
بجانب المحاور الثلاثة الرئيسية، تحمل وثيقة 2026 جملةً من التحديثات الفرعية التي تبقى تحت الرادار حتى تكشف عن نفسها في ملف الإثبات:
متطلب توفير أدوات رقمية لقيادات التحول الرقمي (5.5.3 الجديد)
يُضاف إلى الإشراك اشتراط تقديم بيانات وتقارير دعم اتخاذ القرار للقيادات عبر أدوات رقمية، بحيث يمتلك القائد المعني فعلياً إمكانية الوصول للبيانات اللازمة لدعم قراراته الرقمية. وهذا يعني ليس فقط منح الصلاحية بل توفير الأداة التي تُمكّنه من استخدامها.
تحديث معايير اتفاقيات مستوى الخدمة التشغيلية (5.12.1)
أُضيف اشتراط تحديد وتحديث اتفاقيات مستوى الخدمة التشغيلية بما يشمل الاتفاقيات مع أطراف خارجية ومزودي الخدمات، مع متابعة فاعليتها وتقييمها دورياً. وهذا يُلزم الجهة بأن تكون هذه الاتفاقيات حيّة ومُراجعة لا وثائق مرجعية تُنسى في أدراج النظام.
توسّع في متطلبات الأتمتة والتوثيق لمسار تطوير التقنيات
يُضاف اشتراط توثيق جميع مراحل تطوير التقنيات الداعمة لأعمال الحكومة الرقمية واحتفاظها مرجعاً لأي تطوير لاحق، مما يُرسّخ ثقافة الذاكرة المؤسسية التقنية بدلاً من المعرفة الفردية المرتبطة بأشخاص بعينهم.
خامساً: لماذا تُكلّف هذه التحديثات الدقيقة الجهات أكثر مما تتوقع؟
ثمة نمط مشترك تكشفه التجربة الميدانية: الجهات التي تُركّز استعدادها على المعايير الكبرى كتحقيق مستهدف السحابة في ٢٠٢٦ والخدمات الاستباقية والبنية المؤسسية تدخل مرحلة التقديم وتكتشف أن نقاطاً ثمينة ضاعت على معايير يظنّها كثيرون مُستوفاةً تلقائياً.
عدم امتلاك خطة تدقيق داخلي مُعتمدة، وعقود تطوير برمجيات لا تتضمن بنود الشفرة المصدرية، وآلية تلبية طلبات الأدوات موجودة لكن غير موثقة بالشكل المطلوب، وقادة مؤهلون لكن ليسوا ضمن اللجان بشكل رسمي — كل هذه تُمثّل فجوات قابلة للمعالجة حين تُكتشف مبكراً، لكنها تُصبح مكلفة حين تظهر في تقرير القياس.
دور الشريك الاستشاري المتخصص هنا ليس معرفة أن هذه المعايير موجودة، بل معرفة كيف تُقرأ بعين المُدقق الذي يبحث عن الإثبات الكافي لا فقط الوجود الشكلي. وريناد المجد (RMG) تُوظّف في هذا السياق خبرة متراكمة عبر دورات قياس متعددة، ومعرفة عملية بضوابط حوكمة تقنية المعلومات الصادرة عن الهيئة واشتراطات منظومة البرمجيات مفتوحة المصدر وكيفية توظيفها في بناء خطة تدقيق داخلي قابلة للإثبات بعقود نموذجية تستوفي شروط التعاقد.
الأسئلة الشائعة
هل التدقيق الداخلي على تقنية المعلومات متطلب جديد كلياً أم تطوير لمتطلب قائم؟
هو متطلب مُضاف صراحةً كبند سابع ضمن معيار تنفيذ ومتابعة أعمال إدارة الخدمات التقنية (5.12.2) لم يكن موجوداً بهذا الوضوح في الإصدار الرابع. وعلى الرغم من أن الحوكمة الجيدة كانت تتضمن نوعاً من المراجعة الداخلية تقليدياً، إلا أن الوثيقة الجديدة تُلزم بخطة تدقيق مُعتمدة مع مخرجات قابلة للإثبات.
ما معنى اشتراط 20% إيداع في مستودع البرمجيات، وكيف تُحتسب هذه النسبة؟
تُحتسب من إجمالي البرمجيات المحصورة لدى الجهة، وتعني أن ما لا يقل عن خُمس هذه البرمجيات يجب أن يكون مودعاً أو مُجدولاً للإيداع في مستودع البرمجيات الحكومية. ويبدأ تحقيق هذه النسبة من حصر دقيق شامل لجميع البرمجيات، ثم تصنيف ما هو مفتوح المصدر منها وتحديد أولوية رفعه.
هل تنطبق متطلبات البرمجيات مفتوحة المصدر على كل أنواع البرمجيات لدى الجهة؟
تنطبق المتطلبات على جميع الجهات الحكومية فيما يخص حصر الأصول وإعداد خطة الإيداع. أما المتطلبات الأكثر تفصيلاً كإصدار الرخصة والاستبدال بالبدائل المفتوحة فتنطبق على الجهات بحسب تصنيفها مع استثناء الجهات الأمنية والعسكرية التي تخضع لأحكام خاصة.
ما الذي يُثبت إشراك قيادات التحول الرقمي فعلياً لا شكلياً؟
يُثبته توافر اسم القائد المؤهل ضمن قرار تكوين اللجنة الفاعلة ذات العلاقة بالتحول الرقمي، وحضوره الموثق في محاضر الاجتماعات، ومشاركته الفعلية في القرارات المتخذة. مجرد وجوده في قائمة الأعضاء دون محاضر اجتماعات تُثبت المشاركة لا يكفي.
كيف تُوثّق الجهة آلية تلبية طلبات الأدوات الرقمية بشكل مقبول؟
تُوثّق عبر مسار عمل واضح يُظهر كيف يُقدّم المنسوب طلبه سواء عبر نظام إدارة الخدمات أو نموذج معتمد أو بريد رسمي، وكيف تُستجاب هذه الطلبات، وما هي فترة الاستجابة القياسية. ويُعزّز هذا الإثبات صور الشاشات التي تُظهر طلبات حقيقية وردوداً عليها، وتقارير الورش التدريبية على الأدوات التي نُفّذت فعلاً.
