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