في بيئات التسليم الدولية، نادراً ما تكون إخفاقات ضمان الجودة (QA/QC) الأكثر تكلفة تقنية بطبيعتها.

بل هي إخفاقات “تفسيرية”.

تحمل ملاحظات المراجعة (Markups) في طياتها القصد التصميمي، والقيود، ومعايير القبول. وعندما يفشل هذا “القصد” في العبور خلال عمليات التسليم اليدوية (Handoffs)، ينحرف المشروع بهدوء؛ حيث يعتقد الجميع أنهم فهموا المطلوب، بينما تظهر التكلفة الحقيقية لاحقاً على شكل إعادة عمل (Rework).

لقد اعتمدتُ هذه القاعدة كقاعدة تسليم أساسية: “إذا لم يتم الحفاظ على القصد، فإن المخرج التعاقدي يعتبر غير مكتمل.”

للحد من هذه المخاطر، قمت بتنفيذ حلقة إغلاق بسيطة مصممة للفرق التي تعمل تحت ضغط المواعيد النهائية. لا يعتمد هذا النظام على التواصل المثالي أو إجراءات التشغيل الطويلة (SOPs)، بل يعتمد على الوضوح، والمسؤولية، والإثبات.

المشكلة الأساسية: معالجة المعلومات

عندما تصل البيانات محملة بالملاحظات، نادراً ما يكون الخطر تقنياً. الخطر الحقيقي هو “تشتت الانتباه البشري”.

لوحات الملاحظات (Markups) تكون مزدحمة بصرياً: أسماء الغرف، الأبعاد، الأكواد، والرموز. الخطوط القليلة المهمة قد تختفي وسط هذا الزحام. بينما يمكن للخبير تصفية هذا الزحام فوراً، قد يواجه عضو الفريق الذي يعاني من عوائق لغوية أو ضغط الوقت صعوبة في تحديد الملاحظات الحرجة وترتيب أولوياتها.

تعلمت قاعدة بسيطة: “إذا كان الحل يتطلب من فريق الإنتاج فتح مستندات ثقيلة للبحث عن مهامهم، فإن النظام سيفشل.”

لذلك صممنا سير عمل للواقع، وليس لـ “الفرق المثالية”. سير عمل حيث:

• لا يضطر أحد لمسح المخططات بالكامل للبحث عن عمله.
• لا يضطر أحد لـ “مطاردة” القصد التصميمي.
• لا يتم إغلاق أي مهمة دون إثبات مرئي.

طريقة “طابور الملاحظات” (Comments Queue)

المشاكل التي تحلها

• ضياع البنود المصنفة “مقبول مع ملاحظات” (Approved with Comments).
• الانحراف الخفي بين قصد العميل والتنفيذ الفعلي.
• الاعتماد المفرط على “المعرفة القبلية” أو منسق واحد يتقن اللغة.
• ضعف عملية الإغلاق (الادعاء بالإنجاز دون دليل).

الأداة المستخدمة

استخدم الأدوات التي يفتحها الفريق يومياً: Teams أو Google Chat. يتم إنشاء مساحة مخصصة للمشروع تسمى: #comments-queue.

القاعدة الوحيدة: إذا كانت البيانات تحتوي على ملاحظات، يجب أن تتحول إلى رسالة مهمة قصيرة مع إثبات. لا توجد رسالة مهمة = لا يوجد إغلاق.

سير العمل المكون من 3 رسائل

1) الإرسال (المنسق - Coordinator)

كل سحابة ملاحظات تصبح موضوعاً (Thread) مستقلاً. التنسيق:

[المشروع] | [رقم اللوحة/الإصدار] | [الورقة] | [رقم السحابة] (إرفاق لقطة شاشة لمنطقة الملاحظة) التعليمات: (سطر واحد، مترجم إذا لزم الأمر) المسؤول: @الاسم (بناءً على ملكية منطقة العمل مثلاً) درجة الخطورة: أخضر / أصفر / أحمر

ملاحظة: إذا كانت التعليمات غير واضحة أو الجملة أطول من 10 كلمات، يتم تصنيفها “أحمر” تلقائياً لحماية المنسق من التخمين.

2) الإنجاز (المنفذ - Implementer)

يرد المسؤول في نفس الموضوع:

✅ تم الإنجاز (إرفاق لقطة شاشة تثبت التحديث من النموذج/التفصيلة/المنظور)

3) الإغلاق (المراجع - Checker)

يرد المنسق بعد التحقق:

تم الإغلاق ✅

“القاعدة الحمراء” (بوابة التدقيق اللغوي)

بينما تعتبر البنود الخضراء (ملاحظات/موافقات عامة) و الصفراء (تسميات وبيانات) مباشرة، تعتبر الملاحظة “حمراء” إذا كانت تحتوي على أي من مؤشرات الخطر التالية:

• الأرقام والوحدات: مم، سم، م، درجات، %.
• الاتجاهات المحددة: نقل، إزاحة، محاذاة، توسيط.
• الامتثال: حسب الكاد (as per CAD)، حسب التفصيلة، الكود، الدفاع المدني.
• القيود: “يجب”، “تأكد”، “لا تفعل”، الخلوص (Clearance).
• الغموض: علامات الترقيم مثل ؟ أو !.

تتطلب البنود الحمراء خطوة إضافية: يجب على المنسق الإشارة (Tag) لمراجع متقن للغة للموافقة النهائية قبل الإغلاق.

لماذا ينجح هذا النظام؟

• طابور مرئي: يحول “الجهد الخفي” إلى قائمة شفافة.
• المسؤولية: الإشارة للمسؤول وإرفاق الإثبات تتم علناً.
• الاختصار: يقلل التفسير إلى سطر واحد بدلاً من فقرات.
• سجل التدقيق: لم يعد “مقبول مع ملاحظات” يعني “مقبول ومنسي”.

الاستفادة من الذكاء الاصطناعي: موجه النمذجة (BIM Prompt)

لتسريع هذه العملية، نستخدم النماذج اللغوية الكبيرة (LLMs) لتعمل كمصفاة أولية.

الموجه (Prompt):

“اعمل كمنسق BIM. ترجم ملاحظة العميل التالية إلى [اللغة المستهدفة] كتعليمات تنفيذ من سطر واحد لنموذج ريفيت.”

1. تقييم المخاطر: تصنيف أحمر للأبعاد والازاحة، أصفر للتسمية والبيانات، أخضر للملاحظات العامة.
2. الحفاظ على البيانات: الاحتفاظ بجميع الأرقام والوحدات والمراجع كما هي.
3. التنسيق: تعليمات من سطر واحد + مستوى الخطر + نوع الإثبات المطلوب (مثل: 3D Section Box).

الهدف النهائي: وكيل تنسيق “نيكسوس” (Nexus Agent)

الطريقة الأكثر موثوقية لتوسيع نطاق هذا العمل هي الأتمتة. أقوم حالياً بتطوير “وكيل ذكاء اصطناعي” مخصص يعمل كوسيط بين ملاحظات العميل ومحادثات الفريق.

يقوم الوكيل بقراءة الملاحظات عبر تقنية OCR، وربط رقم اللوحة بمنظور الريفيت المقابل، وتوليد التعليمات بناءً على منطقنا الخاص، وتوجيه المهمة تلقائياً إلى #comments-queue مع الإشارة لصاحب العمل (Workset owner).

الحالة: تحت الاختبار التجريبي (Alpha). الهدف ليس فقط العمل بشكل أسرع، بل ضمان نجاة القصد التصميمي من خلال الآلة.