الضوابط على مستوى التطبيقات

الادعاء والاعتراض

ندّعي ما يلي: اختبار الضوابط على مستوى الكيان وحدها لا يكفي للاعتماد على النظام. الاعتماد بدون اختبار ضوابط التطبيق هو افتراض، لا دليل.

اعتراض شائع: لكن اختبار ضوابط التطبيق مكلف ويتطلب خبرة IT لا يملكها كل فريق.

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

كيف تعمل في الواقع

في تفتيش AFM لعام ٢٠٢٤، وجدت الجهة التنظيمية أن ١٨ ملفاً من أصل ٢٥ لم توثّق منطق الضابط الآلي. الفرق وصفت ما يفعله الضابط، لا كيف يفعله. هذه إجراءات صورية، لا اختبار.

ISA 315.27 يطلب فهم الضوابط على مستوى التطبيقات ذات الصلة بالتأكيدات المهمة، وISA 315.A116 يوسّع المتطلب: على المراجع أن يفهم كيف يعالج النظام المعاملات، لا مجرد أن يقبل وصف الإدارة.

في الميدان، هنا تعيش الأسئلة الصعبة. متى تقبل وصف الإدارة لمنطق الضابط؟ ومتى تنزل بنفسك إلى قاعدة البيانات وتفتح الكود أو إعداد النظام؟ ISA 315.A116 لا يحدد العمق المطلوب بدقة. يطلب الفهم. أما عمق الفهم، فهو حكم مهني.

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

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

الفرق بين الفهم والافتراض هو سطر كود.

ضابط على مستوى الكيان مثل "المجلس يراجع ويوافق على جميع العقود التي تتجاوز مليون يورو" يغطي العقود عبر العمليات كافة. الضابط على مستوى التطبيق يعمل على بيانات واحدة في سياق واحد. لاحظنا أن الفرق التي تخلط بين الاثنين تنتهي عادة بضوابط ورقية على مستوى الكيان وفجوة كاملة في مستوى التطبيق.

مثال عملي: شركة الزراعة المتكاملة ش.م.ل

العميل: شركة متخصصة في معالجة الحبوب، إيرادات سنوية ٢٨ مليون يورو، نظام ERP متكامل للمبيعات والمستودعات.

الخطوة ١: تحديد التطبيق والعملية المهمة نظام المبيعات في ERP يعالج ١٢ ألف فاتورة سنوياً. العملية: من استقبال الطلب إلى إصدار الفاتورة وتسجيلها. التأكيد المهم: الإيرادات المسجلة صحيحة وفي الفترة المناسبة.

في ورقة العمل نوثّق اسم التطبيق "نظام ERP System-X"، والعملية المغطاة، والحقول والجداول ذات الصلة. الملف ينبغي أن يحكي قصة، لا أن يسرد عناوين.

الخطوة ٢: تحديد الضوابط على مستوى التطبيق الشركة طبّقت ثلاثة ضوابط: 1. التحقق التلقائي من أن عنوان الشحن المُدخل يطابق عنوان العميل المسجل في قاعدة البيانات (ضابط آلي). 2. التحقق التلقائي من أن كمية الطلب لا تتجاوز المخزون المتاح في المستودع (ضابط آلي). 3. مراجعة يدوية من موظف المبيعات لجميع الفواتير التي تتجاوز ١٠٠ ألف يورو قبل الإرسال (ضابط يدوي).

لكل ضابط آلي نوثّق آلية عمله، الحقول المعنية، وآلية الكشف عن الانحرافات. للضابط اليدوي نوثّق من يقوم به، المعايير المستخدمة، وسجل الموافقات.

الخطوة ٣: اختبار فعالية الضوابط اختبرنا عينة من ٣٠ فاتورة من أصل ١٢ ألف، موزعة على أربعة أشهر. لكل فاتورة تحقّقنا من: - مطابقة بيانات العنوان للسجل (الضابط الأول). - عدم تجاوز الكمية للمخزون المسجل في نظام المستودع (الضابط الثاني). - وجود دليل موافقة من موظف المبيعات على الفواتير فوق ١٠٠ ألف يورو (الضابط الثالث).

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

عند فحص السبب، اكتشفنا أن الضابط الآلي يقبل تجاوز المطابقة عبر "علم" (flag) خاص بعملاء VIP، وأن دور المستخدم في المبيعات يملك صلاحية ضبط هذا العلم بنفسه.

