الحلقة الثانية من سلسلة «من الانبهار بالعرض إلى امتلاك أصل رقمي قابل للفحص والاستمرار»
إعداد وتحرير مقترح: م. كريم عمر ،د. هبة الله قاعود، محمد لطفي
هذا المقال حوار تحريري مقترح، وليس تفريغًا لتصريحات فعلية، ويتضمن مواقف ساخرة وسيناريوهات افتراضية للتوعية والنقاش، لا تروي وقائع محددة ولا تستهدف أشخاصًا أو شركات بعينها. ومع كامل الاحترام لممارسي البرمجة بالحدس (Vibe Coding)، فإن النقد موجّه إلى الممارسات غير المنضبطة وغياب المراجعة والاختبار والشفافية، لا إلى مستخدمي التقنية أو قدراتهم؛ فاستخدام الذكاء الاصطناعي ليس موضع اتهام، وإنما يناقش المقال مسؤولية التحقق من المخرجات قبل تقديمها باعتبارها حلولًا مكتملة. يسهم المهندس كريم عمر، خبير تكنولوجيا المعلومات، برأيه الشخصي في هذا الحوار التحريري المقترح، إلى جانب الدكتورة هبة الله قاعود. وتُكيَّف المقترحات الواردة فيه بحسب طبيعة المشروع والعقد والقانون الواجب التطبيق، ولا تمثل استشارة قانونية أو ضمانًا أمنيًا.
الأحد. التاسعة صباحًا. أول يوم بعد الإطلاق.
لنتخيّل المشهد التالي: في التاسعة ودقيقتين، تعثّر أول طلب. في التاسعة وخمس دقائق، طلبت الإدارة العودة إلى النسخة السابقة. في التاسعة وعشر دقائق، اكتشف الفريق أن تعليمات الاستعادة موجودة في محادثة قديمة مع المطوّر. وفي التاسعة والربع، اتصلوا به.
رنّ الهاتف. وفي قاعة الاجتماعات، بقيت شريحة واحدة على الشاشة: «تم التسليم بنجاح».
قبل يومين، بدا الوعد مختلفًا: منظومة متكاملة بالذكاء الاصطناعي، وشاشات أنيقة، ووكلاء أذكياء، وتقارير جاهزة للاجتماعات. أما السؤال عن التشغيل دون الفريق الأصلي، فلم يكن ضمن العرض.
هذه ليست دعوة للخوف من السرعة، بل لطرح السؤال الذي يأتي غالبًا متأخرًا: هل اشترت المؤسسة نظامًا قابلًا للاستمرار، أم حق الاتصال بالشخص الوحيد الذي يعرف كيف يعمل؟
أكاديمية الصيد… والتوصيل من المطعم المجاور
في الحلقة الأولى، ناقشنا الفرق بين المنتج المؤسسي والعرض التجريبي (Demo). واليوم نتابع ما يحدث بعد التصفيق: هل تستطيع المؤسسة تشغيل ما اشترته وتغييره إذا غاب المطوّر أو تعطلت خدمة خارجية؟
لطفي: «ما الفارق بين شراء نتيجة جاهزة وامتلاك القدرة على إنتاجها؟»
كريم: «تخيّل أكاديمية صيد يعلّق صاحبها سمكة مشوية في السنّارة، ثم يعلن أنه غيّر قواعد البحر، بينما المطعم المجاور يتولى التوصيل. لا عيب في الوجبة؛ العيب أن نشتريها باعتبارها قدرة على الصيد. وفي البرمجيات، ليست المشكلة استخدام الأدوات والمكونات الجاهزة، بل بيع التجربة المحدودة باعتبارها نظامًا مكتملًا.»
نتناول الدَّين التقني (Technical Debt) بوصفه عملًا هندسيًا مؤجلًا قد يمنح المشروع سرعة اليوم، لكنه يترك تكلفة صيانة أو تعديل أو إعادة عمل غدًا. ليس كل تأجيل خطأ؛ المهم أن يكون معلومًا ومبررًا وله مسؤول وخطة معالجة. وليست كل مشكلة دَينًا تقنيًا؛ فقد تكون تعاقدية أو تشغيلية أو مالية، لكنها تؤثر جميعًا في قيمة ما اشترته المؤسسة.
أولًا: قبل الالتزام — افهم ما تشتريه قبل أن تنبهر به
1. الشاشة تعمل… فهل اكتملت الهندسة؟
لطفي: «ما الذي يثبت جاهزية التطبيق بعد نجاح العرض؟»
كريم: «تحرّك الأزرار لا يثبت صحة الحسابات أو سلامة الصلاحيات. الزرار اتحرّك، مبروك؛ بقي أن نعرف ماذا حرّك، وبصلاحية مَن، وماذا يحدث إذا ضغطناه مرتين. نطلب بطاقة جاهزية (Readiness Checklist) توضح ما يعمل، وما جرت محاكاته، وما يحتاج إلى تدخل بشري، وما لم يُختبر، على إصدار محدد وحدود استخدام معلنة.»
د. هبة: «نجاح العرض قد يبرر تجربة محدودة، لكنه لا يكفي لاعتماد التشغيل الفعلي. وينبغي أن تعكس الالتزامات هذا الفرق، بدل استخدام كلمة «جاهز» دون تعريف.»
2. هو فاهم البيزنس… ولا بيعرف يكتب البرومبت؟
لطفي: «كيف نتحقق من فهم الأعمال، مع أن الفريق يحتاج طبيعيًا إلى شرح أصحاب التخصص؟»
كريم: «طلب الشرح ممارسة سليمة. المشكلة هي الانتقال مباشرة من الكلام إلى توليد الشيفرة (Code Generation)، دون تصميم واختبارات. نوثق قواعد الأعمال (Business Rules)، ونحسم الاستثناءات والافتراضات، ونربط كل متطلب بتنفيذه واختباره: تتبّع المتطلبات (Requirements Traceability). كتابة البرومبت ليست بديلًا عن فهم المتطلبات، كما أن كتابة الكود يدويًا ليست شهادة كفاءة.»
د. هبة: «تحديد أصحاب صلاحية اعتماد المتطلبات جزء مهم من الحوكمة. الرجوع إلى المختص عند الغموض أفضل من بيع افتراض غير محسوم باعتباره وظيفة مكتملة.»
3. نظام ERP في عطلة نهاية الأسبوع… و«بالمرة» HR وCRM
لطفي: «كيف نقيّم وعد بناء نظام مؤسسي واسع خلال مدة قصيرة؟»
كريم: «نحدد هل المقصود نموذج أولي أم نظام تخطيط موارد المؤسسة (ERP)، مرتبط بالموارد البشرية (HR) وإدارة علاقات العملاء (CRM). إضافة إدارة كاملة ليست إضافة بطاطس مع الطلب. نبدأ باستكشاف (Discovery Phase) الوضع الحالي (As-Is) والمستهدف (To-Be)، ثم تحليل الملاءمة والفجوات (Fit-Gap Analysis). استخدام GitHub والمكونات مفتوحة المصدر (Open-Source Components) ليس عيبًا؛ لكن تجميع قطع الغيار لا يصنع وحده مصنع سيارات.»
د. هبة: «أناقة وثيقة متطلبات الأعمال (Business Requirements Document — BRD) لا تثبت الفهم. يلزم نطاق معتمد وأمثلة واقعية وقرار مبرر للبناء أو الشراء أو التهيئة، مع إدارة توسع النطاق (Scope Creep).»
4. قبل الدفع: هل نشتري هندسة ذكاء اصطناعي؟
لطفي: «كيف نترجم هندسة الذكاء الاصطناعي إلى عمل يمكن التحقق منه؟»
كريم: «هندسة الذكاء الاصطناعي (AI Engineering) تظهر في التصميم والاختبارات، لا في عنوان السعر. نحدد دور النموذج، وما تنفذه قواعد برمجية محددة، ومصادر البيانات والتكاملات وصلاحيات الوكلاء. ونفصل اختبارات البرنامج عن تقييم سلوك النموذج (Model Evaluation). نطلب مراجعات شيفرة (Code Reviews)، ونتائج اختبارات، وإعدادات موثقة، وضبط إصدارات (Version Control)، وخطط نشر ومراقبة واستعادة. «هنظبط البرومبت بعدين» ليست خطة تسليم.»
د. هبة: «يحدد نطاق العمل (Scope of Work — SOW) المخرجات (Deliverables)، والمستبعدات والميزانية والجدول ومعايير القبول (Acceptance Criteria)، والحقوق ومسؤوليات العميل والمورد. وربط الدفعات بالمخرجات يحتاج نصًا واضحًا وفق العقد.»
5. الشفافية من اليوم الأول… لا «المطوّر يعرف»
لطفي: «كيف نحقق الشفافية دون كشف الأسرار أو تجاوز حقوق المورد؟»
كريم: «ليس المطلوب تعليق كلمات المرور على باب الشركة. المطلوب معرفة أين توجد المستودعات والحسابات، وعلى ماذا يعتمد النظام، ومَن يدفع فواتيره. مسؤول المشروع يقود التنفيذ ويوضح قراراته؛ لا يحوّل الكود إلى صندوق أسود ومفتاحه في جيبه.»
د. هبة: «نتفق على المعلومات المطلوبة ومواعيد إتاحتها والمخوّلين بالاطلاع، بصلاحيات محدودة أو عبر مراجع مستقل ملتزم بالسرية. الرفض دون مبرر لا يثبت احتيالًا أو عجزًا، لكنه يترك فجوة تستلزم تفسيرًا وطريقة مناسبة للتحقق.»
ثانيًا: أثناء التنفيذ — اختبر العمل، لا براعة العرض
6. استلمنا نظامًا… ولا فرقة روبوتات بتحاول تخلّيه يشتغل؟
لطفي: «كيف نميز الأتمتة المقصودة عن أدوات تعوّض نقص النظام؟»
كريم: «واحد يسحب البيانات، والثاني ينقلها، والثالث يسأل النموذج… والموظف يجمع العيلة على Excel! نطلب خريطة دورة العمل (Workflow) ودور كل مكوّن وصلاحياته وتكلفته وحالات تعطله. الأتمتة الروبوتية (RPA)، والوكلاء الذكيون (AI Agents)، والتوليد المعزّز بالاسترجاع (RAG) أدوات مختلفة. وجودها ليس عيبًا؛ العيب احتساب تصحيح يدوي مخفي إنجازًا آليًا مكتملًا.»
د. هبة: «يفصح الاتفاق عن التدخلات البشرية والحلول المؤقتة والاعتماديات المؤثرة. والحل المؤقت يحتاج سببًا ومسؤولًا وموعد مراجعة، لا مجرد وصفه بأنه مؤقت.»
7. اختبار حي لقواعد الأعمال… لا الاكتفاء باختبارات المورد
لطفي: «ما التجربة التي تثبت إنجاز العملية الفعلية؟»
كريم: «نختبر دورة كاملة (End-to-End Testing) في بيئة اختبار ببيانات مصطنعة: إنشاء طلب، والسعر والضريبة والمخزون، وتعثر الدفع وإعادة المحاولة، والمرتجع الجزئي، والصلاحيات واتساق التقارير. نسجل النتائج المتوقعة والفعلية والإصدار ضمن اختبار قبول المستخدم (User Acceptance Testing — UAT). اختبارات المورد مهمة، لكنها ليست وحدها كافية؛ المستخدم لا يقرأ سيناريو العرض قبل الاستخدام.»
د. هبة: «نربط الاختبارات بمعايير القبول، ونوثق النتائج والاعتراضات والمعالجة. وإذا اختلف أصحاب الأعمال على القاعدة نفسها، نحسمها قبل الحكم على مطابقة التنفيذ.»
8. أصلحنا ميزة… فهل تعطلت وظائف سابقة؟
لطفي: «متى تصبح إعادة توليد الشيفرة بديلًا غير مقبول عن فهم الخلل؟»
كريم: «عندما لا نملك تفسيرًا أو دليلًا على نجاح الإصلاح. نطلب تحليل أثر التغيير (Change Impact Analysis)، ومراجعة، واختبارات عدم التراجع (Regression Testing). اختبارات الوحدات (Unit Tests) لا تغني عن التكامل والأداء والأمن بحسب المخاطر، مع خطة تراجع (Rollback) أو استعادة. إذا غيّرنا لون الفاتورة فاختفى المخزون، فعبارة «النسخة الجديدة أخف» ليست تقرير اختبار.»
9. المساعد يعرف كل شيء… بما فيه ما لا يحق لك معرفته
لطفي: «كيف نتحقق من أن المساعد يحترم صلاحيات المستخدم؟»
كريم: «إذا رفض النظام فتح ملف للموظف ثم سلّمه المساعد الملف وعدّله، فقد طبقنا الصلاحيات على من يستخدم الماوس وأعفينا من يكتب برومبت. نراجع الأدوار والمسؤوليات ومصفوفة الصلاحيات (Authorization Matrix)، وانعكاسها على مواصفات متطلبات البرمجيات (Software Requirements Specification — SRS)، وتصميم البيانات والعلاقات (ERDs)، والتنفيذ والاختبارات. المخطط يدعم التصميم لكنه لا يفرض التفويض وحده؛ يلزم إنفاذه في الخدمات والبحث والاسترجاع والإجراءات، واختبار السماح والمنع.»
د. هبة: «تُراجع السرية وأغراض المعالجة والاحتفاظ والنقل ومسؤوليات الأطراف، وتُستخدم حسابات اختبار وبيانات مصطنعة أو محمية. الوثائق المولَّدة دون مراجعة لا تثبت أن الضوابط تعمل؛ وعدم القدرة على تتبعها يستدعي معالجة قبل اعتماد الوظائف الحساسة.»
ثالثًا: التشغيل والتكلفة — مَن يملك مفاتيح الاستمرار؟
10. انتهى الاشتراك… فهل انتهى النظام؟
لطفي: «ما المعلومات اللازمة لفهم الاعتماد على الخدمات الخارجية؟»
كريم: «نميز أدوات التطوير (Development Tools) عن اعتماديات التشغيل (Runtime Dependencies). استخدام Claude أو Cursor لا يثبت أن التطبيق يحتاج إليهما بعد التسليم، واستلام الكود لا يثبت غياب خدمات خارجية. نطلب سجل اعتماديات (Dependency Inventory) للخدمات والنماذج والتراخيص والحسابات والمسؤولين والتكاليف والبدائل، وتوثيق تنسيق النماذج (Model Orchestration) وصلاحيات الوكلاء وحدود استهلاك الوحدات النصية (Tokens). ثم نختبر تعطل اعتماد حرج بإذن وفي بيئة مناسبة.»
د. هبة: «الاستقلال لا يعني غياب كل مورد، بل إدارة الاعتماد وامتلاك الحقوق والترتيبات اللازمة لاستمرار الخدمة وفق نموذج التعاقد.»
11. المطوّر في إجازة… هل تأخذ الشركة إجازة معه؟
لطفي: «كيف نقلل اعتماد المؤسسة على شخص واحد؟»
كريم: «وجود شخص بارع ميزة، لكن لا نجعل براعته خطة الاستمرارية الوحيدة. وقد يكون هو أول المتضررين: كل إجازة دعم فني. نعالج الاعتماد الحرج على الفرد (Key-Person Dependency) بأدلة تشغيل (Runbooks)، وتوثيق القرارات والمراجعات المشتركة وتدريب بديل مؤهل، ثم نجرب المهام الحرجة فعلًا.»
د. هبة: «نقل المعرفة (Knowledge Transfer) يحتاج وقتًا وميزانية ومخرجات واضحة. كما نميز بين حقوق المؤسسة في المخرجات وخبرات المورد وأصوله السابقة التي لم يتفق على نقلها.»
12. العرض رخيص… لكن مَن يدفع ثمن النجاح؟
لطفي: «ما الحساب الذي يحتاج إليه المستثمر قبل التوسع؟»
كريم: «التكلفة الكلية للملكية (Total Cost of Ownership — TCO): الاستضافة والنماذج والتكامل وإعادة المحاولات والمراجعة والتدريب والدعم. نقيس تكلفة المهمة المكتملة والمقبولة، مع سيناريوهات استخدام وحدود إنفاق (Spending Limits) وتنبيهات وإجراء عند بلوغها. المراجعة البشرية ليست فشلًا؛ إخفاء تكلفتها هو المشكلة. لا نعلن توفير موظفين ثم نخفي فريقًا يصحح الأتمتة.»
د. هبة: «تبدأ دراسة الجدوى قبل الالتزام، ثم تُحدّث بالأرقام الفعلية. وتُوثق مسؤوليات الفوترة وأثر تغيير الخدمات أو نطاق الاستخدام وفق الاتفاق.»
رابعًا: حماية الاستثمار — الفحص ليس تهديدًا للمشروع
13. نخاف على الاستثمار… ولا نخاف نسأل اللي ماسك مفاتيحه؟
لطفي: «إذا ظهرت فجوة بين القدرات والوعود، هل يبرر الخوف من انسحاب المسؤول التقني تأجيل الفحص؟»
كريم: «يتحرك المستثمر للتحقق لا للاتهام: يوثق الحالة ويحمي البيانات والتشغيل ويطلب مراجعة مستقلة (Independent Assessment). وحتى دون مؤشرات إخفاق، تكون المراجعة جزءًا من العناية الواجبة. الكود المولَّد ليس شهادة جودة ولا حكم إدانة. وبعد الفحص نختار التصحيح أو دعم الفريق أو الانتقال المنضبط وفق العقد. المستثمر اشترى حصة في مشروع، لا تذكرة انتظار لرد صاحب المفاتيح.»
14. «لا تقلقوا»… هل تغني عن تقرير الفحص؟
لطفي: «ما الذي يجعل التقييم المستقل مفيدًا؟»
كريم: «نختار التخصص المناسب: تحليل أعمال، أو مراجعة معمارية (Architecture Review)، أو تدقيق شيفرة (Code Audit)، أو تقييم أمني (Security Assessment)، واختبار اختراق (Penetration Testing) عند الحاجة بإذن ونطاق واضحين. التقرير يحدد الدليل والأثر والأولوية والمعالجة وإعادة الاختبار. السيرة الذاتية لا تحل محل نتائج الفحص.»
د. هبة: «نتحقق من كفاءة المقيم واستقلاله وتضارب المصالح، ونضبط الوصول والسرية. ونميز نقص التوثيق عن خلل يحتاج إصلاحًا وعن خطر يمنع استخدام وظيفة، دون استنتاج حقوق تعاقدية غير مقررة.»
15. ولو بنبيع المنتج لغيرنا… بننقل له القيمة ولا بنورّثه الورطة؟
لطفي: «كيف تتغير المسؤولية عند استمرار البيع رغم معرفة قصور جوهري؟»
كريم: «نفرق بين عيب لم يُكتشف رغم فحص مناسب، وقصور معروف يُخفى أثناء البيع. نقيّم الأثر ونصحح الادعاءات ونحدد المعالجة وأي تقييد لازم للبيع أو الاستخدام. لا نحمي استثمارنا بتصدير المخاطر للعميل وإضافة فاتورة وترخيص.»
د. هبة: «إذا ثبت تعمد الإخفاء أو تقديم ادعاءات مضللة فقد تنشأ تبعات تعاقدية أو قانونية بحسب الوقائع والقانون. التوصيف القانوني وواجب الإفصاح ونطاقه يحتاجان مراجعة متخصصة، لا اتهامات عامة.»
خامسًا: التسليم — القبول نتيجة للفحص، لا شرط للسماح به
16. «وقّع القبول أولًا… ثم نفتح الدفاتر»!
لطفي: «كيف نؤكد المطابقة إذا لم تتوفر الأدلة اللازمة للتحقق قبل توقيع القبول؟»
كريم: «نقبل تنظيم الفحص وحماية السرية، لا استبدال الفحص بالتوقيع. أن أستلم السيارة للفحص شيء، وأن أقر بسلامتها قبل فتح الكبوت شيء آخر.»
د. هبة: «نميز اتفاق السرية (Non-Disclosure Agreement — NDA)، ومحضر الاستلام لغرض الفحص، وشهادة القبول النهائي (Final Acceptance). نراجع النصوص وآثارها والمواعيد وإجراءات الاعتراض. وإذا لزم تعديل الالتزامات نُبرم ملحقًا تعاقديًا (Contract Addendum/Amendment) يحدد الإفصاح والمعايير ومهلة المعالجة (Cure Period) وإدارة التغيير (Change Control). ولا نفترض حقًا تلقائيًا في وقف الدفع أو الإنهاء.»
17. التسليم: نظام قابل للتشغيل… أم ملف مضغوط وتهنئة؟
لطفي: «كيف نختبر الاستقلال التشغيلي عمليًا؟»
كريم: «نتفق على اختبار استقلال تشغيلي (Operational Independence Test) ملائم للمشروع، وليس شهادة معيارية. فريق مؤهل ومصرح له يشغّل نسخة من التوثيق في بيئة اختبار، ويفهم أثر تعديل ممثل وينفذه ويختبره، ويجرب النشر والتراجع أو الاستعادة. نحدد مدة ومعايير مناسبة ونسجل تدخلات المورد والنواقص. إذا انتهت كل خطوة بـ«اتصل بالباشمهندس»، فما زال جزء من التسليم في هاتفه.»
د. هبة: «نراجع الشيفرة حيث ينص العقد على تسليمها، وتعليمات البناء والنشر والتوثيق والتراخيص والحسابات والنسخ الاحتياطية وخطة الاستعادة والانتقال (Recovery and Exit Plan). وفي البرمجيات المقدمة كخدمة (Software as a Service — SaaS)، لا نفترض تسليم الكود؛ نركز على إدارة الخدمة والبيانات والصلاحيات والاستمرارية والخروج. وتُنقل الأسرار أو تُدوّر بأمان.»
سادسًا: من السمك والبطاطس… إلى أصل رقمي نملك حقوقه
18. استلمنا البرنامج… هل امتلكنا حقوقه؟
لطفي: «هل البرمجة بالحدس (Vibe Coding) ضد حقوق المؤلف (Copyright) بطبيعتها؟ وكيف نفصل المساهمة البشرية عن حق استخدام الناتج وحقوق المكونات؟»
كريم: «الجرد التقني يوضح مكونات الطبق، لكنه لا يجعل المطعم باسمنا.»
د. هبة: «لا يصح الحكم من اسم طريقة التطوير وحده. نفصل امتلاك نسخة عن امتلاك حقوق استغلالها وعن قابلية أجزائها للحماية القانونية. دفع التكلفة لا يحسم ذلك تلقائيًا. نراجع القانون والوقائع والمساهمة البشرية والعقود والتراخيص، دون افتراض حماية كل مخرج مولَّد أو سقوط الحماية عن المشروع كله.»
لطفي: «وما الذي يجب حسمه وتوثيقه منذ البداية؟»
د. هبة: «نبدأ بخمسة أمور: التمييز بين الملكية الفكرية السابقة (Background IP) وما ينشأ أثناء المشروع (Foreground IP)، وتحديد نقل الحقوق أو الترخيص وحدوده؛ وتوثيق المساهمات البشرية في التصميم والكتابة والاختيار والتعديل؛ ومراجعة تراخيص المكتبات والنماذج والبيانات والخدمات؛ وحسم حقوق استخدام البيانات والخصوصية والسرية والمعالجة والنقل؛ وحفظ سلسلة الحقوق (Chain of Title) من عقود وتراخيص واتفاقات نقل وسجل إصدارات. التسجيل أو الإيداع يُراجع حيث يتاح ويفيد، لكنه لا يعالج غياب الحقوق أو مخالفة الترخيص. والاعتراف بالبرنامج أصلًا في القوائم المالية مسألة محاسبية منفصلة.»
د. هبة: «قائمة مكونات البرمجيات (Software Bill of Materials — SBOM) تساعد في فهم المكونات وإدارة مخاطر سلسلة التوريد، لكنها ليست شهادة ملكية. نربط الجرد بسجل الحقوق والتراخيص والالتزامات ونحدثهما مع الإصدارات. هذه الأسئلة تبدأ من أول عقد وأول مكون وأول مساهمة بشرية، لا عند التسليم.»
سابعًا: القرار — ماذا تبرر النتائج؟
19. دفعنا كثيرًا… فهل ندفع أكثر حتى لا نعترف؟
لطفي: «كيف نربط نتائج الفحص بقرار واضح؟»
كريم: «نقارن تكلفة الإصلاح ومخاطره بالبدائل، لا بما دفعناه فقط. الإنفاق السابق ليس شهادة جودة بأثر رجعي؛ وهذا جوهر الحذر من فخ التكلفة الغارقة (Sunk Cost Fallacy).»
د. هبة: «نختار وفق العقد: قبولًا نهائيًا عند استيفاء المعايير؛ أو قبولًا مشروطًا إذا أجازه الاتفاق وكانت الفجوات ضمن حدود مقبولة بخطة ومسؤولين ومواعيد؛ أو تأجيلًا لاستكمال الأدلة؛ أو عدم قبول نطاق ثبت إخفاقه في معيار متفق عليه. نوثق الإصدار والاختبارات وما لم يُختبر والعيوب وأسباب القرار. وإذا تقرر الانتقال ننظم البيانات والحقوق والمستحقات ونختبر الاستمرارية قبل إلغاء الوصول أو إيقاف الخدمة.»
سؤال قبل الختام: وماذا عن البيانات والقرارات؟
لطفي: «وماذا عن تحليلات البيانات (Data Analytics)، وذكاء الأعمال (Business Intelligence — BI)، ودعم اتخاذ القرار (Decision Support)؟»
كريم: «هناك نسأل: الرقم جاء من أين، ولماذا صدقناه بهذه السرعة؟ نضبط أولًا حكاية “الكود شغّال”، ثم ننتقل إلى “التقرير بيقول”. لا ننتقل من الانبهار بالشاشات إلى الانبهار بالألوان.»
د. هبة: «نخصص لها نقاشًا مستقلًا، مع الاحتفاظ بالسؤال نفسه: ما الدليل الذي يبرر اعتماد المخرج؟ لا يكفي أن يعمل النظام، كما لا يكفي أن يبدو التقرير مقنعًا.»
الخلاصة: اشترِ ما يستمر بعد التصفيق
لطفي: «ما الذي ينبغي طلبه قبل الدفعة أو الإصدار أو الاستثمار التالي؟»
كريم: «تجربة قابلة لإعادة الفحص على إصدار معلوم، ينفذها مختصون، وتثبت إنجاز العمل وإمكان تشغيل النظام وتغييره. ليست كل شيفرة مولَّدة معيبة، ولا كل مطوّر سريع مدّعي خبرة. لا نحاكم المنتج لأن الذكاء الاصطناعي ساعد في بنائه، ولا نعفيه من المراجعة لهذا السبب.»
د. هبة: «نربط الأدلة بحقوق ومخرجات ومعايير قبول واضحة منذ التعاقد، مع مراجعة فنية وقانونية تناسب المخاطر. والمسؤولية مشتركة بين الأعمال والتقنية والتشغيل والأمن والمشتريات والقانون، كل في نطاقه؛ فلا تحل الثقة الشخصية محل التحقق.»
في النهاية، لا نشتري لحظة انبهار، بل قدرة المؤسسة على العمل غدًا ضمن حقوق وتكاليف وحدود معلومة. وإذا كان أهم مكوّن في النظام هو الشخص الذي يرد على الهاتف، فما زالت القدرة على الاستمرار خارج حزمة التسليم.
