الفصل 10 · الإطار الرئيسي للبرمجيات كخدمة ProjectVIEW ERP
ينظم الفصل 10 ما يحدث عندما يصل إصدار ProjectVIEW ERP إلى نهاية العمر: إشعار لا يقل عن 12 شهرًا، وخدمات ترحيل، واعتماد التكاملات والتخصيصات، وإعادة التدريب وإدارة التغيير. سواء انتقل العميل إلى الإصدار اللاحق أو أنهى الاشتراك، تُعاد البيانات خلال يومي عمل من الطلب الخطي (نسخة SQL احتياطية أو CSV أو JSON أو XML) ويُخلى النظام من الخدمة وفق عملية محددة — «لا يُترك أي عميل خلف الركب».
- 12 شهرًاالحد الأدنى لإشعار نهاية العمر
- يومي عملإرجاع البيانات بعد طلب خطي
- .bak · CSV · JSON · XMLتنسيقات التصدير
10.1 نظرة عامة والغرض
يضع هذا الفصل الإطار الشامل الذي يحكم دورة حياة نهاية العمر (EOL) لمنصة ProjectVIEW ERP، بما في ذلك الانتقالات بين الإصدارات الرئيسية، وخدمات الترحيل، والتزامات إعادة التدريب، واعتماد التكاملات والتخصيصات، وحقوق إرجاع البيانات، وإجراءات إنهاء الاشتراك. وهو يحل محل الأحكام التلخيصية الواردة في الفصل 4، الفقرة §4.7.4 ويكملها.
ويستند إطار نهاية العمر لدى مقدم الخدمة إلى ممارسات الانتقال بين الإصدارات الراسخة لدى أبرز مزودي البرمجيات كخدمة وأنظمة ERP المؤسسية، بما في ذلك SAP S/4HANA، وOracle Fusion Cloud، وIFS Cloud، وInfor CloudSuite، مع تكييفه مع نموذج النشر السيادي الخاص المخصص لدى مقدم الخدمة ومع حق العميل في ملكية كاملة للبيانات (الفصل 9، الفقرة §9.9).
المبدأ التصميمي الأساسي هو عدم ترك أي عميل خلف الركب: إذ يحصل كل عميل على إشعار كافٍ، ودعم ترحيل شامل، وإعادة تدريب، وخدمات إرجاع البيانات، سواء اختار الانتقال إلى الإصدار اللاحق أو إنهاء الاشتراك.
10.2 النطاق
يغطي هذا الفصل ما يلي:
- (a) مراحل دورة حياة الإصدار: الإتاحة العامة (GA)، والدعم السائد، والدعم الموسع، ونهاية الهندسة (EOE)، ونهاية العمر (EOL) لكل إصدار رئيسي من المنصة.
- (b) خدمات الترحيل: ترحيل البيانات بقيادة مقدم الخدمة، وتحويل المخططات، وتوفير البيئات، وتخطيط التحويل للعملاء الذين ينتقلون إلى إصدار لاحق.
- (c) إعادة التدريب وإدارة التغيير: برامج تدريب إلزامية، وإعادة اعتماد للـ Champions، وورش عمل لاعتماد المستخدمين، وتحديثات لقاعدة المعرفة اللازمة لنجاح الانتقال بين الإصدارات.
- (d) اعتماد التكاملات والتخصيصات: تقييم وإعادة هندسة والتحقق من التكاملات والتخصيصات والتكوينات الخاصة بالعميل على الإصدار اللاحق.
- (e) إرجاع البيانات للعملاء غير المترقّين: التزامات تصدير البيانات، ومواصفات التنسيق، والجداول الزمنية للتسليم، ووثائق سلسلة الحيازة للعملاء الذين يختارون عدم الانتقال.
- (f) إنهاء الاشتراك: الإجراءات الرسمية لإنهاء الخدمة، وإخراج البيئة من الخدمة، وإنهاء العقد.
- (g) الأدوار والمسؤوليات: توزيع RACI لجميع أنشطة نهاية العمر عبر منظمات مقدم الخدمة والعميل. لا يغطي هذا الفصل الإصدارات/التحديثات التدريجية داخل إصدار رئيسي واحد (انظر الفصل 4، الفقرة §4.7.1) أو ترقيات منصات COTS المنفذة أثناء الدعم السائد (انظر الفصل 4، الفقرة §4.7.3).
10.3 مراحل دورة حياة الإصدار
يمر كل إصدار رئيسي من المنصة (مثل v11 وv12) عبر دورة حياة محددة. ويستند نموذج دورة الحياة لدى مقدم الخدمة إلى أطر دعم الإصدارات المنشورة من SAP (Maintenance Strategy) وOracle (Sustaining Support) وIFS (Mainstream/Extended Maintenance) وInfor (Product Lifecycle Policy)، مع تكييفه مع نموذج التسليم البرمجيات كخدمة فقط:
| المرحلة | المدة | ما يتلقاه العميل | التزامات مقدم الخدمة |
|---|---|---|---|
| الإتاحة العامة (GA) | مستمر حتى الإتاحة العامة للإصدار اللاحق | وصول كامل إلى جميع ميزات المنصة والوحدات والواجهات البرمجية. تُسلَّم الإصدارات التدريجية (v11.01، v11.02...) عبر سباقات Agile (الفقرة §4.7.1). | تطوير نشط، وتحسينات وظيفية، وإصلاحات للأخطاء، وتصحيحات أمنية، والحفاظ على حداثة منتجات COTS. |
| إعلان نهاية العمر | T− 12 شهرًا | إشعار خطي رسمي بأن الإصدار الرئيسي الحالي سيصل إلى نهاية العمر. ويحدد الإشعار الإصدار اللاحق، والجدول الزمني الإرشادي للترحيل، وخدمات الانتقال المتاحة. | نشر إعلان نهاية العمر. بدء تقييم الجاهزية للإصدار اللاحق لكل عميل. |
| نافذة الانتقال | من T− 12 شهرًا إلى T− 30 يومًا | تخطيط الترحيل، وتنفيذ ترحيل البيانات، وإعادة التدريب، وإعادة هندسة التكاملات، واختبار القبول للمستخدمين على الإصدار اللاحق، والتشغيل المتوازي (عند اختياره). | تقديم خدمات الترحيل والتدريب واعتماد التكاملات كما هو محدد في 10.5 إلى 10.7. |
| نهاية الهندسة (EOE) | T− 30 يومًا | لن تُقبل أي طلبات تغيير جديدة. ويستمر الدعم الفني (حل الحوادث + التصحيحات الأمنية فقط). | الاستمرار في تسليم التصحيحات الأمنية وحل حوادث P1/P2 للإصدار القديم. |
| نهاية العمر (EOL) | T = 0 (بعد 12 شهرًا من الإعلان) | يتوقف جميع الدعم للإصدار القديم. يجب أن يكون العميل يعمل على الإصدار اللاحق أو يكون قد اختار إنهاء الاشتراك. | إخراج البيئة القديمة من الخدمة. تنفيذ إرجاع البيانات إذا اختار العميل الإنهاء (10.9). |
| الدعم الموسع (اختياري) | حتى 12 شهرًا بعد EOL | متاح بناءً على طلب خطي ومقابل رسوم إضافية. ويوفر حل حوادث P1/P2 والتصحيحات الأمنية الحرجة فقط. لا يوجد تطوير للميزات. | تقديم الدعم الموسع بموجب ملحق دعم موسع منفصل للعقد التجاري. |
التزام رئيسي: يضمن مقدم الخدمة حدًا أدنى قدره اثنا عشر (12) شهرًا بين إعلان نهاية العمر وتاريخ نهاية العمر. ولا يجوز إلزام أي عميل بالانتقال خلال أقل من 12 شهرًا من تاريخ الإشعار الخطي الرسمي. ويتماشى ذلك مع أفضل الممارسات الملحوظة عبر سياسات دورة الحياة لدى SAP وOracle وIFS وInfor.
10.4 إعلان نهاية العمر والتواصل مع العميل
يتعين على مقدم الخدمة إبلاغ كل عميل بدورة نهاية العمر عبر البرنامج المنظم التالي:
| التواصل | التوقيت | القناة | المحتوى |
|---|---|---|---|
| خطاب إعلان نهاية العمر | T− 12 شهرًا على الأقل | إشعار خطي إلى جهة الاتصال المعينة لدى العميل + البريد الإلكتروني لمدير الحساب | تاريخ نهاية العمر الرسمي، وتحديد الإصدار اللاحق، وملخص خدمات الترحيل، والجدول الزمني الإرشادي، والإجراء المطلوب من العميل. |
| تقييم جاهزية الترحيل | T− 11 شهرًا | ورشة عمل مشتركة (عن بُعد أو في الموقع) | تقييم الأثر على التكاملات والتخصيصات وحجوم البيانات الخاصة بالعميل. خطة الترحيل الأولية ومتطلبات الموارد. |
| تحديثات ربع سنوية عن حالة الانتقال | T− 9 وT− 6 وT− 3 أشهر | اجتماع مراجعة الخدمة + تقرير خطي | تقدم الترحيل، والإجراءات المعلقة، وسجل المخاطر، وجدول التدريب، وتاريخ التحويل المتوقع. |
| إشعار EOE | T− 30 يومًا | إشعار خطي + لافتة داخل التطبيق | تأكيد عدم قبول طلبات تغيير جديدة للإصدار القديم. إشعار بخفض نطاق الدعم. |
| تأكيد الترحيل النهائي | T− 14 يومًا | إشعار خطي | تأكيد اكتمال الترحيل (أو اختيار العميل للإنهاء + إرجاع البيانات). لوجستيات التحويل النهائية. |
| تأكيد نهاية العمر | T = 0 | إشعار خطي | تم إخراج الإصدار القديم من الخدمة. أصبح الإصدار اللاحق هو الإصدار الوحيد المدعوم. وتم تأكيد توفر الدعم الموسع (إن انطبق). |
10.5 خدمات الترحيل
يتعين على مقدم الخدمة تقديم برنامج ترحيل منظم لكل عميل ينتقل إلى الإصدار اللاحق. وتُعد خدمات الترحيل مشمولة في الاشتراك دون تكلفة إضافية للنطاق القياسي للترحيل المحدد أدناه. وتتوفر خدمات ترحيل محسنة (مثل إدخال بيانات من النظام القديم، وتحويلات ETL المعقدة، والتشغيل المتوازي لما بعد الفترة القياسية) ضمن مهام منفصلة محددة النطاق.
10.5.1 نطاق الترحيل القياسي
- (a) توفير بيئة التشغيل: يتعين على المورّد توفير بيئة للإصدار اللاحق داخل مستأجر Azure السيادي الخاص والمخصص للعميل، ومهيأة بنفس ضوابط الأمان والشبكات وإعدادات الامتثال المعمول بها في بيئة الإنتاج الحالية.
- (b) ترحيل البيانات: ترحيل كامل لجميع بيانات العميل من قاعدة بيانات الإصدار القديم إلى قاعدة بيانات الإصدار اللاحق، بما في ذلك البيانات الرئيسية والبيانات المعاملاتية وبيانات التهيئة ومسارات التدقيق. ويجب على المورّد استخدام نصوص آلية لتحويل البنية تتم مواءمتها والتحقق منها وفق ملف بيانات العميل.
- (c) استشارات تنقية البيانات: بما يتوافق مع أفضل ممارسات Oracle Fusion وInfor CloudSuite، يتعين على المورّد أن ينصح العميل بفرص تنقية البيانات قبل الترحيل. والنهج الموصى به هو ترحيل ما لا يزيد على ثلاث (3) سنوات من البيانات المعاملاتية النشطة، مع أرشفة البيانات التاريخية بصيغة للقراءة فقط يمكن الوصول إليها لأغراض التقارير والامتثال.
- (d) ترحيل الإعدادات: تُرحَّل جميع الإعدادات الخاصة بالعميل (الأدوار، وسير العمل، وسلاسل الاعتماد، وقواعد الإشعارات، وقوالب التقارير، ولوحات المعلومات) إلى الإصدار اللاحق باستخدام أدوات التصدير والاستيراد الخاصة بالإعدادات لدى المورّد.
- (e) اختبار الترحيل: يجب تنفيذ ما لا يقل عن محاولتين (2) كاملتين لمحاكاة الترحيل في بيئة الاختبار المرحلي قبل الانتقال إلى الإنتاج. وتشمل كل محاكاة التحقق من سلامة البيانات (المرجعية، والحسابية، والزمانية)، واختبارًا مبدئيًا على مستوى طبقة التطبيق، وقياس الأداء المعياري.
- (f) تنفيذ الانتقال: الانتقال إلى الإنتاج إلى الإصدار اللاحق خلال نافذة صيانة متفق عليها مسبقًا، بما في ذلك انتقال DNS/الشبكة، والتبديل بين قواعد البيانات، والتحقق بعد الانتقال، والاستعداد للرجوع.
- (g) فترة الدعم المكثف: ما لا يقل عن ثلاثين (30) يومًا تقويميًا من دعم مخصص بعد الترحيل، يعيّن خلالها المورّد قائدًا للترحيل وموارد دعم مخصصة لمعالجة الحوادث ذات الأولوية وتحقيق الاستقرار.
10.5.2 ضمان سلامة ترحيل البيانات
يتعين على المورّد تطبيق ضوابط سلامة البيانات التالية طوال عملية الترحيل، بما يتماشى مع إطار الاختبار المعزَّز بالذكاء الاصطناعي المحدد في الفصل 5 (جودة البرمجيات والاختبار):
- (a) خط الأساس قبل الترحيل: تُلتقط قيمة تجزئة تشفيرية (SHA-256) لقاعدة البيانات الكاملة وجرد عدد الصفوف مباشرةً قبل بدء الترحيل، بما يؤسس خط أساس سلامة البيانات.
- (b) المطابقة بعد الترحيل: تُنفَّذ مطابقة عدد الصفوف، وعمليات التحقق من سلامة العلاقات المرجعية، وفحوصات سلامة الحسابات على قاعدة بيانات الإصدار اللاحق. وتُقارن قيمة التجزئة بعد الترحيل بخط الأساس قبل الترحيل.
- (c) التحقق بواسطة وكلاء الذكاء الاصطناعي (اختياري): عندما يكون العميل قد اختار خدمة الاختبار المعزَّز بالذكاء الاصطناعي (الفصل 5)، يتعين على المورّد نشر وكلاء ذكاء اصطناعي على بيئة الإصدار اللاحق لتنفيذ سيناريوهات محاكاة شاملة، مع التحقق من تدفقات البيانات وقواعد الأعمال ونقاط التكامل.
- (d) اعتماد الترحيل: يتعين على العميل إجراء اختبار قبول المستخدم UAT على بيئة الإصدار اللاحق. ويُشترط اعتماد كتابي من العميل قبل الانتقال إلى الإنتاج، بما يتوافق مع متطلبات UAT المحددة في الفصل 5، §5.8.
10.6 اعتماد التكاملات والتخصيصات
قد تؤثر عمليات الانتقال بين الإصدارات الرئيسية في التكاملات والتخصيصات والإضافات التابعة لجهات خارجية الخاصة بالعميل. ويتعين على المورّد إدارة هذا الانتقال من خلال برنامج اعتماد منظم:
10.6.1 تقييم أثر التكاملات
خلال ثلاثين (30) يومًا تقويميًا من إعلان نهاية العمر التشغيلي EOL، يتعين على المورّد تسليم العميل تقييمًا لأثر التكاملات يشمل:
- (a) تحليل توافق واجهات API: مواءمة جميع واجهات API المواجهة للعميل المستخدمة في الإصدار القديم مع نظيراتها في الإصدار اللاحق، مع تحديد التغييرات الكاسرة، والنقاط النهائية المتقادمة، والقدرات الجديدة.
- (b) جرد تكاملات الأطراف الخارجية: فهرس بجميع التكاملات النشطة (البرمجيات الوسيطة، وموصلات B2G، وواجهات الشحن، وواجهات البنوك، وأدوات التقارير التابعة لجهات خارجية) مع بيان حالة التوافق مع الإصدار اللاحق.
- (c) سجل التخصيصات: جرد كامل لتخصيصات العميل (مكتبات DLL المترجمة، ودوال SQL المخصصة، والتقارير المصممة خصيصًا، وامتدادات سير العمل) مع تصنيف مسار الترحيل: (i) متوافق مع الإصدارات اللاحقة، (ii) يتطلب إعادة هندسة، (iii) متقادم / تتوفر بدائل.
- (d) تقدير الجهد والجدول الزمني: جهد تقديري (أيام-شخص) وجدول زمني لإعادة هندسة التكاملات والتخصيصات غير المتوافقة، مع التمييز بين النطاق القياسي (المشمولة) والنطاق المعزَّز (يُسعّر بصورة منفصلة).
10.6.2 إعادة الهندسة والتحقق
بالنسبة إلى التكاملات والتخصيصات المصنفة على أنها «تتطلب إعادة هندسة»:
- (a) إعادة هندسة يديرها المورّد: عندما يكون التخصيص قد بُني أصلاً بواسطة المورّد (ومسجلاً في مستودع Git ضمن فرع العميل الخاص بالعميل)، يتعين على المورّد إعادة هندسة المكوّن واختباره دون أي تكلفة إضافية كجزء من نطاق الترحيل القياسي.
- (b) تكاملات يديرها العميل أو جهة خارجية: عندما يكون التكامل قد بُني بواسطة العميل أو طرف ثالث، يتعين على المورّد أن (i) يوفر وثائق فنية لسطح API في الإصدار اللاحق، و(ii) يتيح بيئة الاختبار المرحلي لأغراض الاختبار، و(iii) يقدم مساعدة اختيارية في الخدمات الاحترافية على أساس الوقت والمواد.
- (c) اختبار الانحدار للتكاملات: تخضع جميع التكاملات المرحَّلة لاختبار انحدار آلي في بيئة الاختبار المرحلي قبل الانتقال إلى الإنتاج، باستخدام إطار عمل وكلاء الذكاء الاصطناعي (الفصل 5) أو نصوص اختبار يدوية حسبما يتم الاتفاق عليه.
10.7 إعادة التدريب وإدارة التغيير
يمثل الانتقال بين الإصدارات الرئيسية تغييرًا جوهريًا في المنصة ويستدعي التزامات إلزامية بإعادة التدريب بموجب الفصل 6 (التدريب ونقل المعرفة). ويتعين على المورّد تقديم برنامج تدريب انتقالي مخصص يشمل:
10.7.1 إعادة تقييم الاحتياجات التدريبية
خلال ستين (60) يومًا تقويميًا من إعلان نهاية العمر التشغيلي EOL، يتعين على المورّد إجراء إعادة تقييم للاحتياجات التدريبية (TNRA) لتحديد:
- (a) عناصر واجهة المستخدم وسير العمل وأنماط التنقل الجديدة أو المتغيرة في الإصدار اللاحق.
- (b) الميزات المتقادمة وبدائلها.
- (c) القدرات الجديدة التي أتاحها الإصدار اللاحق (بما في ذلك الميزات المدعومة بالذكاء الاصطناعي حيثما ينطبق ذلك).
- (d) متطلبات التدريب الخاصة بكل دور بناءً على التهيئة النشطة للوحدات والبنية التنظيمية لدى العميل. ومخرج TNRA هو خطة التدريب الانتقالي، الملحقة بخطة الترحيل، والتي تحدد الجلسات والمدد وطرائق التنفيذ والجمهور المستهدف.
10.7.2 برنامج التدريب الانتقالي
| مكوّن التدريب | الجمهور | النسيق | التوقيت | المدة |
|---|---|---|---|---|
| إحاطة بما هو جديد | جميع المستخدمين المفوضين | ندوة عبر الويب (مسجلة + مُفرَّغة بالذكاء الاصطناعي) | قبل T−6 أشهر | 90 دقيقة |
| ورشة عمل تطبيقية: التغييرات الأساسية | المستخدمون المتقدمون + المدافعون | بقيادة مدرّب (عن بُعد أو في الموقع) | من T−5 إلى T−4 أشهر | 2–3 أيام لكل مجموعة وحدات |
| إعادة اعتماد المدافعين | مدافعو DANAOS ProjectVIEW ERP | بقيادة مدرّب + اختبار | من T−4 إلى T−3 أشهر | يوم واحد لكل مدافع |
| ورشة عمل التكامل وواجهة API | فريق تقنية المعلومات / التكامل لدى العميل | ورشة عمل تقنية (عن بُعد) | T−4 أشهر | يوم واحد |
| جلسة إرشادات UAT | مشاركو UAT | إحاطة بقيادة مدرب | T−2 أشهر | نصف يوم |
| فحص الجاهزية للتشغيل | المدافعون + قائد تقنية المعلومات لدى العميل | اجتماع نقطة مراجعة | T−14 يومًا | ساعتان |
| عيادات أسئلة وأجوبة بعد الترحيل | جميع المستخدمين المفوضين | أسئلة وأجوبة عبر الإنترنت (كل أسبوعين) | من T + 0 إلى T + 90 يومًا | ساعة واحدة لكل جلسة |
يجب تسجيل جميع جلسات التدريب الانتقالي وتفريغها بالذكاء الاصطناعي وفقًا لـ الفصل 6، §6.4.4. وتُنشر التسجيلات والنصوص المفرغة على ويكي التدريب الخاص بكل عميل لدى العميل (https://docs.projectview.wiki/[client]) خلال خمسة (5) أيام عمل من كل جلسة.
10.7.3 تحديثات قاعدة المعرفة
يتعين على المورّد تحديث موارد المعرفة التالية قبل الانتقال إلى الإنتاج على الإصدار اللاحق:
- (a) ويكي التدريب الخاص بكل عميل: تحديث جميع الصفحات الخاصة بكل وحدة، وأدلة العمليات، ومقالات الأسئلة الشائعة لتعكس واجهة المستخدم وسير العمل والمصطلحات في الإصدار اللاحق.
- (b) مركز إصدارات المنصة: نشر ملاحظات الإصدار وأدلة النشر ومراجع التهيئة الخاصة بالإصدار اللاحق.
- (c) الإرشاد داخل التطبيق: تحديث التلميحات السياقية وروابط المساعدة والمطالبات المساندة بالذكاء الاصطناعي للإشارة إلى وظائف الإصدار اللاحق.
10.8 قرار العميل: الانتقال أو الإنهاء
في موعد لا يتجاوز ستة (6) أشهر قبل تاريخ نهاية العمر التشغيلي EOL (أي T−6 أشهر)، يتعين على العميل إخطار المورّد رسميًا بخياره إما:
- (a) الخيار A — الانتقال: المضي في الترحيل إلى الإصدار اللاحق. ويقوم المورّد بتقديم خدمات الترحيل (10.5)، واعتماد التكاملات (10.6)، وإعادة التدريب (10.7). وتستمر الاشتراكية دون انقطاع على الإصدار اللاحق وفق الشروط التجارية القائمة (ما لم يتم تعديلها باتفاق خطي متبادل).
- (b) الخيار B — إيقاف الاشتراكية: اختيار عدم الانتقال. ويبدأ المورّد عملية إيقاف الاشتراكية (10.9)، بما في ذلك إعادة البيانات (10.10)، وإخراج البيئة من الخدمة (10.11)، وإنهاء العقد (10.12). وتنتهي الاشتراكية في تاريخ نهاية العمر التشغيلي EOL (أو تاريخ انتهاء الدعم الموسع، إذا تم اختياره). وإذا لم يقدم العميل إشعارًا كتابيًا بحلول الموعد النهائي T−6، يرسل المورّد إشعار تذكير. وإذا لم يرد أي رد خلال ثلاثين (30) يومًا تقويميًا إضافية، يُعدّ المورّد أن العميل قد اختار الخيار A (الانتقال)، وتستمر خدمات الترحيل.
10.9 عملية إيقاف الاشتراكية
عندما يختار العميل الخيار B (إيقاف الاشتراكية)، تنطبق العملية التالية:
| المرحلة | التوقيت | النشاط | المالك |
|---|---|---|---|
| 1. إشعار الإيقاف | T−6 أشهر (اختيار العميل) | يقدم العميل إشعارًا كتابيًا بنيته عدم الانتقال. ويؤكد المورّد الاستلام خلال يومي عمل. | العميل → مدير الحساب |
| 2. تخطيط الإيقاف | من T−6 إلى T−5 أشهر | يتفق المورّد والعميل على خطة للإيقاف تغطي: صيغة/صيغ تصدير البيانات، والجدول الزمني، وتسليم جهات الاتصال، وحل التذاكر المفتوحة، وجدول تقليص البيئة. | مدير الحساب + قائد العمليات السحابية |
| 3. تصدير البيانات وإعادتها | من T−5 إلى T−2 أشهر | يقوم المورّد بتصدير جميع بيانات العميل بالصيغ المتفق عليها خلال يومي عمل من كل طلب صالح (10.10). ويُسمح بعدة طلبات تصدير. | DBA + عمليات السحابة |
| 4. تحقق العميل | من T−2 إلى T−1 شهر | يتحقق العميل من اكتمال البيانات المصدَّرة وسلامتها. ويُثير أي اعتراضات على اكتمال البيانات (إن وجدت) خلال 14 يومًا تقويميًا من الاستلام. | Customer IT Lead |
| 5. تسوية التذاكر المفتوحة | من T−3 إلى T−30 يومًا | يقوم المورّد بحل جميع الحوادث المفتوحة ذات الأولوية P1/P2. وتُغلق التذاكر الأقل أولوية بموافقة العميل أو يُوثق أنها غير محلولة. | العمليات السحابية + مدير الحساب |
| 6. إخراج البيئة من الخدمة | T = تاريخ نهاية العمر التشغيلي EOL | يُخرج بيئة الإصدار القديم من الخدمة: إيقاف الأجهزة الافتراضية، وحذف قواعد البيانات، ومحو حسابات التخزين، وتدمير مفاتيح التشفير (10.11). | عمليات السحابة + DBA |
| 7. شهادة الإخراج من الخدمة | T + 14 يومًا | يصدر المورّد شهادة إخراج من الخدمة تؤكد أن جميع بيانات العميل قد أُتلفت بأمان وفقًا لـ NIST SP 800-88. | المدير التقني ← العميل |
| 8. الإنهاء التعاقدي | T + 30 يومًا | تنتهي الاتفاقية رسميًا. وتظل البنود الباقية السارية (السرية، والملكية الفكرية، وتحديد المسؤولية، والالتزامات المتبقية في حماية البيانات) مستمرة وفقًا لـ 10.12. | الشؤون القانونية / مدير الحساب |
10.10 إعادة البيانات
يحتفظ العميل في جميع الأوقات بالملكية الحصرية والانفرادية لجميع بيانات العميل (الفصل 9، §9.9). وعند إيقاف الاشتراكية، تكون التزامات المورّد الخاصة بإعادة البيانات كما يلي:
10.10.1 صيغ التصدير والتسليم
- (a) صيغ التصدير القياسية: ملف النسخ الاحتياطي لـ SQL Server (.bak)، وCSV، وJSON، و/أو XML. ويجوز للعميل طلب أي مجموعة من الصيغ.
- (b) الجدول الزمني للتسليم: خلال يومي عمل (2) من استلام طلب كتابي صالح من العميل.
- (c) طريقة التسليم: نقل آمن مشفَّر عبر نقطة SFTP التي يحددها العميل، أو SAS token الخاص بـ Azure Blob Storage، أو وسائط مادية مشفَّرة (تُسلَّم عبر شركة شحن مع وثائق سلسلة الحيازة).
- (d) نطاق التصدير: جميع بيانات العميل بما في ذلك: البيانات الرئيسية، والبيانات المعاملاتية، وبيانات التهيئة، ومسارات التدقيق، وسجلات تتبع التغيير، ومرفقات المستندات (تخزين الكتل)، والتقارير التي يولدها التطبيق.
- (e) عمليات التصدير المتعددة: يجوز للعميل طلب عمليات تصدير متعددة خلال فترة الإيقاف. ويجب تنفيذ كل طلب خلال يومي عمل.
10.10.2 التحقق من إعادة البيانات
بعد كل عملية تصدير بيانات:
- (a) بصمة سلامة البيانات: يجب على المزوّد تسليم بصمة تشفيرية SHA-256 لكل مجموعة بيانات مُصدَّرة، بما يتيح للعميل التحقق من سلامة البيانات عند الاستلام.
- (b) شهادة عدد السجلات: يجب على المزوّد تسليم شهادة بعدد السجلات تتضمن عدد السجلات لكل جدول/كيان في التصدير، مع الإحالة المرجعية إلى قاعدة بيانات الإنتاج عند نقطة زمنية التصدير.
- (c) فترة التحقق: يحق للعميل خلال أربعة عشر (14) يومًا تقويميًا من تاريخ الاستلام إثارة اعتراض يتعلق باكتمال البيانات أو سلامتها. يجب على المزوّد معالجة الاعتراض الصحيح وإعادة التصدير خلال يومي عمل (2) من أي اعتراض صحيح.
- (d) القبول الضمني: إذا لم يثر العميل أي اعتراض خلال فترة التحقق البالغة 14 يومًا، فيُعدّ التصدير مقبولًا.
10.10.3 تكلفة إعادة البيانات
إعادة البيانات ضمن النطاق القياسي (التصدير بالصيغات القياسية عبر نقل رقمي آمن) مشمولة في الاشتراك دون أي تكلفة إضافية. وتتوفر الخدمات التالية بتكلفة إضافية على أساس الوقت والمواد:
- (a) تحويل البيانات المصدَّرة إلى صيغ غير قياسية (على سبيل المثال، تحويلات مخطط خاصة بالنظام المستهدف لأغراض الإدخال إلى ERP لاحق).
- (b) تجهيز الوسائط المادية والتسليم عبر شركة شحن.
- (c) نافذة تصدير بيانات ممتدة تتجاوز جدول الإنهاء القياسي.
- (د) استشارة فنية بشأن مواءمة البيانات، أو برمجة الترحيل، أو تصميم ETL للنظام الخلفي للعميل.
10.11 إنهاء البيئة
عند استكمال إعادة البيانات وانتهاء نافذة التحقق الخاصة بالعميل، يتعين على المورّد إخراج البيئة السيادية الخاصة والمخصصة للعميل من الخدمة:
- (a) إيقاف الآلات الافتراضية: تُوقَف جميع الآلات الافتراضية الخاصة بالعميل (الإنتاج والتهيئة)، وتُحذف صور الأقراص، وتُفرَّغ موارد الحوسبة.
- (b) إتلاف قواعد البيانات: تُحذف نهائيًا جميع قواعد بيانات SQL Server (الإنتاج، التهيئة، النسخ الاحتياطية). وتُمحى سجلات المعاملات وملفات النسخ الاحتياطي في Azure Backup Vault.
- (c) إفراغ حسابات التخزين: تُحذف نهائيًا جميع حاويات Azure Blob Storage ومشاركات الملفات وتخزين الجداول المرتبطة بالعميل، بما في ذلك النسخ المتماثلة عبر GRS في المنطقة الثانوية.
- (d) إتلاف مفاتيح التشفير: تُمحى جميع مفاتيح التشفير والأسرار والشهادات الخاصة بالعميل في Azure Key Vault (بتفويض تجاوز الحماية من الحذف نهائيًا من CTO).
- (e) تنظيف الشبكة: تُزال من الخدمة الشبكات الافتراضية ومجموعات أمان الشبكة NSGs وعناوين IP العامة وسجلات DNS وشهادات SSL/TLS المرتبطة بالعميل.
- (f) تحديث CMDB: تُعلَّم جميع عناصر التكوين المرتبطة بالعميل على أنها مُنهَاة الخدمة في CMDB الخاص بالمزوّد.
- (g) الإتلاف الآمن للبيانات: يُنفَّذ إتلاف جميع البيانات وفقًا للمعيار NIST SP 800-88 (إرشادات تعقيم الوسائط). ويضمن المسح التشفيري من Azure أن البيانات على التخزين المُنهى خدمته غير قابلة للاسترجاع.
NIST SP 800-88 Rev. 1: إرشادات إتلاف وسائط التخزين إتلاف البيانات في Azure
10.12 الالتزامات المستمرة
تظل الالتزامات التالية سارية بعد إنهاء أو انتهاء الإطار وتستمر بكامل قوتها وأثرها:
- (a) السرية: تستمر التزامات السرية المتبادلة لمدة خمس (5) سنوات من تاريخ الإنهاء (Chapter 8, §8.11).
- (b) الملكية الفكرية: تستمر جميع حقوق الملكية الفكرية وقيود الترخيص إلى أجل غير مسمى.
- (c) الالتزامات المتبقية المتعلقة بحماية البيانات: تستمر التزامات الخصوصية بموجب Chapter 7 فيما يتعلق بأي بيانات شخصية يحتفظ بها المزوّد بموجب التزام قانوني أو تنظيمي (Chapter 7, §7.13).
- (d) تحديد المسؤولية: تظل حدود المسؤولية والاستثناءات سارية على المطالبات الناشئة عن أحداث وقعت خلال مدة الاشتراك.
- (e) تسوية النزاعات: تظل أحكام القانون الحاكم وتسوية النزاعات سارية على أي مطالبة تنشأ عن الإطار أو تتصل به.
- (f) حقوق التدقيق: يظل حق العميل في تدقيق الامتثال لإتلاف البيانات قائمًا لمدة اثني عشر (12) شهرًا بعد تاريخ شهادة إنهاء الخدمة.
10.13 خيار الدعم الممتد
بما يتوافق مع نماذج الدعم الموسع التي تقدمها SAP (Extended Maintenance) وOracle (Sustaining Support) وIFS (Extended Maintenance) وInfor (Extended Maintenance)، يقدم المورّد فترة دعم موسع اختيارية للعملاء الذين يحتاجون إلى وقت إضافي لإكمال انتقالهم:
(a) التوافر: يجب طلب الدعم الممتد كتابيًا في موعد لا يتجاوز ستين (60) يومًا تقويميًا قبل تاريخ نهاية العمر التشغيلي. (b) المدة: حتى اثني عشر (12) شهرًا بعد تاريخ نهاية العمر التشغيلي، على دفعات ربع سنوية. (c) النطاق: يقتصر على حل حوادث P1 وP2 والتصحيحات الأمنية الحرجة فقط. لا يشمل تطوير الميزات، ولا طلبات التغيير الجديدة، ولا تفعيل الوحدات الجديدة. (d) التسعير: يُحتسب الدعم الممتد بعلاوة قدرها عشرون في المائة (20%) فوق معدل الإيراد السنوي المتكرر ARR الساري آنذاك، ويدفع ربع سنويًا مقدمًا. (e) الإنهاء: ينتهي الدعم الممتد تلقائيًا عند نهاية الفترة المختارة. وتنطبق جميع أحكام إيقاف الاشتراك (§10.9–§10.12) عند انتهاء الدعم الممتد.
10.14 الأدوار والمسؤوليات (مصفوفة RACI)
توزع مصفوفة RACI التالية المسؤوليات عن أنشطة نهاية العمر التشغيلي الرئيسية بين أدوار المورّد والعميل:
| النشاط | CTO | قائد عمليات السحابة | Account Mgr | DBA Lead | Customer IT Lead | مدافعو العميل |
|---|---|---|---|---|---|---|
| إصدار إعلان نهاية العمر التشغيلي | A | I | R | I | I | I |
| تقييم جاهزية الترحيل | A | R | C | R | C | I |
| تقييم أثر التكاملات | I | R | C | C | R | I |
| تنفيذ ترحيل البيانات | I | R | I | R | C | I |
| التحقق من سلامة ترحيل البيانات | I | R | I | R | C | I |
| تقديم برنامج التدريب الانتقالي | I | C | R | I | C | R |
| إعادة اعتماد المدافعين | I | I | R | I | C | R |
| تحديثات قاعدة المعرفة | I | R | C | I | I | C |
| إعادة هندسة التكاملات | I | R | I | C | R | I |
| UAT على الإصدار اللاحق | I | C | C | C | R | R |
| تخطيط وإجراء الانتقال | A | R | C | R | C | I |
| قرار العميل (الانتقال / الإيقاف) | I | I | C | I | R | I |
| تنفيذ تصدير البيانات | I | R | C | R | R | I |
| التحقق من إعادة البيانات | I | I | I | I | R | I |
| إخراج البيئة من الخدمة | A | R | I | R | I | I |
| إصدار شهادة الإخراج من الخدمة | R | C | I | C | I | I |
| إدارة الدعم الموسع | A | R | C | R | I | I |
الرمز: R = مسؤول · A = محاسب · C = مستشار · I = مُبلَّغ.
10.15 سجل العمليات
يسرد سجل العمليات التالي جميع العمليات الرسمية المحددة في هذا الفصل.
| معرف العملية | اسم العملية | المحفز | المعالج | المعتمد | النتيجة | مرجع القسم |
|---|---|---|---|---|---|---|
| P-10.01 | إعلان نهاية العمر | قرار خريطة الطريق للمنتج بإنهاء الإصدار الرئيسي | مدير الحساب | CTO | إعلان EOL مكتوب مُرسل إلى جميع العملاء المتأثرين قبل موعد EOL Date بما لا يقل عن 12 شهرًا. | §10.4 |
| P-10.02 | تقييم جاهزية الترحيل | إصدار إعلان EOL (T−11 شهرًا) | عمليات السحابة + DBA | CTO | تسليم تقييم الأثر الخاص بالعميل وخطة الترحيل الأولية. | §10.4 |
| P-10.03 | تقييم أثر التكاملات | إصدار إعلان EOL (خلال 30 يومًا) | قائد عمليات السحابة | CTO | تسليم تحليل توافق واجهات API، وجرد التكاملات، وسجل التخصيصات، وتقدير الجهد. | §10.6.1 |
| P-10.04 | إعادة تقييم الاحتياجات التدريبية | إصدار إعلان EOL (خلال 60 يومًا) | مدير الحساب | CTO | إرفاق خطة التدريب الانتقالي بخطة الترحيل. | §10.7.1 |
| P-10.05 | تنفيذ ترحيل البيانات | الموافقة على خطة الترحيل وتوفير بيئة الاختبار المرحلي | DBA + عمليات السحابة | قائد عمليات السحابة | ترحيل بيانات العميل؛ التحقق من السلامة؛ استكمال المحاكاة/المحاكاةات. | §10.5.1 |
| P-10.06 | التحقق من سلامة الترحيل | استكمال محاكاة ترحيل البيانات أو الانتقال إلى الإنتاج | DBA + عمليات السحابة | قائد عمليات السحابة | نجاح مقارنة التجزئة قبل/بعد؛ اكتمال مطابقة عدد الصفوف؛ إصدار تقرير السلامة. | §10.5.2 |
| P-10.07 | إعادة هندسة التكاملات | التكامل مصنّف على أنه «يتطلب إعادة هندسة» في تقييم الأثر | عمليات السحابة | قائد عمليات السحابة | تم تحديث التكامل واختباره والتحقق من صحته على الإصدار اللاحق. | §10.6.2 |
| P-10.08 | تسليم تدريب الانتقال | تمت الموافقة على خطة تدريب الانتقال | مدير الحسابات + المدربون | قائد عمليات السحابة | تم تقديم جميع جلسات التدريب المجدولة؛ ونُشرت التسجيلات على Wiki. | §10.7.2 |
| P-10.09 | إعادة اعتماد المدافعين | تمت جدولة برنامج تدريب الانتقال | مدير الحساب | CTO | اجتاز الأبطال اختبار الإصدار اللاحق؛ وتم إصدار الشهادات. | §10.7.2 |
| P-10.10 | اختبار القبول من المستخدم على الإصدار اللاحق | تم اجتياز تجربة الترحيل؛ واكتمل التدريب | قائد تقنية المعلومات لدى العميل + الأبطال | العميل | تم الحصول على موافقة خطية من العميل على الإصدار اللاحق. | §10.5.2 |
| P-10.11 | التحويل إلى بيئة الإنتاج | تم استلام موافقة اختبار القبول من المستخدم؛ وتم الاتفاق على نافذة التحويل | عمليات السحابة + DBA | CTO | بيئة الإنتاج تعمل بالإصدار اللاحق؛ مع توفر خطة رجوع لمدة 72 ساعة. | §10.5.1 |
| P-10.12 | دعم ما بعد الإطلاق | اكتمل التحويل إلى بيئة الإنتاج | عمليات السحابة + DBA | مدير الحساب | تم تنفيذ فترة دعم ما بعد الإطلاق لمدة 30 يومًا؛ وتم تأكيد الاستقرار. | §10.5.1 |
| P-10.13 | خيار الإنهاء من جانب العميل | إشعار خطي من العميل بعدم الرغبة في الانتقال | مدير الحساب | CTO | تم الاتفاق على خطة الإنهاء؛ وتم تأكيد جدول تصدير البيانات. | §10.8 |
| P-10.14 | تصدير البيانات وإعادتها | طلب خطي صالح من العميل خلال فترة الإنهاء | DBA + عمليات السحابة | مدير الحساب | تم تصدير بيانات العميل بالصغة المتفق عليها خلال يومي عمل. | §10.10 |
| P-10.15 | التحقق من إعادة البيانات | تم تسليم تصدير البيانات إلى العميل | Customer IT Lead | العميل | يؤكد العميل الاكتمال خلال نافذة التحقق البالغة 14 يومًا (أو يُعد مقبولًا حكماً). | §10.10.2 |
| P-10.16 | إخراج البيئة من الخدمة | انتهت نافذة التحقق من إعادة البيانات؛ وتم بلوغ تاريخ نهاية العمر التشغيلي. | عمليات السحابة + DBA | CTO | تم إتلاف جميع موارد العميل وفقًا لـ NIST SP 800-88؛ وتم تحديث CMDB. | §10.11 |
| P-10.17 | شهادة الإخراج من الخدمة | اكتمل إخراج البيئة من الخدمة | CTO | CTO | تم إصدار شهادة الإخراج من الخدمة للعميل خلال 14 يومًا. | §10.11 |
| P-10.18 | تفعيل الدعم الممتد | طلب خطي من العميل قبل ≥60 يومًا من تاريخ نهاية العمر التشغيلي | قائد عمليات السحابة | CTO | تم تنفيذ الملحق الخاص بالدعم الممتد؛ واستمر دعم P1/P2 للفترة المختارة. | §10.13 |
10.16 مخطط سير العملية
يوضح مسار دورة الحياة المكوّن من تسع مراحل التدفق الشامل لانتقال الإصدار وإنهاء الاشتراك:
① إعلان نهاية العمر التشغيلي والتواصل → ② الجاهزية وتقييم الأثر → ③ قرار العميل
(الانتقال / الإنهاء)
↓
مسار الانتقال: ④ الترحيل وإعادة الهندسة → ⑤ إعادة التدريب وإدارة التغيير → ⑥
اختبار القبول من المستخدم والتحويل إلى بيئة الإنتاج
↓
مسار الإنهاء: ⑦ تصدير البيانات وإعادتها → ⑧ إخراج البيئة من الخدمة → ⑨ الإنهاء
التعاقدي
المرحلة ① إعلان نهاية العمر التشغيلي والتواصل: يصدر المزوّد إعلان نهاية العمر التشغيلي الرسمي قبل ≥12 شهرًا من تاريخ نهاية العمر التشغيلي، ليبدأ برنامج التواصل المنظم (§10.4). يتلقى جميع العملاء إشعارًا خطيًا، ويقوم مدير الحسابات بجدولة تقييم جاهزية الانتقال (P-10.01).
المرحلة ② الجاهزية وتقييم الأثر: يقدم المزوّد تقييم جاهزية الانتقال، وتقييم أثر التكامل، وإعادة تقييم الاحتياجات التدريبية خلال 60 يومًا من إعلان نهاية العمر التشغيلي (P-10.02, P-10.03, P-10.04).
المرحلة ③ قرار العميل: عند T−6 أشهر، يختار العميل رسميًا الانتقال (الخيار أ) أو الإنهاء (الخيار ب). والافتراضي هو الانتقال إذا لم يرد خلال 30 يومًا من التذكير (P-10.13).
المرحلة ④ الترحيل وإعادة الهندسة (مسار الانتقال): تُنفذ ترحيل البيانات، وترحيل الإعدادات، وإعادة هندسة التكامل في بيئة التجهيز مع ≥2 محاكاة (P-10.05, P-10.06, P-10.07).
المرحلة ⑤ إعادة التدريب وإدارة التغيير (مسار الانتقال): يتم تقديم برنامج تدريب الانتقال: عروض ما الجديد، وورش عمل تطبيقية، وإعادة اعتماد الأبطال، وتحديثات قاعدة المعرفة (P-10.08, P-10.09).
المرحلة ⑥ اختبار القبول من المستخدم والتحويل إلى بيئة الإنتاج (مسار الانتقال): يجري العميل اختبار القبول من المستخدم على الإصدار اللاحق. ويؤدي الاعتماد الخطي إلى التحويل إلى بيئة الإنتاج. تلي ذلك فترة دعم ما بعد الإطلاق لمدة 30 يومًا (P-10.10, P-10.11, P-10.12).
المرحلة ⑦ تصدير البيانات وإعادتها (مسار الإنهاء): يقوم المزوّد بتصدير جميع بيانات العميل خلال يومي عمل من كل طلب صالح. ويُسمح بتصديرات متعددة. ويتم تسليم بصمة سلامة البيانات وشهادة عدد الصفوف مع كل تصدير (P-10.14, P-10.15).
المرحلة ⑧ إخراج البيئة من الخدمة (مسار الإنهاء): عند انتهاء نافذة التحقق وبلوغ تاريخ نهاية العمر التشغيلي، يتلف المزوّد جميع موارد العميل وفقًا لـ NIST SP 800-88 ويصدر شهادة إخراج من الخدمة (P-10.16, P-10.17).
المرحلة ⑨ الإنهاء التعاقدي (مسار الإنهاء): تنتهي الإطار التعاقدي رسميًا بعد 30 يومًا من إخراج البيئة من الخدمة. وتستمر الالتزامات النافذة (السرية، وحقوق الملكية الفكرية، وحماية البيانات، والمسؤولية، وحقوق التدقيق) وفقًا لـ §10.12 (P-10.18 إذا كان الدعم الممتد نشطًا).
