اكتب وثيقة من سبعة أقسام قصيرة: سياق الموقع بأرقامه، ومسار الزيارة الحالي والمستهدف، ومتطلبات مكتوبة كحالات لها نتيجة متوقعة، وقائمة الأجهزة والأنظمة القائمة، وقيود البيانات، وتوقعات التنفيذ والدعم، ثم صيغة رد إلزامية تُجبر كل مورّد على تصنيف تغطيته لكل بند بالمستويات نفسها.
العروض لا تختلف لأن المورّدين مختلفون فقط، بل لأن كلًا منهم فهم طلبًا عامًا بطريقته. الوثيقة الجيدة تقلل مساحة الفهم الخاص.
لماذا تأتي العروض غير قابلة للمقارنة
حين تصل ثلاثة عروض لنظام زوار بثلاثة أرقام متباعدة، يبدو الأمر كأن المورّدين يسعّرون بشكل مختلف. في الغالب هم يسعّرون أشياء مختلفة. وتعود المشكلة عادة إلى ثلاثة أسباب في الطلب نفسه لا في العروض:
- متطلبات مكتوبة كأسماء ميزات. عبارة «يدعم النظام رمز QR» يقبلها كل مورّد بكلمة «نعم»، لأن كل نظام يقرأ رمزًا بشكل ما. لكنها لا تخبرك بما يحدث عند قراءة رمز زيارة ألغيت، أو رمز صورته زائر وأرسله لغيره.
- غياب السياق الرقمي. دون عدد البوابات وفئات الزوار وحجم الذروة التقريبي، يفترض كل مورّد حجمًا من عنده. أحدهم يسعّر بوابة واحدة وآخر يسعّر ثلاثًا مع طابعات.
- رد حر الصياغة. إن تُرك للمورّد أن يرد بالطريقة التي يريد، ستتلقى عرضًا تسويقيًا مرتبًا بحسب ما يجيده هو، لا بحسب ما تحتاجه أنت.
الوثيقة المقترحة هنا تعالج الأسباب الثلاثة. وهي ليست كراسة شروط كاملة بصياغة قانونية، بل الجزء الفني الذي يُبنى عليه أي طلب — سواء أُرسل برسالة إلى ثلاثة مورّدين أو أُدرج في كراسة رسمية.
أقسام الوثيقة السبعة
الترتيب مقصود: يبدأ المورّد بفهم موقعك قبل أن يقرأ ما تطلبه منه، فتأتي ردوده على المتطلبات في سياقها. وكل قسم يمكن أن يُكتب في صفحة أو أقل.
| القسم | الغرض | أهم ما فيه |
|---|---|---|
| ١. سياق الموقع | أن يسعّر الجميع الحجم نفسه | المواقع والبوابات ونوع كل بوابة، فئات الزوار، أوقات التشغيل والمناوبات، الذروة التقريبية |
| ٢. المسار الحالي والمستهدف | أن يفهم المورّد المشكلة لا الشاشة | مسار زيارة واحدة كما يحدث اليوم، ونقاط التعطّل، وما تريد أن يتغير |
| ٣. المتطلبات الوظيفية | ما يجب أن يفعله النظام | بنود مرقّمة بمستوى إلزام وحالة اختبار ونتيجة متوقعة |
| ٤. الأجهزة والأنظمة القائمة | تقييم التكامل قبل الوعد به | الطراز والإصدار وسنة التركيب والمورّد لكل جهاز أو نظام |
| ٥. البيانات والاستضافة | أن يعرف المورّد قيودك مبكرًا | مكان الاستضافة المقبول، الوصول، الاحتفاظ، التصدير عند الانتهاء |
| ٦. التنفيذ والتدريب والدعم والقبول | ما يحدث بعد التوقيع | التجربة، مصفوفة المسؤوليات، أوقات الدعم، معيار قبول كل مرحلة |
| ٧. صيغة الرد والتسعير | أن تُقارن الردود بندًا ببند | مستويات التغطية الإلزامية، فصل بنود السعر، قائمة «خارج النطاق» |
لاحظ أن القسم الأول والرابع لا يطلبان من المورّد شيئًا، بل يعطيانه معلومات. وهما غالبًا أكثر ما يُحذف من طلبات العروض، وأكثر ما يفسّر تباعد الأسعار.
كيف تكتب متطلبًا قابلًا للاختبار
القاعدة البسيطة: إن لم تستطع أن تتخيل كيف ستختبر البند في العرض التوضيحي أو في اختبار القبول، فهو ليس متطلبًا بعد، بل أمنية. المتطلب الجيد يصف موقفًا، وما يجب أن يحدث فيه، ومن يرى النتيجة.
| صياغة عامة | صياغة قابلة للاختبار |
|---|---|
| يدعم النظام رمز QR للزوار | عند قراءة رمز زيارة أُلغيت أو انتهت نافذتها الزمنية، تعرض شاشة البوابة الحالة وسببها المختصر، ولا تتيح تسجيل الدخول إلا عبر طلب استثناء يُسجَّل باسم من أجازه. |
| إدارة وثائق المقاولين | إذا انتهت وثيقة يشترطها الإجراء لفرد في فريق معتمد، تظهر زيارته القادمة بمتطلب ناقص قبل موعدها، ويبقى بقية الفريق معتمدين، ويصل تنبيه لمسؤول المقاولين قبل الانتهاء بمدة نحددها. |
| مسارات موافقات مرنة | زيارة مقاول لمنطقة إنتاج تمر بالمضيف ثم الأمن ثم السلامة بالترتيب؛ وعند غياب مسؤول السلامة يتولى بديل معرّف مسبقًا، ويظهر في سجل الزيارة أن القرار صدر بالتفويض. |
| تقارير شاملة | استخراج عدد زيارات شركة محددة خلال ربع سنة، بأفرادها ومدد بقائهم والتمديدات ومن أجازها، وتصديره كملف، من قِبل مستخدم بدور «مسؤول أمن الموقع» دون الاطلاع على مواقع أخرى. |
| النظام آمن | يمنع حساب الشركة المقاولة من رؤية بيانات أي شركة أخرى، ويُسجَّل كل تعديل على الصلاحيات بقيمته قبل التعديل وبعده ومنفّذه. |
ولكل بند ثلاثة حقول إضافية تكتبها أنت لا المورّد:
- رقم ثابت مثل «م-١٤»، حتى تُشير إليه الردود والمحاضر والعقد لاحقًا دون لبس.
- مستوى الإلزام: إلزامي (عدم تغطيته يستبعد العرض)، أو مهم (يؤثر في التقييم)، أو اختياري (يُسعَّر منفصلًا إن وُجد).
- المرحلة: هل تحتاجه عند التشغيل الأول أم يمكن تأجيله لمرحلة لاحقة؟ هذا الحقل وحده يمنع كثيرًا من تضخم العروض.
افصل دائمًا بين «لا يُصدر النظام تصريحًا ولا يسجّل دخولًا» وهو إجراء برمجي، وبين «لا تُفتح البوابة الدوّارة» وهو يحتاج تكاملًا مع نظام التحكم بالدخول لديك. بند واحد يجمعهما سيحصل على «نعم» من الجميع، ولن يعني الشيء نفسه عند أي منهم.
نموذج الوثيقة وصيغة الرد
هيكل وثيقة متطلبات نظام زوار صناعي
انسخ الهيكل كما هو واملأ العمود الأوسط. الأمثلة في العمود الأخير توضيحية؛ استبدلها بواقع منشأتك.
| البند | ما تكتبه | مثال صياغة |
|---|---|---|
| ١-١ المواقع والبوابات | كل موقع، وبواباته، ونوع كل بوابة (مشاة / مركبات / مقاولين)، ومن يشغّلها | مصنع واحد: بوابة مشاة يديرها فريق الأمن، وبوابة شاحنات يديرها فريق المستودع نهارًا والأمن ليلًا |
| ١-٢ فئات الزوار | الفئات الموجودة فعلًا، وأيها الأكثر إرباكًا اليوم | زوار أعمال، مقاولو صيانة متكررون، موردون وسائقون، وفود تدقيق |
| ١-٣ الحجم التقريبي | نطاق لعدد الزيارات في يوم عادي وفي يوم ذروة، ومصدر التقدير | «بين كذا وكذا يوميًا بحسب دفتر البوابة لأسبوعين» — بلا دقة مصطنعة |
| ١-٤ التشغيل | أيام العمل والمناوبات والعطل | ثلاث مناوبات، وزيارات صيانة ليلية طارئة |
| ٢-١ المسار الحالي | زيارة مقاول واحدة من الطلب إلى الخروج، بمن يفعل ماذا | الطلب بالهاتف، الموافقة شفوية، الوثائق تُفحص على البوابة |
| ٢-٢ نقاط التعطّل | ثلاث مشكلات تريد أن تختفي | انتظار المقاولين صباحًا، وثائق منتهية تُكتشف عند الوصول، تعذّر معرفة من بالداخل |
| ٣-x المتطلبات | جدول: الرقم، الموقف، النتيجة المتوقعة، من يرى النتيجة، الإلزام، المرحلة | انظر الأمثلة في القسم السابق |
| ٤-١ الأجهزة والأنظمة | جدول: النوع، الطراز، الإصدار، سنة التركيب، المورّد، هل له واجهة ربط موثقة إن كنت تعرف | نظام تحكم بالدخول يشغّل بوابتين دوّارتين؛ نظام صيانة يصدر أوامر العمل |
| ٤-٢ ما نريد ربطه | الربط المطلوب وسببه، وهل هو شرط للمرحلة الأولى | ربط بوابة المقاولين فقط، ويمكن تأجيله |
| ٥-١ البيانات | الاستضافة المقبولة، من يصل إلى البيانات، مدة الاحتفاظ المبدئية، التصدير عند الانتهاء | بحسب سياسة تقنية المعلومات لديكم — اسألهم قبل الإرسال |
| ٦-١ التنفيذ | هل تريدون تجربة على بوابة واحدة؟ من سيكون مسؤول النظام لديكم؟ | تجربة على بوابة المقاولين قبل التعميم |
| ٦-٢ الدعم | ساعات التشغيل التي تحتاج فيها دعمًا، وما يُعد عطلًا يوقف البوابة | المناوبة الليلية تحتاج قناة بلاغ واضحة |
| ٦-٣ القبول | كيف ستقبلون كل مرحلة | اختبار الحالات الإلزامية من القسم ٣ على بيانات تجريبية ثم تجربة ميدانية |
| ٧-١ صيغة الرد | إلزام الرد على كل بند بأحد مستويات التغطية أدناه | جدول بالرقم والمستوى والشرح والمرجع |
| ٧-٢ التسعير | فصل البنود: النظام، التهيئة، التخصيص، التكامل، الأجهزة، الاستضافة، التدريب، الدعم — وما يُدفع مرة وما يتكرر | مع قائمة صريحة بما هو خارج النطاق |
مستويات التغطية الإلزامية في الرد
اطلب من كل مورّد أن يضع أمام كل بند مستوى واحدًا فقط من هذه، مع شرح قصير. ولا تقبل «نعم» أو «مدعوم» وحدها.
| المستوى | معناه | ما تطلبه معه |
|---|---|---|
| أ — إعداد قياسي | يتحقق بضبط إعدادات موجودة دون تطوير | أن يُعرض في العرض التوضيحي |
| ب — محتوى أو قالب | يحتاج إعداد نصوص أو قوالب أو نماذج | من يعدّها ومن يحدّثها لاحقًا |
| ج — تخصيص برمجي | يحتاج تطويرًا خاصًا | بند مسعَّر مستقل وأثره على الترقيات |
| د — تكامل مشروط | يعتمد على نظام أو جهاز لديكم | ما يحتاجه تقييم التوافق وما يحدث إن تعذّر |
| هـ — غير مغطى | خارج نطاق المنتج | بديل مقترح إن وُجد |
هذه المستويات ليست تفصيلًا شكليًا. العرض الذي يضع «أ» أمام عشرين بندًا ويستطيع عرضها فعلًا يختلف جوهريًا عن عرض يضع «نعم» أمام كل شيء ثم يظهر في العقد بند «تطويرات حسب الطلب». وهي المستويات نفسها التي تفصل التهيئة عن التخصيص في صفحة مستويات التخصيص، فيسهل عليك مطابقة الرد بما يُقال في العرض.
الأرقام التي لا تملكها بدقة
كثير من المنشآت تؤجل طلب العروض لأنها لا تعرف عدد زياراتها بدقة. لا حاجة للدقة هنا، بل لنطاق صادق ومصدر معلن. ثلاث طرق تكفي:
- عدّ أسبوعين من دفتر البوابة لكل بوابة على حدة، وسجّل أكبر يوم وأصغر يوم. لا تحسب متوسطًا واحدًا للموقع كله؛ البوابات لا تتشابه.
- اسأل عن الفئات لا عن المجموع. عدد شركات المقاولين النشطة وعدد أفرادها أهم للتسعير والتهيئة من إجمالي الزيارات.
- اذكر الأحداث الاستثنائية كالتوقف المجدول أو المواسم، لأنها تحدد طاقة البوابة المطلوبة أكثر من اليوم العادي.
واكتب بجانب كل رقم مصدره: «من دفتر البوابة»، أو «تقدير المشرف». المورّد الجاد سيسألك عنه، والآخر سيتجاهله — وهذا في حد ذاته معلومة.
ما لا يوضع في الوثيقة
- اسم منتج أو علامة تجارية كمرجع لما تريد. صِف الوظيفة لا المنتج. وإن كانت منشأتكم جهة حكومية، فالنظام يمنع أصلًا تضمين المواصفات إشارة إلى علامة تجارية بعينها أو مواصفات لا تنطبق إلا على مورّدين محددين، إلا في حالات محددة بشروطها.
- «يجب أن يدعم كل أنواع الأجهزة». هذه العبارة تدعو إلى وعود لا يمكن اختبارها. اكتب ما لديك فعلًا في القسم الرابع.
- متطلبات منسوخة من كراسة أخرى لمنشأة مختلفة. كل بند لا يعالج مشكلة لديكم يرفع السعر ويؤخر التنفيذ.
- قرارات سياسة لم تُحسم داخليًا، مثل من يوافق على زيارات الإنتاج. إن لم تتفقوا عليها بعد، اكتبها كسؤال مفتوح بدل متطلب، ودع العرض يقترح.
- بيانات زوار حقيقية أو صور هويات كمرفقات توضيحية. نماذج الحقول تكفي.
يلزم نظام المنافسات والمشتريات الحكومية الجهات الحكومية باستخدام النماذج المعتمدة للعقود ووثائق المنافسة. ضع محتوى هذه الوثيقة في القسم الفني للنموذج المعتمد لديكم، وراجع النسخة السارية من النظام ولائحته عند الإعداد. ولما يتوقعه المورّد من ردّ بندي على الكراسة، انظر صفحة المنشآت الحكومية وشبه الحكومية.
مثال: بند واحد وردّان
بند وثائق المقاولين كما وصل من مورّدين
مثال توضيحيمصنع ببوابتين يكتب البند «م-٠٩»: «إذا انتهت وثيقة يشترطها الإجراء لفرد في فريق معتمد بزيارات متكررة، يتوقف اعتماد زياراته دون بقية الفريق، ويصل تنبيه لمسؤول المقاولين قبل الانتهاء بأسبوعين». الردّان التاليان مصاغان للتوضيح، ولا يمثلان مورّدين حقيقيين.
- الرد الأول«نعم — النظام يدعم إدارة الوثائق وتواريخ الانتهاء.» لا مستوى تغطية، ولا ذكر لسلوك الفريق، ولا لمهلة التنبيه.
- الرد الثاني«المستوى أ: تنبيه قابل للضبط بالأيام، وإيقاف اعتماد الفرد وحده. ملاحظة: إن انتهت الوثيقة أثناء زيارة جارية، لا تُقطع الزيارة، وتظهر الحالة من الزيارة التالية.»
- ما كشفه الفرقالرد الثاني أجاب عن سؤال لم يكتبه المصنع أصلًا: ماذا يحدث أثناء الزيارة الجارية؟ فأضافه المصنع كسؤال موحّد لكل المورّدين قبل التقييم.
- في العرض التوضيحيطُلب من كل مورّد عرض البند «م-٠٩» تحديدًا. الرد العام يحتاج الآن أن يثبت نفسه على الشاشة.
- في العقديُنقل نص البند ومستوى التغطية المعلن إلى ملحق النطاق، فيصبح أساس اختبار القبول لاحقًا.
خطوات الإعداد
- ارسم زيارة مقاول واحدة كما تحدث اليوممع الأمن والسلامة والمضيف في جلسة واحدة. هذه الورقة تصبح القسم الثاني.
- اجمع أرقام أسبوعين من البواباتلكل بوابة وفئة، مع أكبر يوم وأصغر يوم.
- اطلب من تقنية المعلومات قائمة الأجهزة والأنظمةوقيود الاستضافة والبيانات، قبل الإرسال لا بعده.
- اكتب المتطلبات كحالاتوابدأ بعشرة إلزامية فقط تعالج نقاط التعطّل. الزيادة لاحقًا أسهل من الحذف.
- أرسل الوثيقة نفسها لكل مورّدمع صيغة الرد ومهلة للأسئلة، وشارك الأسئلة وإجاباتها مع الجميع.
- قيّم الردود بندًا ببندثم اطلب عرض البنود الإلزامية في العرض التوضيحي قبل مقارنة الأسعار.
أسئلة متكررة
ما يكفي لسبعة أقسام قصيرة، وغالبًا بين خمس صفحات وعشر مع الجداول. الطول ليس معيارًا؛ المعيار أن يستطيع مورّد لم يزر موقعك أن يسعّر النطاق نفسه الذي يسعّره غيره.
ليس ضروريًا. الأنفع أن تحدد المرحلة المطلوبة لكل بند، فتعرف من الردود كلفة البداية المركّزة وكلفة الاكتمال، وتقرر بعدها. ذكر رقم مسبق يدفع العروض نحوه صعودًا أو هبوطًا.
اكتبه كسؤال مفتوح: «نطلب اقتراح مسار اعتماد لزيارات مناطق الإنتاج مع بيان ما يُضبط بالإعداد». لكن احسمه قبل التعاقد، لأن النظام يثبّت الإجراء ولا يحسم الخلاف عليه.
اطلب إعادة تقديمه بالصيغة قبل التقييم. قبول ردود بصيغ مختلفة يعيدك إلى المقارنة بين أساليب العرض لا بين الحلول.
لا. الوثيقة تحدد ما يُعرض، والعرض التوضيحي يثبت أنه موجود. اطلب في العرض البنود الإلزامية بأرقامها، على حالات من منشأتك لا على بيانات عامة.
- وزارة المالية — نظام المنافسات والمشتريات الحكومية ولائحته التنفيذية (المادة الثانية والعشرون بشأن المواصفات، وحكم استخدام النماذج المعتمدة في الأحكام الختامية). تحقّق من النسخة السارية وتعديلاتها قبل الاعتماد.