هناك نسخة من مشروع ERP لا تنتهي أبدا. تبدأ بتقدير معقول، واجتماع انطلاق ودي، وسعر بالساعة. وبعد عام تظل الفواتير تتوالى، ويكون موعد الإطلاق قد تأجل ثلاث مرات، ولا يستطيع أحد أن يحدد ما الذي يعنيه الإنجاز بعد الآن. إذا سبق لك أن عايشت مشروعا من هذا النوع، فأنت تعرف مسبقا لماذا نرفض بيعه.
نحن نعمل بنطاق محدد وسعر ثابت. كل مشروع تنفيذ نتولاه يُسعَّر بعد مرحلة تحديد النطاق، ويُسلَّم وفق نطاق مكتوب، ويُحدَّد ثمنه كرقم واحد — لا كسعر بالساعة. وعندما يطلب عميل محتمل صيغة الوقت والمواد المفتوحة بدلا من ذلك، نقول لا. وهذا ليس تعنتا منا، بل يتعلق الأمر بمن يتحمل المخاطرة، ونحن نرى أن الجواب ينبغي أن يكون نحن.
لماذا تنجرف مشاريع T&M المفتوحة
تبدو صيغة الوقت والمواد عادلة على الورق: فأنت تدفع مقابل العمل المنجز بالضبط. لكنها في الممارسة تُزيل القوة الوحيدة التي تُبقي مشروع ERP متجها نحو الاكتمال — وهي تعريف مشترك وملزم لما يعنيه الإنجاز. فنظام ERP يمس كل قسم في الشركة، وبمجرد أن يصبح النطاق مفتوحا، يكتشف كل قسم شيئا إضافيا يرغب فيه، ويُحسم كل غموض بمزيد من العمل، وتصبح كل ساعة إضافية قابلة للفوترة. ولا يتطلب أي من ذلك سوء نية؛ إنه ببساطة ما تكافئ عليه هذه البنية.
كما أنها تنقل بهدوء كامل مخاطرة التقدير إلى العميل. فإذا أخطأ المورد في تقدير حجم ترحيل المحاسبة، دفع العميل ثمن هذا الخطأ ساعة بساعة. وهكذا ينتهي الأمر بالطرف الأقل اطلاعا على المدة التي يستغرقها عمل ERP إلى تأمين الطرف الأكثر اطلاعا. ونحن نرى أن هذا معكوس تماما. ففي ظل السعر الثابت، يكون التقدير الخاطئ خسارة نتحملها نحن — وهذا بالضبط ما يجعلنا نقدّر بعناية، ونصر على مرحلة حقيقية لتحديد النطاق قبل أن نقدم أي عرض سعر.
ما الذي تنتجه مرحلة تحديد النطاق الحقيقية
تحديد النطاق ليس مكالمة بيعية مصحوبة بعرض شرائح، بل هو عمل منهجي ذو مخرجات ملموسة، وكل ما يرد في عرض السعر النهائي يمكن تتبعه إليها:
- قائمة الوحدات — أي وحدات Odoo Community و OCA تغطي كل عملية تجارية بشكل جاهز، وأين توجد فجوة تستدعي فعلا تطويرا مخصصا. نحن نعتمد مبدأ Community أولا و OCA أولا: فكلما قل الكود المخصص قلت أعباء الصيانة وقلت الأعطال عند الترقية.
- جرد البيانات — أي الأنظمة القديمة تحتفظ بالبيانات، وما الأحجام المعنية، وأي الكائنات سيتم ترحيلها، وأي تقارير المطابقة ستثبت اكتمال الترحيل.
- عمق التخصيص لكل فجوة — هل الحل هو إعداد وتهيئة، أم توسيع لوحدة قائمة، أم وحدة جديدة. كل ما نبنيه يُطوَّر بمستوى وحدة كاملة ويُدار إصداره في Git، بحيث يصمد أمام الترقيات وعمليات التدقيق.
- خطة الانتقال — عمليات ترحيل تجريبية قبل الترحيل الفعلي، وفحوص مطابقة بعده، وخطة تراجع نأمل ألا نستخدمها أبدا.
- الأدوار والتدريب — من يتعامل مع أي شاشات، والتدريب القائم على الأدوار المقابل لذلك، بحيث يكون تبني النظام مخططا له لا مجرد أمنية.
الناتج هو وثيقة نطاق من الدقة بحيث يمكن وضع رقم ثابت تحتها. ويغطي هذا الرقم الوحدات المدرجة، والبيانات المدرجة، والتخصيصات المدرجة، والتدريب المدرج — ولا شيء أكثر غموضا من ذلك. وإذا تبين بعد التوقيع أن تقديرنا كان خاطئا، فتلك مشكلتنا نحن، لا مشكلتك أنت.
طلبات التغيير دون تسلل الفوترة بالساعة
النطاق الثابت لا يعني تجميد أعمالك. فالمتطلبات تتغير، وهذا أمر طبيعي. ما يتغير هو الطريقة التي يدخل بها التغيير إلى المشروع. يتحول المتطلب الجديد إلى طلب تغيير: يوصف كتابيا، ويُراجع مقابل وثيقة النطاق، ويُسعَّر بسعر ثابت خاص به، ويُقبل أو يُرفض قبل بدء أي عمل. فلا استنزاف بالساعة ولا بند مفاجئ في فاتورة الشهر القادم.
وثيقة النطاق هي ما يجعل الأمر عادلا في الاتجاهين. فإذا لم يعمل شيء سلمناه وفق ما هو محدد في النطاق، فهو عيب نصلحه على نفقتنا. وإذا لم يكن أصلا ضمن النطاق، فهو طلب تغيير له سعره الخاص. وفي كلتا الحالتين يُحسم الخلاف حول الحدود استنادا إلى وثيقة مكتوبة، لا إلى الذاكرة في اجتماع متابعة.
وتمتد الفلسفة نفسها إلى ما بعد الإطلاق. فالدعم يعمل وفق اتفاقيات SLA متدرجة — استجابة خلال 24 ساعة أو 4 ساعات أو ساعة واحدة حسب المستوى الذي تختاره — والنسخ الاحتياطية تُختبر بالاستعادة الفعلية لا بالافتراض، والترقيات تُختبر مقابل تخصيصاتك قبل أن تمس بيئة الإنتاج. التزامات محددة في كل مكان، لأن الانفتاح بلا حدود هو حيث تتآكل الثقة.
قول لا للعمل المفتوح يكلفنا بعض الصفقات، ونحن مرتاحون لذلك. فالمشاريع التي نتولاها تكتمل، وتستقر عند رقم اتفق عليه الطرفان، وتترك وراءها نظاما يمكن فعلا صيانته. وإذا كنت تدرس مشروع ERP وتريد أن ترى كيف يمكن لمرحلة تحديد النطاق أن تؤطر مشروعك، فإن صفحة خدمات التنفيذ لدينا تشرح العملية خطوة بخطوة.