خدمة الدعم والعمليات

4.1 نظرة عامة

يحدد هذا القسم إطار الدعم التشغيلي الذي يقدّم من خلاله المزوّد خدمات الدعم اليومية للمنصة. وهو يضع الهيكل والعمليات والمسؤوليات الخاصة بإدارة الحوادث وإدارة دورة حياة التذاكر والصيانة الوقائية والتصعيد الفني وضبط التغيير التشغيلي.

تتوافق جميع عمليات الدعم مع إرشادات أفضل الممارسات في ITIL 4 وتستفيد من نموذج الدعم متعدد القنوات لدى المزوّد لضمان تقديم خدمة سريعة وقابلة للتتبع وغنية بالسياق عبر جميع قنوات الاتصال.

تنطبق خدمات الدعم على بيئة الإنتاج، وعندما يكون ذلك متفقًا عليه صراحةً في العقد التجاري، على بيئة Staging. ويجب على المزوّد الحفاظ على إجراءات دعم موثقة وإتاحتها للعميل عند الطلب المعقول. وتُسجَّل جميع أنشطة الدعم وتُتابع عبر نظام التذاكر المدمج في المنصة، بما يوفر رؤية شاملة من البداية إلى النهاية لكل من المزوّد والعميل.

4.2 مكتب خدمة المزوّد (PSD)

يُعد مكتب خدمة المزوّد (PSD) نقطة الاتصال الوحيدة لتسجيل وإدارة وحل جميع التذاكر المتعلقة بالدعم الفني، بما في ذلك الحوادث وطلبات الخدمة والمشكلات وطلبات التغيير التي يرفعها العميل. ويعمل PSD بنموذج دعم متعدد القنوات يوحّد نظام التذاكر الرسمي والرسائل الفورية وقنوات الاتصال التقليدية في سير عمل دعم واحد قابل للتتبع. وينسق PSD مع جهة اتصال تقنية المعلومات المخصصة لدى العميل لجميع خدمات الدعم والصيانة.

4.2.1 نظام التذاكر المدمج

تتضمن المنصة نظام تذاكر مدمجًا أصيلاً داخل تطبيق ProjectVIEW ERP نفسه. وتتيح هذه القدرة المتكاملة لإدارة خدمات تقنية المعلومات للمستخدمين المفوضين رفع التذاكر وتتبعها وإدارتها مباشرة من داخل المنصة دون مغادرة بيئة ERP. ويوفر نظام التذاكر المدمج ما يلي:

• (a) تسجيل التذاكر داخل التطبيق: يرفع المستخدمون التذاكر مباشرة داخل واجهة ProjectVIEW ERP، مع الالتقاط التلقائي للمعلومات السياقية بما في ذلك الوحدة النشطة، والشاشة، ودور المستخدم، وأي سجلات بيانات مرتبطة؛
• (b) تتبع الحالة في الوقت الحقيقي: تعرض لوحة موحدة داخل ERP جميع التذاكر المفتوحة والجارية والمغلقة مع رؤية كاملة لدورة الحياة، ومؤقتات العد التنازلي لاتفاقية مستوى الخدمة، ومؤشرات الأولوية؛
• (c) اتصال ثنائي الاتجاه: تتم المحادثات المتسلسلة بين العميل ومهندس الدعم المكلّف داخل التذكرة نفسها، مع الحفاظ على سجل زمني تدقيقي كامل؛
• (d) التقاط المرفقات والأدلة: يرفق المستخدمون لقطات الشاشة وسجلات الأخطاء والوثائق وتسجيلات الشاشة مباشرةً بالتذاكر، مما يلغي فقدان السياق أثناء التصعيد؛
• (e) مقاييس وتقارير اتفاقية مستوى الخدمة: تتبع مدمج لاتفاقية مستوى الخدمة مع تنبيهات آلية عند اقتراب أهداف الاستجابة أو الحل من العتبة، إلى جانب تقارير فورية عن أحجام التذاكر والفئات وأداء الحل؛
• (f) تكامل قاعدة المعرفة: يرتبط نظام التذاكر بقاعدة المعرفة المدمجة لدى المزوّد (الويكي)، ويعرض المقالات ذات الصلة والحلول المعروفة أثناء إنشاء التذكرة لتمكين الحل الذاتي؛
• (g) إشعارات آلية: تُفعّل إشعارات البريد الإلكتروني والإشعارات داخل التطبيق عند كل انتقال في حالة التذكرة (تم التسجيل، تم الإقرار، تم الإسناد، تم التحديث، تم الحل، تم الإغلاق)، لإبقاء جميع أصحاب المصلحة على اطلاع.

