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