كيف نعمل: من أهداف المشغّل إلى الإصدارات بعد الـ go-live

ما الذي تتضمنه كل مرحلة

المرحلة	العمل
الإصدارات التقنية (MVP)	إدارة المشروع؛ التحليل والتصميم؛ نشر البنية التحتية؛ البناء والتهيئة؛ التكامل؛ SIT (System Integration Testing)؛ تخطيط الـ cut-over والترحيل؛ نقل المعرفة
إصدار Go-Live	إدارة المشروع وإدارة التغيير؛ التحليل والتصميم؛ إعداد البنية التحتية و CI/CD؛ التكامل؛ UAT (User Acceptance Testing)؛ الـ cut-over؛ الترحيل؛ التدريب
بعد الـ go-live	إدارة التغيير؛ دعم على أربعة مستويات؛ دعم البنية التحتية و CI/CD؛ طلبات التغيير؛ اختبارات السلامة (sanity tests)؛ الرعاية المكثفة (hypercare)

قد تكون هناك عدة إصدارات تقنية، يمر كل منها عبر SIT؛ ويمر إصدار Go-Live عبر UAT لدى فريقكم. وبعد الـ go-live — بقدر ما تحتاجه الأعمال من إصدارات.

من يفعل ماذا

يدير المشروع فريقان: فريقكم — فريق المشغّل، أو الشريك الذي يورّد لكم الـ BSS — وفريقنا. ويُحدَّد تقسيم العمل منذ اليوم الأول ولا يتغير من مرحلة إلى أخرى.

فريقكم	MEF.DEV
يحدد الأهداف والنطاق	يدرس عمليات الأعمال الحالية وبيئة الـ legacy، ويقترح خطة تحول لأهداف أعمالكم
يحدد الوظائف	يطابقها مع متطلبات الأمن والتنظيم ومع المنصة
يصوغ المتطلبات	يلتزم بالجدول الزمني والمواعيد، ويشرح التكاليف
يبني منطق الأعمال والقنوات المتعددة المتكاملة (omnichannel) على low-code	الأنظمة الخلفية والخدمات وأمن عمليات تقنية المعلومات الخلفية
يتابع التقدم والاختناقات والتغييرات	توليد الشيفرة، والتسليم الموجَّه، واستضافة الـ plugins الخاصة بالتطبيقات في عنقود Kubernetes
ثم يتولى بنفسه تنسيق التغييرات والتطوير اللاحق	التدريب، والدعم التقني، ومعالجة المشكلات والطلبات الجديدة

يطوّر الفريقان معًا. ويشمل الطرح على المنصة إدارة التهيئة متعددة الـ tenant (multi-tenant)، وإدارة الإصدارات مع الترقيم والتراجع (rollback)، وإدارة حسابات المستخدمين.

المستويات الثلاثة للمشروع

• الإدارة. إدارة المشروع، والتنفيذ، والحوكمة، وإعداد التقارير — واحدة للبرنامج بأكمله.
• البرنامج. في مجموعة مشغّلين، تكون كل شركة تشغيل مشروعًا مستقلًا على القالب نفسه: الأولى تحدد الحل، والتالية تكرره.
• التسليم. نشر البنية التحتية، وعدة إصدارات تقنية، وإصدار Go-Live والإصدارات التي تليه.

مسارات التسليم والأدوار

المسارات التي يعمل فيها الفريقان: الإدارة، والتهيئة، والمتطلبات الوظيفية، والتكامل، والمتطلبات غير الوظيفية، و QA، وترحيل البيانات، والتدريب، و CI/CD ونشر البنية التحتية. ومن جانبنا: مدير مشروع، ومهندس BSS، ومحلل أعمال، وفريق الهندسة، ومهندس ترحيل بيانات، و BSS DevOps، و infra DevOps. ولكل طرف حوكمة معمارية: لديكم من طرف إلى طرف (end-to-end)، ولدينا لمعمارية التكامل.

كيف نخفّض مخاطر التحويل

• الاختبار الوظيفي لخدمات الـ legacy — إدارة العملاء والطلبات، والـ charging، والفوترة (invoicing)، والـ provisioning — في عمليات تشغيل تجريبية (dry-runs) قبل الـ cut-over ومرة أخرى بعد الـ go-live.
• عتبات الأداء لـ IT Ops — بدءًا من الـ cut-over.
• التكامل والاختبارات E2E وفق نموذج نضج.
• مقاييس SLA و KPI — خلال فترة الاستقرار بعد الـ cut-over وما بعدها.
• المشغّل هو من يقرر التحويل. يذهب كل إصدار إلى بيئة الإنتاج وفق قواعد Change Management لديكم، مع رقم إصدار وإمكانية تراجع.

كيف نعمل مع الـ legacy

• الهندسة العكسية (reverse engineering). نعيد إنتاج سلوك نظام الـ legacy ونوثّقه أولًا بدل افتراضه.
• التخطيط وفق المسار الحرج. يحدد الجدولَ الزمني تسلسلُ الاعتماديات بين الفرق والأنظمة.
• التصميم على نموذج مرجعي. تتبع المجالات والكيانات ممارسات TM Forum؛ وتُولَّد مخططات البيانات والخدمات والوثائق من النماذج.
• Agile والاختبار المؤتمت. حزم صغيرة خلف feature flags تتراكم لتشكّل وظائف أكبر.
• DevOps وفق عمليات ITIL. نشر ومراقبة مؤتمتان يستهدفان استخدام الخدمات والكيانات.

وتعمل المنصة أيضًا إلى جانب BSS من مورد آخر: تستدعيها التطبيقات والقنوات عبر TM Forum Open API، ويجري الوصول إلى طبقة الشبكة و OSS عبر الجزء الخاص بنا. ويجري التطوير والتسليم والدعم وفق نظام جودة ISO 9001.

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