يعمل نظام التذاكر المدمج باعتباره سجل المصدر لجميع تفاعلات الدعم. وبغض النظر عن القناة التي يُبلَّغ من خلالها عن المشكلة في البداية (الهاتف أو البريد الإلكتروني أو WhatsApp أو داخل التطبيق)، يجب إضفاء الصفة الرسمية على جميع التذاكر داخل نظام التذاكر المدمج لضمان قياس اتفاقية مستوى الخدمة وقابلية التدقيق والامتثال.

4.2.2 قنوات الدعم متعددة القنوات

يجب على المزوّد أن يتيح للعميل الوصول إلى PSD عبر القنوات التالية:

4.2.3 قناة الدعم عبر WhatsApp Business

ينشئ المزوّد مجموعة WhatsApp Business مخصصة لكل عميل، تربط بين المستخدمين الرئيسيين المعينين لدى العميل والاستشاريين المكلّفين لدى المزوّد. وتعمل هذه القناة بوصفها طبقة تواصل غير رسمي سريعة تكمل نظام التذاكر الرسمي. وتخضع قناة WhatsApp للقواعد التالية:

• (a) النطاق: الاستفسارات السريعة، وإرشادات الاستخدام، وتوضيح الوظائف، والمناقشات غير الرسمية بشأن طلبات التغيير المحتملة، والإبلاغ الأولي عن المشكلات غير الحرجة. وقناة WhatsApp هي ليست بديلاً عن التسجيل الرسمي للتذاكر;
• (b) قاعدة الإضفاء الطابع الرسمي: أي مسألة يتم الإبلاغ عنها عبر WhatsApp وتتطلب تتبعاً رسمياً أو قياساً لاتفاقية مستوى الخدمة أو تغييراً في الكود أو تعديلاً في الإعدادات أو تصعيداً يجب تسجيلها كتذكرة في نظام التذاكر المدمج بواسطة مستشار المزوّد خلال 4 ساعات من تحديدها. ويجب إخطار العميل بالمرجع الخاص بالتذكرة؛
• (c) استثناء اتفاقية مستوى الخدمة: تبدأ مؤقتات استجابة وحل اتفاقية مستوى الخدمة عند إضفاء الطابع الرسمي على التذكرة في نظام التذاكر المدمج، وليس عند التواصل الأولي عبر WhatsApp؛
• (d) حماية البيانات: لا يجوز للمشاركين مشاركة البيانات الشخصية أو بيانات الاعتماد أو محتوى قاعدة البيانات أو المعلومات السرية عبر WhatsApp. ويقوم المزوّد بإطلاع جميع المشاركين على التزامات معالجة البيانات بموجب قوانين حماية البيانات المعمول بها (راجع القسم 17)؛
• (e) الاحتفاظ: تُحتفظ رسائل WhatsApp وفقاً لسياسة الاحتفاظ بالبيانات لدى المزوّد. ولأغراض قابلية التدقيق، يجب تلخيص أي نقاش تقني جوهري أو قرار يتم عبر WhatsApp في سجل التذكرة المقابل؛
• (f) عضوية المجموعة: تُدار عضوية المجموعة بصورة مشتركة. ويجب على المزوّد تحديث عضوية المجموعة خلال يومي عمل من أي تغيير في الموظفين. ويجب على العميل إخطار المزوّد بأي تغييرات تطرأ على المستخدمين الرئيسيين المعينين لديه.

4.2.4 ساعات تشغيل PSD والتوافر

يعمل PSD 24 ساعة في اليوم، 7 أيام في الأسبوع، 365 يوماً في السنة لتسجيل التذاكر عبر جميع القنوات. وتخضع أنشطة الحل لنوافذ التشغيل المحددة في مصفوفة الاستجابة والحل الخاصة باتفاقية مستوى الخدمة (القسم 3.6).