السؤال هنا ليس "هل نقبل انحرافاً واحداً من ٣٠؟". السؤال أعمق: هل هذا انحراف واحد، أم خلل في تصميم الضابط بأكمله؟

من واقع خبرتنا، هذه ليست حالة إفرادية. الضابط الآلي الذي يمكن للمستخدم تعطيله ليس ضابطاً آلياً. إنه اقتراح. ومنطق الصلاحيات هو الضابط الحقيقي، وهو نادراً ما يُختبر.

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

ما يفعله الفريق ولا يجب أن يفعله

- الخلط بين الضوابط على مستوى التطبيق والضوابط اليدوية العامة: بعض الفرق تصنّف كل الضوابط اليدوية كـ"ضوابط على مستوى الكيان" ولا تقيّم تلك التي تحدث داخل نظام معيّن. ISA 315.30 يوضح أن الضابط اليدوي داخل تطبيق (مثل موافقة فاتورة قبل الإرسال) هو ضابط على مستوى التطبيق، وفعاليته تعتمد على تصميم العملية والمراقبة المستمرة، لا على وجود سياسة مكتوبة.

- عدم توثيق منطق الضابط الآلي: عند اختبار ضابط آلي، يجب توثيق آلية عمله (المنطق، الحقول، جداول البيانات)، لا مجرد اختبار نتيجة واحدة. ISA 315.A116 يطلب فهماً كاملاً لكيفية عمل النظام. ملفات AFM تظهر فرقاً قالت "الضابط آلي ولا حاجة لاختباره" دون أي إثبات لفهمه. اختبار "تحقّقنا من أن الضابط آلي" دون فهم منطق الكود هو مجرد كتابة. ليس اختباراً.

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

الاجتهاد المشروع: شريكان، رأيان

في مكتبنا ناقشنا هذه المسألة مرات عدة، وانقسم الشركاء:

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

كلا الموقفين له سند. ISA 315.A116 يطلب الفهم، لكنه لا يحدد عمق التحقق المطلوب. ما نراه في الممارسة هو أن الموقف الأول يكفي للضوابط البسيطة منخفضة المخاطر، أما الضوابط التي يتوقف عليها اعتماد الاختبار الجوهري بنسبة كبيرة، فلا غنى عن الموقف الثاني.

الضوابط على مستوى التطبيق مقابل الضوابط على مستوى الكيان

متى يكون الفرق مهماً على ملف حقيقي

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

نُفضّل اختبار ٤ أو ٥ ضوابط تطبيق رئيسية بدلاً من ١٥ ضابط كيان، لأن الأخطاء تحدث داخل البيانات لا في سياسة المجلس. هذا ليس رأياً جمالياً. هو اختيار تكلفة-عائد: وقت الفريق محدود، ومنطق الكود هو المكان الذي تتسرّب منه الأخطاء.

اختبار الضوابط على مستوى التطبيق في أهم عمليتين يقلّص حجم الاختبار الجوهري المطلوب. إذا ثبتت فعالية الضوابط على المبيعات والمستودعات، يمكن تقليل حجم عينة الاختبار الجوهري بنسبة ٣٠ إلى ٤٠٪ مقارنة بالسيناريو الذي لا توجد فيه ضوابط موثوقة. AFM تكتب نفس الملاحظة كل دورة. الفرق تُغيّر الصياغة، لا الممارسة.

المصطلحات ذات الصلة

- الضوابط على مستوى الكيان - الضوابط التنظيمية التي تغطي جميع العمليات والأنظمة، مثل سياسات المجلس والإجراءات الإدارية العامة. - الضوابط اليدوية - الإجراءات التي يؤديها الإنسان بدلاً من النظام، مثل المراجعة والموافقة. - الضوابط الآلية - الإجراءات المدمجة في النظام والتي تعمل تلقائياً دون تدخل بشري. - مخاطر الأخطاء الجوهرية - احتمالية عدم كشف خطأ جوهري بواسطة ضابط ما قبل تسجيله. - معيار المراجعة الدولي ٣١٥ - معيار تقييم الأنظمة والضوابط الداخلية المتعلقة بمخاطر الأخطاء الجوهرية.

أدوات Ciferi ذات الصلة

قائمة مراجعة تقييم الضوابط على مستوى التطبيق - نموذج عملي يساعد في توثيق الضوابط والتحقق من فعاليتها.

---