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

الاتنين بيتداخلوا، لكن تكلفة كل واحد ليها شكل مختلف.
بوابة العملاء هي أبلكيشن بيتفتح بتسجيل دخول وموجه لناس من بره الشركة. العملاء أو الموزعين أو المستأجرين أو المرضى أو الملاك بيدخلوا يشوفوا بياناتهم هما بس وينفذوا حاجات بنفسهم: ينزلوا فاتورة، يتابعوا طلب، يبعتوا طلب دعم، يرفعوا مستند، يراجعوا عقد، أو يدفعوا رصيد. المشكلة الهندسية الأساسية هنا هي العزل. العميل أ ما ينفعش يشوف بيانات العميل ب أبدا، لا في الشاشة ولا في الـ API ولا في ملف إكسل بيتصدر ولا في لينك اتبعت بالإيميل واتحول لحد تاني.
النظام المخصص للشركة غالبا بيكون داخلي. بيترجم طريقة شغلك الحقيقية: استقبال العملاء المحتملين، عروض الأسعار، الموافقات، التنفيذ، الجدولة، المخزون، العمولات، والتقارير. المشكلة الأساسية هنا هي إن النظام يمشي زي شغلك بالظبط. يعني القواعد اللي دلوقتي عايشة في شيتات إكسل وجروبات واتساب وفي دماغ اتنين من الموظفين القدامى لازم تتكتب جوه الأبلكيشن.
أغلب المشاريع الحقيقية بتجمع الاتنين: لوحة تحكم داخلية للموظفين، وبوابة بتعرض للعملاء جزء محدد منها. علشان كده عرض سعر “بوابة” واحد ممكن يخبي تحته نظام كامل. عندنا صفحات بتشرح الأشكال المعتادة، منها صفحة برمجة أنظمة مخصصة للشركات. لكن التكلفة نفسها بتتحدد من الطبقات اللي جاية.
سبع طبقات بتتوزع عليها تكلفة أي نظام مخصص
أي مشروع جاد، سواء على لارافيل أو ووردبريس كأساس للأبلكيشن أو أي تقنية تانية، بيصرف مجهود في نفس الأماكن السبعة. لو عرض السعر مش بيوريك المجهود متوزع إزاي عليهم، يبقى مش هتعرف تقيمه.
لما نقيم تكلفة برمجة بوابة عملاء في مصر، بنقسم المشروع للطبقات دي بدل ما نحاول نطلع رقم واحد سريع من عدد الصفحات أو الشاشات.
1. الاستكشاف ورسم العمليات
قبل ما يتكتب سطر كود، لازم حد يوثق الشغل الحالي والاستثناءات والقرارات. هنا بتظهر التعقيدات المستخبية: “الموافقات” طلعت ليها تلات مستويات، و”الفواتير” طلعت نوعين من الضريبة، و”العملاء” بتشمل شركات وأفراد وكل نوع ليه بيانات مختلفة. لو اتخطيت الاستكشاف، التكلفة دي مش بتختفي، دي بتتنقل لمرحلة التنفيذ وبتتدفع بسعر أعلى على شكل طلبات تعديل.
2. هيكل البيانات والصلاحيات
هيكل البيانات هو الأساس، ونظام الصلاحيات بيتبني فوقيه. نظام فيه دورين (مدير وعميل) منتج مختلف تماما عن نظام فيه تمن أدوار، ورؤية حسب الفرع، وموافقات مفوضة، وملكية على مستوى السجل الواحد. كل دور إضافي بيزود عدد الحالات اللي لازم تتصمم وتتبرمج وتتختبر.
3. محرك العمليات وقواعد الشغل