تُستثنى العطلات الرسمية الحكومية في الإمارات العربية المتحدة/اليونان/الفلبين من احتساب أيام العمل، غير أن الحوادث من الفئة P1 تتم معالجتها بغض النظر عن جداول العطلات الرسمية.

4.2.5 مسؤوليات PSD

يتعين على PSD أن:

• (a) يسجل جميع الحوادث وطلبات الخدمة المبلغ عنها من العميل في نظام التذاكر المدمج، مع تخصيص رقم مرجعي فريد للتذكرة مع التقاط تلقائي للبيانات الوصفية السياقية؛
• (b) يتفق مع العميل على مستوى الأولوية الذي سيُخصص لكل تذكرة وفقاً لتصنيف أولوية الحادث المحدد في القسم 3.5؛
• (ج) تزويد العميل بإقرار استلام التذكرة الإلكترونية بعد الاستلام؛
• (د) إدارة جميع عمليات التصعيد اللازمة لاستعادة الخدمات ضمن أهداف مستوى الخدمة المعمول بها؛
• (هـ) تزويد العميل بتحديثات منتظمة عن التقدم عبر نظام التذاكر أو الهاتف أو البريد الإلكتروني أو WhatsApp وفق فترات يتفق عليها الطرفان؛
• (و) إبلاغ العميل عند حل التذكرة، بما في ذلك وصف موجز للسبب الجذري والإجراء التصحيحي المتخذ وما إذا كانت التذكرة ستُغلق أم تتطلب إجراءً إضافياً؛
• (ز) حيثما أمكن، تتم أولاً محاولة حل التذاكر عن بُعد. وعندما لا يكون الحل عن بُعد ممكناً، يقوم المورّد بإيفاد مهندس مؤهل إلى مقر العميل عند الاقتضاء؛
• (ح) تحويل أي مسائل أُبلغ عنها في البداية عبر WhatsApp أو الهاتف إلى نظام التذاكر المدمج خلال 4 ساعات؛
• (ط) الحفاظ على سجل تدقيق كامل لجميع التفاعلات المتعلقة بالتذكرة، وتغييرات الحالة، وأنشطة الحل داخل نظام التذاكر المدمج.

4.3 إدارة دورة حياة التذاكر

تخضع جميع تفاعلات الدعم لدورة حياة تذكرة منظمة تُدار من خلال نظام التذاكر المدمج الخاص بالمنصة لضمان إمكانية التتبع والمساءلة والامتثال لأهداف اتفاقية مستوى الخدمة.

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

4.3.1 تسجيل التذاكر

عندما يسجل العميل تذكرة، يجب توفير الحد الأدنى التالي من المعلومات إلى PSD:

• (a) اسم العميل والمرجع التعاقدي (يتم التعبئة التلقائية تلقائياً عند رفع التذاكر عبر نظام التذاكر المدمج)؛
• (b) اسم وتفاصيل الاتصال بالشخص الذي أبلغ عن المسألة؛
• (ج) وصف واضح للمشكلة، بما في ذلك خطوات إعادة الإنتاج (في الحوادث) أو طبيعة الطلب (في طلبات الخدمة)؛
• (د) الوحدة أو الوحدات المتأثرة وعدد المستخدمين المخولين المتأثرين؛
• (هـ) أي تشخيصات أو لقطات شاشة أو رسائل خطأ حصل عليها العميل؛
• (و) مستوى الأولوية المقترح للتذكرة من جانب العميل.

4.3.2 سير عمل معالجة التذاكر

يحدد الإجراء التالي الطريقة التي تُعالج بها التذكرة من التسجيل الأولي حتى الإغلاق:

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

4.3.3 تصنيف التذاكر

تُصنف التذاكر إلى الفئات التالية:

4.4 التصعيد الفني

يحتفظ المورّد بمصفوفة تصعيد فني منظمة لضمان تصعيد التذاكر إلى المستوى المناسب من الخبرة والسلطة الإدارية عندما لا يتحقق الحل ضمن أهداف مستوى الخدمة المعمول بها أو عندما تستدعي شدة المشكلة تدخلاً من الإدارة العليا.

4.4.1 مستويات التصعيد

