كيف تستخدم هذا القالب
انسخ الجداول أدناه إلى ملف، احذف ما لا يخصك، وأضف ما ينقصك، ثم أرسله لكل مزوّد تقيّمه واطلب عموداً واحداً: «متاح اليوم / يحتاج تطويراً / غير متاح». الردود المكتوبة تكشف في ساعة ما تخفيه العروض الشفهية في شهر.
لماذا تحتاج قائمة مكتوبة أصلاً؟
لأن العروض التوضيحية مصمَّمة لتُبهر لا لتُقارَن. كل مزوّد يعرض أقوى ما لديه ويتجاوز ما ينقصه، وأنت تخرج بانطباعات لا يمكن وضعها جنباً إلى جنب. القائمة المكتوبة تقلب المعادلة: الجميع يجيب على الأسئلة نفسها بالصيغة نفسها.
البند الأهم في القالب
عمود «يحتاج تطويراً» هو الأثمن. إجابة «نعم متاح» و«نعم بعد تطوير» تبدوان متشابهتين في العرض الشفهي — لكن بينهما تكلفة وزمن ومخاطرة صيانة. أجبر المزوّد على التفريق كتابةً.
أولاً: المتطلبات الوظيفية
هذه أهم قسم — وهي المفاهيم التي تفصل النظام الهندسي عن أي نظام إداري عام.
| # | المتطلب | متاح / يحتاج تطويراً / غير متاح |
|---|---|---|
| و-1 | إدارة مراحل التصميم كمفهوم أصيل بدورة اعتماد | |
| و-2 | ضبط إصدارات المخططات وتحديد الإصدار المعتمد للتنفيذ | |
| و-3 | منع وصول إصدار غير معتمد إلى جهة التنفيذ | |
| و-4 | سجل التسليمات الرسمية بمرجع وتاريخ ومستلم | |
| و-5 | إدارة طلبات المعلومات RFI ومتابعة الرد عليها | |
| و-6 | تقارير عدم المطابقة NCR من التسجيل حتى الإغلاق | |
| و-7 | توثيق الزيارة الميدانية بموقع جغرافي وصور وزمن | |
| و-8 | عمل التطبيق الميداني دون اتصال بالإنترنت ومزامنته لاحقاً | |
| و-9 | المستخلص مبنياً على نسبة إنجاز المرحلة | |
| و-10 | فوترة إلكترونية متوافقة مع المتطلبات السعودية | |
| و-11 | تسجيل ساعات الفريق مرتبطة بالمشروع والمرحلة | |
| و-12 | رؤية أحمال الفريق قبل قبول مشروع جديد | |
| و-13 | حساب ربحية كل مشروع من الساعات والتكاليف والفوترة | |
| و-14 | إدارة العروض الفنية والمالية ومتابعتها | |
| و-15 | تحويل العقد الموقّع إلى مشروع بمراحله | |
| و-16 | إدارة الاستشاريين المساعدين ومستحقاتهم | |
| و-17 | أوامر التغيير وتوثيق أثرها على النطاق والمقابل | |
| و-18 | لوحات قرار للإدارة العليا محدَّثة تلقائياً |
ثانياً: المتطلبات التقنية
| # | المتطلب | الرد |
|---|---|---|
| ت-1 | نوع النشر: سحابي أم على خادم داخلي أم كلاهما | |
| ت-2 | موقع استضافة البيانات جغرافياً | |
| ت-3 | واجهة عربية كاملة من اليمين لليسار | |
| ت-4 | دعم العربية والإنجليزية في المحتوى والتقارير | |
| ت-5 | تطبيق جوال للعمل الميداني | |
| ت-6 | نظام صلاحيات على مستوى المستخدم والمشروع | |
| ت-7 | التحقق بخطوتين | |
| ت-8 | سجل تدقيق كامل لا يُحذف | |
| ت-9 | التشفير أثناء النقل وأثناء التخزين | |
| ت-10 | النسخ الاحتياطي ودوريته | |
| ت-11 | واجهة برمجية API للتكامل | |
| ت-12 | التكامل مع نظامنا المحاسبي الحالي (سمّه) | |
| ت-13 | حدود التخزين وسعة الملف الواحد | |
| ت-14 | تصدير البيانات بصيغ قياسية في أي وقت |
ثالثاً: المتطلبات التعاقدية
| # | المتطلب | الرد |
|---|---|---|
| ع-1 | بنية التسعير: رسوم تطبيق واشتراك — مفصّلة | |
| ع-2 | ما المشمول في رسوم التطبيق بالتحديد | |
| ع-3 | خيارا الدفع الشهري والسنوي وفارقهما | |
| ع-4 | آلية إضافة أو تقليص المستخدمين والوحدات | |
| ع-5 | أي بند اختياري يُسعَّر مستقلاً | |
| ع-6 | مدة التطبيق المتوقعة لنطاقنا | |
| ع-7 | نطاق ترحيل البيانات المشمول | |
| ع-8 | جلسات التدريب المشمولة وحسب أي دور | |
| ع-9 | مستوى الخدمة SLA وقنوات الدعم وأوقاتها | |
| ع-10 | ملكية بياناتنا وآلية استخراجها عند الإيقاف | |
| ع-11 | هل توجد رسوم على استخراج البيانات | |
| ع-12 | سياسة التحديثات وهل هي مشمولة |
أرسل لنا قائمتك ونجيب عليها كتابةً
لا نطلب منك مقارنة انطباعات. أرسل متطلباتك ونعيدها إليك مجابة بنداً بنداً بصيغة «متاح / يحتاج تطويراً / غير متاح».
أرسل كراسة شروطككيف تُقيّم الردود؟
لا تجمع «نعم» وتقارن الأعداد. رجّح البنود أولاً:
صنّف كل بند إلى ثلاث فئات
حرِج (لا نستطيع العمل بدونه) · مهم (نريده لكن نتحمّل غيابه سنة) · مرغوب (تحسين).
أسقط أي نظام يفشل في بند حرِج
مهما كان قوياً في غيره. البند الحرِج غير قابل للمقايضة بحكم تعريفه.
احسب «يحتاج تطويراً» كتكلفة لا كنعم
اطلب تقدير التكلفة والمدة لكل بند من هذا النوع، وأضفها إلى إجمالي العرض.
قارن على ثلاث سنوات
رسوم التطبيق + الاشتراك × 3 + التطويرات المطلوبة + صيانتها المتوقعة.
الخطأ الأشيع في التقييم
اختيار النظام الأعلى في عدد «نعم». نظام يجيب بنعم على 40 بنداً ويفشل في «ضبط إصدارات المخططات» أسوأ لمكتب تصميم من نظام يجيب بنعم على 25 بنداً ويتقنه — لأن البند الحرِج الواحد يُفشل التطبيق كله.