الحالات والانتقالات والتحقق من البيانات والإشعارات والتصعيد والمواعيد النهائية. العملية الخطية (اتقدم الطلب، اتراجع، اتنفذ) رخيصة. العملية اللي فيها فروع شرطية وموافقات متوازية ومؤقتات اتفاقيات خدمة وإعادة إسناد تلقائي مش رخيصة. الطريقة الأمينة لتقدير الطبقة دي إنك تعد الحالات المختلفة والانتقالات بينها.
4. الواجهة وتجربة المستخدم
الشاشات والنماذج والجداول والفلاتر ولوحات المتابعة وحالات الخطأ والحالات الفاضية والشكل على الموبايل. وللعميل المصري فيه بند بيتنسى كتير: دعم العربي والإنجليزي مع اتجاه RTL. أبلكيشن لازم يشتغل بالعربي والإنجليزي صح مش مجرد ترجمة. التصميم بينعكس، والجداول بتتقلب، والأرقام والتواريخ محتاجة معاملة ثابتة، والنص المختلط (كود منتج إنجليزي جوه جملة عربي) محتاج معالجة صريحة، وملفات الـ PDF والإيميلات محتاجة نفس العناية. احسبها من أول يوم، لأن إضافة RTL بعد كده أغلى بكتير من التصميم ليها من الأول.
5. الربط مع الأنظمة التانية
بوابات الدفع، برامج المحاسبة أو الـ ERP، الـ CRM، مزودي الـ SMS والواتساب، الفاتورة الإلكترونية، تسجيل الدخول الموحد، شركات الشحن، وواجهات البنوك أو الجهات الحكومية. مجهود الربط مش بيعتمد على عدد الأنظمة قد ما بيعتمد على جودة الطرف التاني. واجهة REST موثقة كويس ومعاها بيئة تجريبية ممكن تاخد أيام قليلة. نظام قديم من غير API، أو تصدير بيوصل بالإيميل، أو مورد بيرد على التذاكر بعد أسبوعين ممكن يضاعف المجهود. اقرا كمان عن ربط أنظمة CRM و ERP.
6. التقارير والتصدير وسجل المراجعة
الإدارة عايزة لوحات متابعة. الحسابات عايزة ملفات تصدير تطابق للجنيه. والامتثال عايز يعرف مين غير إيه وامتى. كل واحدة من دول ميزة ليها تصميمها واختبارها وشغل على سرعة الاستعلامات. وسجل المراجعة بالذات أرخص بكتير لو اتبنى من الأول من إنه يتضاف بعد التشغيل.
7. نقل البيانات والاختبار والنشر والتدريب
البيانات الموجودة لازم تتنضف وتتطابق وتتنقل، وغالبا أكتر من مرة، لأن أول نقل دايما بيكشف مشاكل. بعدها اختبار تلقائي ويدوي، وبيئة تجريبية، والنشر على السيرفر الفعلي، والنسخ الاحتياطي، والمراقبة، وتدريب المستخدمين، والتوثيق. نقل البيانات هو الطبقة اللي بتغيب أكتر من العروض الرخيصة، وهو السبب الأكتر في تأخير الإطلاق.
إيه اللي بيحدد تكلفة برمجة بوابة عملاء في مصر؟
أكبر عامل في تكلفة برمجة بوابة عملاء في مصر مش لغة البرمجة نفسها، لكن حجم القواعد والعمليات والصلاحيات والربط اللي النظام لازم ينفذها بشكل موثوق.
من المشاريع اللي بنقدرها، دي العوامل اللي بتغير الميزانية أكتر، مرتبة تقريبا حسب تأثيرها:
- عدد الأدوار وقواعد الصلاحيات. كل دور محتاج شاشاته وإجراءاته واختباراته. والقواعد على مستوى السجل (“مدير الفرع يشوف عملاء فرعه بس”) أغلى من القواعد على مستوى الدور.
- عدد الأنظمة المطلوب الربط معاها وجودتها. عدها، وبعدين اسأل مين مسؤول عن الطرف التاني وفيه توثيق ولا لأ.
- تعقيد العمليات. الحالات والفروع والموافقات والمؤقتات والاستثناءات.
- حجم نقل البيانات ونضافتها. النضافة أهم من الحجم. عشرة آلاف صف نضيف أسهل من ألفين صف موزعين على أربع شيتات كل واحد ليه طريقة مختلفة.
- اللغتين واتجاه RTL وتعدد العملات. موجودين في أغلب مشاريع الشركات في مصر، وغايبين عن أغلب الطلبات الأولى.
- مستوى الأمان والامتثال. البيانات الشخصية أو المالية أو الصحية أو العقود بترفع المستوى المطلوب في التحكم في الوصول والتشفير والسجلات واختيار الاستضافة.
- تجربة الموبايل. بوابة ويب متجاوبة نطاق، وأبلكيشن موبايل فوقها نطاق تاني ليه دورة إصدار ومراجعة متاجر.
- عمق التقارير. خمس تقارير ثابتة مش زي أداة تقارير بيعملها المستخدم بنفسه.
- عدد أصحاب القرار. كل شخص إضافي بيضيف دورات مراجعة. ده مش بيظهر في أي نموذج تقدير، لكنه كتير بيبقى هو اللي بيحدد الجدول الزمني الحقيقي.
مثال محسوب وكل افتراض فيه ظاهر
علشان تشوف تكلفة برمجة بوابة عملاء في مصر بشكل عملي، المثال التالي بيحوّل المتطلبات إلى أيام عمل بدل ما يبدأ برقم مالي عشوائي.
علشان الفكرة تبقى ملموسة، ده مثال توضيحي لتقدير مشروع. هو مثال للتخطيط مش عرض سعر ومش مشروع لعميل حقيقي. أرقام المجهود افتراضات اخترناها علشان نوضح الحساب.
السيناريو: موزع عايز بوابة للتجار. التاجر بيدخل يشوف قايمة أسعاره، وينزل أوردر، ويتابع حالة التوصيل، وينزل الفواتير وكشوف الحساب، ويفتح طلب دعم. جوه الشركة، موظفين المبيعات بيديروا التجار ويوافقوا على الأوردرات. الشركة بتستخدم برنامج محاسبة ليه API موثق.
النطاق المفترض: تلات أدوار (تاجر، مبيعات، أدمن)، حوالي 25 شاشة، عملية موافقة واحدة على الأوردر فيها أربع حالات، ربط واحد مع برنامج المحاسبة (الفواتير في اتجاه والمدفوعات في اتجاه)، عربي وإنجليزي، نقل مرة واحدة للتجار والمنتجات من شيتات، وخمس تقارير ثابتة.
| الطبقة | المجهود المفترض (يوم عمل للفرد) |
|---|---|
| الاستكشاف ورسم العمليات | 8 |
| هيكل البيانات والصلاحيات | 10 |
| العمليات وقواعد الشغل | 12 |
| الواجهة (25 شاشة عربي وإنجليزي RTL) | 35 |
| الربط مع برنامج المحاسبة | 12 |
| التقارير والتصدير وسجل المراجعة | 10 |
| نقل البيانات والاختبار والنشر والتدريب | 18 |
| الإجمالي الفرعي | 105 |
| إدارة المشروع ودورات المراجعة (مفترض 15 في المية) | حوالي 16 |
| الإجمالي | حوالي 121 |
تكلفة التنفيذ بعد كده هي 121 يوم عمل مضروبة في السعر اليومي المتوسط (س) للفريق اللي هتتعاقد معاه. سبنا (س) متغير قصدا، لأن الأسعار بتختلف بين الفريلانسر والشركة والفريق الداخلي، ولازم تقارن على نفس النطاق مش على رقم معلن.
دلوقتي شوف إيه اللي بيحصل لما النطاق يتغير. ضيف دور رابع (مدير إقليمي بيشوف منطقته بس) وربط تاني (بوابة دفع للسداد أونلاين)، فطبقات الصلاحيات والعمليات والواجهة والاختبار كلها بتكبر. افتراض واقعي إن ده يضيف من 25 لـ 35 يوم عمل. ضيف أبلكيشن React Native لمندوبين الميدان والإجمالي يتحرك تاني. مفيش حاجة من دول غريبة، كلها شائعة. علشان كده النطاق، مش سعر اليوم، هو أكبر عامل في الرقم النهائي.
تبني ولا تشتري ولا تظبط حاجة جاهزة؟

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