4.4.2 التصعيد بمبادرة العميل

يجوز للعميل تصعيد أي تذكرة في أي وقت من خلال الاتصال بـ PSD وطلب التصعيد. ويجب على المزوّد تحديث مصفوفة جهات الاتصال الخاصة بالتصعيد مصفوفة جهات الاتصال الخاصة بالتصعيد مرة واحدة سنوياً على الأقل أو عند أي تغيير في الموظفين، ويجب أن يزوّد العميل بالمصفوفة الحالية خلال 5 أيام عمل من أي تحديث. ويجب أن تتضمن مصفوفة جهات الاتصال الخاصة بالتصعيد الاسم والمسمى الوظيفي وأرقام الاتصال المباشرة وعنوان البريد الإلكتروني لكل مستوى من مستويات التصعيد.

بالنسبة إلى حوادث P1 (حرجة)، يقوم المورّد تلقائياً بالتصعيد إلى المستوى 2 خلال 30 دقيقة إذا لم تحدد الاستجابة الأولية مساراً للحل، وإلى المستوى 3 خلال ساعتين إذا ظلت الحادثة دون حل. ويجري إخطار جهة الاتصال التقنية المعيّنة لدى العميل ومدير تقديم الخدمة بجميع عمليات تصعيد P1 في الوقت الفعلي.

4.5 الصيانة الوقائية

يقوم المورّد بإجراء صيانة وقائية شهرية لجميع مكونات المنصة ضمن بيئة العميل السيادية الخاصة المخصصة. وتُنفذ الصيانة الوقائية بشكل استباقي لتحديد المشكلات المحتملة ومعالجتها قبل أن تؤثر في توافر الخدمة أو أدائها.

4.5.1 نطاق الصيانة الوقائية

تتضمن الصيانة الوقائية الشهرية، على سبيل المثال لا الحصر:

• (أ) فحوصات صحة البنية التحتية: مراقبة أداء الآلات الافتراضية، واستخدام القرص، وتخصيص الذاكرة، وتحليل حمل وحدة المعالجة المركزية، وتقييم زمن انتقال الشبكة؛
• (ب) صيانة قاعدة البيانات: إعادة بناء الفهارس، وتحديث الإحصاءات، وإدارة سجل المعاملات، وفحوصات السلامة (DBCC CHECKDB)، وتحسين التخزين؛
• (ج) تصحيح الأمان: مراجعة وتطبيق تصحيحات الأمان لنظام التشغيل والبرمجيات الوسيطة وقاعدة البيانات وفقاً لسياسة إدارة التصحيحات لدى المورّد (انظر القسم 3.1.3 بشأن نوافذ الصيانة)؛
• (د) التحقق من النسخ الاحتياطي: التحقق من اكتمال مهام النسخ الاحتياطي، واختبار سلامة النسخ الاحتياطية، وتنفيذ تمرين الاستعادة (ربع سنوي)؛
• (هـ) صحة التطبيق: فحوصات وظيفية على مستوى الوحدة، والتحقق من نقاط نهاية واجهة برمجة التطبيقات، ومراقبة التكامل، ومراجعة سجلات الأخطاء عبر جميع وحدات ProjectVIEW ERP النشطة؛
• (و) إدارة شهادات SSL/TLS: مراقبة انتهاء صلاحية الشهادات وتجديدها وتدويرها؛
• (ز) مراجعة السعة: تقييم الاستخدام الحالي للموارد مقابل السعة المخصصة، مع توصيات استباقية للتوسع عندما يتجاوز الاستخدام عتبة 75%.

4.5.2 تقارير الصيانة الوقائية

عند اكتمال كل دورة صيانة وقائية، يقدم مهندس الصيانة لدى المزوّد تقرير الصيانة الوقائية إلى العميل خلال 3 أيام عمل. ويجب أن يتضمن التقرير:

• تاريخ ومدة نشاط الصيانة؛
  • المكونات التي تم فحصها والإجراءات التي تم تنفيذها؛
  • المخاطر أو الشذوذات المحددة مع المعالجة الموصى بها؛
  • مقاييس الاستخدام الحالية للموارد مقارنة بالسعة المخصصة؛
  • جدول التصحيحات والتحديثات المقبلة؛
  • تأكيد نتائج التحقق من النسخ الاحتياطي.

