مراجعة التصميم للتغييرات الجوهرية
أي تغيير يمس نموذج البيانات، أو الأذونات، أو التكامل يمر بمراجعة احترافية قبل بنائه. هذه هي الخطوة التي توفر معظم إعادة العمل.
دعم وتحسين مستمر
Salesforce لا تنتهي بيوم التشغيل.
تستمر المنظمة والمستخدمون والعمليات في التغير. يتيح لك نموذج الرعاية المستمرة الخاص بنا صيانة وتحسين وتوسيع النظام بطريقة موثقة وذات أولوية وقابلة للقياس — دون تراكم ديون تقنية جديدة.
حلقة التحكم التشغيلي
حلقة تشغيل واحدة، وليس قائمة طلبات
الفرق بين الدعم الذي يطفئ الحرائق والرعاية التي تخلق القيمة هو حلقة مغلقة: يتم قياس كل طلب، وتحديد أولويته، وتسليمه، والتحقق منه — وتغذي النتيجة الدورة التالية.
حلقة التحكم التشغيلي
- 01
الاستقبال
قناة طلب واحدة مع تصنيف وملكيه وحالة مرئية.
- 02
تحديد الأولويات
تصنيف مشترك حسب التأثير التجاري والمخاطر والجهد.
- 03
البناء والاختبار
يتم بناؤه في بيئة اختبار (sandbox)، واختباره بالقبول، وإصداره تحت التحكم.
- 04
القياس والتعلم
تقارير النشاط، مقاييس التبني، ومراجعة الاستثناءات.
↻ تتكرر الدورة — كل جولة تغذي أولوية الجولة التالية
نطاق المسؤولية
ما يمكن أن تشمله الرعاية المستمرة
- معالجة الحوادث
- دعم المستخدمين
- التغييرات والتعديلات
- التدفقات والأتمتة
- تطوير Apex وLWC
- التقارير ولوحات المعلومات
- إدارة الصلاحيات
- جودة البيانات
- مراقبة التكامل
- إدارة الإصدارات
- إدارة المتطلبات المتراكمة (Backlog)
- التدريب والتمكين
- الحوكمة ومراجعة التصميم
- خارطة طريق ربع سنوية
- تقليل الديون التقنية
- جاهزية إصدارات Salesforce
النماذج
يتم الاختيار حسب الحاجة، وليس حسب الحزمة
| النموذج | متى يناسب | ما تحصل عليه | قيود تستحق المعرفة |
|---|---|---|---|
| حزمة ساعات | احتياجات صغيرة ومتغيرة | مرونة كاملة في اختيار المهام | أقل ملاءمة للتخطيط طويل الأمد |
| عقد شهري | تدفق مستمر من التحسينات والدعم | سعة معروفة وتحديد أولويات شهرية | يتطلب انضباطًا في تحديد الأولويات من العميل |
| فريق تسليم مستمر | نظام أساسي واسع الاستخدام | دعم وتطوير وصيانة تحت إدارة واحدة | تعاون أوسع |
| مهندس معماري جزئي | يوجد فريق عمل داخلي ولكن لا يوجد صانع قرار تقني رفيع المستوى | مراجعة التصميم، الحوكمة والتحكم في الديون التقنية | لا يحل محل قدرة التسليم |
| مشروع تحسين مركز | هدف محدد له بداية ونهاية | نطاق واضح ونتائج قابلة للتسليم | لا يغطي الدعم المستمر |
حزمة ساعات
- متى يناسب
- احتياجات صغيرة ومتغيرة
- ما تحصل عليه
- مرونة كاملة في اختيار المهام
- قيود تستحق المعرفة
- أقل ملاءمة للتخطيط طويل الأمد
عقد شهري
- متى يناسب
- تدفق مستمر من التحسينات والدعم
- ما تحصل عليه
- سعة معروفة وتحديد أولويات شهرية
- قيود تستحق المعرفة
- يتطلب انضباطًا في تحديد الأولويات من العميل
فريق تسليم مستمر
- متى يناسب
- نظام أساسي واسع الاستخدام
- ما تحصل عليه
- دعم وتطوير وصيانة تحت إدارة واحدة
- قيود تستحق المعرفة
- تعاون أوسع
مهندس معماري جزئي
- متى يناسب
- يوجد فريق عمل داخلي ولكن لا يوجد صانع قرار تقني رفيع المستوى
- ما تحصل عليه
- مراجعة التصميم، الحوكمة والتحكم في الديون التقنية
- قيود تستحق المعرفة
- لا يحل محل قدرة التسليم
مشروع تحسين مركز
- متى يناسب
- هدف محدد له بداية ونهاية
- ما تحصل عليه
- نطاق واضح ونتائج قابلة للتسليم
- قيود تستحق المعرفة
- لا يغطي الدعم المستمر
يتم مناقشة شروط التسعير واتفاقية مستوى الخدمة (SLA) عبر مكالمة ولا يتم نشرها على الموقع.
الحوكمة
أربع آليات تحافظ على صحة النظام بمرور الوقت
التحكم في الدين التقني
تتم قياس وإدارة الأتمتة المكررة والحقول الميتة والأذونات الواسعة جدًا كعناصر متراكمة حقيقية (backlog items)، مع تخصيص قدرة مخصصة لها.
جاهزية الإصدار
تطلق Salesforce ثلاثة إصدارات سنويًا. نتحقق مسبقًا من التغييرات، وما قد يتعطل، وما يستحق الاعتماد.
قياس التبني
تكشف مقاييس الاستخدام حسب الدور حيث لا تعمل العملية فعليًا — قبل أن تصبح بيانات التقرير غير موثوقة.
الأسئلة الشائعة
الدعم والرعاية المستمرة — أسئلة نسمعها غالبًا
ما هو الفرق بين الدعم والرعاية المدارة المستمرة؟
يتعامل الدعم مع الحوادث وأسئلة المستخدمين ويعيد النظام إلى حالة العمل. تتساءل الرعاية المستمرة أيضًا عما يجب تغييره: تحديد أولويات التحسينات، والتحكم في الديون التقنية، ومراجعة التصميم للتغييرات الأكبر، وخارطة طريق تتطلع إلى الأمام. المنظمة التي تشتري الدعم وحده ينتهي بها المطاف بنظام يعمل ولكنه لا يتحسن أبدًا.
ماذا يعتبر حادثًا عاجلاً؟
حدث يعيق عملية عمل لمجموعة من المستخدمين بدون حل بديل معقول — فشل في استقبال العملاء المحتملين، أو تعطل أتمتة أساسية، أو توقف تكامل عن العمل. طلب حقل جديد أو تقرير جديد ليس حادثًا، مهما كان مهمًا. يتم الاتفاق على هذا التمييز كتابيًا مسبقًا.
هل يمر كل تغيير ببيئة اختبار؟
نعم. كل تغيير جوهري يتم بناؤه في بيئة اختبار (sandbox)، ويتم اختباره مقابل سيناريو عمل، ثم يتم إصداره للإنتاج ضمن نافذة محددة. الاستثناء الوحيد هو إصلاح حادث معيق، وحتى في هذه الحالة يتم توثيقه وإعادته إلى المسار القياسي في الدورة التالية.
كيف يتم تحديد الأولوية؟
حسب التأثير على الأعمال، وعدد المستخدمين المتأثرين، والمخاطر والجهد — في اجتماع تحديد أولويات دائم مع مالك العملية من جانب العميل. نحن لا نقوم بتحديد الأولويات وحدنا، لأن تحديد الأولويات هو قرار عمل، وليس قرارًا فنيًا.
ماذا يحدث للديون التقنية المتراكمة قبل أن نبدأ؟
في بداية التعاون، نقوم بتحديد الأتمتة المكررة، والحقول غير المستخدمة، والتعليمات البرمجية غير المختبرة، والأذونات الواسعة جدًا. تدخل النتائج في قائمة ذات أولوية، ويتم تخصيص حصة ثابتة من القدرة الشهرية لتقليل الديون — وإلا فإنها ستنمو فقط.
هل يمكننا بدء الرعاية المستمرة حتى لو لم تقم أنت بتنفيذ النظام؟
نعم، وهذا أمر شائع. في هذه الحالة، نبدأ بمراجعة سريعة للنظام تحدد الوضع الحالي، بحيث يستند التعاون إلى الفهم وليس التخمين.
الخطوة التالية
مراجعة نموذج دعم
سننظر في نطاق الاستخدام، والاحتياجات المفتوحة، ومستوى الحوكمة المطلوب — وسنقترح نموذجًا يناسب وتيرتك.