- الاستضافة والبنية. سيرفر الأبلكيشن وقاعدة البيانات وتخزين الملفات والنسخ الاحتياطية وبيئة تجريبية. قرر بدري البيانات لازم تفضل جوه مصر ولا ممكن تبقى بره، لأن ده بيأثر على التكلفة وعلى سرعة الاستجابة.
- الصيانة. تحديثات الإطار والمكتبات، وسد الثغرات، والمراقبة، واختبارات استرجاع النسخ. دليلنا عن تكلفة صيانة المواقع في مصر بيشرح تسعير الطبقة دي.
- رسوم الأطراف الخارجية. عمولات بوابة الدفع، رسايل الـ SMS أو الواتساب، إرسال الإيميلات، الخرائط أو التوقيع الإلكتروني. دي بتزيد مع الاستخدام وسهل تتنسي.
- طلبات التعديل. أول شهر استخدام فعلي هيطلع قايمة تحسينات. اتفق على سعر وطريقة للتعامل معاها قبل الإطلاق، مش بعده.
- الدعم. مين هيرد لما مستخدم ما يعرفش يدخل الساعة 9 الصبح يوم أحد، وفي خلال قد إيه؟
لو عرض السعر فيه سعر بناء ومفيش سعر تشغيل، يبقى بيوصف نص التكلفة بس.
قرارات معمارية بتغير السعر
من أغلى القرارات في أي مشروع بتتاخد في الأسبوع الأول، ونادرا بتتناقش مع العميل. تستاهل تفهمها لأنها بتحدد كل تعديل بعد كده هيكلف قد إيه.
عزل العملاء عن بعض
لو البوابة بتخدم شركات أو عملاء كتير، لازم من البداية يتحدد إزاي بيانات كل عميل هتتفصل عن التاني. قاعدة بيانات مشتركة وعليها معرف خاص بكل عميل في كل سجل ممكن تكون أقل في تكلفة التشغيل، لكنها محتاجة انضباط شديد في كل استعلام وكل صلاحية، لأن أي خطأ ممكن يفتح بيانات عميل لعميل تاني. في المقابل، استخدام قاعدة بيانات منفصلة لكل عميل ممكن يكون أعلى في تكلفة التشغيل والإدارة، لكنه بيخلي العزل جزء أساسي من تصميم النظام نفسه.
المهم هنا إن قرار العزل مايتاخدش بالصدفة. لازم يتحدد بناءً على حجم النظام، وعدد العملاء، وحساسية البيانات، وطريقة الاستضافة، ومتطلبات الأمان والامتثال. كمان لازم يتعمل اختبار تلقائي يحاول بشكل متعمد الوصول لبيانات عميل تاني، علشان تتأكد إن النظام بيرفض الطلب في كل الحالات، مش بس إن الواجهة مخبية البيانات.
ولو النظام مبني على Laravel، تقدر تراجع التوثيق الرسمي لنظام الصلاحيات في Laravel، واللي بيشرح استخدام Gates وPolicies لتنظيم التحكم في وصول المستخدمين للموارد المختلفة. الأدوات دي بتساعدك تخلي قواعد الصلاحيات موجودة في مكان واضح داخل النظام بدل ما تتوزع بين الشاشات والكود، وده بيسهل اختبارها ومراجعتها مع نمو المشروع.
مفيش اختيار واحد صح لكل المشاريع. النظام البسيط ممكن يشتغل كويس جدًا بقاعدة بيانات مشتركة مع قواعد وصول صارمة، بينما المشاريع اللي فيها بيانات حساسة أو عدد كبير من العملاء ممكن تحتاج مستوى عزل أقوى. المهم إن التصميم يتاخد بقصد، ويتوثق، ويتختبر قبل الإطلاق.
تصميم يعتمد على API من الأول
لما قواعد الشغل تتبني ورا API داخلي نضيف، أي أبلكيشن موبايل أو ربط أو شريك بعد كده بيستخدم نفس القواعد بدل ما تتكرر. ده بيزود المجهود شوية في الأول وبيوفر كتير بعدين. وهو أحسن طريقة تخلي المرحلة التانية في متناول ميزانيتك.
المهام الخلفية وقوائم الانتظار
إرسال الإشعارات وتوليد ملفات الـ PDF والمزامنة مع برنامج المحاسبة واستيراد الملفات مينفعش تحصل والمستخدم مستني الصفحة. نقلها لمهام في الخلفية مع إعادة محاولة وتنبيه بالفشل قرار تصميمي بيحسن السرعة والاستقرار، والتنفيذ الرخيص بيتخطاه.
التعامل مع الملفات
البوابات بتتراكم فيها عقود وصور بطاقات وفواتير وصور. مكان التخزين، والتحكم في الوصول لكل لينك تحميل، وفحص الفيروسات، وحدود الحجم، وقواعد الاحتفاظ، كلها محتاجة قرارات. ملف متاح على لينك عام ممكن أي حد يخمنه من أكتر الثغرات اللي بنشوفها في فحص البوابات.
سجل المراجعة
تسجيل مين غير أنهي حقل وامتى والقيمة القديمة كانت إيه، رخيص لو اتصمم من الأول ومؤلم لو اتضاف بعد كده. وفي البيانات المالية والتعاقدية بيكون شبه إلزامي.
الأمان وحماية البيانات جزء من النطاق مش إضافة
البوابة بتحتفظ ببيانات عملائك، وغالبا بعلاقتهم التجارية معاك. علشان كده شغل الأمان جزء من الأساس: تسجيل دخول قوي مع تحقق بخطوتين اختياري، سياسة كلمات المرور وقفل الحساب، إدارة الجلسات، فحص الصلاحيات في كل طلب مش في كل شاشة بس، التحقق من المدخلات، نقل مشفر، نسخ احتياطية مشفرة، تحديد عدد المحاولات في الدخول واستعادة كلمة المرور، ومراقبة المكتبات المستخدمة.
ولو النظام بيخزن بيانات شخصية لأفراد في مصر، فهو داخل تحت قانون حماية البيانات الشخصية رقم 151 لسنة 2020. عمليا ده معناه إنك تعرف بتجمع إيه من بيانات شخصية، وليه، وبتحتفظ بيها قد إيه، ومين يقدر يوصل ليها، وإزاي ممكن تتعامل مع طلب من الشخص نفسه. نظام بيخلي الأسئلة دي سهلة الإجابة أرخص في التشغيل من نظام بيخليها بحث جنائي. اكتب ده كمتطلب في الطلب، واستشير مستشارك القانوني في التفاصيل الخاصة بمجالك.
سعر ثابت ولا بالجهد ولا على مراحل؟
شكل العقد بيغير مين بيتحمل المخاطرة، وبالتالي بيغير السعر.
السعر الثابت بيشتغل لما النطاق ثابت فعلا: مواصفات واضحة ومتطلبات مستقرة وربط معروف. المورد بيحط المخاطرة جوه السعر، فالرقم أعلى من التكلفة المتوقعة، وأي تغيير بيبقى تفاوض. ده أنسب لمرحلة تانية محددة كويس مش لأول استكشاف.