4.6 إدارة التغيير

تخضع جميع التعديلات على إعدادات المنصة أو وظائفها أو بنيتها التحتية لعملية رسمية لـ إدارة التغيير مصممة للحد من المخاطر التي قد تطال بيئة الإنتاج. وتُصنف التغييرات وتُدار وفقاً لأفضل ممارسات ITIL في إدارة التغيير.

4.6.1 تصنيف التغيير

4.6.2 سير عمل إدارة التغيير

تتبع جميع التغييرات العادية والطارئة هذا سير العمل:

• (أ) الطلب: يقدم العميل أو المورّد طلب تغيير عبر PSD متضمناً الوصف والمبرر التجاري والوحدات المتأثرة وتاريخ التنفيذ المطلوب؛
• (ب) التقييم: يجري المورّد تقييماً للأثر يشمل: المخاطر الفنية، والمستخدمين المتأثرين، وخطة التراجع، والجهد التقديري، والاعتماديات؛
• (ج) الموافقة: يراجع مجلس استشارات التغيير أو مدير تقديم الخدمة في حالة التغييرات الطارئة التغيير ويوافق عليه أو يرفضه؛
• (د) التنفيذ: يتم تطوير التغيير ونشره في بيئة التجهيز؛
• (هـ) UAT: يجري العميل اختبار قبول المستخدم الشامل في بيئة التجهيز. ويُمنح حد أدنى قدره 5 أيام عمل لإجراء UAT. ويلزم اعتماد خطي (راجع القسم 3.2.1)؛
• (و) النشر: بعد اعتماد العميل لـ UAT، يتم نشر التغيير في بيئة الإنتاج خلال نافذة صيانة متفق عليها؛
• (ز) مراجعة ما بعد التنفيذ: يراقب المورّد التغيير لمدة 5 أيام عمل بعد النشر ويقدم تقرير إغلاق إلى العميل.

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

4.6.3 قابلية تدقيق التغيير

تُسجل جميع التغييرات على إعدادات المنصة وقاعدة الشيفرة والبنية التحتية في نظام إدارة التغيير لدى المورّد. ويتضمن كل سجل تغيير: مقدم الطلب، والوصف، وتقييم المخاطر، وسلسلة الموافقات، وتاريخ التنفيذ، والمهندس المنفذ، ونتائج الاختبار، وحالة ما بعد التنفيذ. وتكون سجلات التغيير متاحة للعميل عند الطلب وتُدرج في مراجعة الخدمة الفصلية (راجع القسم 3.9.2).

4.7 إدارة إصدارات البرمجيات

يدير المورّد جميع عمليات تسليم البرمجيات من خلال عملية إدارة الإصدارات الخاضعة للرقابة، والتي تميز بين نوعين مختلفين جوهرياً من التسليم: الإصدارات/التحديثات (تراكمية، خاصة بالعميل، متكررة) والترقيات (إصدار رئيسي، على مستوى المنتج، سنوية). ويضمن هذا التمييز ألا يتعارض التسليم الرشيق اليومي للعميل مع خارطة طريق المنتج الأوسع لدى المورّد.

4.7.1 الإصدارات والتحديثات (تراكمية - على سبيل المثال v11.xx)

تُعد الإصدارات والتحديثات تسليمات تراكمية ضمن الإصدار الرئيسي الحالي من المنصة (على سبيل المثال، v11.01، v11.02، v11.15). وهي تعالج طلبات التغيير، وإصلاحات العيوب، والتعديلات التهيئية، والتحسينات الوظيفية الطفيفة الخاصة بتطبيق العميل. وتُسلم الإصدارات باستخدام منهجية تنفيذ رشيقة مصممة بما يتوافق مع وتيرة التشغيل لدى العميل.

منهجية السبرنت الرشيق: يعمل المورّد وفق سبرنتات قصيرة الدورة بمتوسط 3 أيام عمل لكل سبرنت. ويقدم كل سبرنت مجموعة محددة من طلبات التغيير أو إصلاحات العيوب أو التغييرات التهيئية المتفق عليها مع العميل في تخطيط السبرنت. وتسير دورة السبرنت على النحو التالي:

ترقيم الإصدارات: يُمنح كل إصدار تراكمي رقم إصدار دلالي ضمن الإصدار الرئيسي الحالي (على سبيل المثال، v11.01، v11.02... v11.xx). ويزداد رقم الإصدار تسلسلياً مع كل تسليم ضمن السبرنت. ويحتفظ المورّد بسجل إصدارات يمكن للعميل الوصول إليه عبر المنصة.

4.7.2 الترقيات (الإصدار الرئيسي - على سبيل المثال v11 → v12)

تمثل الترقيات إصداراً رئيسياً جديداً من المنصة (على سبيل المثال، v11 → v12، v12 → v13). وتُعد الترقيات إصدارات على مستوى المنتج تشمل تحسينات وظيفية كبيرة، ووحدات جديدة، وإعادة تصميم واجهة المستخدم/تجربة المستخدم، وواجهات برمجة تطبيقات/حزم تطوير برامج جديدة، وتحسينات معمارية، وترقيات رئيسية لإصدارات COTS (على سبيل المثال، إطار عمل .NET، ومحرك SQL Server). وتُطرح الترقيات بمعدل مرة واحدة تقريباً سنوياً وتمثل رقم إصدار برمجي جديداً.

تشمل الترقيات الرئيسية عادة ما يلي:

• التحسينات الوظيفية الجديدة: إضافات للخصائص، وقدرات جديدة للوحدات، وتحسينات في سير العمل مدفوعة بخارطة طريق المنتج لدى المورّد وملاحظات مجلس الاستشاريين من العملاء؛
• تحسينات UI/UX: إعادة تصميم الواجهات، وتحسين سهولة الاستخدام، وتحسينات إمكانية الوصول، وتحديثات التصميم المتجاوب؛
• امتدادات API وSDK: نقاط تكامل جديدة، وقدرات محسنة لواجهات Web API، وحِزم تطوير برمجيات محدثة؛
• ترقيات منصات COTS: الانتقال إلى إصدارات جديدة من التقنيات الأساسية (.NET، SQL Server، IIS) في إطار التزام المورّد بتحديث التكنولوجيا؛
• تعزيزات الأمان: تطبيق معايير أمنية جديدة، وترقيات التشفير، والامتثال للمتطلبات التنظيمية الناشئة.

4.7.3 عملية متكاملة لإدارة الإصدارات والنشر

تدار جميع الإصدارات (التراكمية) والترقيات (الإصدار الرئيسي) من خلال مركز إصدارات المنصة، الذي يعمل بوصفه منصة الإدارة والتوزيع المركزية للإصدارات. وتوفر المنصة القدرات التالية:

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

4.7.4 نهاية العمر الانتقالي & انتقال الإصدارات

سياسة انتهاء العمر التشغيلي (EOL) الخاصة بالمزوّد، ودورة الانتقال بين الإصدارات، وخدمات الترحيل، وبرنامج إعادة التدريب، وإجراءات إعادة البيانات، وعمليات إيقاف الاشتراك، جميعها موضّحة بشكل شامل في الفصل 10 — انتهاء العمر التشغيلي، الانتقال بين الإصدارات وإيقاف الاشتراك. الفصل 10 ينظم جميع جوانب إدارة دورة حياة الإصدارات ابتداءً من الإتاحة العامة (GA) مرورًا بإعلان انتهاء العمر التشغيلي (EOL)، ونهاية الهندسة (EOE)، وانتهاء العمر التشغيلي، والدعم الممتد الاختياري.

لأغراض هذا الفصل، ينطبق الملخص التالي: يتعين على المزود أن يمنح العميل إخطاراً كتابياً مسبقاً لا يقل عن اثني عشر (12) شهراً قبل أن يصل أي إصدار رئيسي إلى نهاية العمر. وتشمل المساعدة على الترقية، بما في ذلك التخطيط للترحيل، وترحيل البيانات، واعتماد التكاملات، وإعادة التدريب، ودعم اختبار القبول، ضمن مدة الاشتراك دون أي تكلفة إضافية. وترد الشروط الزمنية والإجراءات الكاملة في الأقسام 10.1 إلى 10.14.

4.7.5 إدارة الإصدارات & إيداع الشيفرة المصدرية

