أرسلت اللجنة كراسة بمئتي متطلب إلى أربعة موردين، فعادت الردود بأربعة جداول امتثال متشابهة: «متوفر» أمام كل سطر تقريبًا. بعد العروض التوضيحية اتضح أن أحدهم يقصد بـ«متوفر» حقلًا نصيًا يكتب فيه المستخدم ما يشاء، وأن آخر يقصد أن الميزة ستُطور بعد التعاقد. المشكلة لم تكن في الموردين وحدهم؛ كان السطر نفسه «يدعم النظام إدارة تصاريح العمل» يسمح بالإجابتين.
هذا دليل لصياغة المتطلبات لا لهيكل الكراسة. الهيكل والمتطلبات المرمزة موجودة في قالب كراسة متطلبات نظام HSE؛ هنا كيف تكتب كل متطلب بحيث لا تصلح له إجابة عامة، وكيف تطلب صيغة الرد والدليل، وكيف تربط ذلك بالأوزان.
لماذا يجيب الموردون «نعم ندعم»؟
الإجابة العامة رد طبيعي على سؤال عام. حين يقرأ المورد «يدعم النظام الإبلاغ عن الحوادث»، فأي نظام فيه نموذج حادث يستحق «نعم». ولا أحد يكذب هنا؛ السطر لم يحدد ما المطلوب بالضبط. خمسة أسباب تتكرر في الكراسات التي تعود ردودها متشابهة:
- المتطلب يسمي ميزة ولا يصف سلوكًا: «إدارة المقاولين» اسم وحدة، لا ما يجب أن يحدث حين ينتهي تأمين مقاول.
- لا سياق: من يفعل ماذا، من أي جهاز، وفي أي ظرف. البلاغ من مكتب مكيف يختلف عن البلاغ من ساحة بلا شبكة.
- لا معيار قبول: متى نقول إن المتطلب تحقق؟ إن لم تكتبه أنت، فسيعرّفه كل مورد على مقاسه.
- صيغة الرد ثنائية: «متوافق / غير متوافق» تدفع كل مورد إلى «متوافق»، لأن البديل يُخرجه من المنافسة.
- لا ثمن للإجابة غير الدقيقة: إن لم يكن جدول الامتثال جزءًا من العقد ولم يُطلب الدليل، فالإجابة المتفائلة بلا تكلفة على صاحبها.
كل قسم في هذا الدليل يعالج سببًا من هذه الأسباب. والنتيجة المطلوبة ليست كراسة أطول، بل كراسة أقصر غالبًا وأصعب في الإجابة عنها بعموميات.
تشريح متطلب يصعب الرد عليه بعبارة عامة
المتطلب القابل للتحقق يجيب عن ستة أسئلة في سطرين أو ثلاثة. لا يلزم أن تكتب كل متطلب بهذا التفصيل؛ اكتب بها المتطلبات الإلزامية والمتطلبات التي تفرق فعلًا بين الموردين، واترك البقية مختصرة.
| العنصر | السؤال الذي يجيب عنه | مثال من متطلب إجراءات تصحيحية |
|---|---|---|
| الفاعل والسياق | من يفعل، ومن أين، وفي أي ظرف؟ | مالك الإجراء في الموقع، من الجوال |
| السلوك | ماذا يفعل النظام بالضبط؟ | يُسند الإجراء لمالك واحد بموعد، ويُرسل له إشعارًا |
| الشرط أو الاستثناء | ماذا يحدث حين لا تسير الأمور كما يجب؟ | إذا تجاوز الموعد بيومي عمل يُصعّد إلى مدير المالك |
| القيد | ما الذي يجب ألا يسمح به النظام؟ | لا يُغلق الإجراء دون دليل مرفق وتحقق من شخص غير المالك |
| معيار القبول | كيف نعرف أن المتطلب تحقق؟ | في العرض: إجراء متأخر يظهر عند المدير، ومحاولة إغلاق دون دليل تُرفض |
| الدليل المطلوب | بماذا يثبت المورد إجابته؟ | عرض حي في الجلسة، وإمكانية تكراره في البيئة التجريبية |
لاحظ أن السطر الرابع، القيد، هو الذي يكشف الفروق أكثر من غيره. معظم الأنظمة تستطيع أن تفعل الشيء؛ القليل منها يمنعك من فعل الخطأ. لذلك اسأل دائمًا: ما الذي يجب أن يرفضه النظام؟ تصريح بلا عزل، أو عامل بلا تدريب، أو إغلاق بلا دليل.
من سطر عام إلى متطلب قابل للتحقق: أمثلة إعادة صياغة
الجدول التالي يعيد كتابة سبعة متطلبات تظهر في أغلب كراسات أنظمة السلامة. استخدمه نمطًا لا نصًا: غيّر الأدوار والمواقع والأرقام لتطابق منشأتك، لأن قيمة المتطلب في أنه يصف عملك أنت.
| الصياغة العامة | الصياغة القابلة للتحقق | الدليل الذي تطلبه |
|---|---|---|
| يدعم الإبلاغ عن الحوادث | يسجل المشرف من التطبيق بلاغ Near Miss بصورتين وموقعه أثناء انقطاع الشبكة، ويُرسل تلقائيًا عند عودة الاتصال مع مؤشر حالة المزامنة. ويستطيع عامل المقاول بلا حساب الإبلاغ بمسح رمز QR في المنطقة. | عرض حي بالجوال في وضع الطيران، ومسح رمز من جوال لا يحمل التطبيق |
| إدارة تصاريح العمل | لا يُعتمد تصريح العمل الساخن قبل تسجيل قراءة غاز ضمن الحد المعتمد، ويُعلّق تلقائيًا إذا انتهت مدته دون تمديد معتمد، ويظهر التصريح المعلق لمسؤول السلامة للموقع. | عرض حي بقراءة خارج الحد ثم ضمنه |
| إدارة المقاولين | عند انتهاء وثيقة تأمين مقاول، يتوقف قبول طلبات تصاريح جديدة له تلقائيًا ويُبلَّغ مدير المقاول، دون أن تُلغى التصاريح السارية إلا بقرار من مسؤول السلامة. | عرض بتاريخ انتهاء معدّل في البيئة التجريبية |
| إدارة الإجراءات التصحيحية | كل إجراء له مالك واحد وموعد، ويُصعّد إلى مدير المالك بعد تجاوز الموعد بيومي عمل، ولا يُغلق إلا بدليل مرفق وتحقق من شخص غير المالك. | عرض حي لمحاولة إغلاق دون دليل |
| تقارير ولوحات مؤشرات | يصل لمدير كل موقع في أول يوم عمل من الشهر تقرير مجدول بالحوادث وNear Miss والإجراءات المتأخرة لموقعه، ويمكن من كل رقم فتح السجلات المكوِّنة له. | تقرير نموذجي ببيانات تجريبية، والنقر على رقم في العرض |
| دعم اللغة العربية | يختار كل مستخدم لغة واجهته، ويظهر البلاغ المكتوب بالعربية في التقرير المُصدَّر PDF باتجاه صحيح وحروف متصلة، ويصل الإشعار بلغة المستلم. | تصدير تقرير فعلي في الجلسة |
| التكامل مع الموارد البشرية | يُنشأ حساب الموظف الجديد بوظيفته وإدارته ومديره دون إدخال يدوي، ويُعطّل حساب المغادر في دورة المزامنة نفسها. يذكر المورد طريقة التكامل ودوريتها وما يحتاجه من نظامنا. | وصف مكتوب للتكامل، وتجربة في بيئة الاختبار إن أمكن |
صياغة المتطلب على شكل موقف قصير لا تعني أنك تكتب سيناريو العرض التوضيحي. السيناريو قصة متصلة تمر بعدة وحدات في جلسة واحدة، وطريقة إعداده وتقييمه مشروحة في سيناريو اختبار العرض التوضيحي لنظام HSE. المتطلب هنا وحدة صغيرة يُجاب عنها كتابيًا ثم يُتحقق منها.
إلزامي أم مرغوب: كيف تصنف دون أن يصبح كل شيء إلزاميًا
القالب يقترح ثلاث أولويات: M إلزامي لا يُقبل العرض دونه، وS مهم يؤثر في التقييم، وC اختياري مرغوب. الصعوبة ليست في الرموز بل في الانضباط. حين يُترك التصنيف لكل قسم، يصنف كل قسم متطلباته إلزامية، فتنتهي الكراسة بمئة وخمسين متطلبًا إلزاميًا لا يستوفيها أحد بالكامل، ثم تضطر اللجنة إلى التغاضي عن بعضها، فيفقد التصنيف معناه.
اختبار واحد يكفي لكل متطلب مرشح للإلزام: لو جاء عرض يتفوق في كل شيء آخر لكنه لا يحقق هذا المتطلب، هل نستبعده فعلًا؟ إن كانت الإجابة «لا، سنناقشه»، فالمتطلب مهم لا إلزامي.
ما يستحق الإلزام عادة
ما يتصل بسلامة الأرواح أو بسياسة البيانات أو بقدرة النظام على العمل في مواقعك: منع التصريح دون شروطه، الصلاحيات الطبية المنفصلة، مكان الاستضافة، العمل الميداني دون اتصال إن كانت مواقعك كذلك.
ما يُصنف مهمًا
ما يرفع القيمة أو يقلل الجهد دون أن يوقف التشغيل: تقارير مجدولة، تقييم أداء المقاولين، تكامل BI، مكتبة JSA قابلة لإعادة الاستخدام.
ما يبقى مرغوبًا
ما تخطط له لمرحلة لاحقة أو تريد معرفة توفره دون أن يحسم القرار: وحدات البيئة وESG، المساعد الذكي، تكاملات تشغيلية مؤجلة.
قاعدة النسبة
إن تجاوزت المتطلبات الإلزامية ربع الكراسة تقريبًا، فراجعها. الإلزامي الكثير لا يرفع المعيار؛ يجعل الاستبعاد اعتباطيًا.
وفرّق بين الإلزام الفني والإلزام الإجرائي. «تقديم جدول امتثال لكل متطلب» شرط لقبول العرض، لا متطلب في النظام. اجعل الشروط الإجرائية في قسم مستقل حتى لا تختلط بتقييم المنتج.
صيغة الإجابة: أعمدة تجبر المورد على التمييز
استبدل «متوافق / غير متوافق» بخيارات تفصل بين مستويات التحقيق المختلفة. القالب يقترح أربعة: متوفر، بالإعدادات، تطوير خاص، غير متوفر. ويفيد في أنظمة السلامة إضافة خيار خامس لأن كثيرًا من المتطلبات يعتمد على نظام آخر لدى المنشأة:
| الرد | المعنى الذي تفرضه الكراسة | ما يجب أن يرفقه المورد |
|---|---|---|
| متوفر | يعمل في الإصدار الحالي دون أي ضبط إضافي | مرجع الشاشة أو الوثيقة، واستعداد لعرضه حيًا |
| بالإعدادات | يتحقق بضبط النماذج أو المسارات أو القوائم دون كتابة كود، ويبقى مع التحديثات | ما الذي يُضبط، ومن يضبطه، وهل هو ضمن التهيئة المسعّرة |
| عبر تكامل | يتحقق بتبادل بيانات مع نظام آخر لدى المنشأة، ويعتمد على ما يتيحه ذلك النظام | طريقة التكامل، وما يحتاجه من النظام الآخر، وتكلفته |
| تطوير خاص | يحتاج قدرة غير موجودة تُبنى للمنشأة | تقدير الجهد والتكلفة ضمن العرض، وأثره على الصيانة والتحديثات |
| غير متوفر | لا يتحقق ضمن هذا العرض | بديل مقترح إن وُجد |
ثلاث قواعد تجعل هذه الأعمدة فعالة. الأولى: الخلية الفارغة تُعامل «غير متوفر». الثانية: أي رد «متوفر» أو «بالإعدادات» على متطلب إلزامي يجب أن يكون قابلًا للعرض حيًا في الجلسة التوضيحية. الثالثة: جدول الامتثال جزء من العقد، وهو ما تنصح به صفحة المشتريات ولجان التقييم بين بنود العقد. هذه القاعدة الأخيرة وحدها تجعل الموردين يراجعون إجاباتهم قبل الإرسال.
الفرق بين «بالإعدادات» و«تطوير خاص» هو أهم ما تكشفه هذه الصيغة، لأن الأول يعدّله مسؤول النظام لاحقًا في الغالب دون طلب تغيير، والثاني يحتاج تطويرًا واختبارًا مع كل تحديث. صفحة التخصيص في منصتنا تشرح هذا الفصل وتوصي بأن تطلب من كل مورد تصنيف متطلباتك إلى «متوفر» و«بالإعدادات» و«تطوير خاص»، وهو التصنيف نفسه الذي تقترحه هذه الصيغة.
طلب الدليل: ما الذي يثبت كل نوع من المتطلبات
«أرفق ما يثبت» عبارة لا تعني شيئًا للمورد. حدد نوع الدليل المقبول لكل فئة من المتطلبات، لأن بعض الأدلة لا تصلح لبعض المتطلبات: لقطة شاشة تثبت وجود نموذج، ولا تثبت أن النظام يرفض الإغلاق دون دليل.
| فئة المتطلب | الدليل المقبول | ما لا يكفي |
|---|---|---|
| سلوك سير العمل والقيود | عرض حي بمحاولة تجاوز القيد، أو تجربة في البيئة التجريبية | لقطة شاشة أو وصف مكتوب |
| العمل الميداني | جوال حقيقي في الجلسة بيد عضو من اللجنة، في وضع دون اتصال | عرض من حاسوب المورد |
| التقارير والمؤشرات | تقرير مصدَّر ببيانات تجريبية، وطريقة حساب المؤشر مكتوبة | صورة لوحة جاهزة |
| الأمن والاستضافة | وثائق الضوابط المطبقة وإجابات استبيان الأمن لدى المنشأة | عبارة «نلتزم بأعلى المعايير» |
| التكاملات | توثيق الواجهات، ووصف خطة التكامل مع أنظمتك بأسمائها | قائمة شعارات أنظمة |
| الشهادات والاعتمادات المذكورة | الوثيقة نفسها بنطاقها وتاريخها | ذكرها في العرض دون وثيقة |
وفي البند الأخير تحديدًا: لا تطلب من النظام شهادة ISO 45001؛ الشهادة تُمنح للمنشأة بعد تدقيق نظام إدارتها، والبرنامج يدعم متطلباتها فقط، كما توضح صفحة دعم متطلبات ISO 45001. اكتب المتطلب سلوكًا: «يحتفظ النظام بأدلة التدقيق الداخلي وعدم المطابقة والإجراءات مرتبطة ببنود المعيار».
كيف تربط الأوزان بصيغة الرد
الأوزان تُحدد على مستوى مجموعات المعايير قبل استلام العروض، كما في بطاقة معايير تقييم برامج HSE. ما تضيفه الكراسة هو ربط درجة كل متطلب بنوع الرد والدليل، حتى لا تكافئ البطاقة المورد الذي كتب «متوفر» أمام كل شيء. البطاقة نفسها تقترح سلّمًا من 1 إلى 5، وقاعدة أن ما لم يُعرض يعمل أمامك يأخذ الدرجة 1 مهما كانت الوعود.
مثال افتراضي للتوضيح مجموعة تصاريح العمل بوزن 15 نقطة وثمانية متطلبات
السلّم: متوفر ورُئي حيًا = 5، بالإعدادات = 4، حل جزئي مقبول = 3، تطوير خاص مقدّر في العرض = 2، غير متوفر أو وعد لم يُعرض = 1. الحد الأعلى للمجموعة 8 × 5 = 40.
- المورد أ أجاب «متوفر» عن الثمانية، وعرض خمسة منها حيًا. الثلاثة الباقية تأخذ 1: (5 × 5) + (3 × 1) = 28 من 40، أي 70%، فينال 10.5 من 15.
- المورد ب أجاب «متوفر» عن خمسة وعرضها، و«بالإعدادات» عن اثنين وضبطهما في الجلسة، و«تطوير خاص» عن واحد بتقدير مكتوب: (5 × 5) + (2 × 4) + (1 × 2) = 35 من 40، أي 87.5%، فينال نحو 13.1 من 15.
المورد الأدق في إجاباته تقدم، رغم أنه أقر بأن متطلبًا يحتاج تطويرًا. ويُضاف تقدير ذلك التطوير إلى تكلفته في المقارنة المالية، فلا يكسب مرتين ولا يخسر مرتين.
لهذا الربط أثر مباشر في سلوك الموردين في الجولة التالية: حين يعلمون أن «متوفر» غير المعروض تُحتسب 1، يصبح «بالإعدادات» الصادق أفضل لهم من «متوفر» المتفائل. أما تقييم العرض الفني كاملًا بعد وصوله فموضوع تقييم العرض الفني لنظام HSE.
المتطلبات غير الوظيفية: كيف تكتبها دون عبارات إنشائية
هنا تكثر العبارات التي لا تُقاس: «نظام آمن»، «أداء عالٍ»، «سهل الاستخدام»، «قابل للتوسع». القاعدة نفسها: صف ما يحدث أو ما تطلبه وثيقةً.
- الأمن: بدل «نظام آمن» اكتب ما تريد رؤيته: التحقق متعدد العوامل للأدوار الحساسة، وسجل تدقيق يحفظ القيم قبل التعديل وبعده، وفصل البيانات الطبية بصلاحية مستقلة. تفصيلها في متطلبات أمن منصة HSE.
- الاستضافة: حدد الخيار المقبول ومكان البيانات بوضوح، وإن كان التثبيت على خوادمك فاطلب وثيقة البنية ومصفوفة المسؤوليات كما في متطلبات نظام HSE On-Premise.
- الأداء: بدل «أداء عالٍ» اذكر حجمك: عدد المواقع، والمستخدمين بأدوار، والسجلات الميدانية الشهرية المتوقعة، واطلب من المورد بيان كيف يتعامل نظامه مع هذا الحجم.
- سهولة الاستخدام: لا تكتبها صفة؛ اكتبها اختبارًا: «مشرف لم يتدرب على النظام يُكمل جولة تفتيش بالصور من الجوال دون مساعدة في جلسة الاختبار».
- التوسع: «إضافة موقع جديد بهيكله ومستخدميه دون تطوير، ويوضح المورد من ينفذ ذلك لدى المنشأة».
- الدعم: اطلب تصنيف الأعطال ومسار رفعها ومستوى الخدمة المقترح لكل تصنيف، دون أن تفرض أرقامًا قبل معرفة ما يُعرض عليك.
كتابة RFP لنظام HSE في الواقع: سيناريو إعادة صياغة
مثال افتراضي للتوضيح شركة خدمات حقول نفط في الأحساء تعيد كتابة كراستها
شركة خدمات صيانة آبار وحفر بنحو 1,700 عامل، تعمل في تسعة مواقع ميدانية تتنقل بين الحقول، مع اثني عشر مقاول باطن. كتبت مسودتها الأولى بنسخ قوائم ميزات من عروض سابقة، فخرجت بمئتين وأربعين متطلبًا، منها مئة وتسعون إلزامية. أجاب الموردون الأربعة «متوفر» عن أكثر من تسعة أعشارها، ولم تستطع اللجنة التمييز. ما الذي غيرته في المسودة الثانية:
- حذفت المتطلبات المكررة والمركبة (سطر واحد فيه ثلاثة متطلبات)، ودمجت ما يكرر بعضه، فنزل العدد إلى نحو مئة وأربعين.
- طبقت اختبار الاستبعاد على كل إلزامي، فبقي نحو خمسة وثلاثين، أغلبها في التصاريح وتنقل المواقع والعمل دون اتصال والمقاولين.
- أعادت كتابة الإلزامية بعناصر المتطلب الستة، مع القيد ومعيار القبول.
- غيرت صيغة الرد إلى الخيارات الخمسة، وجعلت جدول الامتثال جزءًا من العقد.
- حددت لكل فئة الدليل المقبول، وأعلنت قاعدة «ما لم يُعرض = 1» في الكراسة نفسها.
- أضافت فقرة وصف للوضع الحالي: الأدوات المستخدمة اليوم، وعدد التصاريح الشهرية، وطبيعة المواقع المتنقلة وتغطيتها بالشبكة.
في الجولة الثانية اختلفت الردود بوضوح: أحد الموردين صنف ثلث المتطلبات «بالإعدادات» وربعها «تطوير خاص»، وآخر أقر بأن نقل هيكل الموقع عند انتقال الفريق إلى حقل جديد يحتاج تطويرًا. صار لدى اللجنة ما تقارنه، والفروق الحقيقية ظهرت قبل العروض التوضيحية لا بعد التعاقد.
أخطاء صياغة تُفسد الكراسة قبل إرسالها
- نسخ كتيب مورد: الكراسة المبنية على قائمة ميزات مورد واحد تنحاز له دون قصد، وتفرض على البقية منطقه ومسمياته.
- المتطلب المركب: «يدعم النظام التصاريح والعزل وقياس الغاز» ثلاثة متطلبات في سطر، والرد «متوفر» عليها لا يقول أيها متوفر.
- الصفات بدل السلوك: «سريع»، «مرن»، «سهل»، «متكامل». كل صفة منها تُستبدل باختبار أو رقم من واقعك.
- فرض الطريقة بدل النتيجة: «يستخدم النظام قاعدة بيانات من نوع كذا» يستبعد حلولًا صالحة؛ اكتب النتيجة واترك الطريقة لسياسة تقنية المعلومات إن كانت ملزمة فعلًا.
- غياب الحجم: دون عدد المواقع والمستخدمين بأدوار والمقاولين، لا يستطيع أحد الإجابة عن الأداء ولا التسعير بدقة.
- غياب الوضع الحالي: المورد الذي لا يعرف أنكم تعملون اليوم بـ Excel وواتساب لا يستطيع تقدير نقل البيانات ولا التدريب.
- متطلبات بلا مالك: كل متطلب يجب أن يعرف أحد في المنشأة لماذا كُتب. إن لم يعرف أحد، فاحذفه.
مراجعة أخيرة قبل إرسال الكراسة
قبل الإرسال، اطلب من شخصين لم يكتبا الكراسة، أحدهما من الميدان، أن يقرآ عشرة متطلبات إلزامية مختارة عشوائيًا ويجيبا عن سؤال واحد: كيف سأعرف أن هذا تحقق؟ إن اختلفت إجابتاهما، فالمتطلب يحتاج إعادة صياغة. ثم راجع:
- كل متطلب إلزامي يجتاز اختبار الاستبعاد، ونسبة الإلزامي معقولة.
- كل متطلب إلزامي فيه سلوك وقيد ومعيار قبول، وليس اسم ميزة.
- لا متطلبات مركبة، ولا صفات غير قابلة للقياس.
- صيغة الرد بالخيارات الخمسة، والخلية الفارغة تُعامل «غير متوفر».
- نوع الدليل المقبول محدد لكل فئة، وقاعدة التقييم معلنة.
- جدول الامتثال منصوص على أنه جزء من العقد.
- وصف المنشأة والحجم والوضع الحالي والمواقع مرفق.
- الشروط الإجرائية منفصلة عن متطلبات المنتج.
- الأوزان معتمدة ومحفوظة قبل فتح أي عرض.
ولقائمة الأسئلة التي تطرحها على كل مورد في الجلسات بعد وصول الردود، راجع أسئلة لمزود نظام السلامة. وإن أردت رؤية جدول امتثال مصنف على متطلباتك أنت، فأرسل الكراسة عبر طلب عرض السعر.
الأسئلة الشائعة
لا يوجد رقم صحيح، لكن الطول ليس دليل جودة. كراسة بمئة متطلب مكتوبة جيدًا تكشف الفروق أكثر من كراسة بخمسمئة سطر منسوخ. ركز التفصيل على الإلزامي وما يفرق بين الموردين، واترك الباقي مختصرًا أو في ملحق.
بلغة الفريق الذي سيقيّم ويستخدم، مع المصطلحات الميدانية كما تُستخدم فعلًا (PTW وLOTO وJSA وNear Miss). المهم أن تكون لغة الكراسة هي لغة المرجع عند الخلاف، وأن يُطلب من المورد الرد باللغة نفسها.
نعم، في عمود شرح منفصل، لكن بعد اختيار أحد الخيارات. الملاحظة توضح، ولا تحل محل التصنيف. والرد الذي يكتفي بالملاحظة دون اختيار يُعامل كما تنص الكراسة، والأوضح أن يُعامل «غير متوفر».
طبّق القاعدة المعلنة في الكراسة: يأخذ أدنى درجة في ذلك المتطلب، وإن كان إلزاميًا فيُعامل كغير مستوفٍ. يمكن منحه فرصة واحدة محددة في البيئة التجريبية إن كانت الكراسة تسمح بذلك، على أن تُتاح الفرصة نفسها للجميع.
يُفضل ذلك، أو على الأقل لكل مجموعة متطلبات تطوير، لأنها تكلفة تضاف إلى العرض عند المقارنة المالية، ولأن لكل تطوير أثرًا على الصيانة والتحديثات. إن جُمعت في سطر واحد فلن تعرف أيها يستحق الاحتفاظ به.
نعم في صياغة المتطلبات الفنية نفسها، داخل النماذج والإجراءات المعتمدة لدى جهتك. تحقق من أن صيغة الرد وقواعد التقييم والدليل المطلوب متسقة مع شروط المنافسة المعتمدة، وأعلنها في الكراسة قبل الطرح لا بعده.