كيف يُدقَّق الملف التقني قبل قرار منح الشهادة؟

إجابة موجزة: متى يكون الملف الفني جاهزًا للقرار؟

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

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

ما البوابات السبع التي ينبغي فحصها قبل القرار؟

إجابة موجزة: لا يُعد الملف مكتملًا قبل اجتياز الهوية والنطاق والمتطلبات المطبّقة والدليل وحالات عدم المطابقة والمراجعة المستقلة ومُدخلات القرار مجتمعةً.

1. هوية المنتج: هل المودل والنوع والمتغير ونطاق الدفعة/التسلسل والتنقيح الفني متطابقة؟
2. البرنامج والنطاق: هل يصف الطلب والعقد وبرنامج منح الشهادات ونطاق الشهادة المطلوب المنتج نفسه؟
3. المتطلبات المطبّقة: هل حُددت الإصدارات السارية للتشريعات والمعايير وقواعد البرنامج ومتطلبات العميل؟
4. كفاية الدليل: هل يرتبط كل متطلب بدليل قابل للتحقق مثل رسم أو سجل مخاطر أو حساب أو تقرير فحص أو اختبار؟
5. إغلاق الملاحظات: هل توجد حالة عدم مطابقة مفتوحة أو تقييم إضافي معلّق أو تصحيح غير موثّق؟
6. المراجعة المستقلة: هل سجّل شخص مخوّل لم يشارك في التقييم اكتمال المعلومات والإجراءات المناسبة؟
7. حزمة القرار: هل يستطيع متخذ القرار رؤية النطاق ونتيجة المراجعة والاستثناءات والمخاطر المفتوحة في عرض واحد؟

كيف ينبغي بناء مصفوفة المتطلب والدليل؟

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

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

كيف تُختبر الاتساقية داخل الملف؟

إجابة موجزة: قارن الهوية الحرجة نفسها عبر وثائق مختلفة، واجعل التعارض مانعًا للقرار لا مجرد تنبيه.

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

يشرح الدليل الأزرق 2022 الصادر عن المفوضية الأوروبية أيضًا أن مسار تقييم المطابقة يتوقف على المنتج والقاعدة المطبّقة. لذلك فإن تقرير اختبار أو علامة CE أو شهادة سابقة ليست وحدها دليل قرار كافيًا لكل برنامج.

لماذا ينبغي الفصل بين المراجعة الفنية والقرار؟

يشرح دليل تقييم المطابقة المحدّث من ISO/IEC توثيق نتائج التقييم قبل المراجعة، وإجراء المراجعة من شخص لم يشارك في التقييم، وإصدار القرار بعد اكتمال المراجعة. وحتى تولى الشخص نفسه المراجعة والقرار، يبقى التمييز بعدم المشاركة في نشاط التقييم قائمًا.

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

كيف ينبغي إدارة إصدار المعيار والبرنامج؟

ينبغي أن تخضع قائمة الفحص لإدارة الإصدارات مع الملف. ففي الجرد الرسمي لـISO، لا تزال ISO/IEC 17065:2012 وISO/IEC 17067:2013 الإصدارين المنشورين؛ أما تنقيحات 2026 فهي في مرحلة تطوير مسودة المعيار الدولي النهائية (FDIS). ولا ينبغي تطبيق النص المسودة تلقائيًا كمتطلب منشور.

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

كيف تُصمَّم بوابة القرار القائمة على مبدأ الفشل المغلق في البرنامج؟

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

1. أنشئ صفوف المتطلبات الإلزامية من إصدار البرنامج.
2. اربط كل صف بتنقيح المنتج وهوية الدليل.
3. اعرض الملاحظة المفتوحة أو الدليل الناقص أو الهوية المتعارضة أو التقييم المعلّق كعائق.
4. تحقق مما إذا كان المراجع ضمن فريق التقييم ومن نطاق صلاحيته.
5. التقط لقطة للمصفوفة المستخدمة لحظة القرار ومرفقاتها كحزمة ثابتة.
6. أدر التغييرات اللاحقة كتنقيح جديد وسجل أثر دون استبدال حزمة القرار القديمة.

المسار الكامل لبرمجيات منح شهادات المنتجاتيشرح نموذج البيانات الأوسع بين الطلب والشهادة. دليل تنقيح الوثائق وسجل الموافقات يفصّل بدوره كيفية الحفاظ على أثر التغيير.

ما السيناريوهات التي ينبغي اختبارها في التجربة التطبيقية لـVizyon Cert؟

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

• ارفع تقرير اختبار يعود إلى تنقيح منتج خاطئ.
• اترك متطلبًا إلزاميًا بلا دليل.
• حاول فتح قرار مع حالة عدم مطابقة غير مغلقة.
• عيّن المستخدم الذي أجرى التقييم مراجعًا.
• غيّر الرسم بعد حزمة القرار وتحقق من أن الحزمة السابقة لم تتغيّر.

معيار النجاح ليس مجرد وسم "اكتمل الملف". بل يجب للنظام أن يوضّح عند أي متطلب يقع النقص؛ ويحفظ أثر إعادة المراجعة بعد التصحيح؛ ولا يعرض لمتخذ القرار إلا الإصدار الصالح.