الإجابة المختصرة
إن مرحلة ما بعد الإطلاق (Go Live) ليست نهاية المشروع، بل هي المرحلة التي تتكشف فيها حقيقة ما تم بناؤه. فترة Hypercare هي فترة مخططة يظل فيها الفريق الذي أنشأ النظام متاحًا، ويعالج الفجوات بوتيرة سريعة، وفي نفس الوقت ينقل الملكية إلى الفريق الذي سيتولى صيانته.
هناك خطآن متناقضان: الأول هو التخلي عن هذه الفترة وترك المستخدمين وحدهم، والآخر هو تمديدها إلى ما لا نهاية مما يخلق تبعية دائمة للمورد. يمكن تجنب كلا الخطأين من خلال تحديد معايير خروج واضحة مسبقًا.
ما يميز هذه الفترة
| الجانب | Hypercare | العمليات الاعتيادية (BAU) |
|---|---|---|
| قناة التواصل | مباشرة مع فريق المشروع + تواجد ميداني | طابور دعم اعتيادي |
| زمن الاستجابة لعطل يعيق العمل | حتى ساعة واحدة | حسب اتفاقية مستوى الخدمة (SLA) الجارية |
| وتيرة إصدار الإصلاحات | يوميًا أو كل يومين | دورة مجدولة |
| صلاحية اتخاذ القرار | مالك العملية متاح يوميًا | لجنة التغيير |
| التركيز | الاستقرار والإصلاح | التحسين والتطوير |
الاجتماع اليومي للفرز هو جوهر العمل
اجتماع يومي لمدة 20 دقيقة كل صباح، في وقت ثابت، للإجابة على ثلاثة أسئلة: ما الذي تم فتحه أمس؟ ما الذي يعيق العمل الآن؟ وما الذي سيتم إطلاقه اليوم؟ يتم تصنيف كل استفسار إلى أربع فئات:
- عطل يعيق العمل — لا يمكن إتمام عملية تجارية. يتم معالجته فورًا.
- فجوة في البيانات — نتج عن الترحيل أو التكامل بيانات خاطئة. أولوية عالية لأنها تضعف الثقة.
- فجوة في التدريب — النظام يعمل كما هو مخطط له، لكن المستخدم لم يكن على دراية به. يتم تقديم إجابة فورية وتسجيل الحاجة لتعديل المواد التعليمية.
- طلب تحسين — يتم إضافته إلى قائمة المتطلبات المتأخرة (Backlog)، ولا يتم تنفيذه خلال هذه الفترة.
هذا التصنيف هو الأداة الرئيسية للتحكم في النطاق: فبدونه، يبدو كل طلب عاجلاً وتتحول فترة الاستقرار إلى دورة تطوير إضافية.
تكوين الفريق والتواجد الميداني
في الأسبوع الأول، يُطلب تواجد فعلي أو افتراضي مكثف في الوحدات الرئيسية. يجلس أعضاء المشروع بجانب المستخدمين، ويشاهدون الفشل في الوقت الفعلي ويصلحونه في نفس اليوم. إن قيمة المراقبة المباشرة أعلى بكثير من التقارير المكتوبة، فمعظم المعوقات الخطيرة لا يتم الإبلاغ عنها على الإطلاق.
ممثلون ميدانيون يرافقون الفريق هم شبكة الأبطال (Champions)، ولذلك يخضعون لتدريب مبكر ويحصلون على قناة اتصال مباشرة. تفاصيل إضافية متوفرة في شبكة Champions على Salesforce.
معايير الخروج
الخروج من مرحلة Hypercare هو قرار قابل للقياس. مجموعة المعايير المقبولة:
- صفر أعطال مفتوحة تعيق العمل لمدة خمسة أيام عمل متتالية.
- انخفاض بنسبة 60% أو أكثر في حجم الاستفسارات اليومية مقارنة بذروة الأسبوع الأول.
- معدل إنجاز العمليات الأساسية حسب الدور أعلى من الهدف المحدد.
- المؤشرات الثلاثة الرئيسية لجودة البيانات ضمن النطاق المتفق عليه.
- تعامل فريق الدعم الداخلي بشكل مستقل مع 80% من الاستفسارات في الأسبوع الأخير.
المعيار الأخير هو الفارق بين نقل الملكية الحقيقي والتخلي في تاريخ عشوائي. يعتمد القياس على نفس الإطار الموصوف في مقاييس تبني Salesforce.
نقل الملكية المنظم
يبدأ نقل الملكية من الأسبوع الأول وليس في اليوم الأخير. آلية بسيطة: اعتبارًا من الأسبوع الثاني، يتعامل فريق الدعم الداخلي مع الاستفسارات أولاً، ويقدم فريق المشروع الدعم من الخلف. يتم توثيق كل استفسار تم حله في قاعدة معرفية داخلية بثلاثة أسطر: الأعراض، السبب، الحل.
مخرجات نقل الملكية: وثيقة بنية (Architecture Document) محدثة، قائمة بالتكاملات مع نقاط الفشل المعروفة، إجراءات التشغيل الدورية، قائمة بالديون التقنية المتراكمة تحت الضغط، وأذونات الوصول والصلاحيات التشغيلية.
الاعتماد على طريقة الإطلاق
في إطلاق Big Bang، تكون فترة Hypercare مكثفة وقصيرة نسبيًا، مع فريق كبير. في الإطلاق المرحلي، تتكرر هذه الفترة في كل مرحلة، ولكن بنطاق أصغر، ويتم التعلم من مرحلة إلى أخرى. هذا التداعيات هو أحد الاعتبارات عند اختيار الاستراتيجية، راجع Big Bang أم Rollout مرحلي.
ما يتم عده كل أسبوع
حجم الاستفسارات اليومية حسب الفئة، متوسط زمن حل عطل يعيق العمل، نسبة الاستفسارات التي عالجها الفريق الداخلي، وعدد الديون التقنية المفتوحة. تقيس الثلاثة الأولى الاستقرار؛ أما الأخيرة فتمنع أن تترك الفترة ألغامًا.
الخلاصة
خططوا لمرحلة Hypercare كمرحلة ذات ميزانية، فريق، اجتماع فرز يومي ومعايير خروج رقمية. صنفوا كل استفسار، لا تطوروا تحسينات خلال هذه الفترة، وانقلوا الملكية تدريجيًا بدءًا من الأسبوع الثاني. النظام المستقر ليس الذي لا يحتوي على أعطال، بل هو الذي تعرف المنظمة كيف تصلحه بنفسها.