كيف تقرأ عرض سعر برمجة قبل أن تدفع؟ علامات التحذير بندًا بندًا.

اقرأ أي عرض سعر برمجة من بنوده قبل رقمه الأخير: نطاق العمل المكتوب، والافتراضات، والاستثناءات، وجدول الدفعات، وطريقة تسعير التغييرات، والضمان، ومن يملك الكود والحسابات بعد التسليم. فإذا غاب أحد هذه البنود أو كُتب بعبارات عامة مثل «نظام متكامل» أو «حسب الحاجة»، فالرقم المكتوب ليس ما ستدفعه فعلًا، والفرق سيظهر لاحقًا في صورة طلبات تغيير أو خلاف على ما اتفقتم عليه.

في هذا الدليل نمر على العرض جزءًا جزءًا كما يصلك من شركة التطوير، ونجمع في جدول واحد ما يجب أن تجده في كل جزء وما يُعد علامة تحذير، ثم نعطيك خطوات عملية لمقارنة أكثر من عرض، ونشرح كيف نكتب عروضنا في HBS. أما إذا كنت تبحث عن نطاقات الأسعار نفسها ومثال لحساب التكلفة على ثلاث سنوات، فستجدها في دليلنا عن تكلفة برمجة نظام ERP أو CRM مخصص.

ما الذي يجب أن يحتويه عرض سعر برمجة واضح؟

العرض الجيد وثيقة تصف ما ستستلمه وبأي شروط، لا ورقة فيها رقم وتاريخ تسليم. ويلخص هذا الجدول الأجزاء التي يجب أن تجدها، وما تبحث عنه في كل جزء، وما يعني أن عليك التوقف والسؤال:

وانتبه إلى بند الضرائب تحديدًا عند المقارنة: بحسب الوضع الحالي (نوفمبر 2026)، السعر العام للضريبة على القيمة المضافة في مصر 14% بحسب قانون الضريبة على القيمة المضافة رقم 67 لسنة 2016، فالفرق بين عرض شامل للضريبة وعرض غير شامل لها ليس صغيرًا.

كيف تقرأ نطاق العمل دون أن تفترض ما لم يُكتب؟

نطاق العمل أهم جزء في العرض، لأن كل ما بعده يُحسب عليه. والقاعدة بسيطة: ما لم يُكتب في النطاق فهو غير موجود، حتى لو تحدثتم عنه في الاجتماع. لذلك اقرأه بهذه العين:

• هل الوحدات مذكورة بمزاياها أم بأسمائها فقط؟ عبارة «وحدة المبيعات» وحدها لا تقول شيئًا. أما «خط مبيعات بمراحل قابلة للتعديل، وعروض أسعار بأكثر من إصدار، وتقرير أداء لكل مندوب» فتستطيع محاسبة المورّد عليها.
• هل الأدوار والصلاحيات محددة؟ عدد أنواع المستخدمين وما يراه كل منهم يغير حجم العمل كثيرًا، وهو من أكثر ما يُنسى عند كتابة العروض.
• هل التكاملات مذكورة بأسماء الأنظمة؟ «الربط مع الأنظمة الأخرى» عبارة مفتوحة. اطلب الأسماء: برنامج المحاسبة، وبوابة الدفع، ومنظومة الفاتورة الإلكترونية، وواتساب.
• هل المنصات واللغات واضحة؟ ويب فقط أم تطبيق موبايل أيضًا، وعربي فقط أم عربي وإنجليزي، ومن يكتب المحتوى ويترجمه.
• هل التقارير مذكورة بأسمائها؟ «تقارير شاملة» قد تعني تقريرين، وقد تعني ما تحتاجه إدارتك فعلًا. الفرق يظهر فقط حين تُكتب الأسماء.

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

لماذا تهمك الافتراضات والاستثناءات أكثر من السعر؟

الافتراضات هي ما بنى عليه المورّد سعره، والاستثناءات هي ما قرر ألا يدخل في السعر. ومعًا يحددان الفرق بين الرقم المكتوب والتكلفة الحقيقية. ومن أمثلة الافتراضات الشائعة:

• بياناتك جاهزة ونظيفة. إذا افترض العرض أن بياناتك القديمة ستصل في ملف Excel مرتب، فمن سينظفها إن لم تكن كذلك، وبأي تكلفة؟
• اعتماد كل مرحلة خلال أيام محددة. تأخرك في المراجعة قد يُحسب تأخيرًا منك لا من المورّد، وقد يغير موعد التسليم كله.
• عدد محدود من جولات التعديل على التصميم. وهذا طبيعي بشرط أن يكون العدد مكتوبًا ومعروفًا لك من البداية.
• توفر واجهات API لدى الأطراف الأخرى. إذا كان الربط يعتمد على نظام لا تملكه، فما الذي يحدث لو لم تكن واجهته متاحة أو موثقة؟

أما الاستثناءات فاطلبها كتابة إن لم تجدها. ومن أكثرها تكرارًا: الاستضافة والخوادم السحابية، والنطاقات، والتراخيص والإضافات المدفوعة، ورسوم بوابات الدفع ورسائل SMS، ورسوم متاجر التطبيقات، وإدخال السجلات الورقية القديمة. ووجود هذه القائمة علامة جيدة لا سيئة، لأنها تعني أن المورّد فكر في التكلفة الكاملة وقالها لك بوضوح.

كيف يجب أن تُربط الدفعات بالمراحل والتسليمات؟

جدول الدفعات يكشف من يتحمل المخاطرة. فالدفعة المقدمة الكبيرة تنقل المخاطرة كلها إليك، والدفعات المرتبطة بالتواريخ تجعلك تدفع حتى لو لم يُسلَّم شيء. والأصح أن ترتبط كل دفعة بتسليم تستطيع رؤيته واختباره، كما في هذا المثال التوضيحي:

النسب نفسها تختلف من مشروع لآخر، والمهم ألا تدفع الجزء الأكبر قبل أن ترى نظامًا يعمل، وأن تبقى دفعة أخيرة مرتبطة بالقبول. ولتحكم على واقعية الجدول الزمني في العرض، راجع مقالنا عن المدة الواقعية لتطوير برنامج مخصص لكل مرحلة.

كيف يتعامل العرض مع طلبات التغيير والضمان والدعم؟

كل مشروع برمجي يتغير أثناء التنفيذ، وهذا ليس عيبًا. العيب أن يحدث التغيير بلا قواعد. ابحث في العرض عن ثلاثة أشياء:

• آلية مكتوبة لطلبات التغيير. تطلب التغيير كتابة، فيرد المورّد بتقدير للوقت والتكلفة، ولا يبدأ التنفيذ قبل موافقتك. ويُفضَّل أن يذكر العرض سعر الساعة أو اليوم الذي ستُحسب به التغييرات.
• ضمان يفرّق بين الخطأ والميزة الجديدة. إصلاح ما لا يعمل كما اتُّفق عليه مسؤولية المورّد خلال فترة الضمان دون مقابل، أما إضافة ما لم يكن في النطاق فهي طلب تغيير. وإذا لم يحدد العرض مدة الضمان وما يغطيه، فكل خلل بعد الإطلاق سيصبح موضوع تفاوض.
• دعم بعد الضمان بشروط معروفة. من يرد عليك إذا توقف النظام، وخلال كم ساعة، وكم يكلف عقد الصيانة الشهري أو السنوي. لا يلزم أن تتعاقد عليه الآن، لكن يجب أن تعرفه قبل أن توقّع.

من يملك الكود والحسابات بعد التسليم؟

هذا البند لا يظهر في السعر لكنه يحدد قيمة ما تدفعه. فإذا لم تملك الكود والحسابات، فأنت تدفع ثمن نظام لا تستطيع نقله أو تطويره مع غير من بناه. تأكد أن العرض يذكر:

• نقل ملكية الكود المصدري إليك. عند سداد المستحقات، لا مجرد «ترخيص استخدام» يبقى الكود بموجبه ملكًا للمورّد.
• تسليم المستودع والتوثيق الفني. بما في ذلك طريقة التشغيل والنشر، حتى يستطيع أي فريق آخر أن يكمل العمل.
• تسجيل الخوادم والنطاق والحسابات باسم شركتك. لا باسم المورّد أو أحد موظفيه.
• حقك في تصدير بياناتك كاملة. في أي وقت وبصيغ معروفة.