يحافظ المزود على جميع الشيفرات المصدرية في نظام تحكم بالإصدارات قائم على Git يتضمن:

• الفرع الرئيسي: التطبيق القياسي لـ DANAOS ("النسخة الخام") الذي يمثل الإصدار المتاح حالياً على نطاق واسع؛
• فروع العملاء: التكوينات والتخصيصات الخاصة بالعميل والتي تُدار كفروع مخصصة. وتُطوَّر إصدارات السبرنت على فرع العميل؛
• النسخ العملية: نسخ عمل المطور التي تُدمج في ظروف مستقرة لإدخال وظائف جديدة إلى فرعي Master وClient. وتخضع جميع تغييرات الشيفرة إلى مراجعة الأقران عبر طلبات السحب (Pull Requests)، والاختبارات الآلية، والامتثال لإرشادات البرمجة الخاصة بالمزود التي تغطي معايير أفضل جودة للشيفرة، والمنطق التجاري، والأمن. وعند تنفيذ Commit وPush، وبعد أي مراجعة لطلب السحب، يُبرِّر المبرمج المسؤول (أو فريق Agile) إصدارات التطبيق بالكامل بتعليقات دلالية وسياقية. ويوافق المراجعون على التغييرات أو يرفضونها بناءً على إرشادات البرمجة الخاصة بالمزود. كما يجري التحقق من المنطق التجاري إضافياً من قبل مهندسي دعم DANAOS، وهم خبراء مختصون في مجالهم.

يمارس المزود التكامل المستمر / التسليم المستمر (CI/CD) لنشر البرمجيات حيثما كان ذلك مناسباً. ويؤتمت خط أنابيب CI/CD مراحل البناء والاختبار والنشر من مستودع Git إلى بيئة الاختبار المرحلي، بما يضمن الاتساق ويقلل أخطاء النشر اليدوي.

يتعين على المزود أن يحافظ على ترتيبات إيداع الشيفرة المصدرية مع وكيل إيداع مستقل من طرف ثالث. وتُحدَّد الشروط الشاملة التي تحكم محتويات الإيداع، وتواتر التحديث، والتحقق السنوي، وشروط الإفراج، وحقوق العميل عند الإفراج في القسم 9.14 (إيداع الشيفرة المصدرية). وتتحمل العميل تكاليف ترتيب الإيداع، بما في ذلك أتعاب وكيل الإيداع (انظر § 9.14.4).

4.8 خدمات IMAC/RD

يقدّم المزود خدمات التركيب والنقل والإضافة والتغيير والإزالة والتخلص (IMAC/RD) للمنصة كجزء من الدعم التشغيلي المستمر. وتُدار أنشطة IMAC/RD كتغييرات قياسية أو عادية (راجع القسم 4.6.1) وتخضع للنطاق التالي:

تُسعَّر أنشطة IMAC/RD التي تخرج عن نطاق مدة الاشتراك بشكل منفصل على أساس لكل يوم عمل، وذلك باتفاق خطي بين الطرفين قبل بدء العمل.

4.9 إرشادات معمارية المؤسسة

يتعين على المزود أن يقدم النصح للعميل بشأن مسائل معمارية المؤسسة المتعلقة بالمنصة، بما في ذلك تكامل الأنظمة، وتصميم تدفق البيانات، ومواءمة التقنية. ويشمل ذلك:

• (a) معمارية التكامل: إرشادات بشأن ربط ProjectVIEW ERP مع أنظمة المؤسسة الحالية لدى العميل (مثل SAP وOracle والمنصات المصرفية وأنظمة الموارد البشرية) عبر واجهة Web API الأصلية الخاصة بالمنصة (راجع القسم 2.5);
• (b) معمارية البيانات: استشارات بشأن تدفق البيانات، وتخطيط ترحيل البيانات، وإدارة البيانات الرئيسية، ومعمارية التقارير داخل بيئة العميل السيادية المخصصة؛
• (c) هندسة الأمن: إرشادات بشأن أمن الشبكات، وسياسات التحكم في الوصول، ومعايير التشفير، والمواءمة مع إطار الأمن المفصل في الجزء B من هذا الإطار؛
• (d) تخطيط القابلية للتوسع: توصيات استباقية لتوسعة البيئة استناداً إلى توقعات نمو المستخدمين، واتجاهات حجم البيانات، وخطط تفعيل الوحدات. وتُقدَّم إرشادات معمارية المؤسسة كـ خدمة استشارية ولا تمتد إلى تصميم أو تطوير أو دعم أنظمة الأطراف الثالثة. ويخضع تنفيذ التوصيات المعمارية إلى تحديد نطاق وتسعير منفصلين حسبما يتم الاتفاق عليه بين الطرفين.