الدفع حسب الجهد صريح مع عدم اليقين. بتدفع على المجهود المستخدم، وبتشوف التقدم كل أسبوع، وبتوجه النطاق وانت بتتعلم. محتاج عميل بياخد قرارات بسرعة ومورد بيبلغ بشفافية. من غير سقف أو مراحل ممكن يطول.
التسليم على مراحل بيجمع الاتنين. مرحلة استكشاف مدفوعة بتطلع مواصفات وقايمة أولويات وتقدير ثابت للمرحلة الأولى. المرحلة الأولى بتسلم أصغر جزء بيعمل قيمة حقيقية، غالبا دور واحد وعملية واحدة. والمراحل بعدها بتتسعر على أساس اللي اتعلمته من الاستخدام الفعلي. لأغلب اللي بيشتروا بوابة لأول مرة، دي الطريقة اللي بتخلي التكلفة والندم أقل ما يمكن.
إزاي تكتب طلب بيجيب عروض تقدر تقارن بينها؟
لو بعت نفس الطلب في سطر واحد لأربع شركات، هتستلم أربع منتجات مختلفة. ابعت طلب فيه العناصر دي والعروض هتبقى قابلة للمقارنة:
- المستخدمين والأدوار. مين هيدخل، وكام واحد من كل نوع، وكل نوع يشوف ويعمل إيه.
- أهم العمليات. من خمس لعشر رحلات مهمة، مكتوبة كخطوات (“التاجر ينزل أوردر، المبيعات توافق، المخزن يأكد، التاجر يتبلغ”).
- الربط. كل نظام بالاسم، ولينك التوثيق لو موجود، ومين من الطرف التاني يقدر يجاوب أسئلة تقنية.
- اللغات والأجهزة. عربي أو إنجليزي أو الاتنين، وكمبيوتر أو موبايل ويب أو أبلكيشن.
- البيانات المطلوب نقلها. الملفات الأصلية، والأحجام التقريبية، وتقييمك لنضافتها.
- الأحجام. عدد المستخدمين والسجلات والملفات والعمليات في الشهر دلوقتي وبعد سنتين.
- قيود الامتثال والاستضافة. أي شرط تعاقدي أو قانوني على مكان البيانات ومين يلمسها.
- مقاييس النجاح. إيه اللي لازم يكون اتحقق بعد ستة شهور من الإطلاق علشان المشروع يبقى كان يستاهل.
- اللي بيحدد الموعد. موسم أو حدث أو تاريخ عقد بيخلي الموعد النهائي حقيقي.
وبعدين اطلب من كل مورد يرد بنفس الهيكل: المجهود لكل طبقة، والافتراضات، والمستبعد، وتكلفة التشغيل، وسعر طلب التعديل.
علامات خطر في عرض السعر
فيه أنماط بتتنبأ بالمشاكل بشكل شبه مؤكد:
- رقم واحد إجمالي من غير تفصيل. مش هتعرف تقارنه، ومش هتعرف تفاوض على النطاق من خلاله.
- مفيش مرحلة استكشاف. يا إما المورد بيخمن، يا إما التكلفة هتظهر بعدين في شكل طلبات تعديل.
- مفيش ذكر للاختبار أو نقل البيانات أو النشر. الطبقات دي موجودة سواء اتسعرت أو لأ.
- “تعديلات غير محدودة”. ده معناه نطاق مش محدد، أو مورد هيقلل الجودة في صمت علشان يحمي هامشه.
- مفيش نص على الملكية. لازم تمتلك الكود المصدري وقاعدة البيانات والدومين، وتقدر تنقل النظام لفريق تاني.
- سعر أقل بكتير من الباقي من غير نطاق أصغر. اسأل أنهي طبقة ناقصة. غالبا نقل البيانات أو الأمان أو RTL أو الربط التاني.
- قوالب جاهزة متباعة على إنها تنفيذ مخصص. لو العرض التجريبي عبارة عن قالب لوحة تحكم عام وعليه لوجو شركتك، فانت بتشتري إعداد جاهز ولازم تدفع سعر إعداد جاهز.
حول التكلفة لدراسة جدوى
السؤال اللي هيسأله المدير المالي مش “بكام؟” لكن “هيحل محل إيه؟”. البوابة أو نظام الشركة بيكسب تمنه في أربع أماكن، وكل واحد منهم ممكن تقيسه قبل ما تصرف أي حاجة.
وقت الموظفين اللي هيتوفر. احسب الساعات في الأسبوع اللي بتتصرف في الرد على “أوردري فين؟” وإعادة كتابة البيانات بين الأنظمة ومطاردة المستندات وتجميع التقارير. اضربها في تكلفة الساعة الفعلية. اعملها بأمانة لمدة شهر والرقم نادرا ما بيطلع صغير.
الأخطاء اللي هتتجنبها. كل إدخال يدوي فرصة لسعر غلط أو فاتورة مكررة أو ميعاد فايت. قدر تكلفة آخر عشر أخطاء فاكرهم.
فلوس بتتحصل أسرع. بوابة بتعرض الأرصدة وتصدر كشوف الحساب وتقبل الدفع أونلاين بتقلل الفجوة بين الفاتورة والتحصيل. حتى تقليل كام يوم على دفتر مديونيات كبير بيفرق.
إيراد بتحافظ عليه أو بتكسبه. التجار والعملاء اللي يقدروا يطلبوا ويتابعوا ويكرروا الطلب بنفسهم في أي ساعة أسهل في الاحتفاظ بيهم. ده أصعب مكسب في القياس، فاعتبره ميزة إضافية مش التبرير الأساسي.
حط الأربع أرقام دول جنب تكلفة البناء (في مثالنا 121 يوم عمل في سعرك اليومي) وتكلفة التشغيل السنوية. لو الاسترداد ما ظهرش في فترة شركتك مرتاحة ليها، قلل النطاق لحد ما يظهر. مرحلة أولى أصغر بترجع فلوسها أحسن من مشروع كامل مش بيرجعها.
وده نفس أسلوبنا في الأنظمة المخصصة في كيميتوفا: نبدأ بالعملية اللي بتكلفك أكتر النهارده، نبني أنحف نسخة بتشيل التكلفة دي، نقيس، وندي الأرقام تمول المرحلة اللي بعدها.