وتأكد كذلك أن هذه البنود ستنتقل كما هي إلى العقد، فالعرض يحدد ما تتفاوض عليه والعقد هو ما يحميك.

كيف تقارن بين أكثر من عرض سعر بطريقة عادلة؟

المقارنة بالرقم الأخير وحده تكافئ غالبًا العرض الأقل وضوحًا. اتبع هذه الخطوات بدلًا من ذلك:

1. أرسل الوصف نفسه للجميع. وثيقة متطلبات واحدة بالصيغة نفسها، حتى تقارن عروضًا للمشروع نفسه.
2. انقل كل العروض إلى جدول واحد. صف لكل جزء من أجزاء الجدول الأول في هذا المقال، وعمود لكل شركة.
3. علّم كل خانة فارغة. البند غير المذكور ليس مجانيًا، بل تكلفته غير معروفة بعد.
4. أرسل أسئلتك كتابة واطلب الردود كتابة. ثم أضف الردود إلى العرض نفسه أو إلى ملحق موقّع.
5. اسأل عن الفريق الذي سينفذ. من سيعمل على مشروعك فعلًا، وهل لديه مشروعات منشورة مشابهة تستطيع رؤيتها.
6. احسب التكلفة الكاملة لا سعر البناء وحده. أضف الاستضافة والتراخيص والدعم لسنتين أو ثلاث إلى كل عرض.
7. قارن ما يحدث عند الخلاف. العرض الذي يحدد طريقة للتغيير والقبول والخروج يحميك أكثر من عرض أرخص لا يذكرها.

وإذا كنت لا تزال في مرحلة اختيار الشركة نفسها قبل مقارنة الأسعار، فراجع ثمانية معايير لاختيار شريك تطوير البرمجيات.

كيف نكتب عرض السعر في HBS؟

لا نرسل في HBS رقمًا قبل أن نفهم طريقة عملك. نبدأ بجلسة اكتشاف نراجع فيها العمليات والبيانات والأنظمة التي يحتاج النظام إلى الاتصال بها، ثم نكتب نطاقًا بمراحل واضحة. ونفصل في العرض بين ما يشمله السعر وما لا يشمله، فتظهر تكاليف الأطراف الأخرى مثل الاستضافة والنطاقات والتراخيص المدفوعة ورسوم بوابات الدفع في قائمة مستقلة بدلًا من أن تفاجئك بعد التوقيع.

ونعرف أهمية هذه البنود من جهة العميل أيضًا. فحين بنينا لوحة التحكم LDY CMS لشركة لبيب دميان يوسف وشركاه، كان من وحداتها مُنشئ عروض أسعار يضيف إلى بنود العرض الخصومات وضريبة القيمة المضافة 14% بحسب الوضع الحالي (نوفمبر 2026) ومدة الصلاحية والعملة وشروط الدفع والتسليم، ويتابع كل إصدار من العرض حتى قبوله. وكان التدريب جزءًا من التسليم: جلسات حضورية في مقر الشركة، وويبينارات مباشرة، وفيديوهات شرح قصيرة بالعربية لكل جزء في النظام. وهذا النوع من البنود هو ما يغيب عن كثير من العروض ثم يُطلب لاحقًا بتكلفة إضافية.

المعلومات القانونية والرسوم في هذا المقال بحسب الوضع في نوفمبر 2026 وقد تتغير، فراجع المصدر الرسمي قبل اتخاذ القرار.

لو قدامك أكتر من عرض سعر برمجة ومش عارف تقارن بينهم، احكيلنا عن مشروعك والأنظمة اللي بتشتغل عليها. فريقنا هيقعد معاك في جلسة اكتشاف مجانية ويساعدك تحدد النطاق اللي هتقارن عليه، وتقدر تعرف أكتر عن خدمة تطوير الأنظمة المخصصة للشركات من HBS.