4.10 التحسين المستمر للخدمة (CSI)

يشغّل المزود برنامج التحسين المستمر للخدمة (CSI) المتوافق مع ممارسات ITIL 4 ومنهجيات AIOps الحديثة لدفع تحسينات مستمرة في جودة الخدمة والكفاءة التشغيلية ورضا العميل. ويشمل برنامج CSI ما يلي:

• تحليل الاتجاهات بمساعدة الذكاء الاصطناعي: تحليل شهري لأحجام الحوادث وفئاتها والمشكلات المتكررة وأزمنة الحل باستخدام التعرف على الأنماط وكشف الشذوذ لتحديد التحسينات المنهجية بصورة استباقية؛
• إزالة السبب الجذري: أنشطة إدارة المشكلات التي تستهدف القضاء على الحوادث المتكررة من خلال إصلاحات دائمة، استناداً إلى تحليل الترابط بين التذاكر؛
• تحسين العمليات: مراجعة دورية لعمليات الدعم، وسير عمل التذاكر، وإجراءات التصعيد، وفاعلية الدعم متعدد القنوات لخفض أزمنة الحل وتحسين تجربة العميل؛
• إدارة ملاحظات العميل وتجربة العميل: إدراج نتائج استبيانات رضا العميل، وملاحظات مراجعة الخدمة الربع سنوية، ومؤشرات فاعلية قناة WhatsApp في سجل CSI؛
• تحديث التكنولوجيا: تحديد استباقي لتحديثات COTS، والتحسينات الأمنية، وتحسينات المنصة التي تفيد العميل؛
• إدارة المعرفة: إثراء مستمر لقاعدة المعرفة المدمجة بحلول من التذاكر المغلقة، بما يتيح معدلات أعلى للحل الذاتي ويقلل أحجام الحوادث المتكررة. ويُدار سجل CSI بواسطة مدير تقديم الخدمة ويُراجع خلال كل مراجعة خدمة ربع سنوية (راجع القسم 3.9.2). وتُتتبع جميع مبادرات CSI من مرحلة التحديد حتى التنفيذ مع نتائج قابلة للقياس. وعندما يعتمد المزود أدوات بمساعدة الذكاء الاصطناعي في عمليات الدعم، يجب أن يتوافق استخدامها مع أطر الحوكمة المعمول بها، بما في ذلك قانون الذكاء الاصطناعي للاتحاد الأوروبي وإطار NIST لإدارة مخاطر الذكاء الاصطناعي (AI RMF 1.0).

عناوين URLs المرجعية:

ITIL 4 Foundation – PeopleCert / Axelos ProjectVIEW ERP Ticketing System – DANAOS Projects WhatsApp Business Platform – Meta Azure Service Health – Microsoft NIST SP 800-88 Media Sanitization Guidelines NIST AI Risk Management Framework (AI RMF 1.0) EU AI Act – European Commission

4.11 سجل العمليات

يلخص الجدول التالي عمليات دعم الخدمة والعمليات التشغيلية المنشأة في هذا الفصل، بما في ذلك الأدوار المسؤولة، والنتائج المتوقعة، والإشارات المرجعية إلى العمليات ذات الصلة في فصول أخرى.

مفتاح الأدوار: P = المزود | C = العميل | PSD = مكتب خدمة المزود | SDM = مدير تقديم الخدمة | CAB =

مجلس استشاري | SC = لجنة التوجيه

4.11.1 سجل العمليات

4.11.2 مصفوفة RACI

R = مسؤول (ينفذ) | A = محاسب عليه (يعتمد) | C = مستشار | I = على علم | — = غير معني

4.11.3 تدفق العمليات — دورة حياة الدعم والعمليات