# HPI Pro — Full Knowledge Base

Website: https://hpi.pro/ar
Language: Arabic (ar)
Hebrew edition: https://hpi.pro
Contact: https://hpi.pro/ar/contact

> استشارات وهندسة وتنفيذ Salesforce وCRM للشركات والمؤسسات.

## Core pages
- https://hpi.pro/ar/services
- https://hpi.pro/ar/consulting-discovery
- https://hpi.pro/ar/crm-architecture
- https://hpi.pro/ar/salesforce-implementation
- https://hpi.pro/ar/salesforce-health-check
- https://hpi.pro/ar/salesforce-development-automation
- CI/CD وDevOps لـ Salesforce: https://hpi.pro/ar/salesforce-cicd-devops
- https://hpi.pro/ar/agentforce-ai
- https://hpi.pro/ar/integrations-data
- https://hpi.pro/ar/support
- https://hpi.pro/ar/salesforce-expert-staffing
- https://hpi.pro/ar/solutions
- https://hpi.pro/ar/methodology

- https://hpi.pro/ar/about
- https://hpi.pro/ar/insights
- https://hpi.pro/ar/contact

---

# Knowledge Base

## كم تبلغ تكلفة تطبيق Salesforce في مؤسستك؟ مكونات التكلفة ونموذج تقدير مسؤول
URL: https://hpi.pro/ar/insights/salesforce-implementation-cost
تتكون تكلفة تطبيق Salesforce من سبعة مكونات مختلفة تمامًا في سلوكها - بدءًا من الترخيص مرورًا بالتكاملات وصولاً إلى التكلفة الداخلية الخفية. غالبًا ما يكتشف من يوافق على ميزانية تستند إلى رقم واحد فقط تجاوزًا في الجولة الثانية.

## الإجابة المختصرة

لا توجد إجابة واحدة لسؤال "كم تبلغ تكلفة تنفيذ Salesforce؟"، لأنها تتألف من سبعة مكونات تتصرف بشكل مختلف: الترخيص يُدفَع بناءً على عدد المستخدمين ومستوى الإصدار، وتُدفَع خدمات التنفيذ بناءً على نطاق العمل، في حين أن التكلفة الداخلية الخفية – ساعات عمل فريقك – لا تظهر على الإطلاق في عرض سعر المورد. المنظمة التي تُخصص الميزانية فقط لما يظهر في العقد ستواجه تجاوزًا للميزانية بحلول الشهر الثاني.

الطريقة الصحيحة للتعامل مع هذا السؤال ليست البحث عن "سعر تنفيذ Salesforce" كرقم واحد، بل بناء نموذج تقدير يفصل بين المكونات ذات اليقين العالي (الترخيص) والمكونات التي تعتمد على النطاق والتعقيد (التنفيذ، التكاملات، ترحيل البيانات). سيجد من هم في مرحلة مبكرة من الاختيار معلومات إضافية في [شركة استشارات Salesforce](/ar/insights/choose-salesforce-implementation-company)، بينما يمكن لمن يقارنون عروض الأسعار بالفعل الاستفادة من المقال حول [طلب تقديم العروض (RFP) لـ Salesforce](/ar/insights/salesforce-rfp-guide).

## مكونات التكلفة السبعة

لا تمثل تكلفة تنفيذ Salesforce بندًا واحدًا في الميزانية، بل سبعة مكونات منفصلة، يتم تسعير كل منها بطريقة مختلفة ويتصرف بشكل مختلف بمرور الوقت:

1.  **الترخيص (Licensing)**: تكلفة سنوية أو شهرية لكل مستخدم، تعتمد على الإصدار (Professional, Enterprise, Unlimited) والمنتجات المرافقة مثل Sales Cloud, Service Cloud, أو Data Cloud.
2.  **خدمات التنفيذ (Implementation Services)**: عمل التوصيف، التهيئة، التطوير المخصص، والاختبار، وعادة ما يتم تسعيرها بالساعة أو بسعر ثابت بناءً على نطاق عمل محدد (Scope).
3.  **التكاملات (Integrations)**: ربط Salesforce بالأنظمة الحالية (ERP, خدمات الدفع، نظام الهاتف، أدوات التسويق)، وهي تكلفة تعتمد على عدد الأنظمة وتعقيد ربط البيانات بينها.
4.  **ترحيل البيانات (Migration)**: تنظيف، تخطيط، ونقل البيانات التاريخية من نظام سابق، والتي غالبًا ما يتم تقديرها بأقل من قيمتها الحقيقية نظرًا لعدم فحص جودة البيانات الأصلية مسبقًا.
5.  **التدريب (Training)**: تدريب المستخدمين النهائيين والمديرين، وهي تكلفة يسهل تجاهلها في الميزانية، لكنها تحدد سرعة التبني الفعلية.
6.  **الدعم المستمر (Ongoing Support)**: الصيانة، إصلاح الأخطاء، التغييرات الصغيرة وتحديثات الإصدار بعد التشغيل الفعلي (Go Live)، وعادة ما تكون جزءًا من اتفاقية منفصلة عن التنفيذ.
7.  **التكلفة الداخلية الخفية (Hidden Internal Cost)**: ساعات عمل فريق المنظمة: مالكو العمليات، مدير المشروع الداخلي، اختبارات القبول وتواصل التغيير، والتي لا تظهر في عرض سعر المورد ولكنها تستهلك موارد حقيقية.

## جدول عوامل السعر

| المكون | ما الذي يحرك السعر | كيف نقلل منه | علامة حمراء |
|---|---|---|---|
| الترخيص | عدد المستخدمين، الإصدار، المنتجات المرافقة | التحقق من الاستخدام الفعلي قبل التجديد وعدم إضافة مقاعد "للاحتياط" | يوصي المورد بإصدار أعلى دون ربط ذلك بحاجة عمل محددة |
| خدمات التنفيذ | عدد العمليات، تعقيد الأتمتة، عدد الكائنات المُخصَّصة | البدء بشريحة عمودية واحدة (Vertical Slice) والتوسع تدريجياً بدلاً من التنفيذ الشامل (Big Bang) | عرض لا يتضمن هيكل تجزئة العمل (WBS) مفصلاً حسب العملية أو مسار العمل |
| التكاملات | عدد الأنظمة، تنسيق البيانات، الحاجة إلى برمجيات وسيطة (Middleware) | رسم خرائط التبعيات مسبقًا واختيار بين iPaaS منخفض التكلفة أو Custom API مكلف حسب الحجم الفعلي | عدم تحديد من المسؤول عن صيانة التكامل بعد التشغيل الفعلي |
| ترحيل البيانات | حجم السجلات، الازدواجية، عدد المصادر التاريخية | إجراء مسح لجودة البيانات قبل التقدير، وليس بعده | يفترض العرض "بيانات نظيفة" دون فحص فعلي |
| التدريب | عدد الأدوار، تعقيد العملية، التوزيع الجغرافي | التدريب حسب الدور والسيناريو، وليس تدريبًا عامًا على الشاشات | بند التدريب مقيد بورشة عمل واحدة لمدة ساعتين لكل المنظمة |
| الدعم المستمر | اتفاقية مستوى الخدمة (SLA)، ساعات التوفر، حجم التغييرات الشهرية | تحديد مستوى SLA بناءً على أهمية العملية وليس بشكل موحد | عدم التمييز بين "خطأ" و"تغيير" في اتفاقية الدعم |
| التكلفة الداخلية الخفية | توفر مالكي العمليات، جودة اختبارات القبول، إدارة التغيير | تخصيص نسبة محددة من وقت مدير المشروع الداخلي مسبقًا | يفترض العرض أن الفريق الداخلي "سيكون متاحًا" دون تقدير للساعات |

## نموذج التقدير: نطاقات الجهد لا التسعير

بدلاً من الاعتماد على قائمة أسعار ثابتة تتقادم بسرعة وتختلف بين الموردين، من الأفضل التفكير في مصطلحات "نطاقات الجهد" (Effort Bands) لكل مكون، وترجمتها إلى سعر فعلي مع المورد المحدد:

-   **جهد منخفض**: عملية عمل واحدة، بدون تكاملات معقدة، أقل من 20 مستخدمًا، بيانات تاريخية محدودة. نموذجي لشركات B2B الصغيرة التي تنفذ Sales Cloud أساسيًا.
-   **جهد متوسط**: عمليتان إلى أربع عمليات عمل، تكامل واحد إلى ثلاثة مع الأنظمة الحالية، 20-100 مستخدم، ترحيل من نظام CRM سابق. هذا هو النطاق الأكثر شيوعًا في السوق المحلي.
-   **جهد عالٍ**: وحدات أعمال أو بلدان متعددة، تكاملات متعددة مع الأنظمة القديمة (Legacy)، نموذج أذونات معقد، أكثر من 100 مستخدم، متطلبات امتثال (Compliance) خاصة بالصناعة.

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

## كيفية ترجمة نطاق الجهد إلى عرض سعر حقيقي

بعد تحديد نطاق الجهد المتوقع، تتمثل الخطوة التالية في طلب تفصيل الساعات حسب المكون من ثلاثة موردين على الأقل، وليس فقط مبلغًا إجماليًا. يمنح هذا التفصيل المنظمة قدرة حقيقية على المقارنة: لقد توسعنا في ذلك في [مستشار Salesforce](/ar/insights/salesforce-consulting-guide)، حيث تم شرح كيفية تحديد العرض الذي يقلل بشكل مصطنع من مرحلة الاختبار ليبدو أرخص.

### ثلاثة سيناريوهات سعرية نموذجية

**السيناريو أ - تنفيذ أولي صغير**: عملية مبيعات واحدة، بدون تكامل، 10-15 مستخدمًا. تتركز معظم التكلفة في خدمات التنفيذ والتدريب؛ يشكل الترخيص والدعم المستمر جزءًا صغيرًا نسبيًا في السنة الأولى.

**السيناريو ب - استبدال نظام CRM حالي**: ترحيل آلاف السجلات، 40-60 مستخدمًا، تكامل واحد مع نظام المحاسبة. هنا قد يشكل الترحيل والتكاملات ثلث الميزانية الإجمالية، وهذا بالضبط المكون الذي تميل التقديرات الأولية إلى التقليل من شأنه.

**السيناريو ج - توسع متعدد السنوات لمنظمة كبيرة**: وحدات أعمال متعددة، Salesforce موجود بالفعل ويحتاج إلى إضافة Service Cloud أو Data Cloud. تصبح التكلفة الداخلية الخفية – وقت مالكي العمليات ومديري تكنولوجيا المعلومات – المكون الأكثر أهمية، وأحيانًا أكبر من تكلفة الترخيص.

## مثال على سيناريو مؤسسي

لنفترض أن مصنعًا متعدد المواقع يطلب عروض أسعار من ثلاثة شركات تكامل لتنفيذ Salesforce. العرض الأرخص أقل بنسبة 35 بالمائة من العروض الأخرى، ولكن عند الفحص يتضح أنه يتضمن 40 ساعة فقط لترحيل البيانات على الرغم من أن المنظمة لديها حوالي 60 ألف سجل عميل تاريخي في نظام قديم به العديد من التكرارات. يطلب الفريق من المورد تفصيل الافتراضات، ويكتشف أن العرض افترض "بيانات نظيفة وجاهزة للترحيل" – وهو افتراض لم يتم التحقق منه مقابل الواقع.

تقرر المنظمة إجراء مسح سريع لجودة البيانات قبل توقيع العقد. يكشف المسح أن 18 بالمائة من السجلات مكررة وأن 30 بالمائة تفتقر إلى حقل إلزامي للعملية الجديدة. ونتيجة لذلك، تطلب المنظمة من جميع الموردين الثلاثة إعادة تسعير مرحلة الترحيل بناءً على النتائج، وتضيف بندًا إلى العقد يفصل بين تكلفة الترحيل لمرة واحدة وصيانة جودة البيانات المستمرة – كما هو مفصل في [SOW مشروع Salesforce](/ar/insights/salesforce-sow-contract-clauses).

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

## المخاطر الشائعة والإجراءات الوقائية

| الخطر | كيف يبدو في الواقع | الإجراء الوقائي |
|---|---|---|
| عرض سعر "مدور" جدًا | مبلغ إجمالي واحد بدون تفصيل حسب المكون | طلب تفصيل الساعات والتكلفة لكل مكون من المكونات السبعة |
| تجاهل التكلفة الداخلية | المنظمة لا تخصص ميزانية لوقت الإدارة الداخلية واختبارات القبول | تقدير ساعات العمل الداخلية مسبقًا بشكل منفصل عن تكلفة المورد |
| ترحيل البيانات بتقييم أقل من قيمته | افتراض أن "البيانات جيدة" بدون فحص | إجراء مسح لجودة البيانات قبل التقدير النهائي |
| التدريب كبند ثانوي | ميزانية تدريب محدودة ليوم واحد لكل المنظمة | تخصيص ميزانية للتدريب حسب الدور والسيناريو الفعلي |
| دعم بدون تحديد SLA | عقد دعم مبهم بشأن أوقات الاستجابة والإصلاح | تحديد SLA متدرج حسب الأهمية وتسعيره وفقًا لذلك |

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

## كيفية التحقق من معقولية التقدير

| مجال الفحص | ماذا نفحص | وتيرة الفحص |
|---|---|---|
| مطابقة الترخيص للاستخدام | نسبة المستخدمين النشطين مقارنة بعدد التراخيص المشتراة | ربع سنوي |
| تجاوز خدمات التنفيذ | انحراف الساعات الفعلية مقابل الساعات المقدرة في العرض | عند كل معلم |
| عبء التكامل | تكرار الأعطال أو التأخيرات في نقل البيانات بين الأنظمة | شهري |
| جودة الترحيل | نسبة السجلات التي تحتوي على خطأ أو ازدواجية بعد النقل | لمرة واحدة بعد التشغيل الفعلي (Go Live) |
| تكلفة الدعم مقابل SLA | هل أوقات الاستجابة الفعلية تتوافق مع ما تم دفعه | شهري |

لتقدير ميزانية مسؤول، من المستحسن اختيار ثلاثة إلى خمسة مقاييس فقط من الجدول للمتابعة المستمرة في السنة الأولى. يمكن حساب المقياس الجيد قبل توقيع العقد وبعده، ويسمح بالمقارنة بين ما وعد به وما حدث بالفعل – وليس فقط الاعتماد على شعور بأن المشروع "سار على ما يرام". يمكن إجراء التطبيق الفعلي لنموذج التقدير من خلال [خدمة الاستشارات والتوصيف](/ar/consulting-discovery).

## قائمة مراجعة قبل الموافقة على الميزانية

- ☐ يتم تسعير كل مكون من مكونات التكلفة السبعة بشكل منفصل وليس بمبلغ إجمالي واحد.
- ☐ تم إجراء مسح لجودة البيانات قبل تقدير تكلفة الترحيل.
- ☐ تم تحديد نطاق الجهد (منخفض، متوسط، عالٍ) قبل طلب عروض الأسعار.
- ☐ تم تقدير ساعات العمل الداخلية بشكل منفصل عن تكلفة المورد.
- ☐ ميزانية التدريب مفصلة حسب الدور وليست كبند عام.
- ☐ تم تحديد اتفاقية مستوى خدمة (SLA) واضحة لاتفاقية الدعم المستمر.
- ☐ يوجد احتياطي بنسبة 10-20 بالمائة لتغييرات النطاق.
- ☐ ثلاثة موردين على الأقل قاموا بتفصيل الساعات حسب المكون وليس فقط المبلغ الإجمالي.
- ☐ تم فحص تكلفة الترخيص لمدة 24-36 شهرًا وليس فقط للسنة الأولى.
- ☐ تم تحديد مقاييس الفحص بعد التشغيل الفعلي (Go Live) وليس فقط "النظام يعمل".

## مصادر احترافية

- HPI Pro – استشارات وتوصيف — https://hpi.pro/consulting-discovery
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro –  خدمات Salesforce — https://hpi.pro/services

### أسئلة وأجوبة
**لماذا يمكن أن يختلف عرضا سعر لتطبيق Salesforce بمقدار الضعف؟**
غالبًا ما يتعلق الأمر بنطاق عمل مختلف وليس 'خصمًا'. قد لا يشمل العرض الأرخص اختبارات التحميل، أو ترحيل البيانات التاريخية، أو تدريب المستخدمين النهائيين، ثم يطلبها كإضافة بعد التوقيع. يجب المقارنة بناءً على نفس هيكل تقسيم العمل (WBS) والافتراضات، وليس فقط بناءً على الرقم الختامي.

**هل من الأفضل دفع تكلفة تراخيص Premium لتوفير تكلفة التطبيق؟**
أحيانًا نعم: الترخيص الذي يتيح ميزات Flow و Automation المضمنة يمكن أن يوفر تكلفة التطوير المخصص. لكن هذه ليست قاعدة ثابتة - غالبًا ما تكون تكلفة الترخيص لمدة ثلاث سنوات أعلى من التوفير في التطبيق. يجب حساب التكلفة الإجمالية لمدة 24-36 شهرًا، وليس فقط سعر التطبيق لمرة واحدة.

**كم يجب تخصيصه من الميزانية للتغييرات أثناء المشروع؟**
في المشاريع المتوسطة إلى الكبيرة، من المعتاد تخصيص 10-15% من تكلفة خدمات التطبيق كاحتياطي لتغييرات النطاق. إذا كانت المنظمة تمر أيضًا بتغيير كبير في العمليات، وليس فقط رقمنة عملية موجودة، فمن المستحسن زيادة النسبة إلى حوالي 20%.

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

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

---

## كيف تختار شركة فعالة لتنفيذ Salesforce؟ دليلك المهني لاتخاذ القرار الصائب
URL: https://hpi.pro/ar/insights/choose-salesforce-implementation-company
عادةً ما يتأرجح اختيار شركة لتنفيذ Salesforce بين قطبين: الانبهار بعرض توضيحي مثير للإعجاب أو مجرد مقارنة للأسعار. عملية الاختيار الصحيحة تتطلب فحصًا للعمق المهني، والتوصيات الحقيقية، ونموذج التعاقد — قبل النظر إلى الرقم في ختام العرض.

## الإجابة المختصرة

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

تختبر عملية الاختيار الناضجة أربعة أمور بالترتيب: تحديد الحاجة الداخلية قبل التوجه إلى السوق، نوع المزود المناسب للنطاق والمخاطر، العمق المهني الذي يتم اختباره بما يتجاوز العرض التوضيحي، ونموذج التعاقد الذي يوزع المخاطر بشكل عادل. لقد كتبنا بالتفصيل عن إطار مقارنة عروض الأسعار والشروط في [مقارنة عروض Salesforce](/ar/insights/compare-salesforce-proposals)، وهنا ينصب التركيز على المرحلة التي تسبق ذلك – كيف نصل في الأساس إلى قائمة مرشحين مناسبة.

## المرحلة الأولى: ما المطلوب حقًا قبل التوجه إلى السوق

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

يحدد نطاق هذه الحاجة مباشرة نموذج التسعير المناسب – المشروع ذو نطاق العمل الواضح (Clear Scope) يناسب أكثر السعر الثابت (Fixed Price)، بينما المشروع الاستكشافي يناسب Time & Material. لقد توسعنا في ذلك في [نماذج تسعير مشاريع Salesforce](/ar/insights/salesforce-project-pricing-models). المنظمة التي تتجاوز مرحلة التحديد تدفع الثمن مرتين تقريبًا: مرة في عرض سعر مبالغ فيه يغطي عدم اليقين، ومرة في تغييرات في نطاق العمل (Scope Changes) في منتصف العمل.

## أنواع المزودين: البوتيك، العالمي، والمستقل

ينقسم السوق الإسرائيلي لخدمات Salesforce بشكل عام إلى ثلاث فئات، وكل منها يناسب ملف مخاطر مختلف.

**شركات البوتيك (Boutique Firms)** تضم عادة ما بين 5 إلى 30 موظفًا، وتتخصص في مجال واحد أو اثنين (المبيعات، الخدمة، Marketing Cloud) وتوفر وصولاً مباشرًا للمهندس المعماري الرئيسي طوال المشروع. الميزة هي المرونة والسعر التنافسي؛ العيب هو القدرة المحدودة – مشروع كبير يتطلب خمسة أشخاص بالتوازي قد يتعثر في قائمة الانتظار.

**شركات التكامل العالمية (Global Integrators)** تجلب منهجية موثقة، والقدرة على التوظيف السريع لموظفين إضافيين، وخبرة من قطاعات مماثلة في العالم. السعر أعلى بنسبة 30-60% مقارنة بشركات البوتيك، وفي كثير من الأحيان تكون هناك طبقة لإدارة المشروع تفصل بين العميل وفريق التنفيذ الفعلي – مما يبطئ الاتصال وقت الأزمات.

**العاملون المستقلون (Freelancers)** يقدمون أقل سعر بالساعة، لكنهم يعرضون للاعتماد على شخص واحد. إذا مرض المستقل، أو سافر إلى الخارج، أو انتقل إلى مشروع آخر، يتوقف العمل. يناسب بشكل أساسي الصيانة الروتينية أو المشاريع الصغيرة ذات نطاق العمل المحدد والمغلق.

## اختبار العمق المهني بما يتجاوز العرض التوضيحي (Demo)

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

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

## التحقق من المراجع الفعلية

مكالمة المراجع الجيدة لا تقتصر على سؤال "هل توصي بنا" – بل تنزل إلى التفاصيل التشغيلية. ثلاثة أسئلة تعطي معلومات حقيقية: هل اكتمل المشروع في حدود الميزانية والجدول الزمني الأصليين، وإذا لم يكن كذلك – ما هو الانحراف وما هو سببه؛ ماذا حدث عندما تم اكتشاف خطأ أو خلل (bug) في الإنتاج، وكم استغرق الأمر للإصلاح؛ وهل الفريق الذي نفذ المشروع لا يزال يعمل لدى المزود اليوم. معدل دوران الموظفين المرتفع في شركة تنفيذ هو علامة على أن المعرفة المكتسبة في المشروع السابق لم تعد متاحة.

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

## نموذج التعاقد: كيف يتم توزيع المخاطر

يحدد نموذج التعاقد من يتحمل المخاطر عندما ينحرف الواقع عن التخطيط – وهذا يحدث دائمًا تقريبًا.

| النموذج | متى يكون مناسبًا | المخاطر الرئيسية |
|---|---|---|
| Time & Material مفتوح | نطاق عمل غير ناضج، مرحلة الاكتشاف | تجاوز في عدد ساعات العمل بدون سقف |
| T&M بسقف (Cap) | نطاق عمل جزئي، مشروع أول مع مزود | يتطلب مراقبة مستمرة مقابل السقف |
| سعر ثابت (Fixed Price) | نطاق عمل مغلق وموثق جيدًا | قد يختصر المزود الزوايا للحفاظ على هامش الربح |
| ريتينر شهري (Monthly Retainer) | صيانة ودعم مستمر | نطاق العمل الفعلي لا يتطابق دائمًا مع الدفع |

للمشروع الأول مع مزود جديد، نموذج T&M بسقف غالبًا ما يكون الخيار الأكثر توازنًا: فهو يمنع المفاجأة المالية ولكنه لا يحفز المزود على تقليص الاختبارات. يجب النظر في السعر الثابت فقط بعد التحقق من نطاق العمل (Scope) مقابل سيناريوهات التشغيل الكاملة (End-to-End) الحقيقية، كما هو موضح في [اختيار مزود Salesforce](/ar/insights/salesforce-vendor-scorecard).

## بطاقة تقييم للمزودين (Scorecard)

تحول بطاقة التقييم المرجحة المقارنة الذاتية إلى عملية يمكن الدفاع عنها أمام الإدارة. الأوزان المقترحة لمشروع نموذجي:

| المعيار | الوزن | ما الذي يتم فحصه فعليًا |
|---|---|---|
| ملاءمة الخبرة للصناعة والعملية | 25% | مشاريع مماثلة في النطاق والقطاع، وليس فقط شعار معروف |
| عمق الفريق المقترح | 20% | سنوات الخبرة والوظيفة الفعلية للمهندس المعماري والمطورين |
| جودة عرض الأسعار ونطاق العمل (Scope) | 20% | تفصيل هيكل تقسيم العمل (WBS)، الافتراضات، الاستثناءات، ومخرجات القبول المكتوبة |
| المراجع ودوران الموظفين | 15% | محادثات مباشرة مع العملاء السابقين |
| نموذج التعاقد والعدالة التعاقدية | 10% | توزيع معقول للمخاطر، وليس مجرد سعر منخفض |
| التوافق الثقافي وتوفر الاتصال | 10% | سرعة الاستجابة، اللغة، المنطقة الزمنية، وتواتر التحديثات |

يحصل كل مزود على درجة 1-5 في كل بند، ويتم ضربها بالوزن. الفرق بين المزود الرائد والثاني في النتيجة الإجمالية لا يقل أهمية عن النتيجة نفسها – فرق أقل من 5 نقاط يبرر غالبًا اجتماع توضيح إضافي قبل القرار النهائي.

## العلامات الحمراء التي يجب تحديدها مبكرًا

- عرض أسعار بدون تفصيل الساعات حسب الموضوع، فقط "إجمالي" عام
- وعد بـ "حل كامل في Salesforce" لحاجة لم يتم فحصها بعمق أبدًا
- الرفض الكشف عن من سيقوم بالعمل فعليًا في الفريق
- الضغط للتوقيع بسرعة "لأن هذا السعر ساري المفعول هذا الأسبوع فقط"
- عدم وجود إشارة إلى حالة فشل أو مشروع واجه صعوبات
- عقد لا يحدد ما يعتبر "إنهاء" للمشروع وقبول نهائي

## ما الذي يجب طلبه للمشاهدة في الاجتماع: قائمة تحقق قصيرة

- ☐ حضور فريق التنفيذ الفعلي، وليس فقط مندوب مبيعات
- ☐ مثال ملموس لمشروع مماثل مع لقطات شاشة حقيقية
- ☐ تفصيل أولي لهيكل تقسيم العمل (WBS) مع افتراضات واستثناءات مكتوبة
- ☐ اسم ومعلومات اتصال لمرجعين على الأقل
- ☐ اقتراح لنموذج تعاقدي مع شرح سبب ملاءمته للنطاق
- ☐ وصف لعملية التعامل مع تغيير نطاق العمل (Scope Change) والخلل (bug) بعد الإطلاق

## سيناريو تنظيمي نموذجي

قامت شركة خدمات مالية متوسطة الحجم بتقييم ثلاثة عروض لـ Salesforce Sales Cloud: شركة بوتيك محلية، شركة تكامل عالمية، ومطور مستقل موصى به. كانت الإدارة تميل مبدئيًا إلى المطور المستقل بسبب السعر المنخفض بنسبة 40%، حتى كشفت مكالمة مرجعية أن مشروعه السابق توقف لمدة ثلاثة أسابيع عندما مرض. اختارت المنظمة أخيرًا شركة البوتيك، بعد أن أظهرت بطاقة التقييم (Scorecard) تفوقًا بـ 12 نقطة في فئة عمق الفريق وانخفاض دوران الموظفين.

واجه المشروع بالفعل تغييرًا في المتطلبات في منتصف الطريق – حاجة جديدة للتكامل مع نظام فواتير داخلي لم يُذكر في مرحلة العرض. بفضل نموذج T&M بسقف، تم التعامل مع التغيير كإضافة متفق عليها مسبقًا بدلاً من إعادة التفاوض على العقد بأكمله. يمكن للمؤسسات التي تتأرجح بين مزودين متشابهين وتريد إطار عمل إضافيًا للأسئلة الاستفادة من [اختيار مُكامل Salesforce](/ar/insights/questions-before-choosing-salesforce-integrator).

## كيف نقيس ما إذا كان الاختيار صحيحًا

| المقياس | ما الذي يتم فحصه | متى يتم الفحص |
|---|---|---|
| الالتزام بالجدول الزمني | الانحراف بالأيام بين الخطة والتنفيذ الفعلي | عند كل معلم رئيسي |
| استقرار الفريق | هل نفس الأشخاص تابعوا المشروع حتى النهاية | في نهاية كل مرحلة |
| التعامل مع الاستثناءات | وقت الاستجابة لخلل (bug) أو تغيير في المتطلبات | طوال المشروع |
| جودة التوثيق | هل يمكن نقل الصيانة إلى فريق آخر دون الاعتماد على شخص واحد | عند التسليم |

المقياس الذي لا يمكن فحصه فعليًا ليس مقياسًا. إذا لم يتضمن العقد تعريفًا واضحًا لما يعتبر "إنهاء" للمشروع، فمن المستحيل تقريبًا معرفة ما إذا كان الاختيار صحيحًا حتى يفوت الأوان للإصلاح. يمكن للمؤسسة التي ترغب في دعم خارجي في بناء عملية الاختيار نفسها أن تبدأ بـ [خدمة الاستشارات والتوصيف](/ar/consulting-discovery)، التي تساعد في تحديد نطاق العمل (Scope) وبناء بطاقة تقييم مخصصة (Customized Scorecard) حتى قبل التوجه إلى السوق.

## مصادر احترافية

- HPI Pro – استشارات وتوصيف — https://hpi.pro/consulting-discovery
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – خدمات Salesforce — https://hpi.pro/services

### أسئلة وأجوبة
**ما هو الفرق العملي بين شركة بوتيك وشركة مدمجة عالمية في مشروع Salesforce؟**
توفر شركات البوتيك عادةً وصولًا مباشرًا إلى المهندس المعماري والمطور الرئيسي، ودورات عمل قصيرة، وتكلفة ساعة عمل أقل، ولكن بقدرة محدودة للمشاريع الكبيرة. أما الشركات العالمية، فتقدم منهجيات منظمة وقدرة على التوسع (Scale)، ولكن بتكلفة أعلى وغالباً مع طبقات إدارية إضافية بين العميل والمنفذ الفعلي.

**كم يكلف عادةً التعاقد مع مستقل Salesforce مقارنةً بشركة متخصصة؟**
يتراوح سعر المستقل الجيد بين 250 و450 شيكل إسرائيلي جديد للساعة دون تكاليف إدارية، ولكنه يعرض المؤسسة لخطر الاعتماد على شخص واحد. تفرض الشركات رسوماً أعلى بنسبة 20-40 بالمائة في المتوسط، ولكنها توفر الدعم، والتأمين المهني، واستمرارية العمل حتى عندما يغادر الموظف في منتصف المشروع.

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

**ما هو نموذج التعاقد الموصى به لمشروع Salesforce الأول في المؤسسة؟**
غالباً ما يوصى بنموذج الوقت والمواد (Time & Material) مع سقف (Cap) للمرحلة الأولى، والانتقال إلى سعر ثابت فقط بعد استقرار النطاق (Scope) حول سيناريوهات شاملة ومحددة. السعر الثابت لنطاق غير واضح يشجع المورد على اختصار الجوانب لحماية ربحيته.

**ما هو الحد الأدنى لحجم فريق المورد المطلوب لمشروع Salesforce متوسط الحجم؟**
لمشروع يتراوح حجمه بين 3-6 أشهر، يجب التأكد من وجود شخصين على الأقل لديهما معرفة كافية ليحل أحدهما محل الآخر: مهندس معماري (Architect) أو قائد فريق (Lead) ومطور إضافي. فريق مكون من شخص واحد فقط يعمل بشكل جيد حتى اللحظة التي يمرض فيها، أو يكون في إجازة، أو يغادر.

---

## كم يستغرق مشروع Salesforce؟ الجداول الزمنية والتبعيات وما يؤخر العمل حقًا
URL: https://hpi.pro/ar/insights/salesforce-project-timeline
يستغرق مشروع Salesforce النموذجي ما بين ستة أسابيع وتسعة أشهر، لكن النطاق الزمني المقدم في عرض الأسعار لا ينبع أبدًا من حجم التطوير، بل ينبع من وتيرة اتخاذ القرارات ومدى جاهزية البيانات ومدى توفر المتخصصين في المؤسسة.

## الإجابة المختصرة

لا توجد إجابة موحدة للسؤال عن المدة الزمنية لمشروع Salesforce، لكن هناك نطاقات واقعية ينبغي الإلمام بها قبل التوقيع على أي عرض سعر. قد يستغرق مشروع "Quick Win" مركّز – مثل أتمتة واحدة، كائن مخصص، أو تقرير متقدم – مدة تتراوح عادةً بين 3 و 4 أسابيع. أما التنفيذ الكامل لـSales Cloud لفريق مبيعات متوسط الحجم، فتتراوح مدته بين 8 و 14 أسبوعًا. وقد يمتد مشروع متعدد الـClouds (Multi-Cloud) مع تكاملات لأنظمة ERP وأنظمة خارجية إلى 6-9 أشهر، وقد يتجاوز ذلك في حال تعدد الأقسام التجارية.

العامل الحاسم الذي يحدد النطاق الزمني الفعلي ليس حجم التعليمات البرمجية، بل سرعة اتخاذ القرار داخل المنظمة: من هو مالك العملية (Owner) لكل إجراء، كم يستغرق الموافقة على النطاق (Scope)، ومتى تكون البيانات جاهزة بالفعل للاختبار. قبل تحديد تاريخ التشغيل الفعلي (Go Live)، يُنصح بالاطلاع على الدليل الكامل لـ[تنفيذ Salesforce في المنظمات](/ar/insights/salesforce-implementation-guide)، والذي يفصل مراحل العمل وراء كل أسبوع من الجدول الزمني.

## لماذا تختلف النطاقات الزمنية بشكل كبير بين المشاريع المتشابهة ظاهريًا

منظمتان تطلبان "تنفيذ Sales Cloud لفريق مبيعات مكون من 20 فردًا" قد تتلقيان عروضًا تختلف بثلاثة أضعاف في مدة التنفيذ، وكلا العرضين قد يكونان صحيحين. وهذا الاختلاف ينبع دائمًا تقريبًا مما لم يُذكر في وثيقة المتطلبات: عدد مصادر البيانات الموجودة، مدى تعقيد عمليات الموافقة الداخلية، ومدى سرعة اتخاذ المنظمة للقرارات التي تمس أكثر من قسم واحد.

المشروع الذي يضم مالك منتج (Product Owner) واحدًا لديه سلطة توقيع على النطاق (Scope) يتقدم بشكل أسرع بكثير من المشروع الذي يتطلب كل تغيير فيه موافقة لجنة توجيهية. هذا ليس اختلافًا تقنيًا، بل هو اختلاف تنظيمي يؤثر مباشرة على الجدول الزمني، وأحيانًا أكثر من أي قرار معماري آخر.

## النطاقات الزمنية حسب نوع المشروع

الجدول التالي يقدم تقديرات لأسابيع العمل الفعلية (Elapsed، وليس Effort) حسب المرحلة ونوع المشروع. هذه هي نطاقات متوسطة مستمدة من التجربة العملية، وليست التزامًا قاطعًا؛ فكل مشروع محدد يتطلب تقييمًا منفصلاً.

| المرحلة | Quick Win / إضافة محددة | تنفيذ قياسي (Cloud واحد) | مشروع Multi-Cloud مع تكاملات |
| :------- | :--------------------- | :----------------------- | :-------------------------- |
| الكشف والتوصيف | 3-5 أيام | 1.5-3 أسابيع | 3-6 أسابيع |
| الهندسة المعمارية ونموذج البيانات | 2-3 أيام | 1-2 أسابيع | 3-5 أسابيع |
| البناء والإعدادات | 1-2 أسابيع | 3-6 أسابيع | 8-16 أسبوعًا |
| ترحيل البيانات | عادة لا يلزم | 1-2 أسابيع | 3-6 أسابيع |
| التكاملات | عادة لا يلزم | 1-3 أسابيع | 4-10 أسابيع |
| UAT والإصلاحات | 2-4 أيام | 2-3 أسابيع | 3-5 أسابيع |
| Go Live ورعاية ما بعد التشغيل (Hypercare) | 2-3 أيام | 1-2 أسابيع | 2-4 أسابيع |
| **إجمالي المدة الكلية** | **3-4 أسابيع** | **8-14 أسبوعًا** | **24-40 أسبوعًا** |

من المهم التذكير بأن الأرقام في الجدول تفترض توافرًا معقولًا لأصحاب المصلحة وبيانات بحجم معقول. أي من هذه الافتراضات، عند عدم تحققها، يمكن أن تضيف أسابيع كاملة إلى كل مرحلة.

## ما الذي يعيق المشاريع حقًا - ليس ما تعتقده

عندما يخرج مشروع Salesforce عن الجدول الزمني، فإن السبب الأكثر شيوعًا ليس التعقيد التقني، بل واحد من خمسة أمور:

- **قرارات معلقة لا تُتخذ في الوقت المناسب** - سؤال تجاري يبقى مفتوحًا لمدة أسبوعين لأنه لا يوجد من يمتلك صلاحية الإجابة عليه، بينما ينتظر الفريق التقني.
- **بيانات غير جاهزة بالفعل** - مصدر بيانات "موجود وجاهز" يتبين أنه يحتوي على تكرارات، حقول مفقودة، أو مصدرين متضاربين.
- **توفر موظفي المحتوى وأصحاب العمليات** - موظفو المبيعات أو الخدمة الذين من المفترض أن يقوموا بالمراجعة والموافقة يكونون مشغولين بالعمل اليومي ولا يتم تحريرهم مسبقًا.
- **التكاملات مع طرف ثالث** - الاعتماد على مورد خارجي، أو على API له قيود، أو على فريق IT داخلي لا يعمل بنفس الوتيرة.
- **اختبار قبول المستخدم (UAT) الذي يتعثر** - لأن الاختبارات تبدأ فقط عندما يكون النظام "شبه جاهز"، وليس بالتوازي مع البناء.

من بين كل هذه العوامل، تعد القرارات المعلقة هي الأكثر سهولة في التجنب والأكثر شيوعًا في الواقع. المنظمة التي تحدد مسبقًا من يوافق على ماذا، وخلال كم يوم يُعتبر الرد "تأخيرًا"، توفر في المتوسط أسبوعين إلى ثلاثة أسابيع في مشروع متوسط الحجم. وقد نوقش هذا الموضوع بالتفصيل أيضًا في [MVP Salesforce](/ar/insights/salesforce-mvp-scope)، والذي يشرح كيفية تقليل عدد القرارات المعلقة من البداية من خلال تحديد إصدار أول أصغر.

## المسار الحرج: ما الذي يحدد التاريخ النهائي

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

1.  **الموافقة على نموذج البيانات والصلاحيات** - طالما لم يتم إغلاق هذا الأمر، لا يمكن البدء في التكامل أو الترحيل بثقة.
2.  **جاهزية مصدر البيانات للترحيل** - حتى لو كان التطوير جاهزًا، لا يمكن الانتقال إلى الإنتاج دون بيانات نظيفة ومتحقق منها.
3.  **توفر أصحاب العمليات لـUAT** - غالبًا ما يكون هذا هو أضيق عنق زجاجة، لأنه يتعلق بأشخاص لديهم وظيفة بدوام كامل في المنظمة وليس وقت فريق المشروع.

يؤدي تأخير لمدة أسبوع في أحد هذه النقاط الثلاث إلى تأخير مباشر في تاريخ التشغيل الفعلي (Go Live)، حتى لو التزم باقي الفريق بالجداول الزمنية. لذلك، يتابع مكتب إدارة المشاريع (PMO) الجيد البنود الموجودة في المسار الحرج بشكل خاص، وليس فقط النسبة المئوية لإنجاز المشروع بشكل عام. وتتجلى هذه الفكرة عمليًا في عملية [UAT لـSalesforce](/ar/insights/salesforce-uat-guide)، التي توضح كيفية تخطيط مرحلة الاختبارات بحيث لا تصبح هي نفسها عنق زجاجة إضافيًا.

## النهج التدريجي مقابل النهج الشامل: كيف يؤثر الاختيار على الجدول الزمني

تُعد مسألة ما إذا كان يجب الإطلاق دفعة واحدة (Big Bang) أو على مراحل (Phased) أحد أهم القرارات التي تؤثر على الجدول الزمني، وليس فقط على المخاطر التشغيلية.

النهج **Big Bang** يناسب المشاريع ذات النطاق الصغير نسبيًا، حيث توجد تبعية وثيقة بين المكونات (على سبيل المثال، عملية Lead-to-Cash موحدة لا يمكن تقسيمها)، وعندما تفضل المنظمة استثمار وقت مركز بدلاً من فترة انتقالية طويلة. الميزة من حيث الجدول الزمني: تاريخ إطلاق واضح ومحدد. العيب: أي تأخير في مكون واحد يوقف تاريخ الإطلاق بالكامل.

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

كقاعدة عامة، إذا كان المشروع يتوقع أن يتجاوز 4 أشهر أو يشمل أكثر من قسمين مستقلين، فإن النهج **Phased** دائمًا ما يقلل الوقت اللازم لتحقيق قيمة أعمال أولى، حتى لو كانت المدة الإجمالية للمشروع مماثلة أو أطول.

## كيف يمكن تقصير الجدول الزمني دون المساس بالجودة

هناك طرق حقيقية للتقصير، وهناك اختصارات تبدو وكأنها توفير للوقت ولكنها في الواقع تؤجل التكلفة إلى مرحلة الرعاية المكثفة (Hypercare) أو إلى العام التالي.

**ما يقصر بالفعل:**

- تحديد نطاق (Scope) صارم للإصدار الأول، مع قائمة "ليس الآن" واضحة ومُعتمدة مسبقًا.
- تعيين مالك منتج (Product Owner) واحد يتمتع بسلطة حقيقية للموافقة أو الرفض، للقضاء على تأخيرات اللجان.
- بدء العمل على تنظيف البيانات بالتوازي مع عملية التوصيف، وليس بعدها.
- تخصيص وقت مسبق في تقويم أصحاب العمليات لاختبار قبول المستخدم (UAT)، وليس عند وصول المرحلة.
- استخدام المكونات القياسية لـSalesforce بدلاً من التطوير المخصص أينما أمكن.

**ما يبدو كاختصار ولكنه ليس كذلك في الواقع:**

- تخطي اختبار قبول المستخدم (UAT) بالكامل والانتقال مباشرة إلى "اختبار المطورين" – يوفر أسبوعًا وينتج شهرًا من إصلاحات مرحلة الإنتاج (Production).
- ترحيل البيانات دون تنظيف، بنية "التنظيف لاحقًا" – تصبح البيانات غير النظيفة مشكلة في التبني.
- ضغط التدريب في يوم واحد قبل التشغيل الفعلي (Go Live) – يؤدي إلى التحايل على النظام في الأسابيع الأولى.

عندما يتعلق الأمر بمشروع يكون فيه الجدول الزمني حاسمًا حقًا للعمل، يركز الدعم المهني من خلال [خدمة تنفيذ Salesforce](/ar/salesforce-implementation) بالضبط على هذا المزيج – أية اختصارات آمنة وأيها يؤجل التكلفة إلى الأمام.

## سيناريو مؤسسي نموذجي

خططت شركة لوجستية لتنفيذ Service Cloud خلال 10 أسابيع، بهدف الانتهاء قبل موسم الذروة. في الأسبوع الثاني، تبين أن نظام ERP الحالي غير جاهز لتوفير API مستقر، وأن فريق IT الداخلي متاح فقط بنصف دوام للمشروع. بدلاً من دفع المشروع بأكمله إلى الأمام، انتقل الفريق إلى نهج Phased (مراحلي): شملت المرحلة الأولى توجيه الطلبات الأساسية وتحديد اتفاقيات مستوى الخدمة (SLA)، دون تكامل مع نظام ERP، وتم الإطلاق في غضون 7 أسابيع - أي قبل ثلاثة أسابيع من موسم الذروة. تم تأجيل التكامل الكامل إلى مرحلة ثانية، والتي تزامنت مع موسم الذروة نفسه وتم إطلاقها بعد شهرين.

الدرس المركزي: عندما تظهر عقبة حقيقية في المسار الحرج، لا يكون السؤال الصحيح "كيف نضغط الوقت المتبقي؟" بل "ما الذي يمكن فصله في مرحلة منفصلة دون المساس بالقيمة الفورية؟". تفاصيل تخطيط الرعاية المكثفة (Hypercare) بعد كل مرحلة من هذه المراحل موضحة في [Salesforce Hypercare](/ar/insights/salesforce-hypercare-plan)، والتي توضح كيفية استقرار كل مرحلة قبل الانتقال إلى التالية.

## قائمة تحقق لتخطيط جدول زمني واقعي

- [ ] تم تحديد نطاق (Scope) مغلق للإصدار الأول، بما في ذلك قائمة "ليس الآن".
- [ ] تم تعيين مالك منتج (Product Owner) واحد يتمتع بسلطة الموافقة.
- [ ] تم التحقق من جودة البيانات في المصدر، وليس فقط افتراض أنها "جاهزة".
- [ ] تم تحرير وقت أصحاب العمليات مسبقًا لأوقات اختبار قبول المستخدم (UAT) المخطط لها.
- [ ] تم فحص التكاملات مع الجهات الخارجية مقابل واجهة برمجة التطبيقات (API) وتوافر المورد.
- [ ] تم اتخاذ قرار صريح: نهج "Phased" أو "Big Bang"، ولماذا.
- [ ] يتم تحديد ومراقبة المسار الحرج بشكل منفصل عن النسبة المئوية الكلية للإنجاز.
- [ ] يوجد هامش زمني مدمج بنسبة 10-15% للجدول الزمني، وليس وعدًا بـ"كل شيء في الوقت المحدد".
- [ ] تم تدريب المستخدمين النهائيين قبل التشغيل الفعلي (Go Live)، وليس في اليوم السابق له.
- [ ] تم تحديد خطة رعاية ما بعد التشغيل (Hypercare) مسبقًا مع معيار للخروج.

## مصادر احترافية

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – تنفيذ Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – منهجية العمل — https://hpi.pro/methodology

### أسئلة وأجوبة
**ما الفرق في مدة المشروع بين Sales Cloud الأساسي و Service Cloud مع التكاملات؟**
يستغرق تطبيق Sales Cloud الأساسي لفريق مبيعات واحد، بدون تكاملات معقدة، عادةً من 6 إلى 10 أسابيع. بينما يتطلب Service Cloud مع التوجيه، واتفاقيات مستوى الخدمة (SLA)، و2-3 تكاملات (ERP، الاتصالات الهاتفية، نظام الفواتير) عادةً من 12 إلى 20 أسبوعًا، نظرًا لتعقيد تخطيط عمليات الخدمة وتعقيد الصلاحيات.

**كم يستغرق فعليًا مرحلة البيانات من إجمالي الجدول الزمني؟**
في المشاريع ذات مصدر بيانات واحد ونظيف، يستغرق تنظيف البيانات وترحيلها حوالي 10% من الوقت الإجمالي. عندما يكون هناك مصدران أو أكثر من البيانات مع وجود تكرارات، ترتفع النسبة إلى 25-30%، لأن كل جولة فحص جودة تكشف عن المزيد من الاستثناءات التي تتطلب قرارًا تجاريًا وليس مجرد إصلاح تقني.

**هل من الأفضل جدول زمني ثابت مسبقًا أم تقدير يتم تحديثه باستمرار؟**
يكون الجدول الزمني الثابت مسبقًا مناسبًا فقط عندما يكون نطاق العمل مغلقًا تمامًا ولا توجد تبعيات على تكاملات خارجية. في معظم المشاريع، يتم تقديم نطاق (على سبيل المثال 10-14 أسبوعًا) يتم تحديثه في نهاية كل Sprint، لأن تحديد الموعد مبكرًا جدًا يؤدي عادةً إلى تجاوزات غير ظاهرة لاحقًا بدلاً من الالتزام الفعلي بالهدف.

**ماذا يحدث للجدول الزمني عند اكتشاف الحاجة إلى تكامل غير مخطط له في منتصف المشروع؟**
في المشاريع ذات النهج المرحلي (Phased)، يمكن تأجيل التكامل إلى المرحلة التالية دون إيقاف العمل المتبقي، وعادةً ما يستغرق ذلك 2-4 أسابيع إضافية لمرحلة منفصلة. أما في النهج الشامل (Big Bang)، فإن هذا الاكتشاف غالبًا ما يوقف العملية بأكملها، حيث من المفترض أن تطلق جميع المكونات معًا.

**كم من الوقت يجب تخصيصه لاختبار قبول المستخدم (UAT) لضمان عدم تحوله إلى عنق الزجاجة للمشروع؟**
للمشروع متوسط الحجم، يوصى بتخصيص 2-3 أسابيع لاختبار قبول المستخدم (UAT)، بما في ذلك جولة واحدة من الإصلاحات. المشكلة الشائعة ليست مدة UAT نفسها، بل مدى توفر أصحاب العمليات - إذا لم يتم تحريرهم من العمل اليومي مسبقًا، فإن المرحلة التي يفترض أن تستغرق أسبوعين تمتد إلى شهر ونصف.

---

## تطبيق Salesforce في الشركات الكبرى: المبادئ، الحوكمة، والمخاطر
URL: https://hpi.pro/ar/insights/enterprise-salesforce-implementation
عند تجاوز 500 مستخدم، تتجاوز المشكلة مرحلة 'كيف نبني' لتصبح 'من يقرر'، 'من يوافق على التغييرات'، و'كيف تُنسق الخطط المتوازية'. يستعرض المقال نموذج الحوكمة، اختيار Single-org مقابل Multi-org، وأنماط الفشل الشائعة.

## خلاصة موجزة

في المؤسسات التي تضم عشرات المستخدمين، يعتبر تنفيذ Salesforce عملية تهيئة وتكييف بالأساس. أما في المؤسسات التي تضم 500 مستخدم أو أكثر، وتنتشر عبر عدة وحدات أعمال وأحيانًا عدة دول، تنتقل المشكلة الجوهرية إلى مكان آخر: من يوافق على التغيير، وكيف لا تتداخل الفرق المتوازية في عمل بعضها البعض، وهل يدعم هيكل Org التوسع المستقبلي أم يعيقه. بدون حوكمة (Governance) منظمة، يصبح كل تحسين جزئي خطرًا على استقرار المؤسسة بأكملها.

يتناول هذا المقال الطبقة الإدارية التي تعلو المشروع الفردي: هيكل القرارات، الاختيار بين Single-org وِ Multi-org، تنسيق الإصدارات (Release Coordination)، الأمن والامتثال (Security & Compliance)، التوطين العالمي (Global Localization)، والاعتمادية بين البرامج المتوازية في مكتب إدارة المشاريع (PMO). الخلفية الكاملة لمراحل التنفيذ الأساسية متاحة في [تنفيذ Salesforce في المؤسسات](/ar/insights/salesforce-implementation-guide)، وهذا المقال الحالي يستند عليها على مستوى النطاق المؤسسي.

## لماذا يغير النطاق قواعد اللعبة

في مشروع يضم 50 مستخدمًا، يمكن إدارة التغييرات من خلال محادثة بين شخصين. لكن في مشاريع تضم 500 مستخدم أو أكثر، غالبًا ما تعمل عدة فرق تطوير، وعدة وحدات أعمال ذات أولويات مختلفة، وأحيانًا عدة مزودي حلول متوازيين. تغيير بسيط في كائن مشترك (Shared Object) — مثل إضافة حقل إجباري، أو تعديل قاعدة تحقق (Validation Rule) — يمكن أن يعطل سير عمل وحدة أخرى لم تكن على دراية بالتغيير.

لذلك، على النطاق المؤسسي، تسبق ثلاثة أسئلة أي نقاش فني: من هو المالك لكل كائن وعملية رئيسية؟ ما هي الآلية التي تتحقق من التأثيرات المشتركة بين الفرق قبل النشر (Deploy)؟ ومن هو المخول بإيقاف إصدار إذا تم اكتشاف مخاطرة؟ المؤسسات التي تتجاهل هذه الأسئلة تبني "بسرعة" في البداية وتدفع الثمن لاحقًا بتوقفات متكررة وعمليات تراجع غير مخطط لها (Unplanned Rollbacks) بعد عام أو عامين.

## الحوكمة (Governance) ومجلس استشاري التغيير (Change Advisory Board)

مجلس استشاري التغيير ليس لجنة بيروقراطية — بل هو آلية تمنع وضعًا يؤدي فيه تغيير يبدو صغيرًا لوحدة واحدة إلى الإضرار بوحدة أخرى. الهيكل الموصى به يتضمن ثلاثة مستويات للموافقة: تغيير التهيئة الروتيني (Low risk) الذي يتم الموافقة عليه على مستوى الفريق؛ التغيير الذي يؤثر على نموذج بيانات مشترك أو تكامل (Medium risk) والذي يرفع إلى اجتماع CAB الأسبوعي؛ والتغيير المعماري (مثل تغيير نموذج المشاركة Sharing Model أو الانتقال إلى Multi-org) الذي يتطلب موافقة اللجنة التوجيهية (Steering Committee) على مستوى المدير التنفيذي للمعلومات (CIO).

في الواقع، إن CAB الأكثر فعالية الذي رأيناه ليس ذا الشفافية الوثائقية الأعلى، بل هو الذي يمتلك اتفاقية مستوى خدمة (SLA) واضحة: طلب التغيير ذو المخاطر المتوسطة (Medium risk) يتلقى إجابة خلال 3-5 أيام عمل، وليس "في الاجتماع القادم الذي سيعقد في وقت ما". عندما لا يتم الالتزام بـ SLA، تتعلم الفرق تجاوز العملية، وهذه هي اللحظة التي تنهار فيها الحوكمة فعليًا حتى لو كانت موجودة على الورق.

### جدول المسؤوليات (RACI) للحوكمة المؤسسية

| مجال القرار | راعي الأعمال (Business Sponsor) | مهندس الحلول المؤسسية (Enterprise Architect) | قائد الإصدار/العمليات (Release/DevOps Lead) | الأمن والامتثال (Security & Compliance) | مكتب إدارة المشاريع (PMO) |
| --- | --- | --- | --- | --- | --- |
| هيكل Org (Single/Multi-org) | مستشار (Consulted) | مسؤول مباشر (Accountable) | مُطْلَع (Informed) | مستشار (Consulted) | مُطْلَع (Informed) |
| الموافقة على التغيير على مستوى الكائن المشترك | مُطْلَع (Informed) | مسؤول (Responsible) | مستشار (Consulted) | مستشار (Consulted) | مُطْلَع (Informed) |
| جدولة الإصدار (Release Schedule) ومسار الإصدار (Release train) | مُطْلَع (Informed) | مستشار (Consulted) | مسؤول مباشر (Accountable) | مُطْلَع (Informed) | مسؤول (Responsible) |
| سياسة الصلاحيات والامتثال | مستشار (Consulted) | مستشار (Consulted) | مُطْلَع (Informed) | مسؤول مباشر (Accountable) | مُطْلَع (Informed) |
| الاعتمادية بين البرامج المتوازية | مسؤول (Responsible) | مستشار (Consulted) | مُطْلَع (Informed) | مُطْلَع (Informed) | مسؤول مباشر (Accountable) |
| التوطين لسوق جديد | مسؤول مباشر (Accountable) | مسؤول (Responsible) | مُطْلَع (Informed) | مستشار (Consulted) | مسؤول (Responsible) |

هذا الجدول ليس قالبًا ثابتًا؛ يجب أن يتناسب مع الهيكل التنظيمي الفعلي. النقطة المهمة هي أن "مسؤول مباشر" (Accountable) يظهر مرة واحدة فقط في كل صف — عندما يتشارك طرفان ملكية كاملة لنفس القرار، فهذه هي العلامة الأولى على أن الهيكل سيؤدي إلى تأخيرات.

## Single-org مقابل Multi-org

هذا هو أحد أغلى القرارات التي يمكن تصحيحها بأثر رجعي. يتيح Single-org مع فصل دقيق للصلاحيات (Profiles، Permission Sets، Record Types، و Sharing Rules) تقريرًا واحدًا عن المؤسسة بأكملها، وصيانة أقل للتكاملات، وتكلفة ترخيص أقل. تبدأ المشكلة عندما تطلب وحدات الأعمال المختلفة ترددات إصدار مختلفة تمامًا، أو عندما تكون هناك متطلبات تنظيمية تفرض فصل البيانات ماديًا.

يحل Multi-org مشكلة الفصل، ولكنه يخلق مشكلة جديدة: كل تقرير مشترك عبر المؤسسات يتطلب طبقة ذكاء أعمال (BI) منفصلة أو حلًا مثل Data Cloud، ويجب بناء كل عملية عالمية (على سبيل المثال Lead-to-Cash) مرتين أو إدارتها عبر MuleSoft / آلية مزامنة. في المؤسسات التي اختبرت كلا المسارين، يميل الانتقال من Single-org إلى Multi-org بعد أن تصبح المؤسسة كبيرة إلى اتخاذ 9-14 شهرًا ويشمل ترحيل بيانات معقد – لذلك يُفضل اتخاذ القرار مبكرًا، حتى لو كان ذلك يعني التعايش مع حل وسط مؤقت في فصل الصلاحيات.

## مسار الإصدار (Release train) وعمليات DevOps على مستوى المؤسسة

عندما تعمل عدة فرق في نفس Org، يتوقف إصدار "متى جاهز" عن العمل. النموذج الذي يؤدي بشكل جيد على النطاق المؤسسي هو Release Train: تكرار ثابت (من أسبوعين إلى شهر)، مصدر واحد للحقيقة (Source of Truth) في التحكم في الإصدارات، وخط أنابيب (Pipeline) يحدد التعارضات في Metadata بين الفرق قبل يوم النشر نفسه، وليس في نفس اليوم.

العناصر العملية التي يجب تضمينها:

- بيئة تكامل مشتركة (Shared Integration environment) حيث تدمج جميع الفرق قبل الانتقال إلى اختبار قبول المستخدم (UAT).
- نافذة تجميد الكود (Code Freeze) ثابتة (عادة 48-72 ساعة) قبل كل إصدار.
- اختبار الانحدار (Regression Testing) التلقائي الذي يعمل على السيناريوهات الأساسية لكل وحدة أعمال، وليس فقط على التغيير الجديد.
- سياسة واضحة: الفريق الذي لم يلتزم بوقت الدمج سينتقل إلى القطار التالي ولن يعرقل الجميع.

التوسع في البنية التحتية لـ Sandbox وعمليات Pipeline مفصل في [بيئات الاختبار Salesforce DevOps Sandboxes](/ar/insights/salesforce-sandbox-devops-strategy)، حيث يتم عرض الهيكل الموصى به للبيئات بين Dev و Production.

## الأمن والامتثال على نطاق مؤسسي

مع وجود أكثر من 500 مستخدم، يصبح نموذج الصلاحيات أصلًا حاسمًا في حد ذاته. من الأخطاء الشائعة بناء Profile جديد لكل تغيير بسيط، مما يؤدي في غضون عام أو عامين إلى مئات الـ Profiles التي لا يتذكر أحد المنطق وراءها. النهج الأكثر فعالية هو: Profile محدود حسب الدور الواسع، ومجموعات صلاحيات (Permission Sets) قابلة للتعديل تُضاف حسب الحاجة المحددة.

في المؤسسات العالمية، تُضاف طبقة امتثال (Compliance): اللائحة العامة لحماية البيانات (GDPR) في أوروبا تفرض القدرة على الحذف وتوثيق الموافقة، تتطلب لوائح الخصوصية في إسرائيل تسجيل قاعدة بيانات، وقد تُلزم مؤسسات الرعاية الصحية أو المالية في الولايات المتحدة بـ HIPAA أو SOX. المعنى العملي: تشفير على مستوى الحقل للبيانات الحساسة، سجلات الوصول إلى السجلات (Field Audit Trail أو Shield)، وعملية توثيق تُظهر من وصل إلى ماذا ومتى — ليس فقط من يُصرح له بالوصول.

## العولمة والتوطين (Globalization and Localization)

يواجه التنفيذ الذي يعمل في عدة دول ثلاث مشكلات متكررة: العملات والتواريخ (Multi-Currency وتنسيق التاريخ حسب Locale)، اللغة في الواجهة والتقارير (Translation Workbench لا يغطي دائمًا الحقول المخصصة)، وعمليات الموافقة التي تتعارض مع قوانين العمل أو الضرائب المحلية. الفريق الذي يخطط للتوطين كإضافة في نهاية المشروع يكتشف عادةً أنه يتطلب تغييرًا في نموذج البيانات نفسه، وليس مجرد ترجمة نصوص.

## مكتب إدارة المشاريع (PMO) والاعتمادية بين البرامج المتوازية

في مؤسسة كبيرة، نادرًا ما يسير مشروع Salesforce بمفرده. بالتوازي، تُنفذ برامج ERP، مشروع مستودع البيانات (Data Warehouse)، وأحيانًا دمج شركتين. PMO الذي لا يخطط للاعتمادية بين البرامج يكتشف في مرحلة متقدمة أنه و ERP يبنيان في نفس الوقت مصدرين مختلفين للحقيقة لنفس بيانات العميل.

الأداة العملية هنا هي مصفوفة اعتمادية تُحدث شهريًا: لكل برنامج، ما هي البيانات التي "يقودها" (Source of Truth)، وما هي البيانات التي يستهلكها فقط. عندما يطالب برنامجين بملكية نفس الحقل، يكون PMO هو الجهة التي يجب أن تفصل — لا تترك الأمر ليحل "في الميدان" بين مطورين اثنين.

## أنماط الفشل النموذجية التي تعلو 500 مستخدم

| نمط الفشل | كيف يظهر عمليًا | إجراء وقائي |
| --- | --- | --- |
| انتشار الـ Profiles (Profile Sprawl) | مئات الـ Profiles المتطابقة تقريبًا، لا أحد متأكد مما هو مسموح لمن | الانتقال التدريجي إلى مجموعات الصلاحيات المعيارية (Modular Permission Sets) |
| إصدار "خاص" بالفريق | فريق واحد يذهب إلى Production دون المرور بـ CAB، مما يعطل عملية أخرى | قطار إصدار إلزامي يتضمن تجميد كود مشترك (Shared Code Freeze) |
| مصدران للحقيقة لنفس البيانات | ERP و CRM كل منهما "مالك" لبيانات العملاء | PMO يحدد مصدر حقيقة واحدًا لكل مجال بيانات |
| صلاحيات واسعة جدًا "لتجنب العرقلة" | تسرب معلومات حساسة بين وحدات الأعمال | مبدأ أقل الامتيازات (Least Privilege) حسب الدور، تدقيق فصلي |
| التوطين كإضافة متأخرة | ترجمة جزئية، تنسيق تاريخ خاطئ، تقارير معطلة في منطقة واحدة | تخطيط للlocale والعملة في نموذج البيانات من اليوم الأول |
| Sandbox غير متزامن | تعمل الاختبارات في Sandbox وتفشل في Production بسبب اختلاف التهيئة | تحديث مجدول وسياسة بيانات أولية (Seed Data) موحدة |

## عملية عمل موصى بها للتنفيذ على نطاق مؤسسي

### 1. إنشاء لجنة توجيهية (Steering Committee) ومجلس استشاري للتغيير (Change Advisory Board) قبل بدء البناء

قبل كتابة سطر الكود الأول، يجب تعيين راعٍ على مستوى الإدارة، وتحديد مستويات الموافقة الثلاثة للتغيير، والاتفاق على اتفاقية مستوى خدمة (SLA) للاستجابة. بدون ذلك، تحدد الفرق الأولى التي تبدأ العمل سابقة لكل من يأتي بعدها.

### 2. اتخاذ قرار مبكر بشأن Single-org مقابل Multi-org وتوثيق السبب

يجب أن يستند هذا القرار إلى المتطلبات التنظيمية الفعلية وتردد الإصدار المطلوب، وليس على التفضيل التقني. يجب توثيق البديل الذي تم رفضه والشرط الذي سيؤدي إلى إعادة النظر (على سبيل المثال، الاستحواذ على شركة جديدة).

### 3. بناء مسار الإصدار (Release Train) قبل وجود أكثر من فريق واحد

تكرار ثابت، بيئة تكامل مشتركة، وعملية تحديد التعارضات قبل يوم الإصدار. يتم تعريف فريق المشروع الأساسي في [فريق مشروع Salesforce](/ar/insights/salesforce-project-team-roles)، ولكن على نطاق مؤسسي، يتطلب الأمر أيضًا دورًا مخصصًا لمدير الإصدار (Release Manager).

### 4. رسم خريطة لنموذج الصلاحيات ومتطلبات الامتثال حسب منطقة التشغيل

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

### 5. توثيق الاعتمادية بين البرامج في PMO وتحديثها شهريًا

مصفوفة اعتمادية حية، لا وثيقة تُكتب مرة واحدة في بداية المشروع. يتم التحقق من أي تغيير في الجدول الزمني لبرنامج واحد مقابل تأثيره على البرامج الأخرى.

### 6. تنفيذ مشروع تجريبي (Pilot) في وحدة أعمال واحدة قبل الإطلاق المؤسسي الكامل

شريحة رأسية كاملة (Vertical Slice)، بما في ذلك الصلاحيات الحقيقية والتكاملات، تتيح تحديد مشكلات الحوكمة والإصدار قبل تضاعفها في عشرات الوحدات. يتم عرض فهم اللبنات الأساسية على مستوى قصص المستخدمين في [قصص المستخدمين Salesforce User Stories](/ar/insights/salesforce-user-stories-backlog).

### 7. التوسع على مراحل (Waves) مُراقبة مع القياس بين كل موجة وأخرى

تُقاس كل موجة إطلاق (Rollout Wave) مقابل خط أساس (Baseline) قبل التوسع إلى الموجة التالية. إذا كشفت الموجة الأولى عن مشكلة في الحوكمة، يتم الإصلاح قبل المتابعة — لا يُجرى التوسع أثناء الإصلاح.

## سيناريو مؤسسي نموذجي

حاولت شركة تأمين تضم 1,200 مستخدم في ثلاث دول تنفيذ Salesforce بوجود فريقين تطوير متوازيين – أحدهما للمبيعات والآخر للخدمة – بدون CAB نشط. بعد خمسة أشهر، كان الفريقان يغيران نفس كائن العميل كل أسبوع، وكانت عمليات الاختبار تفشل بشكل متقطع دون أن يعرف أحد السبب. لم يكن الحل تقنيًا: أنشأت المؤسسة CAB أسبوعيًا مع اتفاقية مستوى خدمة (SLA) مدتها 3 أيام، وعينت مالكًا وحيدًا للكائن (Object Owner) لكل كيان مركزي، وانتقلت إلى مسار إصدار (Release Train) نصف أسبوعي مع بيئة تكامل مشتركة.

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

## قائمة المراجعة قبل التوسع إلى نطاق مؤسسي

- ☐ وجود مجلس استشاري للتغيير (CAB) مع اتفاقية مستوى خدمة (SLA) محددة وليس مجرد وثيقة نظرية.
- ☐ قرار Single-org مقابل Multi-org موثق مع شرط لإعادة النظر.
- ☐ وجود مسار إصدار (Release Train) بتردد ثابت وبيئة تكامل مشتركة.
- ☐ نموذج صلاحيات يستند إلى Permission Sets وليس Profile جديد لكل تغيير.
- ☐ تم فحص متطلبات الامتثال (Compliance) وفقًا لكل بلد يتم التشغيل فيه.
- ☐ وجود مصفوفة اعتمادية بين البرامج المتوازية يتم تحديثها شهريًا.
- ☐ تم تحديد مالك كائن (Object Owner) وحيد لكل كيان بيانات مشترك.
- ☐ تم تنفيذ مشروع تجريبي (Pilot) في وحدة أعمال واحدة قبل الإطلاق الكامل.
- ☐ وجود خطة توطين تتجاوز ترجمة النصوص.
- ☐ تم تعريف مقاييس نجاح منفصلة لكل موجة توسع.

## مصادر احترافية

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – تنفيذ Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – منهجية العمل — https://hpi.pro/methodology

### أسئلة وأجوبة
**متى يصبح Multi-org ضرورة عملية؟**
عندما تعمل الوحدات التجارية بنماذج مبيعات، أو لوائح تنظيمية، أو لغات مختلفة تمامًا، وعندما يمكن أن يؤثر تكرار التغييرات في وحدة واحدة على استقرار وحدة أخرى. في معظم المؤسسات التي يصل عدد مستخدميها إلى 3,000-5,000، يظل Single-org مع فصل دقيق للصلاحيات هو الأفضل، فتكاليف صيانة Multi-org أعلى بكثير.

**كم يستغرق بناء مجلس التغيير (CAB) الفعال؟**
يستغرق الأمر في المتوسط من ستة إلى ثمانية أسابيع حتى تستقر العملية: تحديد أنواع التغيير، عتبات الموافقة، جدول الاجتماعات الثابت، ونموذج طلب التغيير. الصعوبة الحقيقية لا تكمن في تحديد العملية، بل في فرضها عندما تضغط الأعمال لتجاوزها.

**كيف يتم تخطيط Release train عندما يكون هناك 6-8 فرق متوازية؟**
بتحديد وتيرة ثابتة (على سبيل المثال، أسبوعيًا أو شهريًا)، ونافذة Code Freeze مشتركة، وآلية Merge تحدد التعارضات بين Metadata قبل الـ Deploy. تنتقل الفرق غير الجاهزة في الموعد إلى السلسلة التالية — لا يتم تأخير المجموعة بأكملها.

**ما هو المختلف في متطلبات الامتثال (Compliance) عندما تعمل المؤسسة في عدة دول؟**
يتطلب الأمر تحديدًا لكل منطقة: GDPR في أوروبا، وقانون حماية الخصوصية في إسرائيل، وأحيانًا HIPAA أو SOX في مؤسسات الرعاية الصحية والمالية الأمريكية. يكمن الاختلاف العملي في حفظ البيانات، وتشفير الحقول، وسجلات الوصول، وليس فقط في صلاحيات Profile.

**ماذا يحدث عندما تتعارض خطة CRM وخطة ERP في الجدول الزمني؟**
غالبًا ما يتم اكتشاف الاعتماد على التكامل أو على مصدر حقيقة مشترك (مثل بيانات العملاء) في مرحلة متأخرة. يجب على PMO تحديد الاعتمادات بين الخطط من اليوم الأول وتحديد أي خطة 'تقود' في كل مجال بيانات، لتجنب اتخاذ قرارين متضاربين في نفس الحقل.

---

## استبدال نظام CRM بـSalesforce: التخطيط للانتقال دون فقدان سير العمل أو البيانات
URL: https://hpi.pro/ar/insights/replace-crm-with-salesforce
غالباً ما يفشل الانتقال بين أنظمة CRM ليس بسبب Salesforce نفسها، بل بسبب البيانات التاريخية التي يتم نقلها دون مراجعة دقيقة. تشرح هذه المقالة كيفية تخطيط سير العمل الحالي، واختيار ما يجب الاحتفاظ به، ومتى يجب إلغاء ربط النظام القديم بأمان.

## الإجابة المختصرة

إن استبدال نظام إدارة علاقات العملاء (CRM) بـ Salesforce ليس مجرد مشروع تقني "لترحيل البيانات"، بل هو قرار مؤسسي يتعلق بما يستحق الاحتفاظ به، وما يجب تركه، وكيفية مواصلة تشغيل الأعمال أثناء عملية الانتقال. يكمن الفشل الأكثر شيوعًا ليس في تحديد خصائص Salesforce نفسه، بل في الافتراض الضمني بأن كل ما هو موجود في النظام القديم يجب أن ينتقل كما هو.

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

تجد المنظمات التي تواجه هذه التساؤلات خلفية إضافية في [تنفيذ Salesforce في المنظمة](/ar/insights/salesforce-implementation-guide)، حيث يتم تفصيل العملية الشاملة لاتخاذ القرارات في مشروع Salesforce.

## تخطيط العمليات الحالية: ليس تصديرًا، بل فهمًا

الخطوة الأولى في أي انتقال بين أنظمة CRM ليست الوصول إلى وظيفة "تصدير" (Export)، بل الجلوس مع أصحاب العمليات لفهم ما يحدث فعليًا بين فتح فرصة بيع (Lead) وإبرام صفقة، أو بين استلام استفسار وإغلاق تذكرة خدمة. وثيقة العمليات القديمة، إذا كانت موجودة أصلاً، تكون دائمًا تقريبًا قديمة مقارنة بما يحدث في الواقع.

في اجتماعات التخطيط، من المفيد توثيق ليس فقط الخطوات الرسمية بل أيضًا "العمليات الظلية" — مثل ملفات Excel الموازية، الحقول التي لا يملؤها أحد، الموافقات التي تتم عبر WhatsApp بدلاً من النظام. هذه هي بالضبط الأماكن التي يفشل فيها النظام الجديد، حتى لو تم بناؤه بشكل صحيح، في الاعتماد عليه إذا لم تؤخذ هذه الجوانب في الاعتبار.

يجب أن يشمل ناتج التخطيط جدولاً لعمليات العمل الأساسية، مالك العملية، تكرار الاستخدام، ودرجة الاعتماد على النظام القديم. العملية التي يتم تنفيذها مرة واحدة كل ربع سنة وتنتج تقريرًا حاسمًا للامتثال التنظيمي تتطلب معالجة مختلفة عن عملية يومية ذات حجم كبير. مثل هذا التصنيف يحدد أيضًا ترتيب الترحيل (Migration) ومستوى الاختبار (Testing) المطلوب لكل عملية.

## ما الذي لا يجب ترحيله: قرار يوفر نصف الجهد

أحد أهم القرارات في مشروع ترحيل نظام CRM ليس ما سيتم ترحيله، بل ما **لن** يتم ترحيله. في معظم الأنظمة القديمة التي تراكمت على مدى سنوات، توجد طبقات من الحقول المكررة، وحالات تم استبدالها، وعمليات تم تعريفها لمشروع لمرة واحدة وانتهى بالفعل.

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

من المهم التمييز بين ثلاث فئات من المعلومات:

- **البيانات الحية** – يجب ترحيلها إلى النظام الجديد كسجل نشط بجميع ارتباطاتها.
- **البيانات التاريخية ذات الصلة** – يتم ترحيلها كأرشيف للعرض، وعادة لا تتطلب التحرير أو الأتمتة.
- **البيانات الميتة** – لا يتم ترحيلها على الإطلاق، ويتم الاحتفاظ بها فقط في نسخة احتياطية خارجية لأغراض التدقيق.

توسع في إدارة الحدود بين مرحلة التخطيط ومرحلة البناء موجود في [Scope Creep في Salesforce](/ar/insights/salesforce-scope-creep-change-control)، لأن الميل إلى إضافة "المزيد من البيانات القديمة" هو أحد المصادر الأكثر شيوعًا لتضخم نطاق العمل (Scope creep) في مشاريع من هذا النوع.

## نموذج البيانات الجديد مقابل القديم: ليس ترجمة، بل تصميم

الخطأ الشائع هو التعامل مع نموذج البيانات كترجمة 1:1 - حيث يتحول كل جدول في النظام القديم إلى كائن في Salesforce، وكل عمود إلى حقل. مثل هذا النهج يحافظ على جميع نقاط ضعف النظام القديم داخل منصة جديدة، ويفوت الميزة الرئيسية لـ Salesforce: القدرة على بناء علاقات مرنة بين الكائنات، والأتمتة المدمجة، وطبقة الأذونات الغنية.

تساعد المقارنة بين النهجين الرئيسيين للترحيل في اتخاذ قرار واعي:

| الجانب | النقل كما هو (Lift-and-Shift) | إعادة تصميم (Redesign) |
|---|---|---|
| وقت المشروع | قصير نسبيًا، عادة 6-10 أسابيع | أطول، عادة 3-5 أشهر |
| التوافق مع العملية التجارية | منخفض — يحافظ على القيود القديمة | مرتفع — يُبنى حول العملية الحالية |
| مخاطر الديون التقنية | مرتفعة، تظهر بعد سنة-سنتين | أقل، لأن الهيكل مخطط مسبقًا |
| تكلفة الصيانة المستقبلية | تزيد بمرور الوقت | مستقرة نسبيًا |
| مناسب لـ | المنظمات ذات ضغط الوقت الشديد أو نطاق عمل محدود جدًا | معظم المنظمات التي تنتقل من نظام عمره أكثر من ثلاث سنوات |
| المخاطر الرئيسية | "نظام جديد، مشاكل قديمة" | تجاوز الجدول الزمني إذا لم يتم تحديد نطاق العمل (Scope) |

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

## فترة التزامن: كيفية الحفاظ على استمرارية العمل

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

سؤال يتكرر في كل مشروع تقريبًا: أي نظام يعتبر "مصدر الحقيقة" خلال هذه الفترة؟ يجب أن يكون الجواب واحدًا ومحددًا مسبقًا، وعادة ما يكون Salesforce منذ اليوم الأول، حيث يُستخدم النظام القديم للتحقق فقط وليس للعمل اليومي. العمل المزدوج للمستخدمين في كلا النظامين هو وصفة للإرهاق والتخلي الفعلي عن النظام الجديد.

أدوات عملية لإدارة الفترة:

- تقرير مقارنة يومي أو أسبوعي بين البيانات الرئيسية في كلا النظامين (عدد الفرص، مبلغ الصفقات، طلبات الخدمة المفتوحة).
- قائمة استثناءات حية يتم تحديثها فور اكتشاف فجوة، مع وجود مالك مسؤول عن إغلاقها خلال فترة زمنية محددة.
- مجموعة "مستخدمين رئيسيين" (Anchor users) من كل قسم يقدمون تقارير يومية عن مشكلات الاستخدام، وليس فقط عن المشكلات التقنية.

جزء كبير من الرؤى التي يتم جمعها خلال هذه الفترة ذات صلة أيضًا بعملية الاختبار المنظمة، والمفصلة في [دليل UAT لـ Salesforce](/ar/insights/salesforce-uat-guide)، وللفترة التي تلي الإطلاق، والتي يتم وصفها في [خطة Hypercare لـ Salesforce](/ar/insights/salesforce-hypercare-plan).

## فصل النظام القديم: ليس حدثًا واحدًا بل تسلسل قرارات

يتم فصل النظام القديم على مراحل، وليس بضغطة زر واحدة في يوم التحويل الكلي (Cutover). القاعدة الإرشادية: يتم فصل النظام عن العمل اليومي فور تشغيله بالكامل (Go Live)، ولكنه يظل متاحًا للقراءة فقط لفترة سماح قصيرة، عادة ما تكون 30-60 يومًا، في حال اكتشاف بيانات مفقودة أو سؤال من الفريق المالي.

### قائمة تحقق لقرار التحويل الكلي (Cutover)

قبل الإعلان رسميًا عن فصل النظام القديم، يجب التأكد من:

- ☐ إعادة إنشاء كل تقرير كان يُصدر بانتظام من النظام القديم بنجاح من Salesforce أو من الأرشيف.
- ☐ اكتمال دورة عمل تجارية كاملة واحدة (على سبيل المثال، إغلاق شهر كامل) بالكامل داخل النظام الجديد.
- ☐ انخفاض فجوات البيانات بين الأنظمة إلى ما دون العتبة المحددة مسبقًا (على سبيل المثال، أقل من 1% من السجلات).
- ☐ وجود موافقة خطية من الجهة القانونية أو المالية بأن الأرشيف يفي بمتطلبات الحفظ.
- ☐ تحديد المسؤول عن الوصول للقراءة فقط خلال فترة السماح وموعد إيقافها نهائيًا.
- ☐ إجراء نسخة احتياطية كاملة وموثقة لجميع بيانات النظام القديم قبل إلغاء الترخيص.
- ☐ إرسال إشعار إلى جميع مالكي العمليات بتاريخ الفصل النهائي وطريقة الوصول إلى الأرشيف.

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

## الأرشفة والامتثال التنظيمي: ما الذي يجب الاحتفاظ به وكم من الوقت؟

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

الحل المتبع هو الفصل بين طبقتين:

| الطبقة | المحتوى | الموقع | إمكانية الوصول |
|---|---|---|---|
| بيانات تشغيلية حية | 24-36 شهرًا الأخيرة | Salesforce | كاملة، بما في ذلك التحرير والأتمتة |
| أرشيف تنظيمي | التاريخ الكامل كما يتطلبه القانون | مستودع بيانات خارجي أو أرشيف Salesforce | قراءة فقط، مع قدرة البحث |

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

## سيناريو مؤسسي مثال

انتقلت شركة خدمات مالية من نظام CRM محلي عمره 12 عامًا إلى Salesforce. حدد الفريق في مرحلة التخطيط أن حوالي 40% من الحقول الموجودة لم يتم لمسها لمدة عامين أو أكثر، وقرروا تركها خارج عملية الترحيل. وفر هذا حوالي شهر من العمل في البناء والاختبار.

خلال فترة التزامن، التي استمرت ستة أسابيع، تم اكتشاف فجوة في حساب العمولات ناتجة عن اختلاف في تقريب الأرقام بين الأنظمة - وهو خلل ما كان ليكتشف بدون تقرير مقارنة يومي. قام الفريق بتصحيح الصيغة قبل أن تصل إلى كشف حساب أجور حقيقي. تم فصل النظام القديم عن العمل اليومي في يوم التشغيل الكامل (Go Live)، ولكن تم الاحتفاظ بإمكانية الوصول للقراءة فقط لمدة 45 يومًا إضافية لأغراض التحقق من تقرير ربع سنوي كان قيد الإعداد بالفعل.

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

## المخاطر الشائعة والإجراءات الوقائية

| المخاطر | كيف تظهر عمليًا | الإجراء الوقائي |
|---|---|---|
| ترحيل "كل شيء" بدون تصفية | النظام الجديد مُحمَّل ببيانات ميتة ويُبطئ الاعتماد | تحديد معيار تصفية بناءً على الاستخدام الفعلي في السنتين الأخيرتين |
| نموذج بيانات منسوخ | نفس قيود النظام القديم تتكرر في Salesforce | تصميم نموذج جديد حول العملية المحدثة، وليس حول الجداول القديمة |
| تزامن بلا مالك مسؤول | اكتشاف الفجوات بين الأنظمة متأخرًا أو عدم اكتشافها على الإطلاق | تقرير مقارنة دوري مع مسؤول محدد لكل استثناء |
| فصل متسرع جدًا | اكتشاف بيانات مفقودة بعد إلغاء الترخيص بالفعل | فترة سماح للوصول للقراءة فقط قبل الإلغاء النهائي |
| تجاهل متطلبات الأرشفة | يكشف التدقيق التنظيمي عن عدم حفظ المعلومات المطلوبة بشكل صحيح | الحصول على موافقة قانونية خطية على سياسة الأرشفة قبل التحويل الكلي (Cutover) |

## كيف نقيس نجاح عملية الانتقال

| المجال | ما يتم قياسه | وتيرة الفحص |
|---|---|---|
| اكتمال البيانات | نسبة السجلات التي تم ترحيلها بنجاح بدون أخطاء | قبل وبعد كل عملية ترحيل |
| التوافق بين الأنظمة | الفجوات في التقارير الرئيسية بين النظامين القديم والجديد | يوميًا خلال فترة التزامن |
| اعتماد المستخدمين | نسبة العمل في النظام الجديد مقابل العودة إلى القديم | أسبوعيًا في الشهر الأول |
| التكلفة التشغيلية | التوفير في الترخيص والصيانة بعد الفصل | شهريًا بدءًا من ثلاثة أشهر بعد التشغيل الكامل (Go Live) |

لإجراء استبدال نظام CRM بـ Salesforce، من الجيد اختيار ثلاثة إلى خمسة مقاييس فقط مسبقًا، وقياسها قبل المشروع وبعده - وإلا فمن الصعب إثبات أن الانتقال قد حسن العملية فعلاً ولم يقتصر على نقلها إلى منصة أخرى. يمكن تنفيذ هذه العملية فعليًا بمساعدة [خدمة تنفيذ Salesforce](/ar/salesforce-implementation)، التي تدعم المنظمات من مرحلة التخطيط وحتى فصل النظام القديم.

## مصادر احترافية

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – تنفيذ Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – منهجية العمل — https://hpi.pro/methodology

### أسئلة وأجوبة
**كم ينبغي نقل البيانات التاريخية من النظام القديم؟**
كقاعدة عامة فعالة: يتم نقل بيانات آخر 24-36 شهراً إلى النظام الجديد كسجلات نشطة، ويتم أرشفة البقية لتكون متاحة فقط. نقل عشر سنوات من التاريخ 'لأنه ممكن' يزيد من تكلفة الترحيل ويضر بالأداء دون فائدة تجارية مثبتة.

**ماذا نفعل مع الحقول التي ليس لها مقابل في نموذج البيانات الجديد؟**
يجب أولاً التحقق مما إذا كان الحقل لا يزال يستخدم في عملية حية، أم أنه مجرد أثر تاريخي. الحقل النشط يحصل على تعيين صريح أو حقل مخصص جديد (Custom Field)؛ الحقل غير المستخدم يُحفظ فقط في الأرشيف الخارجي، دون نقله إلى Salesforce كـ'حقل نص حر' لا يفهمه أحد بعد عام.

**كم يجب أن تستمر فترة التوازي بين الأنظمة؟**
بالمتوسط، تتراوح الفترة بين أربعة وثمانية أسابيع للمؤسسات متوسطة الحجم، اعتماداً على تعقيد دورة المبيعات أو الخدمة. فترة قصيرة جداً لا تكشف عن الاستثناءات الموسمية؛ فترة طويلة جداً تجعل المستخدمين يعتادون على العمل في نظامين وتؤخر التكيف.

**متى يُسمح بفصل النظام القديم بشكل نهائي؟**
فقط بعد استيفاء ثلاثة شروط: تطابق البيانات بين الأنظمة دون فروقات جوهرية، إكمال دورة عمل كاملة واحدة على الأقل بالكامل في Salesforce، واستعادة كل تقرير تنظيمي أو تدقيقي كان يعتمد على النظام القديم بنجاح من الأرشيف.

**هل يجب الحفاظ على وصول مباشر للنظام القديم حتى بعد الانتقال؟**
في الغالب، لا يتطلب الأمر وصولاً مباشراً يتجاوز فترة سماح قصيرة تتراوح من 30 إلى 60 يوماً لإجراء فحوصات استثنائية. بعد ذلك، يكون النسخ الاحتياطي فقط لأغراض التنظيم والتدقيق كافياً في معظم الصناعات، ويقلل تكاليف الترخيص والصيانة بشكل كبير مقارنة بإبقاء النظام القديم نشطاً.

---

## ربط Salesforce بنظام ERP: دليل معماري للأنماط والمخاطر
URL: https://hpi.pro/ar/insights/salesforce-erp-integration
عند ربط Salesforce بأي نظام ERP، تأتي اللحظة التي تختلف فيها الأرقام – سواء في المخزون، الرصيد المستحق، أو حالة الطلب – وعندها يجب تحديد المصدر الصحيح للمعلومة. يبني هذا الدليل القرار حول مفهوم "مصدر الحقيقة"، وأنماط المزامنة، وتخطيط التعامل مع الفشل، بدلاً من مجرد قائمة باتصالات API.

## الإجابة المختصرة

غالبًا ما يفشل ربط Salesforce بنظام ERP ليس بسبب مشكلة فنية في الربط نفسه، بل بسبب سؤال لم يُطرح مسبقًا: ما هو النظام الذي يُعد مصدر الحقيقة لكل كيان؟ وماذا يحدث عند فقدان الرسالة بين الأنظمة، أو وصولها مرتين، أو وصولها بترتيب خاطئ؟ يبني هذا الدليل القرار حول ثلاث طبقات - مصدر الحقيقة، نمط المزامنة، ومعالجة الفشل - ويوضح كيفية الاختيار بينها بناءً على سيناريو العمل الفعلي، وليس بناءً على ما تسمح به الـ API.

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

يُستكمل هذا النقاش حول ربط Salesforce بنظام ERP بشكل طبيعي في [هندسة Salesforce](/ar/insights/crm-architecture-guide).

## مصدر الحقيقة لكل كيان: السؤال الذي يسبق أي API

قبل اختيار بروتوكول أو أداة تكامل، يجب الإجابة على سؤال واحد لكل كيان: ما هو النظام الذي يقرر ما هو صحيح عند وجود تعارض؟ غالبًا ما يكون ERP هو مصدر الحقيقة للمخزون وقوائم الأسعار والفواتير والتحركات المالية، بينما Salesforce هو مصدر الحقيقة لعلاقات العملاء والفرص وأنشطة المبيعات. تبدأ المشكلة عندما يفترض أحدهم ضمنيًا أن الاتجاهين "سيتدبران نفسيهما" - ثم تنشأ حالات يقوم فيها مندوب المبيعات بتغيير عنوان الشحن في Salesforce بينما يكون نظام ERP قد شحن بالفعل الشحنة إلى العنوان القديم.

الحل العملي هو وثيقة رسم خرائط الكيانات: لكل كيان (Account, Product, Order, Invoice) يتم تحديد مصدر الحقيقة، اتجاه المزامنة (أحادي الاتجاه أو ثنائي الاتجاه)، وتكرار التحديث المطلوب. وعندما تكون هناك حاجة حقيقية لمزامنة ثنائية الاتجاه - مثل تحديث حالة الدفع الذي يعود من ERP إلى سجل الفرصة - يتم تحديد قاعدة صريحة لحل التعارضات، مثل "التحديث الأخير حسب Timestamp هو الفائز" أو "الحقل المالي دائمًا حسب ERP".

|الكيان|مصدر الحقيقة|اتجاه المزامنة|التكرار النموذجي|
|---|---|---|---|
|العميل (Account)|Salesforce|ثنائي الاتجاه مع قاعدة تعارض|شبه فوري|
|المنتج وقائمة الأسعار|ERP|أحادي الاتجاه إلى Salesforce|يومي أو حسب التغيير|
|الطلب (Order)|يُنشأ في Salesforce، يُدار في ERP|ثنائي الاتجاه، مراحل منفصلة|فوري في مرحلة الإنشاء|
|الفاتورة والدفع|ERP|أحادي الاتجاه إلى Salesforce|يومي أو شبه فوري (Near Real-Time)|
|المخزون المتاح|ERP|أحادي الاتجاه إلى Salesforce|كل بضع دقائق حتى ساعة|

## أنماط المزامنة: Request-Reply, Batch و Event-Driven

تغطي ثلاثة أنماط معظم السيناريوهات الفعلية. **Request-Reply (متزامن)** يناسب عندما ينتظر المستخدم في Salesforce إجابة فورية - على سبيل المثال، التحقق من توفر المخزون قبل تأكيد الطلب. الميزة هي البساطة والإجابة الفورية؛ العيب هو الاعتماد الكامل على توفر نظام ERP في تلك اللحظة، وتأثير سلبي على تجربة المستخدم إذا كان الاستجابة بطيئة.

**Batch (دفعات)** يناسب تحديثات الحجم الكبير غير العاجلة، مثل مزامنة قائمة الأسعار الليلية أو استيراد فواتير اليوم السابق. النمط أكثر مرونة تجاه الأعطال المؤقتة، ولكنه يعني تأخير (Latency) من ساعات إلى يوم بين الأنظمة - تأخير يجب أن يكون مقبولاً للعمل، وليس فقط للفريق التقني.

**Event-Driven** (عبر Platform Events، Change Data Capture أو قائمة رسائل خارجية) يناسب عندما تكون هناك حاجة لاستجابة شبه فورية دون فرض اعتماد متزامن. تغيير حالة الطلب في ERP يطلق حدثًا، ويقوم Salesforce بتحديث نفسه عندما يكون جاهزًا - بما في ذلك Retry تلقائي إذا كان غير متاح مؤقتًا. هذا هو النمط الأكثر مرونة، ولكنه أيضًا الأكثر تعقيدًا في الإعداد والمراقبة.

### جدول اختيار النمط حسب السيناريو

|السيناريو|النمط الموصى به|المدة الزمنية (Latency) النموذجية|الخطر الرئيسي|
|---|---|---|---|
|التحقق من المخزون قبل تأكيد الطلب|Request-Reply|بضع ثوانٍ|اعتماد كامل على توفر ERP؛ Timeout يؤثر على تجربة المستخدم|
|مزامنة قائمة الأسعار والمنتجات|Batch ليلي|ساعات حتى 24 ساعة|بيانات غير محدثة بين الدورات؛ تتطلب تنسيقًا مع الحملات والعروض|
|تحديث حالة الدفع|Event-Driven|ثوانٍ حتى دقائق|تعقيد تشغيلي؛ يتطلب مراقبة قائمة الرسائل و Dead Letter Queue|
|إنشاء طلب جديد في ERP|Request-Reply مع Retry|ثوانٍ حتى دقيقة|فشل جزئي - تم إنشاء الطلب في ERP ولكن الإجابة فقدت، خطر التكرار|
|تحديث المخزون المتاح للبيع|Batch متكرر (كل 15-60 دقيقة)|دقائق|البيع بناءً على مخزون نفد بالفعل بين الدورات|
|تنبيه تجاوز حد الائتمان|Event-Driven|شبه فوري|حدث مفقود يؤدي إلى الموافقة على صفقة لم يكن من المفترض أن تتم|

في هذا السياق، يرتبط قرار نوع المزامنة أيضًا بنموذج الصلاحيات والملكية على البيانات - يتوفر المزيد حول هذا في [Salesforce Sharing and Visibility](/ar/insights/salesforce-sharing-visibility-design).

## Middleware مقابل Point-to-Point

عندما يكون هناك ربط واحد فقط بين Salesforce ونظام ERP، قد يكون الربط المباشر (Point-to-Point) باستخدام REST API أو Named Credentials هو الحل الأسرع والأقل تكلفة. تبدأ المشكلة عندما ينضم نظام ثالث - مستودع بيانات، نظام شحن أو منصة تسوية - وعندئذ يتطلب كل نظام جديد بناء منطق تحويل ومعالجة أخطاء خاص به، مكررًا لما هو موجود بالفعل في الربط السابق.

طبقة Middleware (مثل MuleSoft، Boomi أو Workato) تحل هذه المشكلة عن طريق تركيز المنطق: يتصل كل نظام مرة واحدة بالـ Middleware، والـ Middleware مسؤول عن التحويل، Retry، قائمة الرسائل والمراقبة المركزية. التكلفة هي مكون بنية تحتية إضافي يتطلب ترخيصًا وصيانة وخبرة متخصصة.

قاعدة إرشادية عملية: حتى ربطين أو ثلاثة مستقرين وبدون منطق معقد - Point-to-Point معقول. بدءًا من ثلاثة أنظمة وما فوق، أو عند وجود متطلبات حوكمة مركزية (مثل المراقبة الموحدة لجميع عمليات التكامل في المؤسسة)، فإن تكلفة الـ Middleware مبررة دائمًا تقريبًا في غضون سنة إلى سنتين.

## معالجة الأخطاء والتطابقية (Idempotency)

السيناريو الأكثر خطورة في التكامل ليس الفشل التام بل **الفشل الجزئي**: تم إرسال الرسالة، نظام ERP أنشأ طلبًا، ولكن الإجابة إلى Salesforce فُقدت بسبب Timeout. إذا حاول النظام المرسل مرة أخرى بسذاجة، يتكون طلب مكرر.

الحل هو مفتاح التطابقية (Idempotency Key) - معرّف فريد يُنشأ في جانب المرسل ويُرفق بكل طلب. يسجل الجانب المستلم المعرفات التي تم معالجتها سابقًا، ويرفض (أو يُعيد النتيجة الموجودة) إذا كان المعرّف موجودًا بالفعل. مبادئ عملية إضافية:

- يتلقى كل تكامل حرج آلية Retry مع Backoff تدريجي، وليس محاولة فورية ومتكررة
- الرسائل التي فشلت مرارًا وتكرارًا تنتقل إلى Dead Letter Queue للمراجعة اليدوية، ولا تختفي بصمت
- يتضمن سجل الأخطاء الحمولة الكاملة (Payload) للرسالة الفاشلة، للسماح بالاستعادة اليدوية
- تقوم عملية التسوية (Reconciliation) اليومية أو الأسبوعية بالمقارنة بين الأنظمة وتحديد الفجوات التي "فاتتها" المزامنة

بدون مفتاح التطابقية وعملية تسوية منظمة، تصبح أي مشكلة شبكة عابرة مشكلة بيانات مستمرة يصعب تحديد مصدرها بعد أسابيع.

## قيود API، الأمان والمراقبة

تفرض Salesforce قيودًا يومية على عدد استدعاءات الـ API (حسب الترخيص والإصدار)، وقيودًا على حجم الاستجابة ووقت التنفيذ. المؤسسة التي تقوم بمزامنة عشرات الآلاف من السجلات يوميًا عبر REST العادي (استدعاء-استدعاء) ستصل إلى الحد الأقصى بسرعة. الحل هو Bulk API 2.0 لتحديثات الحجم، و Composite API لتقليل عدد الاستدعاءات في العمليات المتزامنة متعددة الخطوات.

على صعيد الأمان، تتكرر ثلاثة مبادئ في كل مشروع ناجح:

1. استخدام Named Credentials و Connected Apps مع OAuth، وليس أسماء مستخدم وكلمات مرور ثابتة في الكود
2. صلاحية "المستخدم التقني" للتكامل محدودة بدقة على الكائنات والحقول التي يحتاجها فقط - وليس بروفايل مدير النظام
3. تمرير البيانات الحساسة (أرقام بطاقات الائتمان، تفاصيل الحساب البنكي) عبر طبقة Middleware أو Tokenization، وعدم تخزينها كنص واضح في Salesforce

للمراقبة، يجب إعداد لوحة تحكم (Dashboard) تعرض على الأقل ثلاثة بيانات: نسبة الرسائل الناجحة مقابل الفاشلة، متوسط ووقت الاستجابة المتوسط، وعدد السجلات في Dead Letter Queue. التنبيه التلقائي عندما تتجاوز نسبة الفشل عتبة محددة (على سبيل المثال، أكثر من 2% من الرسائل في اليوم) يمنع الحالة التي تتراكم فيها مشكلة ولا يتم اكتشافها إلا عندما يشتكي عميل.

تعتمد هذه القرارات غالبًا على العمل الأساسي السابق في مجال البيانات والصلاحيات، الموضح في [الديون التقنية في Salesforce](/ar/insights/salesforce-flow-apex-technical-debt).

## سير عمل موصى به

### 1. رسم خرائط الكيانات وتحديد مصدر الحقيقة

لكل كيان (عميل، منتج، طلب، فاتورة) يتم تحديد النظام الذي يقرر عند التعارض. بدون هذا القرار، أي نقاش حول "ما هي الطريقة الصحيحة للمزامنة" يتم في غفلة.

### 2. اختيار نمط المزامنة حسب الـ Latency المطلوب فعليًا

ليس كل عملية تتطلب استجابة فورية. التحقق من المخزون قبل البيع نعم؛ تحديث قائمة الأسعار الليلية لا. تكييف النمط مع الحاجة الحقيقية يوفر تكلفة بنية تحتية غير ضرورية.

### 3. الحسم بين Middleware و Point-to-Point

يعتمد الحسم على عدد الأنظمة المتصلة والحاجة إلى حوكمة مركزية، وليس على تفضيل تكنولوجي فقط.

### 4. التخطيط للتطابقية (Idempotency)، وإعادة المحاولة (Retry)، والتسوية (Reconciliation) منذ البداية

هذه ليست "تحسينات مستقبلية" بل جزء من تعريف "تم الإنجاز" (Definition of Done) لأي تكامل يتعلق بالمال، المخزون أو الطلبات.

### 5. تحديد صلاحيات دنيا للمستخدم التقني

بروفايل مخصص، وليس صلاحية مدير نظام شاملة. أي تغيير في الصلاحية يخضع لموافقة منفصلة عن التغيير الوظيفي.

### 6. اختبار سيناريوهات الفشل، وليس فقط المسار الطبيعي (Happy Path)

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

### 7. إنشاء لوحة تحكم (Dashboard) وعملية تسوية (Reconciliation) دائمة

المراقبة التقنية (الخادم يعمل) ليست كافية؛ يجب وجود مراقبة أعمال (عدد الطلبات متساوٍ في كلا النظامين).

## سيناريو مؤسسي نموذجي

قامت شركة تجارية بحوالي 40 ألف طلب شهريًا بربط Salesforce بنظام ERP باستخدام استدعاءات REST المتزامنة المباشرة، بدون Middleware. في فترة ذروة المبيعات، ارتفعت نسبة الفشل في استدعاءات الـ API بشكل حاد بسبب حد الاستدعاءات اليومية، والطلبات التي لم تتمكن من التسجيل في ERP "اختفت" ببساطة - لأنه لم يكن هناك Dead Letter Queue ولم يكن هناك تنبيه.

بعد الفحص، تبين نقص ثلاثة أمور: لم يتم تحديد مفتاح التطابقية (Idempotency Key)، لذا فإن المحاولات المتكررة أدت أحيانًا إلى طلبات مكررة؛ لم يتم الانتقال إلى Bulk API لتحديثات الحجم؛ ولم تكن هناك عملية تسوية تقارن عدد الطلبات في كلا النظامين. تضمن الحل الانتقال إلى طبقة Middleware مع قائمة رسائل، واستبدال بعض الاستدعاءات المتزامنة بعمليات Batch متكررة، وإضافة لوحة تحكم (Dashboard) يومية تعرض الفجوات.

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

## المخاطر الشائعة والإجراءات الوقائية

|الخطر|كيف يبدو في الواقع|إجراء وقائي|
|---|---|---|
|عدم تحديد مصدر الحقيقة|جانبان "صحيحان" في نفس الوقت، ولا أحد يعلم من يصدق|وثيقة رسم خرائط الكيانات مع مالك محدد لكل حقل حاسم|
|نقص التطابقية (Idempotency)|طلبات مكررة بعد أي عطل شبكة مؤقت|مفتاح التطابقية (Idempotency Key) والتحقق من التكرار في جانب المستلم|
|Point-to-Point بدون حوكمة|أي تغيير في نظام واحد يكسر ربطات أخرى بصمت|طبقة Middleware، عقود موثقة وملكية واضحة|
|تجاهل قيود API|فشل الاستدعاءات في ذروة التحميل، بدون تنبيه مبكر|الانتقال إلى Bulk API، مراقبة استهلاك الحصص اليومية|
|صلاحيات واسعة للمستخدم التقني|كشف معلومات حساسة تتجاوز حاجة التكامل|بروفايل محدود وفحص دوري للصلاحيات|

من هو في مرحلة أبكر من تخطيط الربط قد يجد معلومات تكميلية في [Salesforce Flow أو Apex](/ar/insights/salesforce-flow-vs-apex)، خاصة في اتخاذ قرار حول مكان تنفيذ منطق التحويل.

## كيفية قياس النجاح

|المجال|ماذا نقيس|معدل الفحص|
|---|---|---|
|الموثوقية|نسبة الرسائل المكتملة مقابل الفاشلة|مستمر، مع تنبيه عند تجاوز الحد|
|المدة الزمنية (Latency)|الوقت من البداية إلى النهاية لكل سيناريو على حدة|مستمر|
|اتساق البيانات|عدد الفجوات في فحص التسوية (Reconciliation)|يومي أو أسبوعي|
|التكلفة التشغيلية|ساعات الدعم المخصصة لمشاكل التكامل|شهري|

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

## قائمة المراجعة قبل الانتقال إلى الإنتاج

- ☐ تم تحديد مصدر حقيقة واحد وقاعدة لحل التعارضات لكل كيان.
- ☐ تم اختيار نمط المزامنة (Request-Reply, Batch أو Event-Driven) لكل عملية على حدة.
- ☐ تم الحسم حول ما إذا كانت طبقة Middleware ضرورية أم أن الربط المباشر يكفي.
- ☐ يوجد مفتاح التطابقية (Idempotency Key) لكل عملية تنشئ سجلًا ماليًا.
- ☐ تم تحديد آلية Retry مع Backoff و Dead Letter Queue للرسائل الفاشلة.
- ☐ تم فحص استهلاك حصة الـ API اليومية مقابل الحجم المتوقع.
- ☐ صلاحية المستخدم التقني محدودة على الكائنات والحقول المطلوبة فقط.
- ☐ تم إجراء اختبار الفشل الجزئي، وليس فقط المسار الطبيعي (Happy Path).
- ☐ توجد لوحة تحكم (Dashboard) للمراقبة التجارية، وليس فقط التقنية.
- ☐ تم تحديد عملية تسوية (Reconciliation) دائمة ومعين لها مسؤول.

## ملاحظات متعمقة للتنفيذ والصيانة

### ملاحظة من مهندس معماري: متى يجب تغيير نمط موجود

إذا تم اختيار نمط Batch ليلي في البداية لأسباب تتعلق بالبساطة، ولكن العمل يتطلب لاحقًا تحديث المخزون بشكل شبه فوري، فلا داعي لـ "نسف" كامل البنية المعمارية - يمكن زيادة التكرار إلى 15 دقيقة كخطوة وسيطة، والانتقال إلى Event-Driven فقط عندما يتضح أن هذا أيضًا غير كافٍ. التغيير التدريجي، المصحوب بقياس الـ Latency الفعلي، أفضل من قرار شامل مبكر جدًا.

من وجهة نظر إدارية، الاختبار الحقيقي لربط Salesforce بنظام ERP ليس فقط أنه "يعمل اليوم"، بل أنه يمكن تفسير سبب اختيار كل نمط في خمس دقائق، ومن المسؤول عن إصلاحه عندما يحدث خطأ. الحل الذي يتطلب تحقيقًا طويلًا في كل عطل يخلق تكلفة تشغيلية مخفية تزداد بمرور الوقت.

في حال نقص القدرة الداخلية لتخطيط أو تنفيذ مثل هذا الربط، فإن [خدمة هندسة CRM](/ar/crm-architecture) هي المسار العملي للمضي قدمًا.

## مصادر احترافية

- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – هندسة CRM — https://hpi.pro/crm-architecture
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ماذا نفعل عندما يختلف نظاما ERP وSalesforce حول حالة نفس العميل؟**
أولاً، يجب تحديد أي نظام هو مصدر الحقيقة لذلك الكيان – غالبًا ما يكون ERP للفوترة والمخزون، وSalesforce لعلاقات العملاء. بعد ذلك، يتم بناء قاعدة تسوية يومية تسلط الضوء على الفروقات، ولا يجب الاعتماد على أن المزامنة 'الخضراء' تعني تطابق البيانات فعليًا.

**متى يكون Point-to-Point كافيًا ومتى يكون Middleware ضروريًا؟**
قد يكون Point-to-Point كافيًا لربطين أو ثلاثة اتصالات مستقرة. ولكن بمجرد وجود ثلاثة أنظمة أو أكثر، أو منطق تحويل مشترك، أو الحاجة إلى إعادة المحاولة والمراقبة المركزية، فإن طبقة Middleware مثل MuleSoft توفر عليك تكرار نفس المنطق في كل طرف.

**كيف نحافظ على Idempotency عندما يتم إرسال رسالة مرتين؟**
تتلقى كل رسالة معرفًا فريدًا (Idempotency Key)، وفي الجانب المستلم، يتم التحقق مما إذا كان المعرف قد تمت معالجته بالفعل قبل إنشاء سجل جديد. عمليًا، يتم تخزينه في حقل خارجي مخصص على السجل أو في جدول سجل منفصل، بحيث لا يؤدي التشغيل المزدوج إلى إنشاء طلب مكرر.

**ماذا يحدث عند الوصول إلى حد الـ API Calls اليومي لـ Salesforce؟**
يجب الانتقال من الاستدعاءات المتزامنة المتكررة إلى العمل على دفعات (Bulk API) أو تقليل وتيرة الاستعلام (Polling). المؤسسة التي لديها عشرات الآلاف من تحديثات الطلبات يوميًا ستواجه دائمًا هذا الحد إذا استخدمت REST العادي بدلاً من Bulk API 2.0.

**كيف يتم اختبار الاتصال بنظام ERP قبل نشره في بيئة الإنتاج؟**
يتم بناء بيئة Staging مع نسخة بيانات تمثيلية، وتشغيل سيناريو كامل يتضمن حالات الفشل الجزئية (ERP غير متاح، رسالة تالفة، تكرار)، وقياس وقت العودة إلى الاتساق. يتم منح الموافقة التجارية فقط بعد عرض سيناريو الفشل، وليس فقط المسار الطبيعي (Happy Path).

---

## ترحيل البيانات إلى Salesforce: الدليل الشامل للتخطيط، التنظيف، والتحويل (Cutover)
URL: https://hpi.pro/ar/insights/salesforce-data-migration-guide
معظم مشاكل ترحيل البيانات لا تنبع من الأداة نفسها، بل من ترتيب تحميل خاطئ، تعيين حقول متسرع، وغياب المطابقة (Reconciliation). يقدم هذا الدليل عملية متكاملة: تحليل البيانات (Profiling)، التنظيف، المعرفات الخارجية (External IDs)، التشغيل التجريبي (Dry Run)، والإصلاحات بعد الانطلاق الفعلي (Go Live).

## الملخص التنفيذي

فشل ترحيل البيانات إلى Salesforce لا يُعزى عادةً إلى الأداة بحد ذاتها، بل إلى منهجية عمل غير سليمة: البدء بالتحميل قبل فهم جودة المصدر، أو تعيين الحقول في جداول Excel دون التحقق من القيم الشاذة، أو التحميل الذي لا يراعي التبعيات بين الكائنات. تُبنى العملية الصحيحة كدورة متكررة: تحليل البيانات (Profiling)، التعيين (Mapping)، التنظيف (Cleansing)، التحميل المُتحكم (Controlled Loading)، الاختبار، والمطابقة (Reconciliation) – وعندها فقط تتم عملية الانتقال (Cutover).

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

يُجنّب عمل التنظيف المبكر من الأضرار اللاحقة، ويُنصح بالاطلاع على المزيد حول هذا الموضوع في مقال [إزالة البيانات المكررة في Salesforce](/ar/insights/salesforce-data-deduplication).

## تحليل المصدر: فهم البيانات قبل التعامل معها

قبل كتابة أي تعيين للحقول، يجب إجراء تحليل لبيانات المصدر: كم عدد السجلات في كل جدول، وما هي الحقول الفارغة فعليًا (ليس فقط في المخطط ولكن في البيانات نفسها)، وما هو نطاق القيم في الحقول الرقمية وحقول التاريخ، وأين توجد قيم نصية حرة يفترض أن تكون ضمن قائمة مغلقة. في أحد المشاريع التي رافقناها، احتوى حقل "حالة العميل" على 47 صياغة مختلفة في المصدر – "نشط"، "Active"، "نشط " مع مسافة، "ن" – وكل هذه القيم كان يجب تعيينها لقيمة واحدة في Salesforce.

تُعدّ أدوات مثل OpenRefine، أو استعلامات SQL البسيطة، أو حتى جداول Pivot في Excel على عينة من البيانات كافية لمعظم المشاريع. الهدف هو إنشاء وثيقة تحليل بيانات تُظهر: العدد الإجمالي للسجلات، النسبة المئوية للحقول الإلزامية الفارغة، عدد القيم الفريدة لكل حقل تصنيفي، وتحديد مبدئي للتكرارات المحتملة بناءً على الاسم، الهاتف، أو البريد الإلكتروني.

في هذه المرحلة، يتم أيضًا تحديد ما إذا كانت هناك عدة مصادر للمعلومات المتداخلة – على سبيل المثال، نفس العميل موجود في نظام CRM القديم وفي نظام المحاسبة – ويُتخذ قرار بشأن المصدر الذي يُعد "مصدر الحقيقة" (Source of Truth) لكل حقل. يجب أن يكون هذا القرار مكتوبًا، وليس مجرد افتراض، لأنه يؤثر على جميع المراحل اللاحقة.

## تعيين الحقول: ما وراء جدول Excel

لا يقتصر تعيين الحقول الجيد على "العمود A في المصدر = الحقل B في الوجهة". بل يتضمن أيضًا اتجاه التحويل: تنسيق التاريخ، تحويل الوحدات، تقسيم حقل عنوان واحد إلى شارع/مدينة/رمز بريدي، وحل للقيم غير الموجودة في القائمة المغلقة في الوجهة. أفضل وثيقة تعيين للحقول رأيناها تضمنت خمسة أعمدة: حقل المصدر، حقل الوجهة، نوع التحويل، قاعدة لمعالجة القيمة المفقودة، ومثال على الإدخال/الإخراج.

يجب التعامل بشكل منفصل مع حقلي Lookup و Master-Detail: فهما لا يحتويان على قيمة مباشرة، بل إشارة إلى سجل آخر، وبالتالي فإن تعيينهما يعتمد على أن السجل المرتبط قد تم تحميله بالفعل ويحتوي على معرّف يمكن الإشارة إليه. هذا هو السبب في أن ترتيب التحميل (لاحقًا) وتعيين الحقول هما وجهان لعملة قرار واحد.

نُقدم مزيدًا من التفاصيل حول إدارة جودة الحقول على المدى الطويل، وليس فقط في مرحلة واحدة، في مقال [جودة البيانات في Salesforce](/ar/insights/salesforce-data-quality-metrics).

## التنظيف والبيانات المكررة: قبل التحميل وليس بعده

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

قواعد التنظيف الرئيسية التي يجب تحديدها مسبقًا:

- توحيد أرقام الهواتف والبريد الإلكتروني (إزالة المسافات، توحيد التنسيق الدولي).
- تحديد التكرارات بناءً على مزيج من الحقول (الاسم + الهاتف، أو رقم الهوية للشركات فقط).
- قاعدة اختيار السجل الرئيسي (Master Record) عند دمج التكرارات – على سبيل المثال، السجل الأكثر حداثة أو الأكثر اكتمالًا.
- معالجة قيم Null مقابل السلاسل الفارغة، لتجنب "التكرارات الوهمية".

في مشروع نموذجي يضم حوالي 80,000 سجل عميل، سيحدد التنظيف المعقول ما بين 3% إلى 8% من التكرارات الحقيقية. يشير عدد أكبر بكثير إلى أن المصدر نفسه لم تتم صيانته بشكل جيد، ويستدعي نقاشًا مع أصحاب العمليات التجارية قبل المتابعة.

## المعرفات الخارجية (External IDs) وترتيب التحميل

المعرف الخارجي (External ID) هو حقل فريد من النظام الأصلي يتم الاحتفاظ به أيضًا في Salesforce، ويسمح بالتحميل المتكرر (Upsert) دون إنشاء تكرارات في كل مرة يتم فيها تشغيل ملف مرة أخرى. بدون External ID، قد يؤدي كل تشغيل متكرر لـ Data Loader إلى إنشاء نسخة إضافية من نفس السجل، لأن النظام لا يعرف كيفية "التعرف" على سجل موجود.

يُحدد ترتيب التحميل بناءً على التبعيات بين الكائنات: لا يمكن تحميل جهة اتصال قبل وجود الحساب الذي ترتبط به، ولا يمكن تحميل بند أمر مبيعات قبل أمر المبيعات نفسه.

| المرحلة | الكائن | التبعية | ملاحظة المعرف الخارجي (External ID) |
| --- | --- | --- | --- |
| 1 | Account | لا توجد تبعية | معرّف العميل من نظام المصدر (ERP/CRM القديم) |
| 2 | Contact | يعتمد على Account | معرّف جهة الاتصال + البحث عن Account External ID |
| 3 | Opportunity | يعتمد على Account, Contact | معرّف الصفقة من نظام المصدر |
| 4 | Product / PriceBook Entry | لا توجد تبعية (يُحمّل بالتوازي مع المرحلتين 1-2) | رقم المنتج (SKU) كـ External ID |
| 5 | Opportunity Line Item | يعتمد على Opportunity, Product | دمج معرّف الصفقة + السطر |
| 6 | Case / Activity History | يعتمد على Account, Contact | معرّف الحالة/النشاط من نظام المصدر |

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

نُقدم معلومات معمقة حول إدارة جودة الحقول على المدى الطويل، وليس فقط في مرحلة واحدة، في مقال [جودة البيانات في Salesforce](/ar/insights/salesforce-data-quality-metrics).

## البيئات والاختبارات

لا يتم تحميل الترحيل مباشرةً إلى بيئة الإنتاج. يتضمن هيكل البيئات الموصى به Sandbox مخصصًا للترحيل (منفصل عن Sandbox التطوير المستمر)، حيث يتم تحميل نفس حجم البيانات ونفس تكوين Validation Rules و Triggers كما هو الحال في الإنتاج، وذلك للكشف عن المشكلات قبل أن تؤثر على المستخدمين الفعليين.

تتضمن الاختبارات في هذه المرحلة اختبار الحجم (ما إذا كان التحميل يكتمل في وقت معقول)، واختبار الأخطاء (ما هي النسبة المئوية للسجلات المرفوضة ولماذا)، واختبار سلوك الأتمتة – Flow أو Trigger الذي يعمل عند إنشاء سجل قد يؤدي إلى إرسال بريد إلكتروني حقيقي إلى العميل إذا لم يتم إيقافه مؤقتًا في بيئة الاختبار. أدى نسيان مثل هذه التفاصيل في أحد المشاريع إلى إرسال آلاف رسائل البريد الإلكتروني المتكررة "مرحبًا بك" للعملاء الحاليين.

## التشغيل التجريبي (Dry Run): تشغيل كامل متكرر

التشغيل التجريبي (Dry Run) هو تشغيل كامل لعملية التحميل في ظروف أقرب ما تكون للإنتاج - نفس الحجم، نفس الملفات، نفس الترتيب - ولكن في بيئة Sandbox. الهدف هو قياس أمرين: وقت التنفيذ الفعلي (لتخطيط نافذة الانتقال (Cutover) بشكل واقعي) والنسبة المئوية للأخطاء في كل مرحلة.

يُوصى بإجراء تشغيلين تجريبيين كاملين على الأقل: الأول يكشف عن معظم المشكلات، والثاني يتأكد من أن الإصلاحات قد حلتها بالفعل ولم تُنشئ مشكلة جديدة. إذا كان التشغيل الثاني لا يزال يُنتج أكثر من 1% إلى 2% من الأخطاء في الكائنات الحرجة، فمن الأفضل عادةً تأجيل موعد الانتقال بدلاً من المساومة على الجودة.

## الانتقال (Cutover) ومطابقة البيانات (Reconciliation)

الانتقال (Cutover) هو النافذة الزمنية الفعلية التي يتم فيها تجميد النظام القديم (Freeze)، ويتم تحميل أحدث المعلومات إلى Salesforce، وينتقل المستخدمون للعمل في النظام الجديد. لا يُقاس النجاح في هذه المرحلة فقط بـ "هل اكتمل التحميل"، بل بالمطابقة (Reconciliation) - وهي مقارنة منهجية بين المصدر والوجهة.

قائمة تحقق للمطابقة (Reconciliation Checklist) يُنصح بتشغيلها عند الانتهاء من كل عملية انتقال:

- ☐ تطابق عدد السجلات (أو توضيحه بفرق معروف) في كل كائن رئيسي.
- ☐ تطابق مجموع الحقول المالية (مثل القيمة الإجمالية للفرص المفتوحة) بين المصادر.
- ☐ عينة عشوائية مكونة من 30-50 سجلًا تم فحصها يدويًا حقلًا بحقل.
- ☐ التحقق من العلاقات – هل لكل Contact حساب سليم، وهل لكل Opportunity Line Item فرصة.
- ☐ التحقق من السجلات "اليتيمة" (التي تم تحميلها بدون إشارة صحيحة).
- ☐ مقارنة عدد التكرارات قبل وبعد مقابل الهدف المحدد في مرحلة التنظيف.
- ☐ الحصول على موافقة صاحب العملية التجارية بأن عينة بياناته تبدو صحيحة.

تشمل فجوات المطابقة الشائعة: تطابق عدد السجلات ولكن اختلاف المبالغ، لأن حقلًا رقميًا تم تحميله بتنسيق خاطئ؛ أو علاقات مفقودة لأن Lookup تم تحميله بناءً على قيمة نصية وليس بناءً على External ID. يُعدّ التوثيق الكامل لعملية المطابقة، بما في ذلك مثال على خط الأساس (Baseline)، متاحًا أيضًا في [إدارة بيانات Salesforce الرئيسية (Salesforce Master Data Management)](/ar/insights/salesforce-master-data-management).

## الإصلاحات بعد التشغيل المباشر (Go Live)

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

من المهم التمييز بين الإصلاح الفوري (سجل فردي تم تحديثه يدويًا) وبين الإصلاح النظامي (خطأ في التعيين يتكرر في آلاف السجلات ويتطلب إصلاحًا في أداة التحميل نفسها وتشغيلًا متكررًا). يؤدي الخلط بين الاثنين إلى قيام الفرق بإصلاح مشكلة يدوية هي في الواقع منهجية، مما يؤدي إلى إهدار الكثير من الوقت.

## مثال سيناريو مؤسسي

طلبت شركة توزيع تضم حوالي 120,000 عميل في نظام CRM قديم، بالإضافة إلى قائمة عملاء منفصلة في نظام المحاسبة، دمج المصدرين في نظام Salesforce واحد. كشف التحليل الأولي أن 11% من العملاء يظهرون في كلا المصدرين بمعلومات اتصال مختلفة، وأن حقل "قطاع الأعمال" احتوى على 340 قيمة حرة كان من المفترض أن تكون حوالي 25 فئة.

قام الفريق بإنشاء تعيين مفصل للحقول، ووضع قاعدة دمج بناءً على مزيج من رقم الهوية والهاتف، وحدد نظام المحاسبة كمصدر حقيقة (Source of Truth) لتفاصيل الفواتير، ونظام CRM القديم كمصدر حقيقة لتفاصيل جهة الاتصال. كشف التشغيل التجريبي الأول أن 4% من السجلات رُفضت بسبب تنسيق تاريخ غير صحيح – وهو إصلاح تم أخذه في الاعتبار في التشغيل الثاني. تم إجراء الانتقال (Cutover) في نهاية الأسبوع، مع مطابقة (Reconciliation) كاملة صباح يوم الأحد قبل فتح النظام للمستخدمين.

النتيجة: أقل من 0.3% من السجلات تطلبت إصلاحًا يدويًا بعد التشغيل المباشر (Go Live)، مقارنة بتقديرات سابقة للفريق توقعت حوالي 5% من الشذوذ. يعزى هذا الفارق بالكامل تقريبًا إلى التشغيلين التجريبيين اللذين تم إجراؤهما قبل الموعد الرسمي.

## المخاطر الشائعة والإجراءات الوقائية

| المخاطرة | كيف تظهر عمليًا | إجراءات وقائية |
| --- | --- | --- |
| عدم توحيد الهويات | نفس العميل يُشغّل عمليات مكررة | قاعدة توحيد بناءً على المعرف الخارجي (External ID) والسجل الذهبي (Golden Record) |
| التحميل بدون المعرف الخارجي (External ID) | يؤدي التشغيل المتكرر إلى إنشاء تكرارات جديدة | تحديد المعرف الخارجي (External ID) قبل التشغيل الأول |
| ترتيب التحميل الخاطئ | أخطاء بحث (Lookup errors) هائلة يصعب تنقيتها | التحميل وفقًا لجدول تبعيات محدد مسبقًا |
| تجاوز التشغيل التجريبي (Dry Run) | نافذة الانتقال (Cutover) تتسع وتظهر مفاجآت في الوقت الفعلي | تشغيلين كاملين على الأقل في بيئة الاختبار |
| عدم وجود مطابقة (Reconciliation) | عدد سجلات مطابق ولكن مبالغ وعلاقات خاطئة | اختبارات العد، المجموع، العلاقة، وأخذ العينات في كل عملية انتقال (Cutover) |

على مستوى إدارة ترحيل البيانات إلى Salesforce، تُعدّ هذه المصفوفة للمخاطر مجرد نقطة انطلاق. يتوفر توسيع لإدارة الجودة المستمرة، بما في ذلك الفرق بين التنظيف لمرة واحدة وحوكمة البيانات المستمرة، في [Data 360 Zero Copy](/ar/insights/data-360-zero-copy-federation).

## كيف نقيس النجاح

| المجال | ما الذي يتم قياسه | وتيرة الاختبار |
| --- | --- | --- |
| الاكتمال (Completeness) | نسبة الحقول الإلزامية والمعلومات الحيوية المكتملة | قبل وبعد كل تحميل |
| التفرد (Uniqueness) | نسبة البيانات المكررة لكل كيان | قبل التشغيل التجريبي (Dry Run) وبعد الانتقال (Cutover) |
| الصلاحية (Validity) | القيم التي تتوافق مع قواعد التنسيق والأعمال | في كل دفعة تحميل |
| المطابقة (Reconciliation) | مطابقة الأعداد والمبالغ والعلاقات مع المصدر | في كل تمرين وفي الانتقال (Cutover) |
| وقت الأداء | المدة الفعلية للتحميل مقابل نافذة الانتقال (Cutover) المخطط لها | في كل تشغيل تجريبي (Dry Run) |

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

## قائمة التحقق قبل التشغيل المباشر (Go Live Checklist)

- [ ] تم إجراء تحليل للمصدر ويتضمن نسب الحقول الفارغة والبيانات المكررة.
- [ ] وثيقة تعيين الحقول كاملة، بما في ذلك التحويلات ومعالجة القيم المفقودة.
- [ ] تم تحديد المعرف الخارجي (External ID) لكل كائن يتطلب تحميلًا متكررًا.
- [ ] ترتيب التحميل مكتوب وموافق عليه من قبل الفريق التقني.
- [ ] تم إجراء تشغيلين تجريبيين (Dry Run)، وانخفضت الأخطاء إلى ما دون العتبة المحددة.
- [ ] سيناريو التراجع (Rollback scenario) مكتوب في حالة فشل الانتقال (Cutover).
- [ ] قائمة التحقق للمطابقة (Reconciliation Checklist) جاهزة ومعروف من سيقوم بتنفيذها.
- [ ] تم تخصيص نافذة زمنية للإصلاحات بعد التشغيل المباشر (Go Live) في الجدول الزمني.
- [ ] تم فحص الأتمتة التي قد ترسل اتصالات للعملاء وتم إيقافها مؤقتًا أثناء التحميل.
- [ ] وافق صاحب العملية التجارية على عينة بيانات نهائية.

## ملاحظات عميقة للتطبيق والصيانة

### ملاحظة معمارية: الترحيل ليس حدثًا لمرة واحدة

حتى بعد نجاح التشغيل المباشر (Go Live)، تُحدث التغييرات في نظام المصدر (إذا كان لا يزال يعمل مؤقتًا بالتوازي) أو الإصلاحات اليدوية انحرافًا بين البيانات. لذلك، يُفضل الاحتفاظ بتقرير مطابقة (Reconciliation report) منتظم – أسبوعيًا في الشهر الأول، ثم شهريًا بعد ذلك – يقارن عينة من البيانات بين التقارير القديمة والجديدة ويكشف عن الانحرافات مبكرًا. المشروع الذي يتعامل مع الترحيل كنقطة نهاية يُفوّت حقيقة أن جودة البيانات هي عملية مستمرة.

من منظور إداري، لا يُقاس النجاح الحقيقي لترحيل البيانات إلى Salesforce فقط بما إذا كانت السجلات قد تم تحميلها، بل بما إذا كان بإمكان مديري البيانات، ونظم إدارة علاقات العملاء (CRM)، والمشاريع، الاعتماد على التقارير في اليوم التالي دون الحاجة إلى التحقق يدويًا من كل رقم. يمكن للمؤسسات التي تسعى للحصول على دعم احترافي لمثل هذه العملية الاستفادة من [خدمات التكامل والبيانات](/ar/integrations-data)، والتي ترافق مرحلة التخطيط ونافذة الانتقال (Cutover) نفسها.

## مصادر احترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**كم من الوقت قبل التحويل (Cutover) يجب إجراء التشغيل التجريبي (Dry Run) الأول؟**
يُوصى بإجراء تشغيل تجريبي كامل قبل ثلاثة إلى أربعة أسابيع على الأقل من تاريخ الانطلاق الفعلي (Go Live)، وتشغيل ثانٍ قبل أسبوع إلى أسبوعين. يتيح ذلك وقتًا كافيًا لتصحيح الاستثناءات، قياس وقت التحميل الفعلي، والتأكد من أن النافذة المخصصة للتحويل (Cutover) كافية حتى مع هامش الأمان.

**ماذا نفعل عند اكتشاف تكرار العملاء بعد استخدام النظام؟**
نقوم بتطبيق قاعدة دمج بناءً على معرّف تجاري (مثل رقم تسجيل الشركة أو بريد إلكتروني موحد)، ونختار السجل الرئيسي (Master Record) بناءً على حداثة البيانات واكتمالها، ثم ندمج باستخدام أداة دمج (Merge tool) أو عملية منظمة تقوم بتحديث العلاقات قبل حذف التكرار. تتطلب هذه العملية نسخة احتياطية كاملة قبل التنفيذ.

**هل يمكن تجاوز المعرفات الخارجية (External IDs) والاعتماد على الأسماء فقط لمطابقة السجلات؟**
لا يُنصح بذلك. الأسماء تتكرر، وتتغير بين الأنظمة، وقد تحتوي على مسافات أو أحرف مختلفة. المعرف الخارجي (External ID) الفريد من النظام الأصلي يضمن تعيينًا فريدًا، ويسمح بالتحميل المتكرر (Upsert) بدون تكرارات، ويقلل بشكل كبير من وقت حل المشكلات.

**ما هو ترتيب التحميل الصحيح عندما يكون هناك ملف واحد يحتوي على جميع أنواع السجلات المختلطة؟**
يجب تقسيم الملف حسب الكائن وتحميل الكيانات غير المعتمدة أولاً (مثل الحسابات)، ثم الكيانات المعتمدة (مثل جهات الاتصال، الفرص)، وأخيرًا العلاقات وعناصر التفاصيل. التحميل المختلط بدون ترتيب يؤدي إلى أخطاء في البحث (Lookup errors) وسجلات يتيمة يصعب تتبعها لاحقًا.

**كم من الوقت يجب تخصيصه للإصلاحات بعد الانطلاق الفعلي (Go Live) قبل إغلاق المشروع؟**
في مشروع ترحيل متوسط، يُوصى بتخصيص أسبوعين إلى أربعة أسابيع من المراقبة الدقيقة، يتم خلالها فحص تقارير الاستثناءات اليومية، فروقات المطابقة (Reconciliation gaps)، وشكاوى المستخدمين. بعد دورتين نظيفتين من التقارير (أسبوعين)، يمكن إعلان إغلاق مرحلة الإصلاحات.

---

## Agentforce للمؤسسات: متى يكون مناسبًا بالفعل ومتى لا يزال غير مناسب
URL: https://hpi.pro/ar/insights/agentforce-for-enterprises
ليس كل عملية تستحق وكيل AI مستقل. يقدم هذا الدليل إطار قرار تشغيلي - نضج البيانات، التأسيس (Grounding)، الصلاحيات، ودور العنصر البشري (Human-in-the-loop) - ليميز بين حالات الاستخدام (Use Case) المناسبة لـ Agentforce وتلك التي يفضل تركها للأتمتة التقليدية.

## الإجابة المختصرة

إن تطبيق Agentforce للمؤسسات ليس مجرد مسألة "هل Salesforce يدعم ذلك"، بل هو مسألة نضج: هل يتوفر مصدر معلومات موثوق به، وهل من الواضح من يوافق على الإجراءات الحساسة، وما هو الخط الأساسي الذي يميز بين النجاح والفشل. المؤسسة التي تتجاهل هذه التساؤلات وتتجه مباشرة نحو بناء وكيل ستكتشف الفجوة في الشهر الثاني، عندما ترتفع التكلفة وتكون النتائج غير متسقة. يبدأ النهج الصحيح بتصفية العمليات،Yتبع ذلك التحقق من جاهزية البيانات والصلاحيات، وينتهي بتجربة أولية (Pilot) مدروسة بمعايير واضحة للاستمرار أو التوقف.

يمكن للمؤسسات التي لا تزال في مرحلة بناء الأساس البدء بـ [جاهزية Agentforce](/ar/insights/agentforce-salesforce-ai-guide)، حيث يتم شرح الفرق بين Copilot و Flow و Agentforce نفسه.

## ستة محاور لتقييم الجاهزية

قبل اختيار أول حالة استخدام (Use Case)، من المفيد تقييم المؤسسة بناءً على ستة مجالات رئيسية. أي مجال يظل في مرحلة "لا نعرف" يمثل مخاطرة ستظهر في التجربة الأولية (Pilot) وليس قبلها.

| مجال الجاهزية | السؤال المركزي | علامة التحذير الشائعة |
|---|---|---|
| نضج البيانات والمعرفة | هل يوجد مصدر معلومات وحيد، محدث ومعتمد؟ | قاعدة معرفية قديمة (Knowledge Base)، تناقضات بين المستندات |
| Grounding (التأريض) | هل يستمد الوكيل معلومات حقيقية أم يخمن؟ | إجابات مقنعة ولكنها خاطئة من حيث الحقائق |
| Topics (المواضيع) والإجراءات (Actions) | هل كل موضوع معرف بحدود ضيقة؟ | وكيل واحد من المفترض أن "يجيب على كل شيء" |
| الصلاحيات والأمن | هل يعمل الوكيل وفقًا للصلاحيات الفعلية للمستخدم؟ | صلاحية نظام تُرجع معلومات لأي شخص |
| Human-in-the-loop (التدخل البشري) | من يوافق على الإجراءات غير القابلة للإلغاء؟ | إجراء مالي أو قانوني بدون رقابة |
| القياس والتكلفة | هل يوجد خط أساس (Baseline) للمقارنة؟ | "يبدو الأمر مثيرًا للإعجاب" بدون أرقام ملموسة |

### نضج البيانات والمعرفة

وكيل الذكاء الاصطناعي الجيد لا يتعدى كفاءة المعلومات التي يتغذى عليها. في مؤسسة خدمات تحتوي على ثلاثة أنظمة معرفية (Knowledge systems) غير متزامنة، سيتعلم الوكيل من أول مصدر يصادفه - حتى لو كان المصدر الأقل دقة. قبل أي عمل تقني، يجب التحقق مما يلي: متى تم تحديث كل مستند آخر مرة، ومن هو المسؤول عنه، وماذا يحدث عندما يكون هناك مستندين متناقضين. المؤسسات التي تتجاهل هذه المرحلة تصل إلى التجربة الأولية (Pilot) مع وكيل ينتج إجابات واثقة ولكنها خاطئة، وهو أمر أسوأ من "لا أعرف".

### Grounding (التأريض)

Grounding هو آلية البحث التي تزود الوكيل بمعلومات حقيقية قبل صياغة الإجابة، بدلاً من الاعتماد على المعرفة العامة للنموذج. تفاصيل الموضوع، بما في ذلك اعتبارات Chunking و Vector Search والفصل بين المصادر الداخلية والخارجية، مشروحة في [Agentforce Grounding](/ar/insights/agentforce-grounding-rag). على مستوى القرار الإداري، يكفي معرفة أنه بدون Grounding قوي، فإن كل الاستثمارات الأخرى - تصميم المحادثة، الإجراءات (Actions)، الواجهة - مبنية على أساس هش.

### Topics (المواضيع) والإجراءات (Actions)

الخطأ الأكثر شيوعًا هو بناء وكيل واحد بموضوع واسع مثل "خدمة العملاء" بدلاً من عدة مواضيع ضيقة مثل "الاستعلام عن حالة الطلب" أو "تحديث تفاصيل الفواتير". الموضوع الضيق أسهل في الاختبار، وأسهل في شرح سبب عدم إجابة الوكيل للمستخدم، وأسهل في إضافة إجراءات (Actions) إليه تدريجياً. يجب أن يعمل الإجراء (Action) نفسه ضمن صلاحيات محدودة، ويجب أن يمر بتحقق من صحة الإدخال، وأن يُرجع خطأ واضحًا عندما لا يتطابق شيء ما - وليس تخمين الاستمرار.

### الصلاحيات والأمن

وكيل يعمل بصلاحية تكامل واسعة (Integration permission) قد يكشف معلومات لا ينبغي للمستخدم الذي يتحدث إليه رؤيتها - راتب موظف آخر، طلب عميل آخر، ملاحظة داخلية حساسة. التوصية المهنية هي تشغيل الوكيل ضمن سياق صلاحيات المستخدم الفعلي (Run As User) حيثما أمكن، وتوثيق أي استثناء لهذا النموذج كقرار واعٍ مع تحديد مالك (Owner).

### Human-in-the-loop (التدخل البشري)

ليس كل إجراء يتطلب موافقة بشرية، ولكن جميع الإجراءات غير القابلة للإلغاء تتطلب ذلك. إرسال استرداد مالي، إلغاء طلب، تغيير صلاحية وصول - هذه هي المواضع التي يفضل فيها ترك الوكيل يعد الإجراء ويتوقف قبل التنفيذ، على الأقل في الأشهر الأولى. بمرور الوقت، عندما تُظهر المقاييس دقة عالية في مجموعة فرعية معينة، يمكن إزالة الموافقة تدريجياً وليس دفعة واحدة.

### القياس والتكلفة

تكلفة Agentforce لا تقتصر على الترخيص فقط - فهي تشمل الرموز (tokens)، واستدعاءات API، والبنية التحتية للمراقبة. الموضوع الاقتصادي الكامل، بما في ذلك أمثلة التسعير وسيناريوهات التوسع (Scale)، موجود في [سعر Agentforce](/ar/insights/agentforce-cost-tco). بدون خط أساس (Baseline) لـ "كم من الوقت يستغرق الوكيل لأداء المهمة اليوم"، من المستحيل معرفة ما إذا كان الوكيل يوفر المال أو يضيف فقط طبقة من التعقيد.

## جدول المطابقة: ملائم أم غير ملائم

لا يحل هذا الجدول محل التحليل المتعمق، ولكنه أداة تصفية سريعة قبل استثمار أسابيع في اختبار حالة استخدام (Use Case) لن تنضج على أي حال.

| حالة الاستخدام (Use Case) | المطابقة | السبب |
|---|---|---|
| الإجابة على الأسئلة الشائعة من قاعدة معرفية (Knowledge) محدثة | ملائم للغاية | معلومات مهيكلة، مخاطر منخفضة، تحسين ملموس في وقت الاستجابة |
| الاستعلام عن حالة الطلب وتحديث تفاصيل الشحن | ملائم للغاية | بيانات مغلقة في النظام، إجراء بسيط (Action)، سهل التحقق |
| تحليل اتجاهات المبيعات المعقدة لعدة سنوات | ملائم جزئيًا | يتطلب سياق عمل عميق؛ مناسب للمراحل المتقدمة فقط |
| الموافقة على الائتمان أو تغيير شروط العقد | غير ملائم في المرحلة الأولية | تأثير مالي كبير، يتطلب موافقة بشرية دائمة (Human Approval) |
| استشارة طبية، قانونية، أو تنظيمية للعميل النهائي | غير ملائم | مخاطر دعوى قضائية ومسؤولية؛ يتطلب رقابة بشرية كاملة |
| كتابة مسودة محتوى تسويقي للمراجعة البشرية | ملائم للغاية | الناتج غير نهائي، يقوم الإنسان دائمًا بمراجعته قبل النشر |

## خطة تجريبية واقعية (Pilot Plan)

### المرحلة الأولى: اختيار حالة استخدام واحدة (الأسبوع الأول)

يتم اختيار عملية واحدة من الجدول تم تصنيفها كـ "ملائمة للغاية"، وتحديد خط أساس (Baseline) (متوسط وقت المعالجة، معدل التصعيد الحالي)، وتسجيل ما يعتبر نجاحًا. يقوم الراعي التجاري (Business Sponsor) بالتوقيع على نطاق العمل.

### المرحلة الثانية: بناء Grounding وموضوع أول (الأسبوعان الثاني والثالث)

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

### المرحلة الثالثة: تشغيل داخلي مراقب (الأسبوعان الرابع والخامس)

تقوم مجموعة محدودة من المستخدمين (5-15 شخصًا) باختبار الوكيل في سيناريوهات حقيقية، بما في ذلك موافقة بشرية (Human Approval) على كل إجراء مهم. يتم جمع سجلات الأداء (Traces) والأخطاء حسب الخطورة.

### المرحلة الرابعة: القياس مقابل خط الأساس (الأسبوعان السادس والثامن)

تتم مقارنة وقت المعالجة، ومعدل النجاح، والتكلفة مقابل المرحلة الأولى. هنا تأتي معايير "المضي قدمًا/التوقف" (Go/No-Go):

- **المضي قدمًا (Go)**: معدل إنجاز المهمة بدون تصعيد يتجاوز 70%، التكلفة لكل مهمة أقل من البديل البشري، صفر حوادث أمنية أو تتعلق بالصلاحيات.
- **التوسع التدريجي**: معدل الإنجاز 50-70% - الاستمرار ولكن مع تقليص النطاق إلى مهمة فرعية كانت أكثر نجاحًا.
- **التوقف (No-Go)**: معدل الإنجاز أقل من 50%، أو حادثة واحدة تتعلق بالصلاحيات - العودة إلى مرحلة البيانات والصلاحيات قبل أي توسع.

يتم وصف اختبارات أكثر شمولاً، بما في ذلك منهجية Scorers الآلية، في [اختبارات Agentforce](/ar/insights/agentforce-testing-scorers).

## سيناريو مؤسسي نموذجي

أرادت شركة خدمات تمتلك مركز اتصال يضم 40 ممثلاً تطبيق Agentforce لتقليل عبء العمل. طلبت الإدارة "وكيلًا يجيب على كل شيء". في فحص الجاهزية، تبين وجود ثلاث قواعد معرفية (Knowledge Bases) غير متزامنة وأن معظم الاستفسارات تتطلب الوصول إلى بيانات فواتير حساسة. بدلاً من البدء على نطاق واسع، اختار الفريق حالة استخدام واحدة: الاستعلام عن حالة الطلب، والتي لا تتطلب بيانات مالية حساسة.

في غضون ستة أسابيع، تعامل الوكيل مع 62% من هذا النوع من الاستفسارات دون تصعيد، بتكلفة أقل بكثير من دقيقة مكالمة مع ممثل بشري. وفقًا لمعيار "المضي قدمًا" (Go)، وسعت الشركة تدريجيًا إلى موضوع ثانٍ - تحديث عنوان الشحن - وفقط بعد ذلك بدأت في تقييم العمليات المالية، مع موافقة بشرية دائمة (Human Approval). منع النهج التدريجي فشلاً شاملاً كان سيحدث لو أن المؤسسة اتجهت مباشرة إلى "الوكيل الذي يعرف كل شيء".

## المخاطر الشائعة والإجراءات الوقائية

| المخاطرة | كيف تبدو في الواقع | الإجراء الوقائي |
|---|---|---|
| حالة استخدام واسعة جدًا | لا يمكن قياس النجاح أو توقع السلوك | البدء بعملية ضيقة واحدة ذات حدود واضحة |
| Grounding ضعيف | إجابات واثقة ولكنها خاطئة من حيث الحقائق | مصدر معلومات واحد، مالك (Owner) وعملية تحديث منتظمة |
| صلاحيات واسعة جدًا | الوكيل يكشف معلومات لا ينبغي للمستخدم رؤيتها | التشغيل ضمن سياق المستخدم، وليس صلاحية النظام |
| تجاوز الموافقة البشرية (Human Approval) | إجراء مالي أو قانوني يتم تنفيذه بدون رقابة | موافقة بشرية إلزامية لجميع الإجراءات غير القابلة للإلغاء |
| عدم وجود خط أساس (Baseline) | "يبدو أنه يعمل" بدون دليل رقمي | قياس الوضع الحالي قبل الإطلاق، وليس بعده |

## كيف تعرف أن الوقت قد حان للتوسع

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

## قائمة مراجعة قبل اتخاذ القرار

- ☐ تم اختيار حالة استخدام (Use Case) واحدة ذات حدود واضحة، وليست "وكيلًا عامًا"
- ☐ يوجد مصدر معلومات معتمد ومحدث للمجال المختار
- ☐ صلاحيات الوكيل تتوافق مع صلاحيات المستخدم الفعلي
- ☐ تم تحديد نقاط الموافقة البشرية (Human Approval) للإجراءات غير القابلة للإلغاء
- ☐ تم قياس خط الأساس (Baseline) قبل الإطلاق، ليس فقط بعده
- ☐ توجد معايير مكتوبة مسبقًا للمضي قدمًا/التوقف (Go/No-Go)
- ☐ توجد خطة لمراقبة سجلات الأداء (Traces) والأخطاء
- ☐ تم تحديد مالك (Owner) مسؤول عن صيانة مصدر المعلومات

## الخلاصة: متى يكون مناسبًا ومتى لا يكون كذلك

Agentforce مناسب عندما تكون هناك عملية ضيقة بمصدر معلومات موثوق به، وعندما يكون تأثير الخطأ منخفضًا نسبيًا، وعندما تكون هناك طريقة لقياس النجاح مقابل خط أساس حقيقي. وهو أقل ملاءمة - على الأقل في المرحلة الأولى - للعمليات ذات التأثير المالي أو القانوني العالي، للمؤسسات التي لا تزال فيها المعلومات مشتتة وغير مُدارة، أو عندما تتوقع الإدارة نتائج فورية دون مرحلة تجريبية (Pilot). المؤسسات التي تحترم ترتيب هذه العمليات - أولاً الجاهزية، ثم تجربة أولية مدروسة، وبعد ذلك التوسع - تصل إلى نتائج أكثر استقرارًا بكثير من تلك التي تقفز مباشرة إلى التطوير. يمكن إجراء التنفيذ الفعلي بالتعاون مع [خدمات Agentforce والذكاء الاصطناعي](/ar/agentforce-ai)، التي ترافق المؤسسة من مرحلة فحص المطابقة وحتى التوسع المراقب.

## المصادر المهنية

- Salesforce – How Agentforce Works — https://www.salesforce.com/agentforce/how-it-works/
- Salesforce – Agentforce Guardrails — https://help.salesforce.com/s/articleView?id=ai.agent_plan_risks_guardrails.htm&language=en_US&type=5
- Salesforce – Agent Testing Custom Scorers — https://developer.salesforce.com/docs/ai/agentforce/guide/testing-api-custom-scorers.html
- HPI Pro – Agentforce و AI — https://hpi.pro/agentforce-ai

### أسئلة وأجوبة
**ما الفرق بين حالة الاستخدام (Use Case) المناسبة لـ Agentforce وتلك التي يفضل بناؤها كـ Flow عادي؟**
حالة الاستخدام المناسبة للوكيل تتطلب اتخاذ قرار أثناء التشغيل - الاختيار بين مسارات متعددة بناءً على اللغة الحرة أو السياق المتغير. إذا كانت العملية تسير دائمًا بتسلسل ثابت، فإن Flow أو Apex أقل تكلفة، وقابلة للاختبار بالكامل، ولا تتطلب مراقبة Traces.

**كم عدد البيانات الموثقة المطلوبة قبل بدء مشروع Agentforce التجريبي؟**
لا يتطلب الأمر توثيقًا مثاليًا، ولكن يجب أن يكون هناك مصدر حقيقة واضح لمجال واحد على الأقل: مقالات المعرفة المحدثة، حقول CRM الدقيقة، أو مستندات السياسات المعتمدة. إذا كانت 30% من الإجابات تتطلب استفسارًا بشريًا بسبب نقص المعلومات أو تناقضها، فسيفشل المشروع التجريبي بسبب البيانات وليس بسبب الوكيل.

**هل يمكن لـ Agentforce العمل دون أي موافقة بشرية على الإطلاق؟**
نعم، لإجراءات منخفضة المخاطر مثل استرجاع المعلومات أو تحديث حقل غير حساس. لأي عملية تؤثر على المال، الصلاحيات، العملاء الخارجيين، أو البيانات غير القابلة للتراجع، يوصى بمرحلة موافقة بشرية على الأقل في الأشهر الثلاثة الأولى بعد الإطلاق.

**كيف يتم قياس التكلفة مقابل الفائدة لوكيل فعليًا، وليس فقط نظريًا؟**
في مشروع تجريبي يستمر من 6-8 أسابيع، يتم بناء لوحة تحكم (Dashboard) توضح تكلفة الرموز (Tokens) والبنية التحتية مقابل عدد المهام المكتملة دون تصعيد. إذا كانت تكلفة المهمة أعلى من التكلفة التي توفرها - على سبيل المثال، ساعة عمل لممثل - فإن الوكيل غير جاهز للتوسع حتى لو كان 'يعمل'.

**ماذا يحدث إذا فشل المشروع التجريبي في معايير المضي قدمًا/الإيقاف (Go/No-Go)؟**
لا يتم التخلي عن المشروع - بل يتم تقليل النطاق (Scope). غالبًا ما ينجم الفشل عن ضعف التأسيس (Grounding) أو حالة استخدام (Use Case) واسعة جدًا، وليس عن التكنولوجيا نفسها. يتم تقسيم العملية إلى مهمة فرعية ضيقة واحدة، وتصحيح مصدر المعلومات، وإعادة الاختبار قبل الاستثمار في المزيد من التوسع.

---

## 15 سؤالاً جوهريًا يجب طرحها قبل اختيار شريك تكامل لـ Salesforce
URL: https://hpi.pro/ar/insights/questions-before-choosing-salesforce-integrator
تبدو معظم عروض Salesforce متشابهة على الورق حتى يتم فحصها بدقة من خلال 15 سؤالاً محددًا. يقسم هذا الدليل هذه الأسئلة إلى ستة محاور - من فريق العمل إلى استمرارية الخدمة - ويوضّح كيف تبدو الإجابة الضعيفة مقابل الإجابة التي يمكن الاعتماد عليها.

## الإجابة المختصرة

غالبًا ما تبدو الاقتراحات الواردة من مختلف شركات تكامل Salesforce متشابهة إلى حد كبير: نفس المفردات مثل "Discovery" و "Agile" و "Best Practice"، ونفس الوعد بـ "المرافقة عن كثب". لكن الفرق الحقيقي لا يتضح إلا عند التدقيق في كل اقتراح مقارنة بأسئلة محددة تكشف عن طريقة تفكير المورّد، وليس فقط ما يعرضه. الهدف من الأسئلة الـ 15 التالية هو الكشف عن الفجوات قبل التوقيع على العقد، وليس بعد تعثر المشروع.

تنقسم الأسئلة إلى ستة محاور رئيسية: الفريق، المنهجية، البنية التقنية، البيانات، الشروط التجارية، والاستمرارية. لكل سؤال شرح موجز لأهميته، ووصف لكيفية تبدو الإجابة الضعيفة - لتسهيل التعرف عليها في الوقت الفعلي، سواء في اجتماع أو في وثيقة عرض.

لقد فصلنا الآثار العملية للاختيار على عملية التنفيذ بأكملها في مقال منفصل حول [شركة تنفيذ Salesforce](/ar/insights/choose-salesforce-implementation-company).

## لماذا 15 سؤالاً وليس قائمة متطلبات تقنية

قائمة المتطلبات التقنية - مثل عدد بيئات الاختبار (Sandbox)، ونوع التراخيص، وأوقات اتفاقية مستوى الخدمة (SLA) – مهمة ولكنها غير كافية. فهي تختبر ما يقول المورد أنه سيفعله، وليس كيف سيتعامل مع موقف يتضح فيه أن التخطيط الأصلي غير دقيق. تم اختيار الأسئلة هنا لأنها تكشف عن أنماط العمل: كيف يوثق الفريق القرارات، وكيف يتعامل مع البيانات غير النظيفة، وماذا يحدث عندما لا تسير الأمور وفقًا للخطة.

## جدول الملخص: الإجابة القوية مقابل الإجابة الضعيفة

| الموضوع | الإجابة القوية تبدو كالتالي | الإجابة الضعيفة تبدو كالتالي |
|---|---|---|
| الفريق | "المستشارة X تقود البنية التقنية، المطور Y ينفذ، سنقدم السير الذاتية ونسمح بمقابلة قصيرة." | "لدينا فريق ذو خبرة، سنخصص الأنسب عند بدء المشروع (Kickoff)." |
| المنهجية | "دورات عمل (Sprints) لمدة أسبوعين، عرض توضيحي حقيقي في نهاية كل دورة، قائمة مهام (Backlog) مشتركة في Jira." | "نحن نعمل بمنهجية Agile، وهي مرنة ومناسبة لأي مشروع." |
| البنية التقنية | "سنبني وثيقة قرار معماري (ADR) لكل قرار رئيسي، بما في ذلك البديل الذي تم رفضه والسبب." | "سنختار الحل الأفضل بناءً على خبرتنا." |
| البيانات | "سنجري تحليل خصائص البيانات (Data Profiling) قبل العرض النهائي، وسنقوم بتقييم جودة مصادركم." | "سنتعامل مع تنظيف البيانات أثناء عملية التطوير." |
| الشروط التجارية | "سعر ثابت لنطاق عمل محدد، ساعات إضافية وفقًا لطلب تغيير موثق (Change Request)." | "نموذج الوقت والمواد (T&M) مرن لعدم تقييدكم." |
| الاستمرارية | "وثيقة تسليم، تدريب مسؤول النظام الداخلي (Admin)، أسبوعان من الدعم المكثف (Hypercare) بعد التشغيل الفعلي (Go Live)." | "نحن هنا دائمًا من أجلكم، لا داعي لبروتوكول انفصال." |

## الفريق: من سيعمل بالفعل على المشروع

### 1. من سيرافق المشروع فعليًا، وليس فقط في العرض؟

هذا السؤال حاسم لأن العديد من العروض تقدم كبار أعضاء الفريق في اجتماع المبيعات ثم تستبدلهم بمستشار مبتدئ بعد التوقيع. تتضمن الإجابة القوية أسماء، أدوار، ونسبة مخصصة من وقت العمل. الإجابة الضعيفة تبدو كـ "سنختار الأنسب حسب التوافر" – بمعنى أنه لا يوجد تخصيص حقيقي حتى اللحظة الأخيرة.

### 2. كم عدد المشاريع المتزامنة التي يديرها كل مستشار في نفس الفترة؟

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

### 3. ماذا يحدث إذا غادر المستشار الرئيسي في منتصف المشروع؟

تصف الإجابة القوية عملية تسليم موثقة، فترة تداخل (Overlap) لمدة أسبوعين، وتوثيقًا مستمرًا يسمح بالاستبدال دون فقدان المعرفة. الإجابة الضعيفة تدعي أن "هذا نادر الحدوث لدينا" دون خطة طوارئ. يمكن قراءة المزيد عن الهيكل التنظيمي الصحيح للعمل مقابل [مستشار Salesforce](/ar/insights/salesforce-consulting-guide).

## المنهجية: كيف تتم إدارة العمل فعلياً

### 4. كيف تبدو دورة العمل النموذجية (Sprint) – وماذا يحدث عندما لا يكتمل شيء في الوقت المحدد؟

تصف الإجابة القوية تخطيط دورة العمل (Sprint Planning)، اجتماعًا يوميًا قصيرًا (Daily Stand-up)، عرضًا توضيحيًا (Demo)، ومراجعة بعد دورة العمل (Retrospective)، بالإضافة إلى ما يحدث عندما تتعثر مهمة – هل يتم تأجيلها للدورة التالية بطريقة شفافة. الإجابة الضعيفة تكتفي بـ "نحن نعمل بمنهجية Agile" دون تفصيل أي إجراء عملي محدد.

### 5. كيف يبدو التواصل المستمر – القناة، التردد، والمسؤول؟

تفصّل الإجابة القوية القناة (Slack, Teams)، اجتماع حالة أسبوعي منتظم، ونقطة اتصال واحدة للتصعيد. الإجابة الضعيفة تجيب "سنكون متاحين دائمًا عبر البريد الإلكتروني"، وهذا يعني عمليًا عدم وجود اتفاقية مستوى الخدمة (SLA) للاستجابة.

### 6. كيف يتم اختبار العمل قبل تقديمه للعميل كجاهز؟

تصف الإجابة القوية اختبار ضمان الجودة (QA) الداخلي، قائمة تحقق للاستلام (Acceptance Checklist)، واختبار الوصول والصلاحيات قبل العرض التوضيحي (Demo). الإجابة الضعيفة تعترف ضمنيًا بأن العرض التوضيحي الأول للعميل هو أيضًا الاختبار الأول.

## البنية التقنية: كيف تتخذ القرارات

### 7. كيف يتم توثيق القرارات المعمارية ومن يوافق عليها؟

تقدم الإجابة القوية نموذجًا موجزًا للقرار - المشكلة، البدائل، الاختيار والسبب - الذي يتم حفظه ويكون متاحًا للعميل. الإجابة الضعيفة تقول "نحن نختار الحل الصحيح" دون توثيق سبب رفض البدائل الأخرى.

### 8. كيف سيتعامل الحل مع عبء العمل والنمو خلال سنتين إلى ثلاث سنوات؟

تشير الإجابة القوية إلى قيود Governor Limits، وحجم البيانات المتوقع، والتخطيط للتوسع. الإجابة الضعيفة تجيب "Salesforce قابلة للتوسع بطبيعتها" دون ربط ذلك بالحالة المحددة.

### 9. ماذا يحدث عندما يتعارض متطلب جديد مع قرار سابق؟

تصف الإجابة القوية عملية طلب تغيير (Change Request) تقوم بتقييم التأثير على ما تم بناؤه بالفعل. الإجابة الضعيفة تعد ببساطة بـ "سنتكيف مع أي تغيير"، وهو ما ينتهي غالبًا بدين تقني يتراكم بصمت.

## البيانات: حيث تتعثر معظم المشاريع

### 10. كيف يتم فحص جودة البيانات قبل بدء البناء؟

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

### 11. ما هو مصدر الحقيقة لكل نوع بيانات، وكيف يتم التعامل مع الازدواجية بين الأنظمة؟

تحدد الإجابة القوية مسبقًا أي الأنظمة "تفوز" في حالة التعارض (على سبيل المثال، ERP مقابل Salesforce لعميل حالي) وتوثق القاعدة. الإجابة الضعيفة تجيب "Salesforce ستكون مصدر الحقيقة" بشكل عام دون التحقق مما إذا كان ذلك صحيحًا لكل كائن.

### 12. ما هي خطة النسخ الاحتياطي والاستعادة، ومن المسؤول عنها بعد التنفيذ؟

تفصّل الإجابة القوية أدوات النسخ الاحتياطي، التردد، ومن يقوم بالاستعادة فعليًا عند الحاجة. الإجابة الضعيفة تفترض أن Salesforce "تهتم بهذا بالفعل" دون التمييز بين النسخ الاحتياطي للمنصة والنسخ الاحتياطي على مستوى المؤسسة.

## الشروط التجارية والاستمرارية: ماذا يحدث بعد التوقيع

### 13. كيف يتكون السعر – ثابت، T&M (الوقت والمواد) أو مختلط، وماذا يشمل فعليًا؟

تفصل الإجابة القوية السعر إلى مهام عمل (Workstreams) مع ساعات تقديرية لكل منها، وتحدد ما يُعد طلب تغيير (Change Request) يستدعي دفعًا إضافيًا. الإجابة الضعيفة تقدم رقمًا إجماليًا واحدًا دون تفصيل، مما يجعل من الصعب مقارنة العروض.

### 14. ماذا يحدث إذا تجاوز المشروع المدة الزمنية – من يتحمل التكلفة؟

تميز الإجابة القوية بين التجاوز الناتج عن المورد (على نفقته) والتجاوز الناتج عن تغيير المتطلبات من العميل (مدفوع الأجر). الإجابة الضعيفة تصاغ بغموض يسمح للمورد بتحميل أي تأخير على العميل.

### 15. ماذا يحدث عند انتهاء المشروع – ما نوع الدعم، وكم مدته، وبأي سعر؟

تتضمن الإجابة القوية فترة دعم مكثف (Hypercare) محددة (عادة من أسبوعين إلى أربعة)، وثيقة تسليم، وتدريب مسؤول النظام الداخلي (Admin). الإجابة الضعيفة تعد بـ "دعم مستمر" دون تحديد سعر أو نطاق أو تاريخ انتهاء واضح. يتوفر المزيد من التفاصيل حول الصياغة الصحيحة لمثل هذه البنود التعاقدية في [شروط عقد مشروع Salesforce](/ar/insights/salesforce-sow-contract-clauses).

## سيناريو تنظيمي نموذجي

تلقت شركة خدمات مالية ثلاثة عروض لدمج نظامي CRM قديمين في نظام Salesforce واحد. اثنان من العروض كانا أقل سعرًا بنسبة 20%-25% من العرض الثالث. عندما سأل الرئيس التنفيذي للمعلومات (CIO) السؤال رقم 10 (فحص جودة البيانات المبكر)، أجاب الموردان الأرخص "سنتعامل مع هذا كجزء من عملية الترحيل (Migration)" – بينما قدم المورد الأكثر تكلفة خطة تحليل خصائص البيانات (Profiling) لمدة أسبوع قبل توقيع المبلغ النهائي.

اختار التنظيم المورّد الأكثر تكلفة. كشف أسبوع تحليل خصائص البيانات عن حوالي 12,000 سجل مكرر وحقل تاريخ بتنسيق غير موّحد في 3 من مصادر البيانات. تم تضمين هذا التصحيح المبكر في التسعير الأصلي؛ أما مع الموردين الآخرين، لكان قد تم اكتشافه أثناء عملية الترحيل، كتغيير في نطاق العمل يتطلب دفعًا إضافيًا.

الدرس المستفاد هنا ليس "الرخيص دائمًا سيء" – بل هو أن الفجوة بين الإجابة المفصلة والإجابة العامة تساوي أموالًا حقيقية، ولا يمكن الكشف عنها إلا من خلال أسئلة محددة قبل التوقيع، وليس بعده.

## قائمة تحقق لمقارنة العروض

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

## ملاحظة ختامية: الأسئلة أداة، وليست طقسًا

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

عند الافتقار إلى القدرة الداخلية لإجراء عملية مقارنة كهذه بأنفسكم، فإن [خدمة الاستشارات والتحديد المبدئي للمتطلبات](/ar/consulting-discovery) هي المسار العملي للمضي قدمًا – بما في ذلك بناء بطاقة تقييم مرجحة، والمرافقة في الاجتماعات مع مقدمي العروض، ومقارنة الإجابات مقابل معايير موضوعية.

## مصادر احترافية

- HPI Pro – استشارات وتحديد المبدئي للمتطلبات — https://hpi.pro/consulting-discovery
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – خدمات Salesforce — https://hpi.pro/services

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

**ماذا نفعل عندما يرفض المورد الإجابة كتابيًا على بعض الأسئلة؟**
هذه علامة تحذير مهمة، وليست مجرد مسألة فنية. الإجابة الشفهية من السهل نسيانها أو إنكارها لاحقًا. إذا أوضح المورد أن الإجابة 'تعتمد على المشروع'، يمكن طلب نطاق أو افتراض عمل صريح - الرفض المطلق يبرر الاستمرار في البحث عن مُقَدِّم آخر.

**هل يُسمح بطرح هذه الأسئلة على مورد حالي عند تجديد العقد؟**
نعم، وفي بعض الأحيان يكون ذلك أكثر أهمية. المورد الحالي الذي اكتسب معرفة داخلية قد يتوقف أحيانًا عن التوثيق ومراجعة نفسه مع مرور الوقت. الفحص الدوري كل 12-18 شهرًا يكشف عن التآكل في الفريق، التوثيق، أو أوقات الاستجابة قبل أن يصبح اعتمادًا خطيرًا.

**ما هو الوزن النسبي الذي يجب إعطاؤه لكل من المحاور الستة في اتخاذ القرار؟**
لا توجد صيغة موحدة، ولكن بالنسبة للمشروع الأول الذي يحتوي على بيانات متعددة المصادر، يجب إعطاء الفريق والبيانات معًا حوالي 45% من النقاط، للمنهجية والبنية حوالي 35%، والجوانب التجارية والاستمرارية الباقي. عند تجديد عقد قائم، ينتقل الوزن إلى الاستمرارية والجوانب التجارية.

**ما الأفضل - مورد يقدم سعرًا منخفضًا مع إجابات عامة، أم مورد أغلى مع إجابات مفصلة؟**
الإجابة المفصلة تستحق أكثر في جميع الأحوال تقريبًا. فرق السعر بنسبة 15-20% أقل أهمية بكثير مقارنة بتكلفة إعادة العمل (Rework) بسبب افتراض خاطئ حول البيانات أو الصلاحيات. السعر المنخفض مع نطاق عمل غامض غالبًا ما يعني نفس العمل مع مفاجآت لاحقًا.

---

## كيفية إنقاذ مشروع Salesforce متعثر؟ منهجية التشخيص والإنقاذ
URL: https://hpi.pro/ar/insights/rescue-stalled-salesforce-project
يبدو مشروع Salesforce المتعثر وكأنه مشكلة تطوير، لكن في معظم الحالات يتعلق الأمر بمزيج من نطاق عمل غير واضح، وقرارات معمارية لم تُتخذ، وثقة تلاشت. يقدم الدليل خطة تشخيص لمدة 10 أيام وخطة إنقاذ لمدة 90 يومًا.

## الإجابة المختصرة

غالبية مشاريع Salesforce المتعثرة لم تتوقف بسبب جودة التعليمات البرمجية. بل توقفت لعدم توقف أي شخص في الوقت المناسب لسؤال: ما الذي سيتغير فعلاً في عمل المستخدمين، ومن المسؤول عن كل قرار، وماذا يحدث عندما لا تسير الأمور وفق الخطة؟ النتيجة: سباقات Sprint متتالية تضيف ميزات دون تحسين الصورة الكلية.

إنقاذ مشروع Salesforce متعثر يعني أولاً إيقاف النزيف، ثم فقط تحديد ما يجب فعله بما تم بناؤه بالفعل. هذا الترتيب حيوي: تتجاوز العديد من المؤسسات مباشرة إلى مرحلة الإصلاح دون تشخيص سبب فشل العملية السابقة، مكررةً نفس الخطأ للمرة الثانية. يمكن لمن يرغب في فهم كيفية تحديد أولويات الديون المتراكمة في الطريق التعمق في [تحديد أولويات الديون التقنية في Salesforce](/ar/insights/salesforce-technical-debt-prioritization).

## علامات التعثر: كيف تعرف أن المشروع لم يعد على المسار الصحيح

هناك فرق بين مشروع يتقدم ببطء ومشروع توقف تماماً. تتكرر العلامات التالية في كل عملية إنقاذ تقريباً قمنا بها:

- **تحول اجتماعات الحالة إلى اجتماعات تبرير**: اجتماع حالة أسبوعي يتحول إلى تقديم مبررات لعدم جاهزية شيء ما حتى الآن، دون تحديد موعد نهائي جديد وموثوق.
- **نمو قائمة الأعمال المتراكمة (Backlog) أسرع من معدل الإغلاق**: تتم إضافة عناصر جديدة كل أسبوع، لكن عدد العناصر المغلقة يظل ثابتاً أو يتناقص.
- **عدم وجود إصدار تم اختباره مع مستخدم حقيقي في الشهر الأخير**: عرض توضيحي داخلي فقط من قبل الفريق التقني، دون أي تواصل مع من سيعملون فعلياً على النظام.
- **تغيير متكرر للمتطلبات دون توثيق**: كل محادثة تولّد "تعديلاً صغيراً آخر" لا يتم إدخاله في وثيقة نطاق عمل (Scope Document) منظمة.
- **فقدان الثقة العلني**: يبدأ المستخدمون في إنشاء جداول بيانات Excel موازية "للاحتياط"، وهذه علامة على أنهم فقدوا الثقة في أن النظام سيعمل في الوقت المناسب.

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

## تشخيص في 10 أيام: ماذا تفحص وبأي ترتيب

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

**الأيام 1-2: مقابلات ورسم خرائط مبدئي.** محادثات قصيرة مع الراعي (Sponsor)، ومالك العملية، واثنان إلى ثلاثة من المستخدمين النهائيين، ورئيس فريق التطوير. الهدف هو جمع روايات مختلفة عن "ماذا حدث خطأ"، وليس الوصول إلى استنتاج بعد.

**الأيام 3-5: فحص تقني مباشر.** المراجعة الفعلية لمنصة Salesforce (Org): هيكل البيانات، الأتمتة الحالية، الصلاحيات، سجلات الأخطاء، والاستعلامات البطيئة. هنا يتم التحقق مما إذا كانت المشكلة معمارية أم تشغيلية.

**الأيام 6-7: مقارنة ما تم الوعد به بما تم بناؤه.** قراءة المستندات الأصلية (SOW, User Stories, Design Docs إن وجدت) مقابل الوضع الفعلي في بيئة الاختبار (Sandbox) أو بيئة الإنتاج (Production).

**الأيام 8-10: بلورة النتائج واتخاذ قرار مبدئي.** مستند قصير يصنف كل مشكلة تم العثور عليها على أنها مشكلة نطاق عمل (Scope)، أو بنية معمارية (Architecture)، أو ثقة (Trust)، ويقدم توصية أولية: إعادة تعيين (Reset)، أو إعادة هيكلة (Refactor)، أو الاستمرار بوتيرة معدلة.

## ثلاث طبقات للمشكلة: النطاق، البنية المعمارية، والثقة

الخطأ الأكثر شيوعاً هو معالجة كل تعثر وكأنه مشكلة واحدة. في الواقع، يكاد يكون دائماً مزيجاً من ثلاث طبقات مختلفة، تتطلب كل منها نهجاً مختلفاً.

**تظهر مشكلة النطاق (Scope)** في أن لا أحد يعرف حقاً ما الذي يدخل في الإصدار الأول. يحدث هذا عندما يكون التعريف الأصلي عاماً جداً ("إدارة عملية المبيعات بأكملها في Salesforce") ولم يتم تقسيمه إلى سيناريوهات ملموسة. الحل ليس اجتماع تخطيط آخر، بل كتابة قائمة حادة من المهام التي "يجب/ ينبغي/ لاحقاً" (Must/Should/Later)، مع تحديد مسؤول (Owner) لكل بند.

**تظهر مشكلة البنية المعمارية (Architecture)** في الاختيارات التقنية التي لا تصمد على نطاق واسع: نموذج بيانات لا يدعم حجم السجلات، أتمتة تعمل بترتيب غير صحيح، تكاملات تتعطل بصمت. هنا يتطلب الأمر فحصاً تقنياً معمقاً، وأحياناً تدخل [ترقية نظام Salesforce](/ar/insights/salesforce-system-upgrade-signs) كبنية تحتية موازية للإصلاح.

**مشكلة الثقة (Trust)** غالباً ما تكون نتيجة المشكلتين الأوليين، لكنها تكتسب حياة خاصة بها: يتوقف المستخدمون عن الإبلاغ عن المشكلات لأن "إصلاحها غير مجدٍ على أي حال"، وتتوقف الإدارة عن تمويل التغييرات لأن "لقد جربنا بالفعل". مشكلة الثقة لا تُحل بالتصريحات، بل بالأدلة الصغيرة والمتكررة فقط.

### جدول التشخيص: العرض، السبب الجذري، والخطوة الأولى

| العرض المرئي | السبب الجذري المحتمل | الخطوة الأولى الموصى بها |
|---|---|---|
| كل محادثة تولّد متطلباً جديداً | نطاق عمل غير مغلق مطلقاً، لا يوجد تعريف لخارج النطاق | كتابة وثيقة نطاق عمل تتضمن بنداً صريحاً "ما لا يشمله هذا الإصدار" والحصول على توقيع موافقة عليه |
| التقارير تعرض أرقاماً متضاربة | مصادر متعددة وموثوقة للمعلومات، بدون مصدر وحيد للحقيقة (Single Source of Truth) | تحديد الحقل/الكائن الرسمي للمصدر وإلغاء تكرار التقارير |
| النظام "يتعطل" عند حمولة متوسطة | أتمتة غير فعالة أو حلقات تحديث | تحليل الأداء (Profiling) لتدفقات Flow وApex تحت حمولة محاكاة، قبل أي إصلاح جزئي |
| المستخدمون يعودون إلى Excel | عدم الثقة في أن النظام سيعكس الوضع الحقيقي | إصلاح سريع لمشكلة واحدة تؤثر يومياً، والتواصل العلني بالإصلاح |
| الفريق التقني لا يشرح خياراته | فجوات في الاتصال بين الأعمال وتقنية المعلومات، وليست بالضرورة مشكلة تقنية | اجتماع توضيحي قصير يتم فيه عرض كل قرار تقني بمصطلحات تجارية |
| كل إصدار يؤجل موعداً نهائياً | نمو النطاق أثناء العمل دون رقابة | تجميد التغييرات (Change Freeze) حتى اكتمال الموجة الحالية |

## إعادة التعيين (Reset) مقابل إعادة الهيكلة (Refactor): كيف تتخذ القرار

هذا هو القرار المركزي والأكثر تكلفة، لذلك يجب أن يعتمد على معايير وليس على الحدس. تساعد ثلاثة اختبارات:

1. **مدى الدين التقني مقابل حجم ما يعمل بالفعل.** إذا كانت 70% من الوظائف تعمل بشكل معقول وفقط أجزاء معينة تفشل، فهذه إعادة هيكلة (Refactor). إذا كانت المشكلة تكمن في نموذج البيانات الأساسي، فإن إعادة التعيين الجزئي (Partial Reset) تكون دائماً تقريباً هي الأفضل.
2. **تكلفة الشرح مقابل تكلفة إعادة البناء.** إذا استغرق الفريق الجديد أكثر من أسبوع لفهم سبب بناء شيء بطريقة معينة، فمن المحتمل أن تتجاوز تكلفة الصيانة المستقبلية تكلفة البناء النظيف.
3. **حالة ثقة المستخدمين.** عندما تكون الثقة منخفضة جداً، فإن إعادة التعيين الموجهة والعلنية (مع الإعلان "نحن نبدأ إصداراً جديداً ومصححاً") تحقق أحياناً تعاوناً أكبر من الإصلاح الصامت الذي لا يلاحظه المستخدمون.

في الواقع، معظم عمليات الإنقاذ الناجحة هي هجينة: إعادة تعيين (Reset) للمكون الأساسي المشكل (مثل نموذج الفرص Opportunity model أو عملية الموافقات)، إلى جانب إعادة هيكلة (Refactor) لبقية النظام. تظهر مقارنة منظمة بين الأساليب في [إعادة بناء Salesforce](/ar/insights/salesforce-rebuild-vs-refactor)، والتي توضح المعايير لكل سيناريو.

## خطة إنقاذ لمدة 90 يوماً

| المرحلة | الأيام | الهدف الرئيسي | ناتج قابل للقياس |
|---|---|---|---|
| الاستقرار | 1-10 | إيقاف الضرر، تجميد التغييرات في المناطق الحساسة | تشخيص كامل وقائمة بالمخاطر |
| القرار | 11-20 | إعادة تعيين مقابل إعادة هيكلة، نطاق نهائي للموجة الأولى | وثيقة قرار موقعة مع تحديد المسؤول (Owner) |
| الموجة الأولى | 21-50 | إصلاح المشكلة الأكثر إيلاماً للمستخدمين | سيناريو End-to-End عامل وتم اختباره |
| التوسيع | 51-75 | إضافة قدرات وفقاً لأولوية متفق عليها | عمليتان إلى ثلاث عمليات إضافية قيد الاستخدام |
| الاستقرار والإغلاق | 76-90 | القياس مقابل خط الأساس (Baseline)، تسليم الحوكمة (Governance) | لوحة تحكم (Dashboard)، توثيق، وخطة صيانة |

من المهم تخطيط مرحلة "الموجة الأولى" حول عملية واحدة سيشعر بها المستخدمون في غضون أسابيع، وليس حول المكون الأكثر إثارة للاهتمام تقنياً. غالباً ما تفشل المشاريع للمرة الثانية لأنها عادت إلى نفس الخطأ: بدأت بالقدرة المبهرة بدلاً من المعاناة الحقيقية. ترتبط هذه المرحلة مباشرة بالأداء الفعلي أيضاً، ويمكن لمن يواجهون مشكلات في سرعة الاستجابة قراءة [تحسين أداء Salesforce](/ar/insights/salesforce-performance-optimization).

## استعادة الثقة مع المستخدمين

الثقة لا تعود بسبب عرض تقديمي، بل تعود بسبب نمط ثابت من الوفاء بوعد صغير. بعض المبادئ التي نجحت على أرض الواقع:

- **أعلن بوضوح عن انتصار صغير.** عندما تصلح خطأ متكرراً، أرسل رسالة قصيرة تحدد بالضبط ما تم إصلاحه ومن طلب ذلك. هذه الشفافية تبني ثقة أكبر من قائمة الإنجازات الشاملة.
- **ادعُ المستخدمين للاختبار المبكر، وليس فقط لاختبار قبول المستخدم (UAT) في النهاية.** من يرى إصداراً وسيطاً ويشعر بأن ملاحظاته تم أخذها في الاعتبار، يصبح سفيراً للمشروع أمام بقية الفريق.
- **لا تعد بتاريخ لست متأكداً منه.** التاريخ الذي يؤجل للمرة الثالثة يضر بالثقة أكثر من جدول زمني واقعي ولكنه أقل تفاؤلاً.
- **وثق الفشل علناً أيضاً.** عندما لا يعمل شيء ما، فإن شرحاً قصيراً عما حدث وما الذي يتغير يبني مصداقية أكبر من التجاهل الصامت.

غالباً ما تستغرق عملية استعادة الثقة وقتاً أطول من الإصلاح التقني نفسه، لذا ينبغي التخطيط لها كمسار موازٍ لخطة 90 يوماً وليس كنتيجة تلقائية لها. يمكن للمنظمات التي ترغب في دعم منظم لهذه العملية، بما في ذلك الدعم الوثيق للفريق والإدارة، الاستفادة من [خدمة Salesforce Health Check](/ar/salesforce-health-check) كإطار عمل كامل.

## مثال على سيناريو مؤسسي

أدارت شركة خدمات مالية مشروع Salesforce لمدة تسعة أشهر دون تشغيل مباشر (Go Live). أظهر الفحص أن النطاق (Scope) تضخم ثلاثة أضعاف التخطيط الأصلي، وأن الفريق التقني بنى ثلاث نسخ مختلفة لنفس عملية الموافقات دون توثيق السبب، وأن المستخدمين الرئيسيين (Key Users) انتقلوا بالفعل إلى إدارة التقرير الشهري في جدول بيانات منفصل.

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

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

## قائمة المراجعة قبل اتخاذ قرار بالإنقاذ

- ☐ تم إجراء تشخيص لمدة 10 أيام يتضمن مقابلات، فحص منصة Salesforce (Org)، ومقارنة بالوثائق الأصلية.
- ☐ تم تصنيف المشكلات بوضوح إلى نطاق (Scope)، أو بنية معمارية (Architecture)، أو ثقة (Trust).
- ☐ تم اتخاذ قرار إعادة تعيين/إعادة هيكلة موثق مع المبررات.
- ☐ تم اختيار عملية واحدة للموجة الأولى بناءً على معاناة حقيقية للمستخدمين.
- ☐ تم تحديد تجميد للتغييرات (Change Freeze) خلال فترة التشخيص والقرار.
- ☐ تم تحديد مقاييس خط الأساس (Baseline) قبل بدء الإصلاح.
- ☐ توجد خطة اتصال مستمرة للمستخدمين والإدارة.
- ☐ تم تعيين مالك (Owner) وحيد يحتفظ بخريطة القرارات بأكملها.
- ☐ تتضمن خطة الـ 90 يوماً مراحل قابلة للقياس وليست مجرد تاريخ انتهاء.
- ☐ تم تحديد عملية لتسليم الحوكمة (Governance) والصيانة عند الانتهاء من عملية الإنقاذ.

## مصادر احترافية

- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check
- HPI Pro – الدعم والإرشاد — https://hpi.pro/support

### أسئلة وأجوبة
**ما الفرق بين مشروع 'بطيء' ومشروع 'متعثر' حقًا؟**
المشروع البطيء لا يزال يولد قرارات وتقدمًا قابلاً للقياس، وإن كان بوتيرة منخفضة. المشروع المتعثر هو الذي تمر فيه أسبوعان إلى ثلاثة أسابيع دون قرار جديد، دون إصدار تم اختباره مع مستخدم حقيقي، ودون تغيير في حالة الـ Backlog. إذا لم يكن هناك إجابة واضحة على سؤال 'ماذا حدث هذا الأسبوع؟'، فمن المحتمل أن يكون المشروع متعثرًا.

**من يجب أن يقود عملية التشخيص، مستشار خارجي أم شخص من الفريق الداخلي؟**
يُفضل أن يقود طرف خارجي مرحلة التشخيص، لأنه لا يتحمل مسؤولية القرارات السابقة ويمكنه طرح أسئلة غير مريحة دون إثارة ردود فعل دفاعية. يجب أن يكون الفريق الداخلي شريكًا كاملاً في المقابلات ومراجعة البيانات، وإلا ستُعتبر الاستنتاجات مجرد نقد خارجي وليست أساسًا للعمل المشترك.

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

**كم من الوقت يستغرق رؤية التحسن الأول الذي سيشعر به المستخدمون؟**
في المشاريع التي تم فيها التشخيص بشكل صحيح، يظهر التحسن الملموس الأول خلال 3-4 أسابيع من بدء خطة الـ 90 يومًا، عادةً من خلال إصلاح خطأ متكرر أو تقصير عملية يومية. التحسين الهيكلي الأعمق، مثل إصلاح نموذج البيانات، يستغرق ما بين 6 إلى 12 أسبوعًا اعتمادًا على حجم الدين التقني.

**ماذا يحدث إذا فقد الراعي الأصلي الثقة بالمشروع؟**
هذا هو أقوى مؤشر على الحاجة إلى الإنقاذ، وليس سببًا للاستسلام. الخطوة الأولى هي بناء رؤية صغيرة وقابلة للقياس لذلك الراعي خلال أسبوعين، على سبيل المثال إصلاح خطأ يزعجه شخصيًا كل يوم. تُبنى الثقة من جديد من خلال إثباتات صغيرة ومتكررة، وليس من خلال عرض تقديمي لخطة مفصلة.

---

## كيفية تحديد MVP لمشروع Salesforce دون إنشاء نظام مؤقت
URL: https://hpi.pro/ar/insights/salesforce-mvp-scope
الفرق بين MVP والنظام نصف المكتمل لا يكمن في عدد الميزات، بل في القرارات التي تم حسمها. الموجة الأولى الصحيحة تحسم نموذج البيانات والصلاحيات بالكامل، وتقلص النطاق العملي. يقدم هذا المقال اختبارًا دقيقًا لحدود MVP وجدول قرارات مسموح بتأجيلها وغير مسموح بها.

## الاختبار الذي يفرق بين الحد الأدنى للمنتج القابل للتطبيق (MVP) والنظام المؤقت

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

القاعدة العملية: **في الموجة الأولى، يتم تضييق النطاق التجاري، وليس العمق المعماري.** يُسمح بتضييق عدد العمليات، والوحدات، وأنواع العملاء المستهدفين. ولكن لا يُسمح بتضييق نموذج البيانات الأساسي، أو نموذج الصلاحيات، أو تعريف مصدر الحقيقة — فهذه العناصر تُبنى بشكل صحيح مرة واحدة، حتى لو خدمت مبدئيًا خمسين مستخدمًا فقط.

من يضيق العمق بدلاً من النطاق، يحصل على نظام يعمل لربع سنة ثم يُعاد بناؤه. يتوفر السياق الأوسع لمراحل المشروع في [دليل تنفيذ Salesforce](/ar/insights/salesforce-implementation-guide).

## ثلاثة تعريفات يختلط الأمر بينها

| المصطلح | ما يعنيه في الواقع | متى يكون مناسبًا | الخطر الرئيسي |
|---|---|---|---|
| Proof of Concept | إثبات الجدوى الفنية لمكون واحد | عندما يكون هناك شك حقيقي في إمكانية تحقيق شيء ما | يميلون إلى دفعه نحو الإنتاج |
| Pilot | تشغيل كامل على مجموعة محدودة | عندما يكون الحل معروفًا والسؤال يدور حول التبني | المجموعة غير ممثلة بما فيه الكفاية |
| MVP | الإصدار الأول في الإنتاج الذي يولد قيمة حقيقية | عندما يراد التعلم من الاستخدام الفعلي | يصبح دائمًا بدون قرار |

الاختيار بين هذه الثلاثة ليس مسألة دلالية. يمكن التخلص من PoC، بينما لا يمكن التخلص من MVP — ولذلك يجب بناء MVP بمعايير الإنتاج فقط.

## القرارات التي لا يجوز تأجيلها

هناك مجموعة من القرارات التي تزداد تكلفة تغييرها بشكل كبير بعد وجود بيانات في مرحلة الإنتاج. وهذه القرارات يجب أن تُدرج في الموجة الأولى، حتى لو كانت تخدم جزءًا صغيرًا من الصورة العامة في البداية:

- **الكائن الذي يحمل العملية التجارية** وعلاقته بالكيانات الأساسية.
- **المفتاح الفريد الذي يحدد العميل** في مواجهة الأنظمة الخارجية.
- **إعداد الرؤية الافتراضية** لكل كائن مركزي.
- **هيكل ملكية السجل** — من هو المالك وماذا يحدث عندما يغادر الموظف.
- **تعريف مصدر الحقيقة** لكل كيان تتم مزامنته مع نظام آخر.

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

## كيف يتم اختيار عملية الموجة الأولى

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

اعتبار آخر هو الحجم: العملية التي تحدث عشر مرات في الشهر لن تولد استخدامًا كافيًا للتعلم منها خلال ربع سنة.

## معيار الخروج — ما الذي يدل على نجاح الموجة

يتحول الـ MVP بدون معيار خروج إلى حالة دائمة. يجب أن يكون المعيار قابلاً للقياس، ومختصرًا، ومعروفًا مسبقًا. مثال على الهيكل:

- نسبة من العمليات من النوع المختار تتم فعليًا داخل النظام وليس خارجه.
- عدم وجود عطل حاجز مفتوح لأكثر من عدد محدد من الأيام.
- البيانات التي تم إنشاؤها خلال الفترة تستوفي عتبة الجودة المحددة مسبقًا.
- يؤكد مالك العملية كتابيًا أن العملية تعمل بدون ممارسة التحايل الدائمة.

لاحظ أن أياً من هذه المعايير ليس "تم إطلاق النظام". هذا التاريخ هو نقطة بداية القياس وليست نهايته.

## تكلفة التأجيل — الأداة التي تحسم نقاشات النطاق

عندما يُجادل حول ما إذا كانت القدرة ستُدرج في الموجة الأولى، فإن السؤال المفيد ليس كم تكلف بناؤها الآن، بل كم تكلف بناؤها لاحقًا. يستخدم الجدول التالي كأداة عمل في اجتماع تحديد النطاق:

| نوع القدرة | تكلفة البناء في الموجة الأولى | تكلفة البناء في الموجة الثانية | الخلاصة |
|---|---|---|---|
| تغيير في بنية الكائن الأساسي | منخفضة | عالية جدًا — تشمل الترحيل | تُدرج في الموجة الأولى |
| نموذج صلاحيات جديد | متوسطة | عالية — حدث الكشف بالفعل | يُدرج في الموجة الأولى |
| تقرير إداري | منخفضة | منخفضة | يُؤجل |
| أتمتة تنبيه | منخفضة | منخفضة | يُؤجل |
| تكامل مطلوب لاتخاذ قرار فوري | عالية | عالية + ممارسة التحايل مترسخة | تُدرج إذا كانت العملية تعتمد عليه |
| تكامل لأغراض الإبلاغ فقط | متوسطة | متوسطة | يُؤجل |

## مثال توضيحي: شركة لوجستيات دولية

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

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

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

## علامات تحول الـ MVP إلى نظام مؤقت

- وجود عملية يدوية دائمة مخصصة "لسد الفجوة حتى الموجة التالية" وهي تعمل منذ شهرين.
- تم الاتفاق على حقل يستخدم لغرضين مختلفين لعدم وجود وقت للتقسيم.
- وجود مجموعة من المستخدمين يعملون بالتوازي في نظامين.
- لا يوجد تاريخ محدد لاتخاذ قرار للموجة التالية، بل قائمة انتظار فقط.

تظهر هذه الأنماط بتفصيل أكبر إلى جانب إخفاقات أخرى في [دليل الأخطاء الشائعة في تنفيذ CRM](/ar/insights/crm-implementation-mistakes).

## التكامل مع الجدول الزمني الإجمالي

يؤثر تعريف الحد الأدنى للمنتج القابل للتطبيق (MVP) بشكل مباشر على مدة المشروع، وأحيانًا في الاتجاه المعاكس للمتوقع: فالموجة الأولى الضيقة جدًا تطيل مدة المشروع الإجمالية، لأن كل موجة تتحمل تكلفة ثابتة للاختبار والتدريب والإطلاق. كيفية ترجمة ذلك إلى تخطيط واقعي مفصل في [دليل مدة مشروع Salesforce](/ar/insights/salesforce-project-timeline)، وفي حالة استبدال نظام موجود أيضًا في [دليل الانتقال إلى Salesforce](/ar/insights/replace-crm-with-salesforce).

## الخطوة التالية

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

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

**هل يمكن تأجيل التكامل مع نظام أساسي للموجة الثانية؟**
ممكن، بشرط ألا تعتمد العملية في الموجة الأولى عليه لاتخاذ قرار. إذا اضطر مندوبو المبيعات إلى فتح نظام ERP بالتوازي لمعرفة المخزون أو رصيد الائتمان، فإن تأجيل التكامل لا يوفر العمل بل يخلق ممارسة التفافية يصعب التخلص منها لاحقًا.

**من يقرر ما الذي يبقى خارج MVP؟**
القرار يقع على عاتق الراعي التجاري باقتراح من مالك العملية والمهندس المعماري، وليس لجنة. والسبب عملي: إخراج قدرة من الموجة الأولى هو تنازل سياسي، ولا يمكن لأي جهة تتمتع بسلطة ميزانية أن تدعم ذلك دون أن تعود القدرة إلى الداخل من خلال طلبات التغيير.

**كيف نمنع أن يصبح MVP دائمًا؟**
يتم تحديد معيار خروج قابل للقياس وتاريخ قرار للموجة التالية مقدمًا، وليس فقط قائمة متابعة. بالإضافة إلى ذلك، لا يسمح للموجة الأولى بتجاوز القرارات المعمارية: نظام يبقى دائمًا على نموذج بيانات صحيح هو نتيجة معقولة، ونظام يبقى دائمًا على حل مؤقت هو دين.

**هل MVP مناسب أيضًا لاستبدال نظام CRM موجود؟**
نعم، ولكن يتم تحديد الحد بشكل مختلف. عند الاستبدال، هناك ضغط لنقل كل ما كان يفعله النظام القديم، وبالتالي يتم تعريف الموجة الأولى بناءً على مجموعة مستخدمين أو وحدة عمل وليس بناءً على مجموعة فرعية من القدرات. التشغيل المتوازي لنظامين لنفس المجموعة يخلق عملًا مزدوجًا ويؤثر على مصداقية البيانات.

---

## فريق مشروع Salesforce: الأدوار، المسؤوليات، ونموذج العمل مع المورد
URL: https://hpi.pro/ar/insights/salesforce-project-team-roles
يحدّد دورا رئيسيان ما إذا كان مشروع Salesforce سيلتزم بالجداول الزمنية، وهما دائمًا يخصّان العميل وليس المورد. نُحدّد هنا الأدوار التسعة المطلوبة، الأهمية المحورية لكل دور، أيٌّ منها لا يمكن شراؤه من الخارج، وكيف يبدو جدول RACI الذي يمنع انتظار القرارات.

## الأدوار التي تحدد وتيرة المشروع

في مشروع Salesforce، قد تقوم بتعيين مهندس معماري متميز، وفريق تطوير ذي خبرة، ومدير مشروع مُنظّم، ومع ذلك تتأخر عن الجدول الزمني. السبب الشائع ليس وتيرة البناء، بل وتيرة اتخاذ القرار. التطوير ينتظر قرارًا، والقرار ينتظر اجتماعًا، والاجتماع ينتظر موعدًا.

لذلك، فإن التقسيم الفعال للأدوار لا يعتمد على من يفعل ماذا، بل على **من يقرر ماذا وفي أي وقت استجابة**. يمكن مراجعة الخطوات التي يتطلبها كل دور في [دليل تنفيذ Salesforce](/ar/insights/salesforce-implementation-guide).

## الأدوار التسعة وصلاحيات كل منها

**Executive Sponsor** (الراعي التنفيذي) — يتخذ القرارات بين الإدارات، ويوافق على التنازلات في نطاق العمل، ويدافع عن الأولوية في مواجهة الضغوط المتزامنة. إذا لم تكن لديه صلاحية ميزانية، فهو ليس راعيًا بل ممثلًا.

**Process Owner** (مالك العملية) — يحدد كيفية تنفيذ العمل فعليًا بعد التغيير، ويؤكد أن العملية المُنشأة تتوافق مع الواقع. يجب أن يكون هناك مالك واحد لكل عملية أساسية، وليس لجنة.

**Product Owner / CRM Manager** (مالك المنتج / مدير CRM) — يدير أولويات قائمة المهام المتأخرة (backlog)، ويتخذ القرارات بين الطلبات المتنافسة، ويحافظ على العلاقة بين المتطلبات والقيمة.

**Project Manager** (مدير المشروع) — مسؤول عن الجدول الزمني، والتبعيات، والمخاطر، وتنسيق الموردين، وإعداد التقارير.

**Solution Architect** (مهندس الحلول) — يتخذ القرارات بشأن نموذج البيانات، والصلاحيات، وحدود النظام، وطريقة التنفيذ؛ ومسؤول عن توثيق البدائل التي تم النظر فيها.

**Salesforce Admin** (مسؤول Salesforce) — مسؤول عن التهيئة (configuration)، والبيئات، وإدارة المستخدمين، والصيانة الروتينية بعد الإطلاق.

**Developer** (المطور) — مسؤول عن المنطق المخصص (custom logic)، والتكاملات (integrations)، والاختبارات الآلية (automated tests).

**Data Owner** (مالك البيانات) — يحدد مصدر الحقيقة، وما يعتبر سجلًا صحيحًا، ومن يوافق على تحميل البيانات.

**Adoption & Training Lead** (مسؤول التبني والتدريب) — مسؤول عن التواصل، والتدريب حسب الدور، وإدارة المقاومة، وقياس الاستخدام.

في المشاريع الصغيرة، يمكن لشخص واحد تولي دورين، ولكن هناك زوجان من الأدوار لا ينصح بالجمع بينهما: المهندس المعماري ومدير المشروع (تضارب بين الدقة والسرعة)، ومالك العملية ومسؤول الاختبارات (يختبر عمله الخاص).

## من يجب أن يكون داخليًا

| الدور | يمكن توفيره خارجيًا | الشرح |
| --- | --- | --- |
| Executive Sponsor | لا | يتطلب سلطة تنظيمية |
| Process Owner | لا | يتطلب ملكية العمل الفعلي |
| Data Owner | لا | يتطلب مسؤولية تنظيمية وتجارية |
| Product Owner | جزئيًا | يمكن تقديم الدعم، وليس الاستبدال |
| Project Manager | نعم | شائع ومقبول |
| Solution Architect | نعم | يُفضل مع دعم داخلي للمعرفة |
| Admin | نعم، مؤقتًا | يُفضل نقله إلى داخلي قبل الإطلاق |
| Developer | نعم | قياسي |
| Adoption Lead | جزئيًا | يجب أن تأتي الرسالة الداخلية من المنظمة |

## جدول RACI لنقاط اتخاذ القرار الرئيسية

| القرار | المسؤول (Accountable) | المستشار (Consulted) | وقت الاستجابة المطلوب |
| --- | --- | --- | --- |
| هيكل نموذج البيانات | المهندس المعماري | مالك العملية، مالك البيانات | حتى أسبوع |
| تغيير في نطاق العمل | الراعي التنفيذي | مالك المنتج، مدير المشروع | حتى أسبوع |
| ترتيب أولويات قائمة المهام المتأخرة | مالك المنتج | مالكي العمليات | حتى يومين |
| تعريف حقل إلزامي | مالك العملية | المسؤول الإداري | حتى يومين |
| الموافقة على تحميل البيانات | مالك البيانات | المهندس المعماري | حتى ثلاثة أيام |
| الموافقة على الانتقال للإنتاج | الراعي التنفيذي | مدير المشروع، مالك العملية | وفقًا لبوابة محددة |
| حل مشكلة حظر | مدير المشروع | المهندس المعماري، المسؤول الإداري | في نفس اليوم |

عمود وقت الاستجابة هو الجزء المثير للاهتمام في الجدول. جدول RACI بدون اتفاقية مستوى الخدمة (SLA) للقرار هو وصف لطيف لا يغير الوتيرة.

## التوفر الواقعي — الخطأ المتكرر في التخطيط

| الدور | التوصيف | البناء | الاختبارات | الإطلاق والأسابيع التي تليه |
| --- | --- | --- | --- | --- |
| الراعي التنفيذي | منخفض، ثابت | منخفض | متوسط | متوسط |
| مالك العملية | عالٍ | متوسط | عالٍ جدًا | عالٍ |
| مالك المنتج | عالٍ | عالٍ | عالٍ | متوسط |
| المسؤول الإداري | متوسط | عالٍ | عالٍ | عالٍ جدًا |
| مالك البيانات | متوسط | منخفض | عالٍ | متوسط |
| مسؤول التبني | منخفض | متوسط | متوسط | عالٍ جدًا |

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

## مثال توضيحي: كلية أكاديمية

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

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

## نموذج العمل مع المورد

ثلاث آليات كافية لمعظم المشاريع:

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

في المؤسسات الكبيرة، تتطلب طبقة إضافية من الحوكمة بين الوحدات التجارية، كما هو موضح في [دليل تنفيذ Salesforce في المؤسسات الكبرى](/ar/insights/enterprise-salesforce-implementation).

## نقاط الالتقاء مع المراحل الأخرى

يتأثر تشكيل الفريق مباشرة بعاملين: المخرجات المطلوبة في مرحلة التوصيف، المفصلة في [دليل استكشاف CRM](/ar/insights/crm-discovery-guide)، ونطاق الموجة الأولى، والذي يحدد وفقًا للقواعد في [دليل تحديد MVP](/ar/insights/salesforce-mvp-scope). تتطلب الموجة الأولى الضيقة عددًا أقل من مالكي العمليات المتزامنين، وهذا سبب مستقل لتقليل النطاق.

## فحص سريع قبل بدء المشروع

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

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

**ما هي الأدوار التي لا يمكن تحويلها إلى المورد؟**
ثلاثة أدوار: الراعي (Sponsor) المخول باتخاذ القرارات بين الأقسام، مالك العملية (process owner) الذي يحدد كيف سيبدو العمل، ومالك البيانات (data owner) الذي يقرر ما يعتبر موثوقًا. يمكن للمورد توفير الهندسة المعمارية، التطوير، إدارة المشروع، وحتى إدارة التغيير، لكنه لا يستطيع أن يقرر نيابة عن المؤسسة ما هو الأنسب لها.

**هل نحتاج إلى Salesforce Admin داخلي خلال فترة المشروع؟**
يفضل ذلك، وليس فقط قرب النهاية. Salesforce Admin الذي ينضم في مرحلة التحديد يكون على دراية بأسباب القرارات وليس فقط بالنتيجة، وبالتالي يكون قادرًا على الصيانة والتغيير لاحقًا. Salesforce Admin الذي يتلقى النظام في أسبوع التشغيل يضطر لتعلم الهندسة المعمارية من خلال التهيئة (configuration)، وهذا بطيء ومعرض للأخطاء.

**ما الفرق بين Product Owner ومدير المشروع في سياق Salesforce؟**
مدير المشروع مسؤول عن الجدول الزمني، التبعيات، المخاطر، والميزانية. Product Owner مسؤول عن أولويات المحتوى: ما يتم بناؤه أولاً وما يتم تأجيله. عندما يندمج الدورين في شخص واحد، عادة ما يتم إهمال إحدى المسؤوليتين – غالبًا ما يتم التضحية بالأولويات مقابل الالتزام بالموعد النهائي.

**كيف نعمل بفعالية مع فريق مورد خارجي عن بعد؟**
من خلال ثلاث آليات: نقطة اتصال واحدة من كلا الجانبين، قرارات تُسجل في سجل قرارات مشترك وليس عبر البريد الإلكتروني، وجولة عرض قصيرة بوتيرة ثابتة يرى فيها مالك العملية منتجًا عاملًا. فوارق اللغة والمنطقة الزمنية محتملة؛ ما هو غير محتمل هو قرار تم اتخاذه شفهيًا ولم يسجله أحد.

---

## اختبار قبول المستخدم (UAT) في مشروع Salesforce: كيف نختبر العمليات التجارية وليس الشاشات فقط
URL: https://hpi.pro/ar/insights/salesforce-uat-guide
اختبار UAT الذي يبدو كجولة إرشادية عبر الشاشات لن يكتشف الأعطال التي ستؤدي إلى فشل الإطلاق. يجب أن يتم الاختبار على سيناريوهات كاملة، وبيانات مشابهة للواقع، ومن قبل المستخدمين الفعليين للنظام. يقدم هذا الدليل منهجية لبناء السيناريوهات، ونموذج لتصنيف الأعطال، وشروط انتقال واضحة.

## لماذا يفشل اختبار قبول المستخدم (UAT) حتى عندما يبدو ناجحًا

في العديد من دورات اختبار قبول المستخدم (UAT)، تُصنّف جميع السيناريوهات على أنها ناجحة، وبعد أسبوعين من إطلاق النظام، تُفتح عشرات الطلبات. هذه ليست مفارقة؛ بل هي نتيجة مباشرة لاختبار تم تصميمه حول الشاشات.

الاختبار الذي يتمحور حول الشاشة يسأل: "هل يمكن إنشاء سجل؟" أما الاختبار الذي يتمحور حول العملية فيسأل: "هل يمكن لممثل خدمة العملاء استلام طلب، وتحديد ما إذا كان العميل موجودًا تحت اسم آخر، والتحقق من أهليته في النظام الأساسي، وفتح حالة، وتحويلها إلى جهة أخرى، وإغلاقها – مع وجود العميل مرتين في النظام؟" السيناريو الثاني يكشف ما يغفل عنه الأول.

يقدم هذا الدليل هيكل اختبار قبول المستخدم (UAT) الذي يركز على السؤال الثاني. الارتباط بالمراحل الأخرى للمشروع موجود في [دليل تنفيذ Salesforce](/ar/insights/salesforce-implementation-guide).

## ما يجب أن يكون جاهزًا قبل البدء

*   **بيئة مستقرة** لا تتلقى عمليات نشر في منتصف الدورة، باستثناء إصلاحات حاسمة ومُعتمدة.
*   **بيانات اختبار** بحجم وتعقيد مماثلين لبيئة الإنتاج.
*   **مستخدمون بصلاحيات حقيقية** — وليس صلاحيات مسؤول (Admin) للجميع. نصف مشاكل الصلاحيات تُكتشف فقط عندما يكون المختبر يمتلك الملف التعريفي الصحيح.
*   **معايير قبول** مُحددة لكل عملية أساسية.
*   **آلية إبلاغ موحدة** عن الأخطاء، بحد أدنى من الحقول الإلزامية.

العنصر الأكثر تعرضًا للتجاهل هو الثالث، وهو الذي يسبب أكثر المشاكل إحراجًا في يوم الإطلاق.

## كيفية بناء سيناريو يكشف المشاكل

السيناريو الجيد يبدأ بشخصية وحالة بداية، وليس بنقرة. هيكل فعّال:

1.  **من؟** — الدور والصلاحية الدقيقة.
2.  **حالة البداية** — أي معلومات موجودة في النظام قبل بدء السيناريو.
3.  **ماذا يحدث؟** — الحدث التجاري الذي يُشغّل العملية.
4.  **ماذا يفعل المختبر؟** — على مستوى الإجراء التجاري، وليس على مستوى النقرة.
5.  **النتيجة المتوقعة** — بما في ذلك ما حدث في أنظمة أخرى.
6.  **ما لا ينبغي أن يحدث؟** — السجل لا يُكشف لمن لا يجب أن يراه، الإشعار لا يُرسل مرتين.

القسم السادس هو ما يميز بين قائمة التحقق والاختبار الاحترافي.

## ست مجموعات من السيناريوهات يجب تضمينها

| المجموعة | مثال لسيناريو | ما تكشفه |
| --- | --- | --- |
| المسار الطبيعي | عملية كاملة من البداية إلى النهاية | إمكانية تنفيذ العملية من الأساس |
| الاستثناء التجاري | الإلغاء، الائتمان، العودة إلى مرحلة سابقة | منطق بُني في اتجاه واحد فقط |
| البيانات الإشكالية | عميل مكرر، اسم بالعربية والإنجليزية، حقل فارغ | عدم كفاية التعيين والتنظيف |
| الصلاحيات | مستخدم يحاول الوصول إلى سجل لوحدة أخرى | ثغرات في نموذج الكشف |
| فشل التكامل | النظام الهدف غير متوفر | معالجة الأخطاء، الحلقات، التكرار |
| الحجم | إجراء جماعي على عدد كبير من السجلات | قيود الأداء والأتمتة |

إن غياب مجموعة كاملة من القائمة هو علامة على أن الاختبار سيعطي شعورًا زائفًا بالأمان.

## تصنيف الخطورة — شرط إدارة الدورة

بدون تصنيف متفق عليه، تبدو كل مشكلة عاجلة، ويصبح قرار الإطلاق محل جدل. نموذج من أربع مستويات يكفي:

| المستوى | التعريف | التأثير على الإطلاق |
| --- | --- | --- |
| حاسم | لا يمكن إكمال عملية أساسية، لا يوجد حل بديل | حاسم |
| خطير | العملية ممكنة بحل بديل معقد أو حفظ بيانات خاطئة | حاسم ما لم يتم الموافقة عليه صراحة |
| متوسط | إزعاج كبير، حل بديل معقول | ليس حاسمًا، يدرج في خطة الإصلاح |
| منخفض | صياغة، ترتيب الحقول، تحسين | يجمع للموجة التالية |

القاعدة المهمة: يحدد مالك العملية التصنيف بالاشتراك مع الفريق التقني، وليس من أبلغ عن المشكلة.

## شروط الانتقال إلى الإنتاج

تُصاغ هذه الشروط قبل بدء الدورة وليس في نهايتها:

*   صفر مشكلات حرجة مفتوحة.
*   جميع المشكلات الخطيرة تم إغلاقها أو الموافقة عليها كتابيًا مع حل بديل ووقت إصلاح.
*   جميع العمليات الأساسية تم تشغيلها في الدورة الثانية بدون فشل جديد.
*   أصحاب العمليات وافقوا كتابيًا.
*   توجد خطة للعودة إلى الإصدار السابق (rollback plan) تم اختبارها، وليس فقط كتابتها.

## مثال توضيحي: صندوق التقاعد

السيناريو افتراضي ويهدف للتوضيح. قام صندوق تقاعد باختبار عملية معالجة طلبات الأعضاء. الدورة الأولى لاختبار قبول المستخدم (UAT) مرت بالكامل تقريبًا. لاحظ الفريق أن جميع المختبرين استخدموا ملفًا تعريفيًا موسعًا واحدًا، لأن تخصيص الملفات التعريفية الدقيقة قد تأخر.

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

النتيجة العملية التي تم تبنيها هناك: لا يتم بدء دورة اختبار قبول المستخدم (UAT) قبل أن يتم تعيين جميع المشاركين على الملف التعريفي الذي سيعملون به في بيئة الإنتاج.

## أخطاء إدارية تزيد من تكلفة الدورة

*   نشر الإصدارات في منتصف الدورة، مما يبطل صحة الاختبارات التي تم إجراؤها بالفعل.
*   إبلاغ المختبرين عبر WhatsApp والبريد الإلكتروني بالتوازي مع نظام التتبع.
*   سيناريوهات مكتوبة على مستوى النقرة، مما يحول أي تغيير في الواجهة إلى تحديث للوثائق.
*   تقصير الدورة الثانية بسبب ضغط الجدول الزمني — وهي الدورة التي تكشف عن الانحدارات.

تظهر هذه الأنماط إلى جانب إخفاقات أخرى في [دليل الأخطاء الشائعة في تنفيذ CRM](/ar/insights/crm-implementation-mistakes)، ومسؤولية كل منها محددة في [دليل أدوار فريق مشروع Salesforce](/ar/insights/salesforce-project-team-roles).

## عند استبدال نظام قائم

في مشروع الاستبدال، يضيف اختبار قبول المستخدم (UAT) دورًا ثانيًا: المقارنة. تُشغل نفس السيناريوهات العشرة في كلا النظامين، وتُقارن النتائج حقلًا بحقل. هذه هي الأداة الأكثر فعالية لاكتشاف فجوات التعيين قبل أن تتحول إلى فجوات في مصداقية النظام. تفاصيل تسلسل الإجراءات في مثل هذا الانتقال موجودة في [دليل استبدال CRM بـ Salesforce](/ar/insights/replace-crm-with-salesforce).

## ما تبقى بعد الدورة

سيناريوهات اختبار قبول المستخدم (UAT) ليست وثيقة لمرة واحدة. إنها الأساس لاختبارات الانحدار في كل إصدار مستقبلي، وهي أفضل مصدر لمواد التدريب — لأنها مكتوبة بلغة العملية وليس بلغة النظام. إن الاحتفاظ بها بتنسيق يمكن تشغيله مرة أخرى هو أرخص استثمار يمكن القيام به للعام القادم.

### أسئلة وأجوبة
**ما هي المدة الزمنية المخصصة لاختبار UAT في مشروع Salesforce؟**
يتراوح النطاق العملي بين أسبوعين وأربعة أسابيع لدورة متوسطة، ولكن المتغير الحاسم ليس عدد السيناريوهات بل عدد جولات الإصلاح. خطط لدورتين على الأقل: الأولى للاكتشاف، والثانية للتحقق من أن الإصلاح لم يؤثر على أي شيء آخر. غالبًا ما ينتهي اختبار UAT لمدة أسبوع واحد باكتشاف الأعطال في بيئة الإنتاج.

**هل يجب أن يتم تشغيل UAT على بيانات حقيقية؟**
يجب أن يتم على بيانات مشابهة للواقع من حيث الحجم والتعقيد، ولكن مع تكييفها لقيود الخصوصية. الاختبار على عشرة سجلات نظيفة لن يكشف عن التكرارات، أو الأسماء الإشكالية، أو العملاء ذوي التسلسل الهرمي العميق، أو السجلات التاريخية المفقودة – وهذه هي بالتحديد الحالات التي تولد الأعطال في الأسبوع الأول بعد الإطلاق في الإنتاج.

**من يكتب سيناريوهات الاختبار؟**
أصحاب العمليات، بمساعدة من يعرف النظام. عندما يكتب المطورون السيناريوهات، فإنهم يعكسون ما تم بناؤه وليس ما يحتاجه العمل. دور الفريق التقني هو إضافة سيناريوهات الحالات القصوى، وليس تحديد العملية التي يتم اختبارها.

**ما الفرق بين UAT واختبارات التكامل؟**
تضمن اختبارات التكامل أن الأنظمة تتواصل بشكل صحيح: التنسيق، الحقول، معالجة الأخطاء، الأداء. يضمن اختبار UAT أن الشخص الذي يقوم بالعمل يمكنه إكماله وأن النتيجة صحيحة من الناحية التجارية. من الممكن اجتياز اختبارات التكامل بالكامل والفشل في UAT، لأن البيانات قد انتقلت ولكن العملية غير قابلة للتنفيذ.

**هل يمكن الإطلاق بوجود أعطال مفتوحة؟**
نعم، إذا تم تصنيفها والموافقة عليها. العطل الذي لا يمكن تجاوزه قد يؤدي إلى التأجيل؛ العطل الذي له حل بديل موثق ووقت إصلاح متفق عليه يمكن أن يمر. ما هو غير مسموح به هو الإطلاق بقائمة أعطال لم يتم تصنيفها، لأنه في هذه الحالة يتم اتخاذ القرار فعليًا في الأسبوع الأول من الإنتاج، من قبل المستخدمين.

---

## تسعير مشروع Salesforce: سعر ثابت، الوقت والمواد (Time & Materials)، أم عقد خدمة (Retainer)؟
URL: https://hpi.pro/ar/insights/salesforce-project-pricing-models
اختيار نموذج التسعير هو بالأساس قرار بشأن الجهة التي تتحمل مخاطر عدم اليقين. السعر الثابت (Fixed Price) ليس دائمًا الأقل تكلفة، ونموذج الوقت والمواد (T&M) ليس بالضرورة الأكثر خطورة — فلكل منهما ما يناسب مستوى نضج مختلف لتعريف النطاق (Scope). نقدم هنا خريطة مقارنة، وآليات حماية لكل نموذج، والنماذج الهجينة الفعالة.

## التسعير ليس مسألة سعر بل مسألة مخاطرة

عندما يوازن أي مؤسسة بين نموذج السعر الثابت (Fixed Price) ونموذج الوقت والمواد (Time & Materials)، فإن السؤال الشائع غالبًا ما يكون حول النموذج الأقل تكلفة. هذا السؤال غير دقيق. كلا النموذجين يشتملان على نفس حجم العمل؛ الفرق يكمن في **الطرف الذي يتحمل الفارق عندما تختلف الواقعية عن الافتراضات**.

في نموذج السعر الثابت، يتحمل المورد هذا الفارق — ولذلك يقوم بتسعير هامش مخاطرة مقدمًا، ويحمي نفسه من خلال تحديد دقيق لما هو مشمول في النطاق. في نموذج الوقت والمواد (T&M)، تتحمل المؤسسة هذا الفارق — ولذلك تحتاج إلى آليات تحكم ومراقبة. أما في نموذج الريتينر (Retainer)، يحصل الطرفان على استقرار مقابل مرونة أقل.

القاعدة البسيطة هي: **كلما كان تعريف النطاق (Scope) أكثر نضجًا، كلما كان السعر الثابت أكثر جدوى.** وكلما كانت هناك مجهولية حقيقية أكبر، كان نموذج الوقت والمواد (T&M) مع سقف تكلفة (Cap) مفضلًا.

## مقارنة سريعة بين النماذج الثلاثة

| الجانب | السعر الثابت (Fixed Price) | الوقت والمواد (Time & Materials) | الريتينر (Retainer) |
|---|---|---|---|
| من يتحمل مخاطر النطاق | المورد | المؤسسة | مشترك ضمن النطاق المتفق عليه |
| شروط النجاح | نطاق (Scope) محدد جيدًا | شفافية وإدارة دقيقة | طلب مستقر ومتوقع |
| مرونة التغيير | منخفضة، من خلال طلبات التغيير | عالية | متوسطة |
| العبء الإداري على المؤسسة | متوسط، يتركز في التعريف | عالٍ، مستمر | منخفض |
| الفشل النموذجي | صراع على النطاق (Scope) | زحف الساعات | ساعات غير مستخدمة أو ممتصة |
| ملائمة جيدة لـ | مرحلة تنفيذ محددة | التكامل (Integration)، الترحيل (Migration)، البحث | الصيانة والتحسين المستمر |

## السعر الثابت — متى يكون مناسبًا وماذا يجب الانتباه إليه

يكون مناسبًا عندما يكون هناك تحليل متكامل (Functional Specification) مع معايير قبول واضحة، وعندما تكون عمليات التكامل (Integrations) معروفة وموثقة، وعندما يتم فحص جودة البيانات. في هذه الحالة، يمكن للمورد التسعير بثقة معقولة، وتحصل المؤسسة على يقين مالي حقيقي.

آليات الحماية التي ينبغي المطالبة بها:

- تحديد "تم الإنجاز" لكل مخرَج (Deliverable)، وليس مجرد اسم المخرَج.
- قائمة صريحة بالافتراضات التي بُني عليها السعر.
- سعر متفق عليه مسبقًا لطلبات التغيير، لتجنب تحديده في أوقات الضغط.
- جدول مدفوعات مرتبط بالقبول الفعلي للمخرجات وليس بالمواعيد.

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

## الوقت والمواد (Time & Materials) — متى يكون مناسبًا وكيفية التحكم فيه

يكون مناسبًا عندما تكون هناك مجهولية لا يمكن إزالتها بتكلفة منخفضة: كنظام نواة (Core System) قديم بدون توثيق، أو بيانات تاريخية بجودة غير معروفة، أو عملية عمل لا تزال تتغير.

آليات التحكم التي تجعله آمنًا:

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

البند الأخير غالبًا ما يُنسى، ويؤثر على التكلفة أكثر من سعر الساعة نفسه.

## الريتينر (Retainer) — متى يتحول إلى هدر

يعمل نموذج الريتينر بشكل جيد بعد الإطلاق النهائي (Go-Live)، عندما يكون هناك تدفق مستمر من الطلبات. لكنه يصبح غير فعال في حالتين متناقضتين: عندما يكون الطلب منخفضًا وتدفع المؤسسة مقابل ساعات غير مستخدمة، وعندما يتم إدخال تطوير كبير ويستنزف القدرة على تقديم الدعم.

تصحيحان بسيطان: فصل واضح بين الدعم والتطوير، وبند لتدوير جزء من الساعات غير المستخدمة إلى الشهر التالي، مع سقف. الجمع بين هذين التصحيحين يثبت النموذج.

## نماذج هجينة فعالة في الواقع

| مرحلة المشروع | النموذج الموصى به | التبرير |
|---|---|---|
| استشارات وتحليل (Scoping) | سعر ثابت قصير الأجل | النطاق معروف، المخرَج محدد |
| ترحيل البيانات (Data Migration) | T&M مع سقف | جودة البيانات تتضح أثناء العمل |
| التكامل مع الأنظمة القديمة (Legacy Integrations) | T&M مع سقف | يعتمد على الطرف الآخر |
| دورة تنفيذ محددة (Defined Implementation Wave) | سعر ثابت | معايير القبول موجودة |
| فترة استقرار (Stabilization Period) | مشمولة ضمن سعر الدورة | تمنع الجدل حول ما هو خلل وما هو تغيير |
| الصيانة الدورية (Ongoing Maintenance) | ريتينر | طلب مستمر |

قد يبدو تقسيم العمل بهذه الطريقة أكثر تعقيدًا من الاتفاق على عقد واحد، لكنه يقلل تحديدًا من النقاشات التي تعرقل المشاريع.

## مثال توضيحي: مستورد معدات طبية

السيناريو افتراضي ويهدف للتوضيح. طلب مستورد عرض سعر ثابت لمشروع تضمن أيضًا تكاملًا مع نظام إدارة مخزون يبلغ عمره خمسة عشر عامًا، بدون توثيق لواجهة برمجة التطبيقات (API). تراوحت العروض الثلاثة المستلمة في نطاق واسع جدًا، واحتوى العرض الأقل تكلفة على جملة صغيرة: "بافتراض وجود واجهة REST متاحة".

أجرت المؤسسة دراسة جدوى قصيرة لمدة أسبوع قبل التوقيع. تبين أنه لا توجد واجهة برمجة تطبيقات (API) من هذا النوع وأن هناك حاجة إلى طبقة وسيطة. غيرت هذه الدراسة الصورة: تم تحويل عملية التكامل إلى نموذج الوقت والمواد (T&M) مع سقف (Cap)، بينما بقي بقية المشروع بنموذج السعر الثابت.

ما منعته دراسة الجدوى القصيرة لم يكن تكلفة إضافية — التي كانت ستأتي على أي حال — بل نقاشًا تعاقديًا في منتصف المشروع حول من يتحمل مسؤولية الافتراض الذي لم يتم التحقق منه.

## ما الذي يؤثر على السعر أكثر من نموذج التسعير

- **نضج التعريف** — التحليل الجزئي يزيد تكلفة أي نموذج.
- **عدد الأنظمة المصدرية** ومستوى توثيقها.
- **جودة البيانات** الموجودة.
- **توفر أصحاب العمليات (Process Owners)** في المؤسسة — التأخير في اتخاذ القرارات هو تكلفة مباشرة.
- **عدد الوحدات التجارية** التي تحتاج إلى الموافقة.

أربعة من هذه العوامل الخمسة تقع تحت سيطرة المؤسسة وليس تحت سيطرة المورد. هذا هو السبب في أن الاستثمار في التحضير يخفض تكلفة المشروع أكثر من أي مفاوضات على الأسعار.

## من النموذج إلى الاتفاقية

بعد اختيار النموذج، ما يحدد النجاح هو الصياغة: ما الذي سيُعتبر مخرَجًا مكتملًا، من يوافق عليه، وماذا يحدث عندما يتأخر الطرف الآخر. البنود التي يجب تضمينها في الاتفاقية مفصلة في [دليل العقود وبيان العمل لمشاريع Salesforce](/ar/insights/salesforce-sow-contract-clauses)، وطريقة صياغة المناقصة بحيث تكون العروض قابلة للمقارنة مفصلة في [دليل طلب تقديم العروض (RFP) الخاص بـSalesforce](/ar/insights/salesforce-rfp-guide).

تحديد نوع الخدمة المطلوب تسعيرها مفصل في [دليل خدمات Salesforce](/ar/insights/salesforce-services-guide)، وفحص المورد نفسه في [دليل اختيار شركة تنفيذ Salesforce](/ar/insights/choose-salesforce-implementation-company).

## الخطوة التالية

قبل طلب التسعير، قم بترتيب أهم ثلاثة مصادر لعدم اليقين في مشروعك. إذا كان بإمكانك تحديدها بوضوح، فأنت جاهز لسعر ثابت لجزء من العمل. إذا لم تتمكن من ذلك — فإن أول شيء يجب الحصول عليه هو دراسة قصيرة تزيل هذه الشكوك، وليس عرض سعر للمشروع بأكمله.

### أسئلة وأجوبة
**هل يحمي نموذج السعر الثابت (Fixed Price) الميزانية حقًا في مشروع Salesforce؟**
هو يحدد سعر النطاق (Scope) المعرّف، وليس سعر المشروع بأكمله. عندما يكون التعريف جزئيًا، يتم سد الفجوة من خلال طلبات التغيير التي يتم تسعيرها بشكل منفصل وفي بعض الأحيان بسعر أعلى. يحمي Fixed Price الميزانية فقط عندما يكون وثيقة الـ Scope مفصلة بما يكفي لاتفاق الطرفين على ما هو مشمول وما هو خارج النطاق.

**متى يكون نموذج الوقت والمواد (Time & Materials) أفضل من السعر الثابت؟**
عندما يكون هناك عدم يقين حقيقي لا يمكن إزالته قبل بدء العمل — مثل التكامل مع أنظمة قديمة بدون توثيق، أو بيانات ذات جودة غير معروفة، أو عملية تجارية تمر بتغيير. في مثل هذه الحالات، ينقل Fixed Price ببساطة عدم اليقين إلى هامش مخاطرة تدفع ثمنه سواء تحققت المخاطر أم لا.

**ما الذي من المنطقي تضمينه في عقد خدمة شهري (Retainer) لبيئة Salesforce؟**
عادةً ما يشمل الصيانة، والدعم، والتغييرات الصغيرة في التكوين، وإدارة الإصدارات، والمراقبة. تطوير قدرة جديدة يجب أن يكون خارج نطاق Retainer أو بحد أقصى محدد، وإلا فإنه سيستهلك الساعات المخصصة للدعم ويخلق شعورًا بأن المورد غير متاح.

**كيف يمكن منع تضخيم الساعات في نموذج T&M؟**
بثلاث آليات: سقف متفق عليه لكل مرحلة رئيسية مع إشعار مبكر عند الاقتراب منه، وتسجيل الساعات على مستوى المهام وليس على مستوى الشهر، وحق المؤسسة في التوقف عند نهاية كل مرحلة رئيسية. هذه الآليات الثلاث معًا توفر تحكمًا أفضل من السعر الثابت، لأنها تسمح بالتصحيح أثناء التنفيذ.

**هل يمكن الجمع بين نماذج تسعير مختلفة في نفس المشروع؟**
نعم، وهذا غالبًا ما يكون الخيار الصحيح. من الأنماط الشائعة هو السعر الثابت لمرحلة التخطيط والتحليل، وT&M بسقف محدد لعمليات التكامل والترحيل، والسعر الثابت لمراحل التنفيذ المحددة بالفعل، وعقد خدمة Retainer بعد الإطلاق. يساعد هذا التقسيم على مواءمة كل جزء من المشروع مع النموذج الذي يناسب مستوى عدم اليين الخاص به.

---

## Salesforce Flow أم Apex؟ إطار عمل لاتخاذ القرارات لحلول الأتمتة المؤسسية
URL: https://hpi.pro/ar/insights/salesforce-flow-vs-apex
لا يُحدَّد الاختيار بين Flow و Apex بناءً على مهارة الفريق فحسب، بل بناءً على طبيعة المنطق: حجم السجلات في المعاملة، الاعتماد على Governor Limits، الحاجة إلى Transaction Control، ومدى تعقيد الشروط. تطرح هذه المقالة اختبار قرار عملي بدلاً من مجرد مقارنات عامة للقدرات.

## الإجابة المختصرة

تُشكل الإجابة على سؤال "Flow أم Apex" غالبًا غير صحيحة عندما يتم تقييمها بناءً على سهولة الكتابة أو توفر المطورين. تعتمد الإجابة الصحيحة على أربعة عوامل فنية: عدد السجلات التي تمر عبر معاملة واحدة، وما إذا كانت المنطقية تتطلب Atomicity كاملة، ومدى تعقيد الشروط والفروع، ومن سيتولى صيانة المكون بعد عام. يعتبر Flow هو الخيار الافتراضي الصحيح لمعظم أتمتة الأعمال، ولكن هناك نقاط تحول واضحة حيث يؤدي الاستمرار في العمل باستخدام Flow إلى مخاطر تشغيلية، وليس مجرد "رمز أقل أناقة."

تتناول هذه المقالة قرار الاختيار نفسه: كيفية تحديد مسبقًا أن المنطقية تستدعي Apex، وكيفية منع اتخاذ القرار كخيار افتراضي بدلاً من تقييم مدروس. تُناقش مسألة تنظيف Flow-ات وعمليات الأتمتة الحالية التي تراكمت كديون تقنية في مقال منفصل ولا تشكل جزءًا من هذا النقاش.

## ما الذي يميزهما فعليًا على مستوى المنصة؟

Flow هو محرك تصريحي (Declarative) يُترجم في وقت التشغيل إلى تعليمات تنفذ DML و SOQL نيابة عن المستخدم، بينما Apex هو رمز مُبرمج (Compiled code) يعمل ضمن نفس حدود الحاكم (Governor Limits) ولكن مع تحكم مباشر في تسلسل العمليات. الفرق العملي الأول هو Bulkification: يقوم مطور Apex بإنشاء حلقة بشكل صريح تجمع جميع السجلات في مصفوفة واحدة وتنفذ DML واحدًا، بينما في Flow، من السهل إنشاء حلقة (Loop) تنفذ عملية DML أو استعلام في كل تكرار بشكل منفصل - وهو نمط يصل إلى حد 101 استعلام المسموح به بشكل أسرع بكثير.

الفرق الثاني هو التحكم في المعاملات (Transaction). يتيح Apex استخدام `Savepoint` و `Database.rollback` للتراجع الجزئي، ومعالجة `DmlException` على مستوى سجل فردي عبر `Database.insert(list, false)`، ومنطقًا شرطيًا معقدًا "دون قيود على عمق الأفرع". في Flow، يتم تعريف معالجة الأخطاء على مستوى Fault Path لكل عنصر، ويعمل هذا جيدًا للسيناريوهات الخطية ولكنه يصبح صعب التتبع عندما يكون هناك أكثر من مسارات فشل متوازية.

## إطار عمل القرار: أربعة اختبارات قبل اختيار الأداة

### اختبار الحجم

قاعدة عامة: إذا كانت العملية تعمل على سجل واحد نتيجة لإجراء المستخدم (إنشاء عميل محتمل، تغيير حالة فرصة)، فإن Flow يكفي دائمًا تقريبًا. أما إذا كانت العملية تعمل على عشرات إلى آلاف السجلات في وقت واحد – تحديث دوري، معالجة دفعة Batch تأتي من تكامل، تنظيف بيانات مجدول – فإن Apex مع `Batchable` أو `Queueable` هو الخيار الآمن، لأنه يمنح تحكمًا كاملاً في الـ Bulkification وإدارة Governor Limits في مواجهة الحجم المتغير.

### اختبار الـ Atomicity

يجب أن نسأل: إذا فشل جزء من التحديث، هل يجوز أن يبقى الجزء الآخر محفوظًا؟ إذا كانت الإجابة "لا" – على سبيل المثال تحديث أمر وإنشاء سجل دفع يجب أن يحدثا معًا – فإن Apex مع Savepoint هو الطريقة الصحيحة لضمان ذلك. لا يوفر Flow دمجًا (Rollback) كاملاً بين العناصر دون بناء يدوي ومعقد لمنطق التعويض.

### اختبار تعقيد الفروع

يصبح Flow الذي يحتوي على أكثر من 6-8 عناصر قرار متداخلة صعب القراءة ومكلفًا للاختبار، حتى لو كان كل فرع بسيطًا. عندما يتجاوز تعقيد المنطق التجاري هذا الحد، فإن كتابة نفس المنطق كدالة Apex موثقة باختبارات الوحدة (`@isTest`) تكون عادةً أرخص في الصيانة، حتى لو كان وقت الكتابة الأولي أطول.

### اختبار الصيانة والملكية

يجب أن نسأل من سيصون المكون بعد عام، وليس من يبنيه الآن. إذا كان فريق Admin هو الذي سيحتاج إلى تحديث قواعد العمل بشكل دوري - مثل تغيير شروط الخصم أو القيم الحدية - فإن Flow أفضل حتى لو كان Apex "أنظف" تقنيًا، لأنه متاح للتحديث دون دورة نشر. أما إذا كانت التغييرات تتطلب معرفة بمخطط البيانات واختبارات الانحدار (Regression Testing)، فإن Apex هو الخيار الصحيح حتى لو كان هناك فريق تطوير صغير فقط يتولى صيانته.

## جدول القرار

| المعيار | اختر Flow | اختر Apex |
|---|---|---|
| حجم السجلات في معاملة واحدة | حتى بضع عشرات | المئات إلى الآلاف |
| متطلبات الذرية (Atomicity) بين عدة كائنات | غير حاسمة | حاسمة - يتطلب تراجعًا كاملاً |
| عدد فروع القرار | حتى 6-8 تقريباً | أكثر من ذلك، أو منطق متكرر |
| وتيرة تغيير قواعد العمل | متكررة، من قبل المسؤول | نادرة، تتطلب اختبارات انحدار |
| الحاجة إلى استدعاء API خارجي معقد | استدعاء بسيط واحد (HTTP Callout) | منطق Retry، مصادقة معقدة أو دفعة Batch |
| متطلبات الاختبارات الآلية (CI) | محدودة | كاملة، `@isTest` مع التغطية |
| التكامل مع وظيفة مجدولة ثابتة (Scheduled Job) | غير مناسب مباشرة | طبيعية عبر `Schedulable` |

## سيناريو مثال: شركة معدات طبية بعملية موافقة على الطلبات

قامت شركة معدات طبية متوسطة الحجم تضم حوالي 40 مندوب مبيعات بتفعيل Flow واحد لعملية الموافقة على الطلبات: التحقق من المخزون، حساب الخصم، إنشاء سجل موافقة، وإرسال تنبيه للمدير. في البداية، عمل هذا بشكل جيد على طلب واحد. بعد ستة أشهر، أُضيف سيناريو جديد – استيراد طلبات دفعة من ملف تكامل مع نظام ERP، مما ينشئ ما بين 200 و 800 طلب بشكل متزامن.

قام الـ Flow، الذي تم تشغيله عبر Record-Triggered Flow على مستوى "لكل سجل"، بتنفيذ استعلام للتحقق من المخزون ضمن كل عملية تشغيل منفصلة. مع استيراد 500 طلب، تجاوز النظام حد 100 استعلام في معاملة واحدة وفشلت الطلبات دون رسالة خطأ واضحة للمستخدم. أدرك الفريق أن المشكلة ليست في الـ Flow نفسه، بل في التوافق بين عملية صُممت لسجل واحد وبين سيناريو حجم لم يكن موجودًا وقت البناء.

لم يكن الحل هو التخلص من الـ Flow. قام الفريق بتقسيم المنطق: بقي الـ Flow مسؤولاً عن العملية اليدوية للطلب الواحد (اختبار الحجم منخفض، وهناك حاجة لتحديث متكرر لقواعد الخصم من قبل المسؤول)، بينما تم نقل عملية الاستيراد بالجملة إلى Apex Batch Job تقوم بتنفيذ Bulkification كامل، وتتحقق من المخزون في استعلام مركزي واحد، وتنفذ DML واحدًا لجميع السجلات. يستدعي كلا الآليتين نفس طبقة المنطق التجاري المشترك (Apex Class واحدة يستدعيها الـ Flow أيضًا عبر Invocable Method)، حتى لا يتم صيانة قاعدة الخصم مرتين.

## المخاطر الشائعة والإجراءات الوقائية

| المخاطر | كيف تبدو في الواقع | الإجراء الوقائي |
|---|---|---|
| Flow على حجم يتزايد تدريجياً | العملية عملت لمدة ستة أشهر ثم فشلت بصمت بسبب حدود الحاكم (Governor Limits) | التحقق من الحجم المتوقع مسبقًا وتخطيط نقطة تحول إلى Apex قبل الوصول إلى الحد الأقصى |
| ازدواجية منطق العمل في Flow و Apex | مكانان يحسبان الخصم بشكل مختلف | تركيز الحساب التجاري في طبقة Apex مشتركة يمكن لـ Flow استدعائها أيضاً |
| ترتيب التشغيل (Trigger Order) غير متوقع | Flow-ات متعددة و Trigger على نفس الكائن تتعارض | Trigger Handler مركزي واحد في Apex لكل كائن حرج |
| معالجة جزئية للأخطاء في Flow معقد | يتم تحديث بعض السجلات وليس كلها، دون رؤية واضحة | نقل العمليات التي تتطلب Atomicity إلى Apex مع Savepoint |
| Apex بدون اختبارات كافية | تغيير بسيط يكسر عملية حرجة في النشر التالي | طلب تغطية حقيقية وليس مجرد نسبة مئوية شكلية، بما في ذلك سيناريوهات الفشل |

## قائمة التحقق للقرار قبل البناء

- [ ] تم التحقق من الحجم المتوقع لمدة عام، وليس الوضع الحالي فقط.
- [ ] تم تحديد ما إذا كانت العملية تتطلب Atomicity بين عدة كائنات.
- [ ] تم حساب فروع القرار المتوقعة في المنطق.
- [ ] من المعروف من سيصون المكون وكم مرة ستتغير القواعد.
- [ ] تم التحقق مما إذا كان هناك منطق مشابه موجودًا بالفعل في Apex أو في Flow آخر على نفس الكائن.
- [ ] تم تحديد Trigger Order إذا كانت هناك آليات أتمتة متعددة على الكائن.
- [ ] إذا تم اختيار Apex - تم تحديد سيناريوهات الاختبار بما في ذلك الفشل الجزئي.
- [ ] إذا تم اختيار Flow - تم تحديد Fault Path لكل عنصر حرج.

## كيف يرتبط هذا بالهندسة المعمارية الشاملة؟

يُعد اختيار الأداة المناسبة لأتمتة فردية مجرد طبقة واحدة ضمن صورة أوسع من [هندسة حلول إدارة علاقات العملاء (CRM)](/ar/insights/crm-architecture-guide)، حيث يؤثر كل من نموذج البيانات والأذونات على ما يمكن لـ Flow أو Apex الوصول إليه. عندما تتجاوز الأتمتة حدود المؤسسة الخارجية – على سبيل المثال، التحقق من المخزون مقابل نظام ERP في الوقت الفعلي – يندمج الاختيار بين Flow و Apex أيضًا في اعتبارات [أنماط التكامل](/ar/insights/salesforce-integration-patterns) وفي مسألة كيفية [ربط Salesforce بنظام ERP](/ar/insights/salesforce-erp-integration) من حيث زمن الاستجابة ومعالجة الفشل.

في المؤسسات التي تدير عددًا من المؤسسات (Orgs)، يجب أيضًا التحقق مما إذا كان منطق العمل متطابقًا في جميعها – وهي مسألة نوقشت في [دليل Single Org مقابل Multi Org](/ar/insights/salesforce-single-org-vs-multi-org) وتؤثر على ما إذا كان من المجدي تركيز المنطق في حزمة Apex مشتركة.

## الخلاصة

الاختيار بين Flow و Apex ليس مسألة مهارة فريق أو تفضيل شخصي، بل هو نتيجة لأربعة اختبارات فنية: الحجم، Atomicity، تعقيد الفروع، وتكرار التغيير. يُعد Flow هو الخيار الافتراضي الصحيح لمعظم عمليات الأتمتة التي تتعلق بسجل واحد وتتغير بشكل متكرر. يصبح Apex ضروريًا عندما يكون هناك حجم كبير، عندما تكون هناك حاجة للتحكم الكامل في المعاملات، أو عندما يتجاوز التعقيد المنطقي الحد الذي لا يزال من الممكن صيانته من خلال واجهة تصريحية (Declarative). إن المؤسسة التي تضع هذه الاختبارات كجزء من عملية العمل - ولا تتركها لتقدير فردي من قبل كل مطور - توفر غالبية الحالات التي تنكسر فيها الأتمتة التي عملت بشكل جيد في البداية بصمت عندما يزداد الحجم.

### أسئلة وأجوبة
**هل يمكنني البدء باستخدام Flow والتحول إلى Apex لاحقًا دون تعطيل العملية؟**
نعم، بشكل عام، إذا تم تصميم Flow حول حدث عمل واضح وليس حول شاشة محددة. عندما يستدعي Flow عملية عبر Invocable Action أو Subflow، يمكن استبدال التنفيذ الداخلي بـ Apex دون المساس بالمحفز، الأذونات، أو الواجهة. تظهر المشكلة عندما يتشابك Flow والمنطق التجاري بشكل وثيق — عندها يتطلب أي تغيير إعادة بناء كاملة، وليس مجرد إعادة هيكلة.

**هل يمكن لـ Flow التعامل مع تحديث آلاف السجلات دفعة واحدة؟**
تقنيًا نعم، ولكن عمليًا يعتمد ذلك على الحمل المنطقي داخل الحلقة. Flow الذي يُنفِّذ استعلام SOQL أو DML داخل حلقة لكل سجل قد يتجاوز Governor Limits قبل Apex المماثل بكثير، لأن محرك Flow لا ينفذ دائمًا Bulkification تلقائيًا بنفس الكفاءة. عندما يتعلق الأمر بالتحديثات الجماعية المنتظمة بدلاً من التحديثات لمرة واحدة، فإن Apex مع Batch أو Queueable هو الخيار الأكثر أمانًا.

**ماذا يحدث عندما يكون هناك عدة Flow و Triggers على نفس الكائن؟**
يتم تحديد ترتيب التنفيذ وفقًا لإعدادات Salesforce وليس دائمًا وفقًا لنية الفريق، ولذلك فمن السهل الحصول على نتيجة غير متوقعة عندما تتفاعل آليات متعددة مع نفس السجل. الحل هو مركزة جميع المنطق التلقائي لكائن مركزي حول Trigger Handler واحد في Apex، واستخدام Flow فقط للعمليات التي لا تتعارض مع المنطق الحرج.

**متى يجب كتابة Apex حتى لو كان Flow كافيًا من الناحية التقنية؟**
عندما يتضمن المنطق معاملة واحدة يجب أن تنجح أو تفشل بالكامل — على سبيل المثال، تحديث كائنين مرتبطين لا يجب أن يبقيا غير متزامنين. يتعامل Flow مع الأخطاء على مستوى العنصر الفردي ولا يضمن دائمًا Atomicity الكاملة، بينما يسمح Apex بـ Savepoint و Rollback المتحكم بهما.

**هل صيانة Apex دائمًا أغلى من Flow؟**
ليس بالضرورة. يمكن أن يكون Flow المعقد الذي يحتوي على عشرات الفروع القرارية، Subflows مدمجة، ومنطق مخفي داخل Formula Fields، أكثر صعوبة في التشخيص من Apex الموثق باختبارات الوحدة. تعتمد التكلفة على نطاق المنطق وجودة التوثيق، وليس على الأداة نفسها.

---

## Real-Time، Batch أم Event-Driven؟ اختيار نمط التكامل لمنصة Salesforce
URL: https://hpi.pro/ar/insights/salesforce-integration-patterns
اختيار نمط تكامل خاطئ لا يظهر في العرض التوضيحي؛ بل يتجلى عندما يزداد الحمل، أو عندما يتعطل نظام خارجي لدقيقة، أو عندما يقوم مستخدمان بتحديث نفس العميل في وقت واحد. يقدم هذا الدليل إطارًا لاتخاذ القرار بناءً على ثلاث أسئلة فقط: ما مدى السرعة المطلوبة للمعلومة، من يمتلك الحقيقة، وماذا يحدث عند الفشل.

## ثلاثة أسئلة تحدد النمط - وليس الأداة

الخطأ الشائع في اختيار نوع التكامل مع Salesforce هو البدء بالأداة: MuleSoft، أو Platform Events، أو Bulk API، أو Webhook بسيط. فالأداة هي نتيجة وليست نقطة انطلاق. تحدد ثلاثة أسئلة النمط الصحيح:

1. **مدى السرعة المطلوبة ليطّلع الطرف الآخر على المعلومة؟** ثانية، دقيقة، ساعة، أو يوم – هذا هو الفرق بين الزمن الفعلي (Real-Time) والمعالجة الدفعية (Batch).
2. **من هو المالك للبيانات في أي لحظة معينة؟** إذا كانت الإجابة غير واضحة، فلن يحل أي نمط تقني المشكلة.
3. **ماذا يحدث عندما يكون الطرف الآخر غير متاح؟** الإجابة "سننتظر مرة أخرى" ليست إجابة – يجب تحديد سلوك معين: إعادة المحاولة (Retry)، أو وضع في قائمة الانتظار (Queue)، أو الفشل الصريح (Explicit Failure).

من يجيب على هذه الأسئلة الثلاثة قبل اختيار التكنولوجيا، يصل غالبًا إلى نفس النتيجة التي كان سيصل إليها مهندس معماري خبير – ولكن بدون دفع تكاليف التجربة والخطأ في مرحلة الإنتاج. يتوفر المزيد حول العلاقة بين هذا القرار والهندسة المعمارية الشاملة في [دليل هندسة CRM](/ar/insights/crm-architecture-guide).

## خريطة الأنماط: متى يكون كل نمط مناسبًا

| النمط | وقت الاستجابة النموذجي | مثال الاستخدام النموذجي | تكلفة الصيانة | الخطر الرئيسي |
| --- | --- | --- | --- | --- |
| طلب-استجابة متزامن (Request-Reply Synchronous) | ميلي ثانية إلى ثوانٍ | التحقق من الائتمان قبل الموافقة على صفقة على الشاشة | متوسطة | انقطاع (Timeout) يوقف المستخدم |
| إطلاق ونسيان (Fire-and-Forget) | فوري عند الإرسال، بدون انتظار النتيجة | إرسال حدث لإنشاء مهمة (Task) في نظام آخر | منخفضة-متوسطة | فشل صامت بدون مراقبة |
| معالجة دفعية دورية (Batch Periodic) | ساعات إلى يوم | مزامنة كتالوج المنتجات مرة واحدة يوميًا من نظام تخطيط موارد المؤسسات (ERP) | منخفضة | فجوات زمنية بين الأنظمة |
| التقاط تغيير البيانات (CDC - Change Data Capture) | ثوانٍ إلى دقائق | تحديث حالة طلب يؤثر على الدعم | متوسطة-عالية | حمل زائد على ناقل الأحداث (Event Bus) مع تغييرات متعددة |
| مبني على الأحداث (Event-Driven - Platform Events / Pub-Sub) | ثوانٍ | إشعار بحدث تجاري لعدة مستهلكين في نفس الوقت | عالية في الإعداد، منخفضة في الصيانة | يتطلب انضباطًا في تخطيط المخطط (Schema) وتحديد الإصدارات (Versioning) |

الجدول هو نقطة بداية للمناقشة، وليس حكمًا نهائيًا. يمكن لنظام واحد، وفي بعض الأحيان يجب عليه، استخدام عدة أنماط في نفس الوقت حسب نوع البيانات.

## لماذا وقت الاستجابة (Latency) وحده لا يكفي لاتخاذ القرار

الخطأ الشائع الثاني: اتخاذ القرار بناءً على وقت الاستجابة (Latency) فقط وتجاهل الاتساق (Consistency). فالنمط السريع الذي يقوم بتحديث طرف واحد فقط ويترك الطرف الآخر "شبه متزامن" يخلق مشكلة أخطر من النمط البطيء لكن المتسق – لأن المستخدمين يتعلمون عدم الوثوق بالبيانات، ثم يتجاوزون النظام.

السؤال الصحيح هو مزدوج: ما مدى السرعة المطلوبة للاستجابة، **وما مدى خطورة** أن تكون البيانات غير متزامنة بين الطرفين للحظة؟ عملية تسعير تُعرض على العميل تتطلب السرعة والاتساق الكامل – وهنا يلزم نمط طلب-استجابة متزامن (Request-Reply Synchronous) مع مهلة زمنية (Timeout) محددة ومعالجة صريحة للفشل. تحديث "عدد مشاهدات المقال" يمكن أن يتحمل تأخير بضع دقائق – هنا يكفي نمط إطلاق ونسيان (Fire-and-Forget) أو التقاط تغيير البيانات (CDC).

## ملكية البيانات: قرار يسبق أي نمط

قبل اختيار طريقة انتقال البيانات بين الأنظمة، يجب اتخاذ قرار بشأن المكان الذي تكون فيه البيانات "حقيقية". فالحقل الذي يتم تحديثه في نظامين بدون مالك محدد ينشئ حلقة مزامنة: A يرسل إلى B، B يقوم بالتحديث ويعيد الإرسال إلى A، A يرسل مرة أخرى. هذا ليس سيناريو استثنائيًا – إنها النتيجة المتوقعة للمزامنة ثنائية الاتجاه بدون قاعدة قرار.

قاعدة عمل عملية: لكل حقل مشترك، يتم تحديد مالك واحد. إذا كانت هناك حاجة تجارية حقيقية للتعديل من كلا الجانبين (على سبيل المثال، خدمة العملاء تقوم بتحديث العنوان في Salesforce وفي نظام ERP)، تتم إضافة قاعدة واضحة لحل التعارض (Conflict Resolution) – آخر طابع زمني (Timestamp) يفوز، أو حقل واحد يحدد القيمة والآخر للعرض فقط. تتم مناقشة إدارة الصلاحيات حول نفس الحقول الحساسة في [دليل نموذج الصلاحيات في Salesforce](/ar/insights/salesforce-permission-model).

## معالجة الفشل: الاختبار الذي تتجاهله معظم المشاريع

تخضع معظم عمليات التكامل لاختبار المسار الطبيعي (Happy Path). القليل منها يخضع لاختبار منهجي لهذه السيناريوهات الثلاثة للفشل:

- **النظام الآخر غير متاح وقت الإرسال** - هل يتم حفظ الرسالة في قائمة الانتظار وإعادة إرسالها، أم تُفقد؟
- **وصول الرسالة مرتين** (مشكلة شائعة في إعادة المحاولة التلقائية وناقل الأحداث) - هل ينشئ الطرف المتلقي سجلًا مكررًا؟
- **وصول الرسالة بترتيب خاطئ** - هل تحديث الحالة "مُلغى" الذي يصل قبل "معتمد" يؤدي إلى نتيجة خاطئة؟

النظام الذي لا يتم بناؤه بشكل لا يتغير مع التكرار (Idempotent) (معرف فريد لكل رسالة + التحقق مما إذا كان قد تم معالجتها بالفعل) سيفشل بالضبط في السيناريوهين الأولين، وغالبًا تحت الحمل – أي بالضبط عندما يكون العمل يعتمد عليه بشدة. يتم تفصيل قيود واجهة برمجة التطبيقات (API) والتعامل مع تحديد السرعة (Throttling) في هذا السياق في [دليل حدود Salesforce API ومرونتها](/ar/insights/salesforce-api-limits-resilience).

## إطار القرار: من السؤال التجاري إلى النمط

| السؤال الأول الذي يُطرح | إذا كانت الإجابة "نعم" | إذا كانت الإجابة "لا" |
| --- | --- | --- |
| هل ينتظر المستخدم على الشاشة لنتيجة التكامل؟ | طلب-استجابة متزامن مع مهلة زمنية محددة | ننتقل إلى السؤال التالي |
| هل يتطلب التحديث خلال دقائق معدودة لتغيير فردي؟ | التقاط تغيير البيانات (CDC) أو حدث منصة (Platform Event) | ننتقل إلى السؤال التالي |
| هل يحتاج عدة مستهلكين مختلفين إلى معرفة نفس الحدث؟ | مبني على الأحداث (Event-Driven) مع نشر-اشتراك (Pub-Sub) | ننتقل إلى السؤال التالي |
| هل من الملائم معالجة حجم كبير في نافذة زمنية ثابتة؟ | معالجة دفعية دورية (Batch Periodic) | دراسة استخدام إطلاق ونسيان (Fire-and-Forget) مع قائمة انتظار |

هذه نقطة انطلاق للمناقشة في اجتماع الهندسة المعمارية، وليست صيغة شاملة – هناك دائمًا حالات استثنائية (على سبيل المثال، حجم هائل يتطلب التقاط تغيير البيانات (CDC) وأيضًا تسوية دفعية يومية كشبكة أمان).

## سيناريو توضيحي: شبكة عيادات خاصة بعشرين فرعًا

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

كان الاختيار الأولي للفريق هو معالجة دفعية ليلية ثنائية الاتجاه – سهلة الإعداد، ولكنها خلقت فجوة تصل إلى 24 ساعة حيث رأى الممثلون معلومات غير محدثة وتسببت في شكاوى. الحل الذي تم اختياره فعليًا: اتجاه واحد (إكمال الموعد من Salesforce إلى الفواتير) انتقل إلى إطلاق ونسيان (Fire-and-Forget) مع قائمة انتظار رسائل وإعادة محاولة تلقائية، لأنه لا داعي لانتظار المستخدم. الاتجاه الثاني (تأكيد الدفعة من الفواتير إلى Salesforce) انتقل إلى التقاط تغيير البيانات (CDC)، لأنه تغيير محدد يجب أن يصل في غضون دقائق. بقيت المعالجة الدفعية الليلية فقط كآلية تسوية (Reconciliation) – مقارنة يومية تكتشف الفجوات وتصدر تنبيهات، وليست قناة التحديث الرئيسية.

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

## المخاطر وإجراءات الوقاية الخاصة بالتكامل

| الخطر | كيف يظهر عمليًا | إجراء الوقاية |
| --- | --- | --- |
| نقص في لا تغير التكرار (Idempotency) | سجلات مكررة بعد إعادة المحاولة أو فشل الشبكة | معرف فريد للرسالة + التحقق من الوجود قبل الإنشاء |
| مصدر حقيقة غير محدد | حلقة مزامنة أو تحديث "فائز" عشوائي | مالك محدد لكل حقل + قاعدة لحل التعارض |
| نقطة-لنقطة بدون طبقة تكامل | كل تغيير في المخطط (Schema) في نظام واحد يعطل اتصالًا آخر | طبقة وسيطة (Middleware/API) مع عقد إصدارات واضح |
| مراقبة تقنية فقط | التكامل "أخضر" ولكن الطلبات مفقودة فعليًا | مقياس تسوية تجاري، وليس فقط وقت التشغيل التقني |
| تجاهل حدود الحاكم (Governor Limits) | التكامل ينهار عند ذروة الحمل | تخطيط التجميع (Bulkification) والعودة التدريجية (Backoff) مسبقًا، وليس كاستجابة |

## قائمة التحقق لاختيار نمط التكامل

- ☐ تحديد وقت الاستجابة المطلوب بأرقام، وليس بكلمة "بسرعة"
- ☐ تحديد مالك واحد لكل حقل مشترك بين الأنظمة
- ☐ التحقق مما يحدث عندما يكون الطرف الآخر غير متاح – وتوثيق ذلك
- ☐ التحقق مما يحدث عندما تصل الرسالة مرتين
- ☐ التحقق مما يحدث عندما تصل الرسائل بترتيب خاطئ
- ☐ وجود آلية تسوية (Reconciliation) حتى عندما يكون النمط الرئيسي غير متزامن
- ☐ مراجعة قيود واجهة برمجة التطبيقات (API) وحدود الحاكم (Governor Limits) مقابل الحجم المتوقع عند ذروة الحمل
- ☐ تحديد مقاييس النجاح التجارية وليس فقط التقنية

## مقاييس الفحص الدوري للتكامل

بعد الإطلاق، يُنصح بمتابعة ثلاثة إلى أربعة مقاييس فقط: نسبة الرسائل التي نجحت في المحاولة الأولى، وقت الاستجابة الفعلي من البداية إلى النهاية مقابل اتفاقية مستوى الخدمة (SLA) المحددة، الفروق اليومية في التسوية بين الأنظمة، ومدى القرب من حدود واجهة برمجة التطبيقات (API). الزيادة المستمرة في أحد هذه المقاييس – وليس مجرد انحراف لمرة واحدة – هي الإشارة لتقييم الانتقال إلى نمط آخر، قبل أن يفشل النظام في الإنتاج. يتم تفصيل اعتبارات الهوية وصلاحيات الوصول بين الأنظمة في [دليل SSO والهوية في Salesforce](/ar/insights/salesforce-sso-identity-architecture).

## الملخص

اختيار نمط تكامل صحيح لا يبدأ بالسؤال "أي أداة"، بل بثلاثة أسئلة: مدى السرعة المطلوبة للاستجابة، من هو مالك البيانات، وماذا يحدث عندما يفشل شيء ما. الزمن الفعلي (Real-Time) مناسب عندما ينتظر المستخدم نتيجة؛ التقاط تغيير البيانات (CDC) والمبني على الأحداث (Event-Driven) مناسبان لتحديث سريع لتغيير فردي أو للتوزيع على عدة مستهلكين؛ المعالجة الدفعية (Batch) مناسبة للحجم الكبير في نافذة زمنية ثابتة. في كل نمط، خاصية عدم تغير التكرار (Idempotency)، ووجود ملكية محددة للبيانات، وآلية التسوية (Reconciliation) ليست "أمرًا لطيفًا أن يكون موجودًا" – بل هي شرط لكي يصمد التكامل تحت الحمل الحقيقي وليس مجرد عرض توضيحي.

## مصادر احترافية

- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – CRM Architecture — https://hpi.pro/crm-architecture
- HPI Pro – Integrations & Data — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ما الفرق العملي بين Fire-and-Forget و Request-Reply في تكامل Salesforce؟**
في Request-Reply، ينتظر المُستدعي استجابة ويتلقى تأكيدًا فوريًا بنجاح العملية أو فشلها - وهو مناسب عندما يكون المستخدم أمام الشاشة ويحتاج إلى نتيجة للمتابعة. في Fire-and-Forget، يتابع المرسل عمله على الفور وتصل الاستجابة، إذا وُجدت، بشكل غير متزامن - وهو مناسب عندما يتعلق الأمر بتحديث لا يعيق عملية بشرية. الاختيار الخاطئ يجعل المستخدمين ينتظرون نظامًا لم يتم تصميمه للانتظار، أو يفوتون حالات فشل صامتة.

**متى يكون CDC أفضل من Batch الدوري لمزامنة البيانات؟**
CDC (Change Data Capture) أفضل عندما يكون حجم التغييرات النسبي إلى الحجم الكلي صغيرًا، وعندما تكون هناك حاجة لعكس التغيير في غضون دقائق لا ساعات - على سبيل المثال تحديث حالة طلب يؤثر على خدمة العملاء. Batch أفضل عندما يكون من الملائم معالجة حجم كبير في فترة زمنية ثابتة، أو عندما لا يدعم المصدر Event Stream، أو عندما تتطلب المعالجة نفسها حسابًا على مجموعة كاملة من السجلات وليس على تغيير فردي.

**كيف يتم التعامل مع تكرار الرسائل في تكامل قائم على الأحداث؟**
نفترض أن كل رسالة قد تصل أكثر من مرة، ونصمم الجانب المُستقبِل ليكون Idempotent: معرف فريد لكل رسالة، والتحقق مما إذا كانت قد تم معالجتها قبل تنفيذ الإجراء، وحفظ النتيجة بحيث لا يؤدي التشغيل المتكرر إلى إنشاء سجل مكرر أو التحديث مرتين. الاعتماد على 'وصول الرسالة مرة واحدة' هو الافتراض الذي ينهار أولاً تحت الحمل الزائد أو فشل الشبكة.

**من المسؤول عن مصدر الحقيقة عندما يتم تحديث نفس الحقل في Salesforce وفي نظام خارجي؟**
يجب تحديد أي نظام يمتلك الحقل مسبقًا، وتوثيق ذلك في عقد التكامل وليس فقط في ذاكرة الفريق. التحديث ثنائي الاتجاه بدون مالك محدد سيخلق حلقات مزامنة ونتيجة نهائية تعتمد على التوقيت. عندما تكون هناك حاجة حقيقية للتحرير من كلا الجانبين، يتطلب الأمر قاعدة واضحة لتسوية التعارضات (Conflict Resolution) - على سبيل المثال 'آخر تحديث يفوز' بناءً على Timestamp - وليس الافتراض بأن هذا الوضع لن يحدث.

**كيف نعرف أن نمط التكامل المختار لا يزال مناسبًا بعد تضاعف الحمل عشرة أضعاف؟**
نتحقق من ثلاثة أمور: هل لا يزال وقت المعالجة يفي باتفاقية مستوى الخدمة (SLA) المحددة؟ هل ارتفع معدل الفشل وإعادة المحاولة (Retry) فوق العتبة المحددة مسبقًا؟ وهل تقترب حدود API الخاصة بـ Salesforce (مثل Governor Limits أو API Calls) من الحد الأقصى؟ أي ارتفاع في أي من هذه المؤشرات هو إشارة للنظر في الانتقال من Batch إلى CDC، أو إضافة قوائم انتظار (Queueing)، أو تقسيم العمليات إلى عمليات متوازية - قبل أن يفشل النظام في بيئة الإنتاج.

---

## نموذج صلاحيات Salesforce: كيف تخطط الوصول دون إفراط
URL: https://hpi.pro/ar/insights/salesforce-permission-model
تبني معظم المؤسسات نموذج الصلاحيات من الأعلى إلى الأسفل – أولاً ملف تعريف (Profile) واسع، ثم تعديلات فردية حتى لا يتذكر أحد لماذا يمتلك المستخدم صلاحية معينة. الطريقة الصحيحة عكس ذلك: ملف تعريف (Profile) محدود للوصول الأساسي، ومجموعات صلاحيات (Permission Set Groups) تُشكّل القدرة التشغيلية حسب الدور. تقدم هذه المقالة ذلك كإطار عمل تشغيلي.

## السؤال الجوهري: ما الذي يحدد صلاحيات المستخدم؟

عندما يسأل أحدهم "كيف حصل مستخدم على صلاحية الوصول إلى هذا الحقل؟"، فإن الإجابة الصحيحة دائمًا ما تكون مزيجًا من عدة عوامل: يحدد ملف التعريف (Profile) صلاحية الوصول الأساسية، وتضيف مجموعات مجموعات الصلاحيات (Permission Set Groups) المخصصة للمستخدم إمكانات بناءً على دوره الوظيفي، وأحيانًا يتم التعامل مع استثناء معين من خلال مجموعة صلاحيات (Permission Set) واحدة إضافية. المشكلة الفعلية هي أن معظم المؤسسات تبني هذا المزيج في الاتجاه المعاكس - تبدأ بملف تعريف (Profile) واسع النطاق يضم كل شيء تقريبًا، ثم "تصلح" المشكلات المحددة بصلاحيات فردية لا يتذكر أحد إزالتها.

يُبنى نموذج الصلاحيات السليم في الاتجاه المعاكس: ملف تعريف (Profile) محدود قدر الإمكان، يحدد بشكل أساسي الترخيص (Licensing)، الوصول الافتراضي للتطبيق (App Visibility)، وخصائص تسجيل الدخول (Login Properties)؛ وتُنقل جميع إمكانيات العمل الفعلية - مثل الكائنات (Objects)، الحقول (Fields)، والعمليات (Actions) - إلى مجموعات الصلاحيات (Permission Sets) ومجموعات مجموعات الصلاحيات (Permission Set Groups). من المهم التوضيح: تتناول هذه المقالة مستوى الكائن (Object)، الحقل (Field)، وصلاحيات النظام (System Permissions) فقط. أما قضايا رؤية السجلات بين المستخدمين - مثل إعدادات الافتراضيات على مستوى المؤسسة (OWD)، التسلسل الهرمي للأدوار (Role Hierarchy)، وقواعد المشاركة (Sharing Rules) - فتُناقش في [دليل رؤية ومشاركة البيانات](/ar/insights/crm-architecture-guide)، لأنها تمثل طبقة قرار منفصلة ذات مقايضات خاصة بها.

## الوحدات الثلاث ودور كل منها

| الوحدة | ما الذي تحدده | عدد الوحدات الممكنة للمستخدم | متى يتم اختيارها |
|---|---|---|---|
| Profile | الترخيص (Licensing)، الرؤية الافتراضية للتطبيق (Default App Visibility)، تخطيط الصفحة (Page Layout)، ساعات/عناوين IP لتسجيل الدخول (Login Hours/IP) | واحد فقط | الاختلافات البنيوية بين أنواع المستخدمين |
| Permission Set | صلاحيات الكائن (Object)، الحقل (Field)، فئة Apex (Apex Class)، علامة التبويب (Tab) - تضيف فقط | حسب الحاجة | إمكانية واحدة ذات صلة ببعض الأدوار |
| Permission Set Group | تجميع لعدة مجموعات صلاحيات (Permission Sets) تحت اسم واحد، مع إمكانية الكتم (Muting) | حسب الحاجة | مجموعة ثابتة من الصلاحيات تمثل دورًا وظيفيًا كاملاً |

الفرق بين مجموعة الصلاحيات (Permission Set) ومجموعات مجموعات الصلاحيات (Permission Set Group) ليس تقنيًا فقط - بل هو تنظيمي. مجموعة الصلاحيات (Permission Set) الواحدة مناسبة لإمكانية واحدة ومحددة ("الوصول إلى التقارير المالية"). أما مجموعات مجموعات الصلاحيات (Permission Set Group) فتكون مناسبة عندما يراد تخصيص "حزمة عمل" كاملة لقسم أو دور، وتحديثها في مكان واحد عند تغييرها.

## إطار القرار: إلى أي وحدة تنتمي الصلاحية الجديدة؟

عندما يثار طلب لإضافة صلاحية وصول، فإن السؤال الأول ليس "إلى أي ملف تعريف (Profile) يجب إضافتها؟" بل "إلى أي وحدة تنتمي هذه الصلاحية من الناحية الهيكلية؟":

1.  **هل هذه الصلاحية تميز جميع أصحاب نفس نوع الترخيص؟** إذا كان الأمر كذلك - فهذا مكان لملف تعريف (Profile)، بشرط أن يتعلق الأمر بجميع أصحاب الترخيص وليس بمجموعة فرعية.
2.  **هل هذه إمكانية عمل تحتاجها مجموعة وظيفية معينة دائمًا مع صلاحيات إضافية؟** إذا كان الأمر كذلك - فهذا مكان لمجموعة مجموعات الصلاحيات (Permission Set Group)، حتى لو كان يتطلب تقسيمها أولاً إلى عدة مجموعات صلاحيات (Permission Sets) منفصلة للسماح بدمج مرن.
3.  **هل هذه صلاحية محددة ومؤقتة لمستخدم واحد أو استثناء؟** إذا كان الأمر كذلك - مجموعة صلاحيات (Permission Set) مستقلة، تُخصص يدويًا وتُراجع في التدقيق الدوري.
4.  **هل من المفترض أن تسلب الصلاحية شيئًا من مستخدم معين ضمن مجموعة أوسع؟** هنا يأتي دور مجموعة الصلاحيات الصامتة (Muting Permission Set) ضمن مجموعة مجموعات الصلاحيات (Permission Set Group) - وهي الأداة الوحيدة في Salesforce التي تسمح بتقليل الصلاحيات دون لمس ملف التعريف (Profile) أو تفكيك المجموعة.

القاعدة التي تمنع معظم الانحراف (Drift): لا يتم أبدًا تعديل ملف تعريف (Profile) لحل مشكلة مستخدم واحد. إذا كان التعديل يُعرف على أنه استثناء، فإنه يمر عبر مجموعة صلاحيات (Permission Set) موثقة ولها تاريخ مراجعة.

## قائمة تحقق لبناء نموذج صلاحيات من البداية

-   ☐ تم تحديد الأدوار الوظيفية الفعلية (وليس الأقسام التنظيمية) وتم تسمية كل دور بوضوح.
-   ☐ لكل دور، تم تحديد قائمة الإمكانيات المطلوبة على مستوى الكائن (Object)، الحقل (Field)، وفئة Apex (Apex Class).
-   ☐ تم بناء مجموعات صلاحيات (Permission Sets) مركزة على إمكانية واحدة، وليست "كومة صلاحيات" عامة.
-   ☐ تلقى كل دور مجموعة مجموعات صلاحيات (Permission Set Group) واحدة تجمع الإمكانيات ذات الصلة.
-   ☐ تم تقليص ملفات التعريف (Profiles) لتقتصر على اختلافات الترخيص والبنية التحتية فقط.
-   ☐ تم تحديد عملية للحالات الاستثنائية: من يوافق على مجموعة صلاحيات (Permission Set) محددة ولأي مدة.
-   ☐ تم تحديد وتيرة مراجعة (ربع سنوية على الأقل) تقارن الصلاحيات النشطة بالدور الحالي.
-   ☐ تم تحديد مالك واحد (Owner) لصيانة نموذج الصلاحيات لمواجهة التغييرات الهيكلية التنظيمية.

## سيناريو مؤسسي: شركة تأمين بثلاث وحدات مبيعات

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

أعاد فريق الهندسة بناء النموذج: ثلاثة ملفات تعريف (Profiles) فقط، حسب نوع الترخيص (Sales Cloud الكامل، Community للوكلاء الخارجيين، Service Cloud للمطالبات). وفوقها، سبع مجموعات مجموعات صلاحيات (Permission Set Groups) حسب الدور الوظيفي الفعلي - ممثل مبيعات، مدير فريق مبيعات، وكيل خارجي، مدير وكلاء، محقق مطالبات، مدير مطالبات، ودور وسيط يتعامل مع المبيعات والمطالبات معًا. تم تشكيل كل مجموعة مجموعات صلاحيات (Permission Set Group) من مجموعات صلاحيات (Permission Sets) مركزة مثل "الوصول إلى وثائق التأمين النشطة" أو "الموافقة على استرداد مالي حتى سقف محدد"، بحيث يمكن دمجها مرة أخرى عند إنشاء دور جديد دون بناء صلاحية من الصفر.

النتائج الملموسة: انخفض وقت إعداد مستخدم جديد من عدة أيام (تضمنت فحصًا يدويًا لأي ملف تعريف (Profile) مناسب) إلى عدة ساعات، وانخفض عدد طلبات الدعم من نوع "ليس لدي وصول إلى الحقل X" إلى النصف في الربع الذي تلا الانتقال، لأن معظم هذه الطلبات كانت ناتجة عن ملف تعريف (Profile) لم يتضمن الإمكانية ولم يكن واضحًا لمن يجب الاتصال للإصلاح.

## المخاطر الشائعة والإجراءات الوقائية

| المخاطرة | كيف تظهر عمليًا | إجراء وقائي |
|---|---|---|
| تحول Profile إلى أداة إصلاح محددة | تعدد Profiles شبه متطابقة، كل منها لمجموعة صغيرة | نقل كل صلاحية محددة إلى Permission Set وتقليص Profiles إلى الترخيص فقط |
| عدم اتساق Field-Level Security | نفس الحقل مكشوف في مكان ومحظور في مكان آخر | توثيق مصفوفة FLS مركزية لكل حقل حساس ومراجعتها في كل إصدار |
| "التصاق" الصلاحيات بعد تغيير الدور الوظيفي | المستخدم الذي غير دوره يحتفظ بصلاحيات من الدور السابق | عملية إلغاء تعيين الدور (Offboarding-from-role) التي تزيل مجموعة مجموعات الصلاحيات (Permission Set Group) القديمة قبل إضافة الجديدة |
| صلاحيات النظام (System Permissions) واسعة جدًا (View All Data, Modify All) | تُعطى "لتوفير الوقت" ولا تُزال لاحقًا | موافقة مخصصة وتاريخ انتهاء صلاحية لكل صلاحية نظام واسعة النطاق |
| عدم وجود مالك لنموذج الصلاحيات | كل فريق يضيف صلاحيات دون رؤية شاملة | مالك واحد (Owner) يوافق على كل Permission Set أو Group جديد قبل النشر |

## مقاييس للتحقق من صحة النموذج

| المجال | ما الذي يتم قياسه | وتيرة الفحص |
|---|---|---|
| التكرار غير الضروري | عدد الوظائف النشطة (Profiles) بالنسبة لعدد أنواع التراخيص الفعلية | ربع سنوي |
| دقة الصلاحيات | نسبة المستخدمين الذين تتطابق صلاحياتهم مع الدور المسجل في الموارد البشرية | ربع سنوي |
| الاستثناءات المفتوحة | عدد مجموعات الصلاحيات (Permission Sets) المحددة التي لا تحتوي على تاريخ مراجعة | شهري |
| الصلاحيات الواسعة النطاق | عدد المستخدمين الذين لديهم صلاحيات View All Data / Modify All Data بدون مبرر موثق | شهري |
| وقت الإعداد | متوسط الوقت من طلب وصول جديد إلى التخصيص الكامل | مستمر |

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

## كيف تتكامل هذه العناصر في البنية الشاملة

نموذج الصلاحيات الجيد هو شرط مسبق، وليس بديلاً، لتخطيط رؤية السجلات (OWD، Role Hierarchy، Sharing Rules) - يكمل هذان الموضوعان بعضهما البعض ولكنهما يُحلان بشكل منفصل. عادةً ما تكتشف المؤسسة التي تحاول حل مشكلة الرؤية عن طريق توسيع الملف التعريفي (Profile)، أو العكس، أن الحل هش بمجرد تغير الهيكل التنظيمي. عندما تنتقل المؤسسة بين بيئات Salesforce متعددة (Multi Orgs) وبيئة Salesforce واحدة (Single Org)، فإن نموذج الصلاحيات هو أحد الأمور التي يجب إعادة تخطيطها - يتوفر توسع في هذا الموضوع في [دليل Single Org مقابل Multi Org](/ar/insights/salesforce-single-org-vs-multi-org). وعندما تعتمد الصلاحية نفسها على منطق مشروط معقد، فمن المجدي النظر فيما إذا كان التنفيذ ينتمي إلى Flow أو Apex، كما هو مفصل في [دليل Flow مقابل Apex](/ar/insights/salesforce-flow-vs-apex).

في المؤسسات التي تدير عمليات تعتمد على الأحداث بين الأنظمة، يجب التأكد من أن صلاحيات مستخدمي الخدمة (Integration Users) مبنية على نفس المبدأ - مجموعة صلاحيات (Permission Set) مركزة وليست ملف تعريف (Profile) واسع النطاق مع "System Administrator" كخيار افتراضي مناسب. يرتبط هذا الموضوع بالتخطيط الأوسع للتواصل بين الأنظمة، الموضح في [دليل هندسة Salesforce المعتمدة على الأحداث](/ar/insights/salesforce-event-driven-architecture).

## ملخص

يُبنى نموذج الصلاحيات الذي يصمد أمام اختبار الزمن من الأسفل إلى الأعلى: إمكانيات مركزة في مجموعات الصلاحيات (Permission Sets)، وتجميعها وفقًا لدور وظيفي حقيقي في مجموعات مجموعات الصلاحيات (Permission Set Groups)، وملف تعريف (Profile) يحافظ على دور ضئيل يقتصر على الترخيص والبنية التحتية فقط. العلامة الواضحة للفشل هي تعدد ملفات التعريف (Profiles) التي تم إنشاؤها لحل مشكلات محددة - كل ملف تعريف إضافي من هذا النوع هو دين يتراكم حتى لا يتذكر أحد سبب وجوده. عندما لا تتوفر القدرة الداخلية لبناء أو تنظيف نموذج موجود، فإن [خدمة هندسة CRM](/ar/crm-architecture) توفر مسارًا عمليًا لبداية مركزة.

### أسئلة وأجوبة
**ما هو الفرق العملي بين Profile و Permission Set؟**
لكل مستخدم ملف تعريف (Profile) واحد فقط، والذي يحدد أيضاً أموراً ليست صلاحيات بالمعنى المعتاد – مثل رؤية التطبيق الافتراضية (App Visibility)، تعيين تخطيط الصفحة (Page Layout Assignment)، ساعات تسجيل الدخول (Login Hours)، ونطاقات IP. أما Permission Set فهو إضافة تزيد فقط من إمكانية الوصول ولا تلغيها أبداً. الخلاصة التخطيطية: اجعل دور Profile ضئيلاً، وابنِ معظم الاختلافات بين المستخدمين في Permission Sets.

**متى يتم دمج عدة Permission Sets في Permission Set Group واحد؟**
عندما تحتاج مجموعة من المستخدمين – على سبيل المثال 'ممثل خدمة عملاء أول' – دائماً إلى نفس المجموعة الثابتة من الصلاحيات التي تأتي من عدة Permission Sets منفصلة (الوصول إلى سجلات العملاء، الوصول إلى المبالغ المستردة، الوصول إلى قاعدة المعرفة). يوفّر الدمج في مجموعة واحدة التخصيص اليدوي المتكرر ويقلل من الأخطاء حيث يتلقى المستخدم جزءاً فقط من المجموعة المطلوبة للدور.

**هل يمكن لـ Permission Set إلغاء صلاحية موجودة في Profile؟**
لا. الصلاحيات في Salesforce هي إضافية فقط – Permissin Set يضيف، ولا يقيّد أبداً. إذا كنت بحاجة إلى منع الوصول عن مستخدم محدد دون التأثير على الآخرين، فالحل هو Muting Permission Set ضمن Permission Set Group، وليس تعديل ملف تعريفه (Profile).

**كم عدد الـ Profiles التي يجب أن تكون موجودة في مؤسسة متوسطة الحجم؟**
لا يوجد رقم ثابت، ولكن قاعدة إرشادية مفيدة هي: يجب أن يعكس عدد الـ Profiles اختلافات الترخيص والبنية التحتية (License Type، الوصول الافتراضي للتطبيق)، وليس اختلافات الصلاحيات بين الأدوار. المؤسسة التي تحتوي على عشرات الـ Profiles غالباً ما تستخدمها للتعويض عن عدم وجود Permission Set Groups منظمة.

**كيف يمكن التحقق من أن الصلاحية التي تمت إضافتها لم تبقَ نشطة بعد الحاجة إليها؟**
باستخدام Permission Set مخصص لفترة زمنية محدودة (Permission Set License مع تاريخ انتهاء صلاحية عند الاقتضاء، أو عملية تدقيق ربع سنوية) وليس صلاحية دائمة. بالإضافة إلى ذلك، يتم تشغيل تقرير دوري يقارن بين الصلاحيات النشطة والدور الحالي في جدول الموارد البشرية (HR)، ويتم تحديد الانحرافات للتحقيق.

---

## Salesforce Org واحد أم Multi-Org؟ اعتبارات المؤسسات متعددة الوحدات
URL: https://hpi.pro/ar/insights/salesforce-single-org-vs-multi-org
لا ينشأ مفهوم Multi-Org من قرار واحد، بل يتراكم نتيجة لوحدات عمل ولوائح ونماذج بيانات لا تتوافق في نفس المساحة. يقدم هذا المقال اختبارًا من ثلاثة أسئلة لتحديد الحاجة الحقيقية، ومصفوفة مقارنة للتكلفة والعائد، ومسارًا متدرجًا للمؤسسات التي تتجه بالفعل نحو التجزئة.

## الأسئلة الثلاثة التي تحدد الحاجة إلى بيئات Salesforce متعددة (Multi-Org)

يُعد الخطأ الشائع هو التعامل مع سؤال "بيئة واحدة أم بيئات متعددة؟" كمسألة فنية تتعلق بالقدرة أو الأداء. في معظم الحالات، يمكن تحقيق المتطلبات الفنية ضمن بيئة واحدة (Org واحد) لـ Salesforce: حيث توفر ميزات مثل Record Types، Profiles، Permission Sets، وSharing Rules فصلًا كافيًا بين الوحدات التجارية دون الحاجة إلى تقسيم البيئة نفسها. تدعم Salesforce عشرات الآلاف من المستخدمين وملايين السجلات ضمن بيئة واحدة – ونادرًا ما تكون القدرة هي السبب الحقيقي للتقسيم.

السؤال الحاسم حقًا هو مسألة الاستقلالية التنظيمية، وينقسم إلى ثلاثة اختبارات:

1.  **استقلالية تنظيمية حقيقية** — هل هناك متطلب قانوني أو تعاقدي للفصل المادي للبيانات (على سبيل المثال، كيان قانوني منفصل يخضع لتنظيم محلي يمنع مشاركة البنية التحتية)، بخلاف الفصل المنطقي الذي يمكن تحقيقه في نموذج المشاركة (Sharing Model)؟
2.  **وتيرة تغيير غير متوافقة** — هل تحتاج وحدة أعمال واحدة إلى دورات إصدار متكررة وسريعة بينما تتطلب وحدة أخرى أقصى درجات الاستقرار والتدقيق الصارم، بحيث يصبح كل إصدار مشترك نقطة احتكاك مستمرة بين الفرق؟
3.  **نموذج بيانات متعارض بشكل مادي**، وليس مجرد اختلاف — عندما يكون لذات الكيان (مثل "العميل" أو "الطلب") تعريف حقل إلزامي، أو سير عمل موافقة، أو هيكل علاقات يتعارض ماديًا بين الوحدات، وليس مجرد اختلاف في العرض.

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

## مصفوفة القرار: بيئة Salesforce واحدة مقابل بيئات متعددة

| البُعد | بيئة Salesforce واحدة بفصل منطقي | بيئات Salesforce متعددة منفصلة |
| :---------------- | :---------------------------------- | :------------------------- |
| تكلفة الترخيص والصيانة | أقل – ترخيص واحد، إدارة مستخدمين مركزية | أعلى – ترخيص مضاعف، إدارة إصدارات مضاعفة |
| Customer 360 وعرض موحد | طبيعي – جميع البيانات في نفس مساحة الاستعلام | يتطلب طبقة ذكاء أعمال (BI) أو تكامل مخصص |
| استقلالية تشغيلية للوحدة | محدودة – كل إصدار يؤثر على الجميع | كاملة – كل وحدة تتحكم في وتيرتها |
| الامتثال للمتطلبات التنظيمية الصارمة | غير ممكن إذا كان المتطلب هو الفصل المادي | الحل الوحيد الذي يلبي المتطلب |
| تعقيد التكامل بين الوحدات | منخفض | مرتفع – يتطلب وسيطًا (Middleware) أو أداة ETL |
| مخاطر الدمج/التقسيم المستقبلي | منخفضة – تغيير في الصلاحيات فقط | عالية – مشروع ترحيل كامل |

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

## ما يحدث في الواقع عند التقسيم دون سبب كافٍ

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

لذلك، فإن أحد المبادئ التوجيهية في [هندسة Salesforce](/ar/insights/crm-architecture-guide) هو تقييم ما إذا كان بالإمكان تحقيق الحاجة التنظيمية باستخدام الصلاحيات وقواعد المشاركة (Sharing Rules) ضمن بيئة Salesforce واحدة، ومن ثم النظر في التقسيم.

## مسار تدريجي لمن يتطلب منهم التقسيم بالفعل

عندما ينطبق أحد الاختبارات الثلاثة بالفعل، يجب أن يتم التقسيم وفقًا لترتيب يقلل من المخاطر:

### 1. تحديد مفتاح تعريف عالمي قبل التقسيم

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

### 2. اختيار نمط التكامل حسب اتجاه البيانات وسرعتها

إذا كان الأمر يتعلق بتحديث دوري لأغراض الإبلاغ فقط، فإن أداة ETL مجدولة تكفي. أما إذا كانت هناك حاجة إلى رؤية فورية (على سبيل المثال، التحقق من الائتمان عبر الوحدات)، فيتطلب الأمر واجهة برمجة تطبيقات (API) متزامنة مع معالجة الأخطاء وإعادة المحاولة (Retry). يُعد اختيار النمط غير المناسب السبب الرئيسي في تعطل عمليات التكامل بين البيئات المختلفة (Cross-Org Integrations) تحت الضغط – مزيد من التفاصيل في [أنماط تكامل Salesforce](/ar/insights/salesforce-integration-patterns).

### 3. التخطيط المسبق للهويات وصلاحيات الوصول

يحتاد المستخدمون الذين يعملون عبر بيئتي Salesforce (على سبيل المثال، مديري الحسابات العالميين) إلى حل إدارة هويات يُدار مرة واحدة، لا إلى مستخدمين منفصلين بكلمتي مرور منفصلتين. يمنع تخطيط الدخول الموحد (SSO) بين بيئات Salesforce من الحاجة إلى إجراء أي تغييرات على صلاحيات المستخدم يدويًا في بيئتين – يتناول الموضوع بالتفصيل في [هندسة الدخول الموحد (SSO) والهوية في Salesforce](/ar/insights/salesforce-sso-identity-architecture).

### 4. اختبار حدود الـ API قبل نشر التكامل في بيئة الإنتاج

كل طلب بين بيئتي Salesforce يُحسب ضمن حصة الـ API لكلا الجانبين. قد يؤدي حجم حركة مرور البيانات الذي يُخطط له دون اختبار حجم التحميل إلى تجاوز الحدود اليومية بالذات خلال أوقات الذروة، أي بالتحديد عندما يكون التكامل في أمس الحاجة إليه. يجب التحقق من ذلك مسبقًا مقابل [حدود مرونة الـ API في Salesforce](/ar/insights/salesforce-api-limits-resilience).

### 5. تحديد المالك وعملية حوكمة مشتركة لكلتا بيئتي Salesforce

يجب أن يكون هناك مسؤول عن اتساق القرارات المعمارية بين البيئات – مثل هيكل الحقول، وتوافق التسميات، وسياسات التغيير. بدون ملكية مركزية، تتباعد بيئتي Salesforce على مستوى المعايير خلال عام واحد، مما يجعل أي تكامل مستقبلي أكثر تكلفة.

## سيناريو توضيحي: مجموعة تأمين ذات قسمين

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

كان الاقتراح الأولي هو التقسيم إلى بيئة Salesforce منفصلة لكل قسم، ولكن عند الفحص مقابل الأسئلة الثلاثة، تبين أن وتيرة التنظيم (الاختبار 2) هي الوحيدة التي تنطبق حقًا – لم يتعارض نموذج العميل والمنتج (الاختبار 3 سلبي)، ولم يكن هناك متطلب منفصل للفصل المادي للبيانات (الاختبار 1 سلبي). كان الحل المختار هو بيئة Salesforce واحدة مع "مسارين إصدار" منفصلين ضمن نفس البيئة – بيئة Sandbox مخصصة وعملية موافقة منفصلة لقسم التأمين على الحياة، مع استخدام نموذج بيانات مشترك لـ Customer 360 واحد. تم تجنب التقسيم الكامل، وبالتالي تم توفير تكاليف الصيانة المزدوجة التي كان من الضروري تحملها لسنوات.

## المخاطر الشائعة وكيفية تجنبها

-   **التقسيم "المؤقت" الذي يصبح دائمًا** — بيئة Sandbox تتحول إلى بيئة إنتاج دون المرور بالرقابة الأمنية. يتم تجنب ذلك بفرض عملية موافقة حوكمة رسمية على كل بيئة Salesforce تحتوي على بيانات حقيقية للعملاء، دون استثناء.
-   **سجلات مكررة دون مفتاح مشترك** — يحدث هذا عندما يتم التقسيم قبل تحديد معرف عالمي. الحل هو تحديد الحقل المشترك كشرط مسبق للتقسيم، وليس كخطوة متأخرة.
-   **استنفاد حصة الـ API في أوقات الذروة** — يحدث ذلك عندما يتم تخطيط التكامل بين بيئات Salesforce بناءً على متوسط ​​الحجم وليس حجم الذروة. الحل هو اختبار التحميل قبل النشر في بيئة الإنتاج وبناء آلية للتحمل (Backoff).
-   **تآكل المعايير بين بيئات Salesforce** — يحدث ذلك عندما لا يكون هناك مالك واحد للهندسة المعمارية المشتركة. يتم تجنب ذلك من خلال إنشاء لجنة حوكمة صغيرة توافق على تغييرات هيكل البيانات على جانبي التكامل.
-   **تقارير إدارية غير موثوقة** — يحدث ذلك عند محاولة حساب مؤشرات الأداء الرئيسية (KPI) على مستوى المؤسسة مباشرة من Salesforce دون طبقة توحيد. يتم تجنب ذلك من خلال إنشاء طبقة ذكاء أعمال (BI) مخصصة منذ اليوم الأول للتقسيم، وليس كمشروع إصلاح متأخر.

## الملخص

الخيار الافتراضي هو بيئة Salesforce واحدة؛ ويعتبر التقسيم استثناءً يتطلب مبررًا ملموسًا في أحد الاختبارات الثلاثة: الاستقلالية التنظيمية الحقيقية، أو وتيرة التغيير غير المتوافقة، أو نموذج البيانات المتعارض ماديًا. عند وجود هذا المبرر، يقاس نجاح الانتقال بالتحضير الذي تم قبل التقسيم: مفتاح تعريف عالمي، نمط تكامل ملائم، هوية مشتركة، اختبار حدود الـ API، ووجود ملكية واضحة للمعايير المشتركة. فالمؤسسة التي تتجاهل هذا التحضير لا توفر جهدًا، بل تؤجله فقط إلى اللحظة التي سيكون فيها الإصلاح أكثر تكلفة بكثير.

### أسئلة وأجوبة
**هل استحواذ الشركات كافٍ لتبرير الانتقال إلى Multi-Org؟**
ليس تلقائيًا. إذا استمرت الشركتان في العمل تحت علامات تجارية وعمليات بيع منفصلة لسنوات، فهناك أساس للنظر في Org منفصل. أما إذا كانت الخطة هي توحيد العمليات في غضون سنة أو سنتين، فمن الأفضل غالبًا الاندماج مؤقتًا تحت Org واحد مع فصل في الصلاحيات وتوفير تكلفة الاندماج العكسي مستقبلًا.

**كيف يتم التعامل مع التقارير الموحدة عند وجود عدة Orgs؟**
عادةً ما يكون ذلك من خلال طبقة ذكاء أعمال (BI) خارجية (مثل Data Cloud أو Snowflake أو Tableau) التي تسحب البيانات من كل Org على حدة وتوحدها في نموذج تقارير واحد. محاولة بناء تقارير Cross-Org داخل Salesforce نفسه تتطلب دائمًا تقريبًا عمل تكامل مكلف لا يستحق القيمة التي يقدمها.

**ماذا يحدث للعميل الذي يظهر في اثنين من Orgs مختلفين؟**
بدون عملية مطابقة محددة، سيتم إنشاء هذا العميل كسجل مكرر في كل Org، مع سجل جزئي على كل جانب. يجب تحديد مفتاح تعريف خارجي مشترك (مثل رقم التسجيل الضريبي أو معرف العميل العالمي) وعملية مزامنة أو على الأقل تقرير مطابقة دوري، حتى قبل حدوث الانفصال الفعلي.

**هل يمكن إعادة دمج اثنين من Orgs في Org واحد؟**
نعم، ولكن هذا مشروع ترحيل كامل وليس مجرد إعداد تهيئة. يجب مطابقة Object Model، وRecord Types، وتدفقات الموافقة، وبيانات السجل، والتكاملات بين البيئتين، وسيتطلب غالبًا أداة ترحيل مخصصة. لذلك، ينبغي النظر إلى الانفصال كخطوة يصعب التراجع عنها، وليس كتجربة قابلة للعكس.

**ماذا يعني 'Multi-Org فعليًا بدون قرار'؟**
هو وضع شائع حيث تقوم وحدة عمل بفتح Sandbox أو Org منفصل لغرض تجريبي مؤقت، ثم يتحول هذا إلى بيئة إنتاج فعلية دون أن يتخذ أحد قرارًا واعيًا بذلك. العلامة المميزة هي وجود بيانات عملاء حقيقية في Org لم يخضع لعملية حوكمة وأمان ورقابة وصول كاملة.

---

## ربط البيانات (Data Mapping) لترحيل Salesforce: كيف تتفادى الأخطاء قبل التحميل
URL: https://hpi.pro/ar/insights/salesforce-data-mapping
لا تعود معظم إخفاقات ترحيل البيانات إلى Salesforce إلى فشل في الأدوات، بل إلى اختلاف في الدلالات: فقد يكون هناك حقل يحمل الاسم نفسه في نظامين مختلفين ولكنه يصف أمرين متباينين. يعرض هذا الدليل كيفية بناء وثيقة ربط بيانات (Mapping) توثّق الدلالات التجارية، وقواعد التحويل (Transformation)، والقيم الافتراضية، والمسؤوليات، وذلك قبل تشغيل عملية التحميل الأولى.

## الإجابة المختصرة

لا تُعد خرائط البيانات (Data Mapping) مجرد جدول ترجمة بين الحقول، بل هي الوثيقة التي يحدد فيها الكيان التجاري معنى كل معلومة يقوم بترحيلها إلى Salesforce. تُعزى تقريباً كل أخطاء التحميل التي تبدو تقنية – كتنسيق تاريخ خاطئ، أو قائمة منسدلة (Picklist) غير معروفة، أو علاقة مكسورة – إلى قرار عمل لم يُتخذ مسبقاً.

التسلسل الفعال هو كالتالي: أولاً تحديد الكيانات التي ستُرحل، ثم تحديد المالك التجاري لكل كيان، ثم تحديد الحقول التي لها مستهلك حقيقي، وأخيراً كتابة قواعد التحويل. عندما يبدأ العمل بالاتجاه المعاكس، يتخذ الفريق التقني قرارات تجارية بصمت – ويُكتشف الأمر بعد ثلاثة أشهر من إطلاق النظام (Go Live) عندما لا يتطابق تقرير الإيرادات.

يمكن الاطلاع على خلفية تخطيط عملية التحويل بأكملها في [ترحيل البيانات إلى Salesforce.](/ar/insights/salesforce-data-migration-guide)

## الأنواع الثلاثة للفجوات التي تكشفها خرائط البيانات

| نوع الفجوة | مثال شائع | من يقرر |
| --- | --- | --- |
| فجوة دلالية | "عميل نشط" = اشترى هذا العام في نظام واحد، = لم يُحظر في نظام آخر | مالك العملية التجارية |
| فجوة هيكلية | عميل واحد بخمسة عناوين مقابل نموذج Account/Contact | مهندس البيانات |
| فجوة جودة | 18% من السجلات بدون رقم تعريف صالح | مالك البيانات + التشريعات |

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

## طبقة المعنى: قاموس البيانات قبل جدول التخطيط (Mapping)

قبل ربط حقل بحقل، يجب كتابة تعريف قاموس مصطلحات لكل كيان رئيسي: ما هو Account، ما الذي يميز Lead عن Contact في هذا الكيان، متى تُغلق Opportunity. هذه التعريفات قصيرة – سطران لكل كيان – لكنها ما يمكّن من حسم النزاعات بدلاً من مجرد التصويت.

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

## تشريح سطر تخطيط (Mapping) سليم

يجب أن يجيب كل سطر في الجدول على سبعة أسئلة: من أي كائن وحقل في المصدر، إلى أي كائن وحقل في Salesforce، ما هو نوع البيانات وطولها، ما هي قاعدة التحويل، ما الذي يحدث في حالة القيمة الفارغة، ما هي القيمة الافتراضية، ومن وافق. أي سطر ينقصه عمود واحد من هذه الأعمدة سيعود كسؤال في منتصف عملية التحميل ليلة الانتقال (Cutover).

ثلاث قواعد عمل لتجنب الأعطال:

- **لا يوجد تحويل صامت.** يجب تسجيل كل قيمة "يصلحها" النظام بنفسه في سجل الاستثناءات (exception log).
- **القيمة الافتراضية قرار عمل.** يجب أن يكون المسؤول عن التقارير حسب المنطقة هو من يكتب `Country = IL` كقيمة افتراضية.
- **المفاتيح الخارجية قبل كل شيء.** يجب الاحتفاظ بمعرف خارجي (External ID) لكل كيان من نظام المصدر. بدونه لا توجد مطابقة (Reconciliation) ولا تشغيل ثانٍ.

## التحويلات (Transformations): أين تقع الأخطاء

التحويلات التي تُحدث أكبر قدر من الضرر هي في الواقع التحويلات البسيطة. التواريخ بدون منطقة زمنية تحرك السجلات بيوم واحد؛ الأسماء التي تُقلَّم (Trim) وتُحوَّل إلى أحرف كبيرة (Upper) بدون قاعدة موحدة تخلق تكرارات جديدة بعد أن قمنا بتنظيف التكرارات القديمة مباشرة؛ المبالغ التي تُحوَّل إلى عملة موحدة بسعر يومي تولّد فجوات تقارير مقارنةً بنظام تخطيط موارد المؤسسات (ERP).

القاعدة: يُفحص كل تحويل رقمي أو مالي بمقارنة المبالغ، وليس بمقارنة السجلات. الرقم المتطابق ليس دليلاً على الصحة.

من لم يحسم بعد مسألة مصدر الحقيقة سيجد خلفية في [مصدر الحقيقة في الكيان التجاري](/ar/insights/salesforce-source-of-truth)، ونافذة الانتقال (Cutover) نفسها في [الانتقال والمطابقة (Cutover & Reconciliation) في ترحيل Salesforce.](/ar/insights/salesforce-migration-cutover-reconciliation)

## سيناريو: شركة خدمات بنظامي مصدر

اقترب كيان خدمات يضم 90 ألف عميل من الترحيل من نظامين: نظام فواتير قديم ونظام خدمات تم شراؤه مع شركة فرعية. وُضع إشارة "جاهز" على جدول التخطيط (Mapping) الأول في غضون أسبوعين – 340 حقلاً مُخططاً.

عند تشغيل الاختبار التجريبي الأول (Rehearsal)، تم تحميل 97% من السجلات. تم اكتشاف المشكلة في المطابقة (Reconciliation): كان إجمالي الأرصدة في Salesforce أقل بـ 4.1% من نظام ERP. لم يكن السبب فشل التحميل، بل أن جميع السجلات ذات الرصيد السلبي (الائتمانات) تم ربطها بحقل به قاعدة تحقق (Validation Rule) تمنع القيمة السلبية – وتم وضعها كـ "صفر" بصمت.

كان التصحيح على مستويين: قاعدة تحويل صريحة للائتمانات، بالإضافة إلى تغيير السياسة – يجب أن ينتج كل قاعدة تقوم بتصفير أو تقصير قيمة سطراً استثنائياً. في التشغيل الثاني، ارتفع عدد الاستثناءات إلى 1,900، وكان هذا تقدماً: كانت الاستثناءات مرئية بدلاً من أن تكون مخفية. انخفض التشغيل الثالث إلى 40 استثناءً موثقاً، وعندها فقط تم تحديد تاريخ الانتقال (Cutover).

## المخاطر الشائعة والإجراءات الوقائية

| المخاطرة | كيف تبدو في الممارسة العملية | إجراء وقائي |
| --- | --- | --- |
| نقل كل التاريخ | ينتقل الحجم والتكرارات والمعلومات عديمة القيمة إلى النظام الجديد | تحديد سياسة الاحتفاظ بـ (Retention) وحدود الجودة |
| التخطيط التقني فقط | تُنقل الحقول دون فهم المعنى التجاري | قاموس البيانات والملاك التجاريون |
| التحويلات الصامتة | تُصحح القيم تلقائياً ولا يعلم أحد | تسجيل الاستثناءات إلزامي لكل قاعدة تحويل |
| عدم وجود اختبار تجريبي (Rehearsal) | تطول نافذة التوقف وتحدث مفاجآت | على الأقل تشغيلان كاملان |
| عدم وجود External ID | لا يمكن التحقق أو التصحيح أو إعادة التشغيل | يُحفظ مفتاح المصدر لكل كيان |

## كيف نقيس النجاح

| المجال | ماذا نقيس | وتيرة الفحص |
| --- | --- | --- |
| الاكتمال (Completeness) | نسبة الحقول الإلزامية المملوءة في الهدف | قبل وبعد كل تحميل |
| المطابقة (Reconciliation) | مطابقة العدد، المبالغ، والعلاقات مع المصدر | في كل اختبار تجريبي (Rehearsal) وفي الانتقال (Cutover) |
| الاستثناءات | عدد سطور الاستثناءات المفتوحة حسب الخطورة | يومياً خلال فترة الترحيل |
| الحقول بلا مستهلك | كم عدد الحقول التي تم ترحيلها ولم تُقرأ خلال 90 يوماً | مرة واحدة بعد الإطلاق (Go Live) |

يُعد المقياس الأخير تحضيراً للدورة التالية: فهو يوضح مقدار العمل الذي كان غير ضروري ويوجه نطاق الترحيل التالي.

الكيانات التي تفضل المرافقة المهنية في بناء خرائط البيانات تقوم بذلك ضمن [خدمة التكامل والبيانات](/ar/integrations-data).

## قائمة التحقق قبل التحميل الأول

- ☐ قاموس مصطلحات موجز لكل كيان رئيسي، معتمد تجارياً
- ☐ قائمة بالحقول ذات المستهلك المحدد؛ الباقي للأرشيف
- ☐ معرف خارجي (External ID) لكل كيان يُرحّل
- ☐ جدول ربط القيم (Value Mapping) كامل، بما في ذلك قيمة للقيم غير المعروفة
- ☐ قاعدة صريحة لكل قيمة فارغة ولكل قيمة افتراضية
- ☐ كل قاعدة تحويل تنتج سطر استثناء بدلاً من التصحيح الصامت
- ☐ سيناريو المطابقة (Reconciliation): العد، المبلغ، العلاقة، الفحص العيني
- ☐ حد استثناءات متفق عليه لا يجوز بعده إجراء الانتقال (Cutover)
- ☐ إصدار وتوقيع على جدول التخطيط (Mapping)
- ☐ خطة لإعادة الوضع السابق (Rollback) وإعادة التشغيل.

## مصادر احترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكامل والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ما الفرق بين الربط التقني والربط التجاري (Business Mapping)؟**
الربط التقني (Technical Mapping) يجيب عن السؤال "إلى أي حقل يتم إدخال هذا؟". أما الربط التجاري (Business Mapping) فيجيب عن "ماذا يعني هذا الحقل، ومن يقوم بتحديثه، وماذا يحدث عندما يكون فارغًا؟". قد يحتوي نظامان على حقل باسم "Status" يصف مرحلة بيع في مكان وحالة تحصيل في مكان آخر؛ الربط التجاري وحده يكشف هذا التباين قبل التحميل.

**كم عدد الحقول التي يجب ترحيلها بالفعل؟**
في المشاريع التي أشرفنا عليها، يتراوح بين 40% و60% من الحقول في النظام الأصلي إما غير مستخدمة فعليًا أو يمكن استنتاجها. القاعدة العملية هي ترحيل الحقل فقط إذا كان له مستخدم محدد: عملية، تقرير، أتمتة، أو التزام تنظيمي. يبقى الحقل الذي لا مستخدم له في الأرشيف وليس في Salesforce.

**أين توثّق قواعد التحويل (Transformation)؟**
في جدول ربط بيانات (Mapping) واحد مع تحديد الإصدار، حيث يحتوي كل صف على: المصدر، الوجهة، النوع، قاعدة التحويل، القيمة الافتراضية، معالجة القيم الفارغة، والمالك التجاري الذي وافق. إذا كانت القاعدة موجودة فقط في نص برمجي لعملية ETL، فلا يمكن لأي شخص في العمل الموافقة عليها ولا يمكن التحقق منها من خلال التسوية (Reconciliation).

**ماذا نفعل مع قيم قائمة الاختيار (Picklist) غير المتطابقة؟**
يتم بناء جدول منفصل لربط القيم (Value Mapping) مع ربط شامل يتضمن قيمة افتراضية للقيم غير المعروفة. القاعدة: لا تبقى أي قيمة في المصدر بدون وجهة، ولا يتم تحميل أي قيمة غير معروفة بصمت ــــ يتم إدخالها في تقرير استثناءات يقوم أحدهم بمعالجته قبل الانتقال الكامل (Cutover).

**متى يعتبر ربط البيانات (Mapping) جاهزاً؟**
عندما ينجح تشغيل تجربة كاملة (Rehearsal) مع تسوية البيانات (Reconciliation) التي تتحقق من الأعداد، المبالغ، وعلاقات الأب-الابن (Parent-Child relationships)، وتكون قائمة الاستثناءات المتبقية أصغر من الحد المتفق عليه مسبقًا ومُعتَمَدَة كتابيًا من قبل مالكي العملية.

---

## إزالة الازدواجية قبل Salesforce: استراتيجية عملية لتنقية البيانات
URL: https://hpi.pro/ar/insights/salesforce-data-deduplication
الازدواجية ليست مجرد خلل في البيانات، بل هي خلل في تحديد الهوية: لم يحدد التنظيم بعد ما الذي يجعل سجلين مختلفين لنفس العميل. يقدم هذا الدليل كيفية تحديد قواعد المطابقة، وبناء السجل الذهبي (Golden Record)، واتخاذ القرار بشأن ما يتم حذفه وما يتم الاحتفاظ به في السجل التاريخي، وكيفية منع تكرار الازدواجية بعد أسبوعين من التحميل الأولي للبيانات.

## الإجابة المختصرة

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

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

يُشرح التخطيط الشامل للترحيل في [دليل ترحيل البيانات إلى Salesforce](/ar/insights/salesforce-data-migration-guide).

## ثلاث طبقات من المطابقة

| الطبقة | الاعتماد عليها | الإجراء |
| --- | --- | --- |
| مفتاح قوي | رقم تعريف الشركة، رقم تعريف صاحب العمل الفردي، معرف من نظام المصدر، بريد إلكتروني موثق | دمج تلقائي |
| مفتاح مركب | اسم مُوحّد + مدينة + هاتف مُوحّد | دمج تلقائي بدرجة عالية |
| تشابه نصي | الاسم فقط، عنوان حر | مراجعة بشرية فقط |

النسبة التي تميز المشروع المُدار هي كالتالي: حوالي 70% من التكرارات تُغلق في الطبقة الأولى، وحوالي 20% في الطبقة الثانية، ويصل حوالي 10% إلى التدخل البشري. إذا وصلت معظم التطابقات إلى الطبقة الثالثة، فهذه علامة على عدم استثمار الجهد في توحيد البيانات – وليس بالضرورة أن تكون البيانات سيئة بشكل استثنائي.

## التوحيد قبل المقارنة

قبل أي مقارنة، يتم إنشاء أعمدة مساعدة مُوحّدة دون المساس بالبيانات الأصلية: إزالة لواحق الشركات (مثل "ذ.م.م." أو "Ltd")، توحيد المسافات وعلامات الاقتباس، تحويل أرقام الهواتف إلى تنسيق E.164، تحويل البريد الإلكتروني إلى أحرف صغيرة مع إزالة العلامات بعد علامة الجمع، وتقسيم العنوان إلى الشارع/الرقم/المدينة. في اللغة العبرية، يتم التعامل مع الكتابة الكاملة والناقصة والاختصارات.

يؤدي التوحيد وحده عادةً إلى تخفيض ثلث إلى نصف التكرارات "الصعبة"، حتى قبل تطبيق خوارزمية التشابه.

## Golden Record على مستوى الحقل

القرار "أي سجل سيبقى" ليس هو القرار المهم. القرار المهم هو "أي قيمة ستبقى في كل حقل". يتم تحديد سياسة موجزة: معلومات الفواتير من نظام تخطيط موارد المؤسسة (ERP)، معلومات الاتصال من النظام الذي سُجل فيه آخر نشاط، حالة العميل من النظام التشغيلي. لكل حقل مصدر مفضل واحد، ويتم الاحتفاظ بسجل للقيمة التي تم رفضها.

لولا هذه السياسة، سيكون كل دمج قرارًا لمن قام به في تلك اللحظة – ولن يكون من الممكن لاحقًا تفسير سبب اختفاء عنوان ما.

## ماذا يحدث للعلاقات والسجلات التاريخية

يؤثر دمج السجلات على الأنشطة، الفرص، الحالات (Cases)، الملفات، والصلاحيات. قبل التشغيل الجماعي، يجب تحديد ما يلي بوضوح: إلى أين تنتقل الأنشطة، ماذا يحدث للفرص المفتوحة لنفس العميل من سجلين مختلفين، ومن هو المالك بعد الدمج – لأن تغيير المالك يغير الرؤية وتقارير العمولات.

القاعدة العملية: لا يتم الدمج قبل وجود تقرير "ماذا تغير" يمكن استعادته، ويتم الاحتفاظ بمعرفات المصدر في حقل منفصل للسماح بالتحقيق بعد أشهر.

## سيناريو: مستورد لديه 210 آلاف جهة اتصال

شرع مستورد يعمل بنظام B2B في عملية ترحيل مع 210 آلاف جهة اتصال من ثلاثة أنظمة. أظهر التشغيل الأول لأداة التشابه 31 ألف زوج مشتبه به – وهو رقم لا يمكن لأحد مراجعته.

توقف الفريق وعكس الترتيب. أولاً، تم توحيد البريد الإلكتروني ورقم الهاتف: 14 ألف زوج تم إغلاقها تلقائيًا بناءً على مفتاح قوي. ثم تقرر أن الوحدة التجارية هي موقع العميل وليس الشركة الأم، مما أدى إلى إخراج 6 آلاف زوج كانوا شرعيين – فروع منفصلة لنفس السلسلة. بقي 4200 زوج للطبقة الوسطى، منها 3800 تم إغلاقها بدرجة عالية. وصل 400 زوج للمراجعة البشرية، وأغلقهما شخصان في ثلاثة أيام.

الدرس المستفاد لم يكن في اختيار الأداة. بل كان في أن تعريف الوحدة التجارية – الموقع مقابل الشركة الأم – قلل من الضجيج أكثر من أي تحسين خوارزمي.

## المنع: لماذا تتكرر الازدواجية

هناك ثلاثة مصادر رئيسية تعيد التكرارات بعد التشغيل المباشر (Go Live): الإدخال اليدوي بدون قواعد مطابقة نشطة (Matching Rules)، وعمليات التكامل التي تنشئ سجلاً بدلاً من تحديثه (تقوم Upsert على External ID بحل معظمها)، ونماذج Web-to-Lead التي لا تتحقق من الوجود. إذا لم يتم التعامل مع هذه المصادر الثلاثة، يعود معدل التكرار إلى مستواه الأصلي في غضون سنة إلى سنتين.

## المخاطر الشائعة والإجراءات الوقائية

| المخاطر | كيف تظهر عمليًا | إجراء وقائي |
| --- | --- | --- |
| دمج مفرط | دمج عملاء مختلفين ولا يمكن فصلهم | عتبة درجة عالية + مراجعة في المنطقة الرمادية |
| عدم تعريف الهوية | جدل متكرر حول ما يعتبر نفس العميل | قرار موثق على مستوى الكيان |
| فقدان السجلات التاريخية | اختفاء الأنشطة والفرص في الدمج | تقرير "ماذا تغير" وحفظ معرفات المصدر |
| تنظيف بدون منع | عودة الازدواجية في غضون أشهر | Matching Rules، Upsert ونماذج محمية |
| تنظيف بعد التحميل | كل دمج يؤثر على العلاقات الحية | التنظيف في مرحلة التجهيز (Staging) |

## كيف نقيس النجاح

| المجال | ماذا نقيس | وتيرة الاختبار |
| --- | --- | --- |
| التفرد (Uniqueness) | النسبة التقديرية للتكرار حسب الكيان | أسبوعيًا في الترحيل، ربع سنويًا لاحقًا |
| دقة الدمج | نسبة الدمج التي تم إلغاؤها أو تصحيحها يدويًا | في كل دورة دمج |
| المنع | السجلات الجديدة التي تم حظرها كازدواجية عند الإدخال | شهريًا |
| التأثير التجاري | الاستفسارات المكررة للعميل، دقة تقارير العملاء | ربع سنويًا |

يتم توفير الدعم المهني في بناء قواعد الهوية والمنع ضمن [خدمات التكامل والبيانات](/ar/integrations-data).

## قائمة تحقق قبل تشغيل الدمج

- [ ] تم تحديد الوحدة التجارية: شركة، موقع أو عقد.
- [ ] تم إنشاء أعمدة للتوحيد دون تغيير المصدر.
- [ ] ثلاث طبقات من المطابقة مع عتبات رقمية مكتوبة.
- [ ] سياسة Golden Record على مستوى الحقل، معتمدة تجاريًا.
- [ ] تم تحديد ماذا يحدث للأنشطة، الفرص، والملكية.
- [ ] يتم الاحتفاظ بمعرفات المصدر بعد الدمج.
- [ ] تقرير "ماذا تغير" يمكن إنتاجه واستعادته.
- [ ] تشغيل تجريبي على عينة مع فحص يدوي.
- [ ] قواعد مطابقة (Matching Rules) و Upsert نشطة للمنع.
- [ ] مالك دائم للعملية بعد التشغيل المباشر (Go Live).

## مصادر متخصصة

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ما الذي يعتبر ازدواجية وما لا يعتبر كذلك؟**
هذا قرار تجاري وليس تقنيًا. يمكن أن يكون هناك فرعان تابعان لنفس الشركة سجلين شرعيين لأغراض المبيعات، وسجل واحد لأغراض التحصيل. قبل تشغيل أداة Dedupe، يجب تحديد المستوى الكياني: هل الوحدة التجارية هي شركة، أو موقع، أو عقد؟

**هل يتم التنظيف قبل التحميل أم بعده؟**
التنظيف يتم قبله. فالسجل المكرر الذي تم تحميله مسبقًا يولد علاقات - مثل الأنشطة، Cases، والفرص - وأي عملية دمج متأخرة تصبح عملية محفوفة بالمخاطر مع فقدان السجلات التاريخية. بعد التحميل، يبقى فقط التنفيذ المستمر، وليس التنظيف الشامل.

**ماذا نفعل عندما يحتوي سجلان على معلومات مختلفة وكلاهما صحيح؟**
يجب بناء سجل ذهبي (Golden Record) على مستوى الحقل وليس على مستوى السجل: لكل حقل، يتم تحديد قاعدة أسبقية - نظام مصدر مفضل، أو الأحدث، أو القيمة التي تم التحقق منها. بهذه الطريقة، لا نفقد عنوانًا صحيحًا لمجرد اختيار السجل الآخر كفائز.

**هل قواعد المطابقة الخاصة بـ Salesforce كافية؟**
إنها كافية للمنع المستمر عند الإدخال اليدوي، ولكن ليس للتنظيف الشامل قبل التحويل. للتنظيف الأولي، يتطلب الأمر أداة أو سكريبت يقوم بـ Fuzzy Matching على تطبيع النص، ويسمح بمراجعة بشرية للمناطق الرمادية قبل الدمج.

**كم عدد الازدواجيات التي تعتبر 'طبيعية'؟**
في قواعد البيانات القديمة التي لم يتم إدارتها بشكل جيد، عادة ما نرى 8%-20% ازدواجية على مستوى جهات الاتصال (Contact) و3%-10% على مستوى الحسابات (Account). الهدف العملي ليس صفرًا، بل عتبة متفق عليها - على سبيل المثال، أقل من 2% - مع عملية تمنع التدهور مرة أخرى.

---

## مصدر الحقيقة في المؤسسة: من المسؤول عن العميل، المنتج، الطلب والدفع؟
URL: https://hpi.pro/ar/insights/salesforce-source-of-truth
عندما لا يكون هناك قرار حاسم بشأن الطرف المخوّل بتغيير البيانات، تتحول كل عملية تكامل إلى تفاوض، وينتهي المطاف بنظامين يحل أحدهما محل الآخر. يقدم هذا الدليل كيفية تحديد مصدر الحقيقة لكل كيان على مستوى الحقل، وكيفية التمييز بين النظام الذي يعرض البيانات والنظام المخوّل بإدارتها، وكيفية فرض القرار عبر الكود بدلاً من الوثائق.

## الإجابة المختصرة

"مصدر الحقيقة" (Source of Truth) ليست مسألة تقنية، بل هي مسألة صلاحية: من هو المخول داخل المؤسسة لتحديد صحة قيمة معينة. عندما لا يتم اتخاذ هذا القرار بشكل صريح، فإنه يُتخذ ضمنيًا - من قبل من قام بكتابة آخر تكامل.

القاعدة الأساسية: تُحدد الملكية على مستوى الحقل، وليس على مستوى النظام. محاولة الإعلان بأن "نظام تخطيط موارد المؤسسات (ERP) هو مصدر الحقيقة للعميل" تنهار بمجرد أن يقوم قسم الخدمة بتحديث رقم هاتف في Salesforce، ثم يقوم التزامن الليلي بحذف التحديث.

## ثلاثة أسئلة حاسمة للملكية

لكل كيان، ثم لكل مجموعة حقول، نسأل: أين تم **إنشاء** البيانات أولاً، من هو **المخوّل** تجارياً لتغييرها، ومن **يتحمل المسؤولية** عند الخطأ. في الحالات الثلاث، يجب أن تكون الإجابة اسم وظيفة، وليس اسم نظام. النظام يُشتق من الوظيفة.

عندما تشير الإجابات إلى وظيفتين مختلفتين، فهذه دائمًا تقريبًا علامة على دمج حقلين مختلفين في حقل واحد.

## مصفوفة ملكية نموذجية

| الكيان / الحقل | مصدر الحقيقة | Salesforce | اتجاه المزامنة |
|---|---|---|---|
| الاسم القانوني، رقم تعريف الشركة، شروط الدفع | ERP | قراءة فقط | ERP ← Salesforce |
| جهة الاتصال، المسمى الوظيفي، التفضيلات | Salesforce | تحرير | Salesforce ← أنظمة التسويق |
| كتالوج المنتجات وقائمة الأسعار الأساسية | ERP / PIM | قراءة فقط | ERP ← Salesforce |
| عرض الأسعار والخصم المعتمد | Salesforce | تحرير | Salesforce ← ERP |
| الطلب المعتمد وحالة التسليم | ERP | قراءة فقط | ERP ← Salesforce |
| الرصيد المستحق وحالة التحصيل | النظام المالي | قراءة فقط | مالي ← Salesforce |
| النشاطات، الحالات والتواصل | Salesforce | تحرير | لا يوجد تزامن خارجي |

هذا الجدول هو الناتج. إنه موجز، وموجود في وثيقة واحدة، ويُختبر كل تكامل جديد مقابلها قبل كتابته.

## الفصل بين العرض والصلاحية

يزول الكثير من التوتر بين الأنظمة عندما نفهم أن عرض البيانات لا يتطلب نسخها. الرصيد المستحق الذي يُعرض للبائع لا يجب أن يكون حقلاً في Salesforce يتم تحديثه كل ليلة؛ يمكن أن يكون عرضًا عن بُعد أو طبقة اتحاد (Federation).

كل حقل يتم نسخه يمثل التزامًا تشغيليًا: تزامن، فشل، تباين، ووقت. قبل النسخ، نسأل عما إذا كانت هناك حاجة إلى الأتمتة أو التقارير التاريخية عليه. إذا لم يكن الأمر كذلك - فمن الأفضل عرضه بدلاً من نسخه. يتوفر شرح موسع لهذا النهج في [Zero Copy و Federation في Data 360](/ar/insights/data-360-zero-copy-federation).

## التعارضات: اتخاذ القرار مسبقًا، وليس في الوقت الفعلي

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

## سيناريو: مؤسسة ذات حقيقتين لعنوان واحد

أدارت شركة خدمات بنية تحتية عنوان عميل في نظامين: ERP لأغراض الفواتير ونظام خدمة ميدانية لوصول الفنيين. وكلاهما كانا متزامنين مع Salesforce باتجاهين. وكانت النتيجة: عنوان يتبادل ذهابًا وإيابًا، وفنيون وصلوا إلى عنوان الفواتير.

لم يكن الحل في إصلاح التزامن بل في تفكيك الكيان. تم تعريف حقلين منفصلين - عنوان الفواتير بملكية نظام ERP، وعنوان الخدمة بملكية نظام الخدمة الميدانية - وكلاهما قراءة فقط في Salesforce، مع رابط لطلب التغيير موجه إلى المالك الصحيح. وانخفض عدد مكالمات الخدمة التي تم إغلاقها على أنها "عنوان خاطئ" بشكل ملحوظ في الربع التالي.

الدرس المستفاد: عندما "تتشاجر" الأنظمة على حقل، فغالبًا ما يكون الأمر متعلقًا ببيانات عمل مختلفة تحصل على نفس الاسم.

## التنفيذ: من الوثيقة إلى الواقع

تحقق مصفوفة الملكية وجودها فقط إذا تم تطبيقها في ثلاث نقاط: أمان مستوى الحقل (Field-Level Security) الذي يمنع التعديل من الجانب غير المالك، ومستخدم تكامل بصلاحيات محدودة للحقول التي يملكها فقط، وتقرير شهري يعرض الحقول التي تم تحديثها خلافًا للسياسة. التقرير الثالث هو الذي يكشف عن عمليات التكامل القديمة التي لا يتذكرها أحد.

يتصل توثيق معنى كل حقل مباشرة بـ [Data Mapping للترحيل](/ar/insights/salesforce-data-mapping).

## المخاطر الشائعة والإجراءات الوقائية

| الخطر | كيف يبدو في الواقع | إجراء وقائي |
|---|---|---|
| الملكية على مستوى النظام | تناقضات داخل نفس الكيان | تحديد الملكية على مستوى الحقل أو مجموعة الحقول |
| التزامن ثنائي الاتجاه كافتراضي | قيم تتبادل بالتناوب | اتجاه واحد + قراءة على الجانب الآخر |
| النسخ غير الضروري | عشرات الحقول المتزامنة بدون مستهلك | العرض بدلاً من النسخ |
| وثيقة بدون تنفيذ | تآكل السياسة في غضون أشهر | صلاحيات الحقول + مراقبة الانتهاكات |
| لا توجد قائمة انتظار للتعارضات | تتراكم التناقضات بصمت | قائمة انتظار مع مالك و SLA |

## كيف نقيس النجاح

| المجال | ما الذي يتم قياسه | وتيرة الفحص |
|---|---|---|
| الاتساق | معدل عدم التطابق في الحقول الرئيسية بين الأنظمة | شهري |
| انتهاكات السياسة | عمليات الكتابة على الحقل خارج المالك المعرف | شهري |
| التعارضات | عدد ووقت إغلاق العناصر في قائمة الانتظار | أسبوعي |
| التأثير التشغيلي | الأعطال الناتجة عن بيانات خاطئة | ربع سنوي |

يتم بناء مصفوفة الملكية وتطبيقها ضمن [خدمات التكامل والبيانات](/ar/integrations-data).

## قائمة مراجعة لتحديد مصدر الحقيقة

- ☐ قائمة بالكيانات الرئيسية في المؤسسة
- ☐ لكل كيان: أين تم إنشاؤه، من هو المفوض، من المسؤول عن الخطأ
- ☐ تم تحديد الملكية على مستوى الحقل أو مجموعة الحقول
- ☐ اتجاه تزامن واضح لكل مجموعة
- ☐ كل حقل منسوخ يفي بمعيار "لديه مستهلك"
- ☐ تم اختيار وكتابة قاعدة حل النزاعات
- ☐ توجد قائمة معالجة يدوية مع مالك و SLA
- ☐ أمان مستوى الحقل (Field-Level Security) يتوافق مع المصفوفة
- ☐ مستخدم التكامل مقيد بالحقول التي يمتلكها
- ☐ تقرير شهري عن انتهاكات السياسة

## مصادر احترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**هل يمكن لنظامين أن يكونا مصدر الحقيقة لنفس الكيان؟**
نعم لنفس الكيان، ولكن ليس لنفس الحقل. فمثلاً، يمكن أن تكون تفاصيل الفواتير مملوكة لنظام ERP في حين تكون تفاصيل الاتصال والنشاط مملوكة لـ Salesforce - وذلك لنفس العميل. ما هو غير مقبول هو أن يتمكن طرفان من الكتابة إلى نفس الحقل دون قاعدة حسم واضحة.

**ما الفرق بين System of Record و System of Engagement؟**
System of Record هو النظام المخول بتحديد القيمة؛ System of Engagement هو النظام الذي يعمل فيه المستخدمون ويتفاعلون معه. غالبًا ما يكون Salesforce بمثابة System of Engagement للعميل، وأيضًا System of Record لمسار المبيعات ومختلف الأنشطة المتعلقة بالعملاء. يعد الخلط بين المفهومين مصدرًا شائعًا للمزامنة ثنائية الاتجاه غير الضرورية.

**متى تكون المزامنة ثنائية الاتجاه مبررة؟**
فقط عندما يقوم كلا الطرفين بإنشاء قيمة حقيقية على نفس الحقل، وتكون هناك قاعدة حسم واضحة ولا لبس فيها - على سبيل المثال، ختم زمني أو أولوية نظام. في أي حالة أخرى، يُفضل الاتجاه الواحد مع شاشة عرض للقراءة فقط على الجانب الآخر. فالمزامنة ثنائية الاتجاه تضاعف عدد حالات الفشل المحتملة.

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

**ماذا نفعل عندما لا يوجد نظام مناسب ليكون مصدر الحقيقة؟**
هذا يعني أن الكيان معرف بشكل واسع جدًا. يجب تجزئته: يمكن تقسيم 'المنتج' إلى كتالوج (ERP)، عرض تجاري (CRM)، وتفويض استخدام (نظام تشغيلي). لكل جزء من هذه الأجزاء مصدر حقيقة واضح ومحدد.

---

## مقاييس جودة البيانات في Salesforce: ماذا نقيس وكيف نحدد العتبة؟
URL: https://hpi.pro/ar/insights/salesforce-data-quality-metrics
تصبح جودة البيانات قابلة للإدارة فقط عند اقترانها برقم، وعتبة، ومالك. يشرح هذا الدليل الأبعاد التي تستحق القياس حقًا في Salesforce، وكيفية تحديد عتبة غير عشوائية، وكيفية ربط كل مقياس بتأثير تجاري، وكيفية بناء لوحة نتائج (Scorecard) يراجعها أحدهم أكثر من مرة.

## الإجابة المختصرة

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

بطاقة الأداء (Scorecard) الفعالة تتكون من أربعة إلى ستة مقاييس فقط، كل منها له عتبة (حد)، ومالكاً، وإجراء تصحيحي محدد. الفرق بين بطاقة الأداء والتقرير هو أن أي رقم أحمر في بطاقة الأداء يحرك شخصًا ما لاتخاذ إجراء.

## الأبعاد الخمسة - وماذا تقيس حقاً

| البعد | ما الذي يفحصه | متى يكون حرجًا |
| --- | --- | --- |
| Completeness (الاكتمال) | نسبة تعبئة الحقول التي تدفع اتخاذ القرار | دائمًا |
| Validity (الصحة) | التوافق مع قواعد التنسيق والقيم الصالحة | التكاملات، اللوائح |
| Uniqueness (التفرد) | التكرار على مستوى الكيان | قبل التحويل وبعد عمليات الدمج |
| Timeliness (الحداثة) | مدى حداثة البيانات مقابل الواقع | التنبؤ، الخدمة، التحصيل |
| Consistency (الاتساق) | هل نفس البيانات متطابقة بين الأنظمة | تعدد الأنظمة والتقارير المالية |

تبدأ المنظمات دائمًا تقريبًا بالأبعاد الثلاثة الأولى. يدخل Timeliness و Consistency عندما تعتمد أنظمة إضافية على نظام الـ CRM - وهذه هي اللحظة تحديدًا التي تكون فيها أي مشكلة في هذه الأبعاد مكلفة للغاية.

## الاكتمال (Completeness): ليس كل حقل يستحق القياس

قياس نسبة التعبئة لـ 300 حقل ينتج رقمًا بلا معنى. النهج الصحيح هو تحديد "مجموعة حقول" صغيرة لكل عملية رئيسية - من خمسة إلى ثمانية حقول لا يمكن للعملية أن تتم بدونها - وقياسها فقط.

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

## الحداثة (Timeliness): البعد الذي يتجاهله الجميع

قد تكون البيانات كاملة وصحيحة وفريدة - ولكنها ببساطة لم تعد صحيحة. حقل حالة العميل الذي لم يتم تحديثه لمدة 14 شهرًا ليس بيانات، بل هو مجرد ذكرى. القياس بسيط: توزيع الوقت منذ آخر تحديث للحقول الجوهرية، مقابل السرعة التي يتغير بها الواقع بالفعل.

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

## من العتبة إلى الفعل: ماذا يحدث عندما يكون المقياس أحمر

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

يجب أن تكون الإجراءات نفسها متنوعة: في بعض الأحيان يكون التصحيح تنظيفًا لمرة واحدة، وأحيانًا تغييرًا في سير العمل، وفي كثير من الأحيان يكون الحل الصحيح هو إزالة الحقل - لأنه لم يعد مطلوبًا من أحد.

للحصول على معلومات إضافية حول التكرار، راجع [Salesforce Data Deduplication](/ar/insights/salesforce-data-deduplication)، وحول التصميم الذي ينتج الجودة، راجع [Salesforce Data Model Design](/ar/insights/salesforce-data-model-design).

## حالة دراسية: شركة تأمين قامت بقياس كل شيء ولم تحسن شيئًا

قامت إحدى شركات التأمين بإنشاء لوحة معلومات (Dashboard) للجودة تحتوي على 34 مقياسًا. استمرت سنة كاملة. لم يتحسن أي مقياس بشكل ملحوظ، لأنه لم تكن هناك ملكية: لوحة المعلومات كانت تابعة لفريق الـ BI، والحقول كانت تخص الوكلاء.

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

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

## المخاطر الشائعة والإجراءات الوقائية

| الخطر | كيف يظهر عمليًا | إجراء وقائي |
| --- | --- | --- |
| الكثير من المقاييس | لوحة معلومات لا يتصرف أحد بناءً عليها | من أربعة إلى ستة مقاييس مع مالك |
| مقياس بلا عتبة | نقاش حول "هل 78٪ جيد" | عتبة مستقاة من التأثير التجاري |
| الملكية لدى IT | لا يوجد تغيير في السلوك على أرض الواقع | مالك تجاري لكل مقياس |
| التحقق بدون قياس | حقول مليئة بقيم وهمية | قياس التعبئة الاصطناعية |
| قياس لمرة واحدة | تحسن مؤقت يتراجع | بطاقة أداء (Scorecard) دورية ثابتة |

## كيفية قياس النجاح

| المجال | ما الذي يتم قياسه | وتيرة الفحص |
| --- | --- | --- |
| Completeness (الاكتمال) | نسبة تعبئة مجموعة حقول للعملية | شهري |
| Timeliness (الحداثة) | متوسط الوقت منذ آخر تحديث | شهري |
| Uniqueness (التفرد) | نسبة التكرار التقديرية | ربع سنوي |
| Impact (التأثير) | الشكاوى، فشل التكامل، دقة التنبؤ | ربع سنوي |

يتم بناء بطاقة الأداء (Scorecard) والعملية التشغيلية كجزء من [خدمات التكامل والبيانات](/ar/integrations-data).

## قائمة تحقق لإنشاء القياس

- ☐  تم اختيار ستة مقاييس كحد أقصى
- ☐  لكل مقياس، توجد مجموعة حقول محددة، وليس الكائن بأكمله
- ☐  لكل مقياس، توجد عتبة مستقاة من التأثير التجاري
- ☐  لكل مقياس، يوجد مالك تجاري بالاسم الكامل
- ☐  تم تحديد إجراء لمستوى "عنبري" و"أحمر"
- ☐  يتم قياس التعبئة الاصطناعية أيضًا، وليس فقط التعبئة
- ☐  يوجد خط أساس (Baseline) قبل بدء التحسين
- ☐  يتم عرض التقرير في منتدى تجاري وليس تقني
- ☐  تم التحقق مما إذا كان الحقل المشكل به ضروريًا في الأساس
- ☐  تم تحديد مراجعة دورية لقائمة المقاييس نفسها

## المراجع المهنية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrations and Data — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**بأي بُعد يجب البدء؟**
ابدأ بالاكتمال (Completeness) لمجموعة صغيرة من الحقول التي تدفع القرارات، وليس لجميع الحقول. معدل التعبئة هو الأسهل في الحساب، والأسهل في الشرح للإدارة، وعادةً ما يكشف بسرعة عن العمليات المتعثرة.

**كيف تحدد عتبة غير عشوائية؟**
تُستنتج العتبة من التأثير. إذا كانت 5% من رسائل البريد الإلكتروني خاطئة وكانت الحملة تولد 200 عميل محتمل شهريًا، يمكن ترجمة ذلك إلى خسارة متوقعة. يتم تحديد العتبة عند النقطة التي تبدأ فيها تكلفة الإصلاح في تجاوز الضرر، وليس عند رقم دقيق يبدو جيدًا.

**من المسؤول عن مقياس الجودة؟**
مالك العملية التي تنتج البيانات، وليس فريق البيانات. يقوم فريق البيانات بالقياس وتوفير الأدوات؛ ولكن من يقوم بالمبيعات أو تحصيل الأموال أو الخدمة هو من يمكنه تغيير السلوك الذي يولد الفجوة. لا يتحسن أي مقياس لا يملك مالكًا تجاريًا.

**هل قواعد التحقق (Validation Rules) تحل مشكلة جودة البيانات؟**
جزئيًا. إنها تمنع إدخال قيم خاطئة يدويًا، ولكنها تدفع المستخدمين لملء أي قيمة فقط للمضي قدمًا. يجب أن تكون قاعدة التحقق مصحوبة بمقياس يختبر ما إذا كان الحقل قد مُلئ حقًا أم مُلئ بشكل مصطنع.

**ما هو التكرار الصحيح للقياس؟**
أسبوعيًا أثناء عمليات الترحيل. في العمليات الروتينية، شهريًا لمعظم المقاييس، وربع سنويًا كمراجعة للإدارة. القياس اليومي لجودة البيانات غالبًا ما يولد ضوضاء لا يتصرف أحد بناءً عليها.

---

## Agentforce لخدمة العملاء: حالات استخدام موصى بها للبدء
URL: https://hpi.pro/ar/insights/agentforce-customer-service-use-cases
ليست كل استفسارات العملاء مناسبة لمعالجة تلقائية بالذكاء الاصطناعي، وترتيب البدء يحدد مدى نجاح المشروع أو توقفه. يقيّم هذا الدليل حالات الخدمة الشائعة حسب مستوى الجاهزية، ويشرح المتطلبات اللازمة لكل حالة، ويسلط الضوء على الحالات التي قد تبدو مغرية ظاهريًا ولكنها قد تقوض الثقة مبكرًا.

## الإجابة المختصرة

في خدمة العملاء، يُحدد الفرق بين المشروع التجريبي الذي يتوسع والذي يتوقف دائمًا تقريبًا باختيار السيناريو الأولي. السيناريو الناضج هو الذي يعتمد على مصدر معلومات موثوق به واحد، ولا يُجري عملية غير قابلة للتراجع، ولديه حجم يبرر صيانته.

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

يظهر إطار القرار العام لتكييف حالات الاستخدام في [Agentforce للمؤسسات](/ar/insights/agentforce-for-enterprises).

## تصنيف السيناريوهات حسب النضج

| السيناريو | النضج | المتطلبات | الخطر الرئيسي |
| --- | --- | --- | --- |
| استفسارات الحالة | مرتفع | حقل واحد موثوق به في نظام إدارة علاقات العملاء (CRM) | شبه معدوم؛ خطأ قابل للعكس |
| أسئلة المعرفة الشائعة | مرتفع | مقالات Knowledge محدثة للسيناريوهات الشائعة | الاستشهاد بسياسة قديمة |
| مساعدة الوكيل أثناء المكالمة | مرتفع | Knowledge وسجل الحالة | الوكيل يتبنى إجابة خاطئة |
| توجيه وتصنيف الاستفسارات | متوسط | تصنيف متناسق لأنواع الاستفسارات | تصنيف خاطئ يطيل مدة المعالجة |
| تحديث التفاصيل والعمليات البسيطة | متوسط | صلاحيات دقيقة وإجراءات محدودة | تحديث خاطئ في سجل العميل |
| التنسيق، الإلغاء، وتغيير الموعد | متوسط | تكامل مستقر مع النظام التشغيلي | فشل التكامل مع العميل |
| استرداد الأموال والتعويضات | منخفض | سياسة مكتوبة، صلاحية، وموافقة بشرية | تعرض مالي وسابقة مع العميل |
| معالجة الشكاوى والاستبقاء | منخفض | فهم السياق، الحساسية، والسجل الكامل | ضرر للعلامة التجارية والثقة |

## السيناريوهات الثلاثة التي يُفضل البدء بها

تعد استفسارات الحالة أفضل نقطة انطلاق. يستفسر العميل عن مكان الطلب، حالة الطلب، أو موعد وصول الفني. الإجابة تعتمد على حقل واحد، لا توجد عملية كتابة، والحجم عادة ما يكون كبيرًا. كما أن النجاح سهل القياس: هل تلقى العميل إجابة ولم يعاود الاتصال؟

تُعد أسئلة المعرفة الشائعة السيناريو الثاني. هنا، التحدي ليس الوكيل بل المحتوى، لذا تبدأ العملية بمراجعة الاستفسارات العشرين الأكثر شيوعًا والتأكد من وجود مقال معتمد ومحدث لكل منها.

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

ما الذي يتطلبه الأمر حتى يتمكن مستودع المعرفة من تحمل العبء بالتفصيل في [إدارة المعرفة لـ Agentforce](/ar/insights/agentforce-knowledge-readiness).

## ما يؤجل إلى مرحلة لاحقة

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

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

السيناريوهات الشاملة للأنظمة التي تتوزع فيها المعلومات بين ثلاثة أنظمة دون مصدر حقيقة واحد – ليس بسبب قيود الذكاء الاصطناعي، بل لأن الفجوة في البيانات ستظهر هنا أولًا وستعتبر فشلًا للوكيل.

## قواعد التصعيد التي يجب أن تكون محددة

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

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

تفاصيل تصميم مسارات التصعيد ضمن أنظمة القنوات موجودة في [Omni-Channel و SLA في Service Cloud](/ar/insights/service-cloud-omnichannel-sla).

## سيناريو: مركز اتصالات غيّر المشروع التجريبي بعد أسبوعين

خططت شركة منتجات استهلاكية للبدء بوكيل يتعامل مع طلبات الاسترجاع – السيناريو الذي يحتوي على أكبر عدد من الشكاوى. في الأسبوعين الأولين، تبين أن كل طلب يتطلب فحص شروط الضمان في نظام ERP، وفحص المخزون، واتخاذ قرار يتم فعليًا حسب تقدير المدير.

تم تحويل المشروع التجريبي إلى سيناريو آخر: الرد على حالة استرجاع قائمة. نفس العملاء، نفس المجال، لكنه يعتمد على حقل حالة واحد. كان الحجم كبيرًا، ومعدل التصعيد منخفضًا، وشهد مركز الاتصال انخفاضًا فوريًا في الاستفسارات المتكررة.

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

## المخاطر والإجراءات الوقائية

| المخاطر | كيف تظهر في مركز الاتصال | إجراء وقائي |
| --- | --- | --- |
| البدء بسيناريو عاطفي | شكاوى تصل إلى الإدارة في الأسبوع الأول | البدء بسيناريو معلومات وليس سيناريو حل |
| لا يوجد مسار للتواصل البشري | العميل عالق في حلقة من الأسئلة | زر للتحويل إلى وكيل في أي مرحلة ومحفزات قوية |
| فقدان السياق عند التصعيد | العميل يكرر القصة للوكيل | نقل ملخص المحادثة تلقائيًا |
| سياسة غير مكتوبة | إجابات غير متسقة بين الحالات | كتابة السياسة قبل إدخال السيناريو |
| كثرة السيناريوهات المتزامنة | لا توجد قدرة على الصيانة وتدهور الجودة | ثلاثة سيناريوهات نشطة كحد أقصى في السنة الأولى |

## المقاييس في الخدمة

| المقياس | التعريف | التردد |
| --- | --- | --- |
| Containment | نسبة الاستفسارات التي تم إغلاقها بدون وكيل وبدون تكرار الاتصال | أسبوعي |
| معدل الاتصال المتكرر | العملاء الذين عادوا بنفس الموضوع خلال أسبوع | أسبوعي |
| الوقت حتى التصعيد | المدة التي تمر حتى التحويل إلى شخص عند الحاجة | أسبوعي |
| رضا العميل عن القناة | مقارنة بقناة بشرية مماثلة | شهري |
| وقت معالجة الوكيل | هل ساعد الدعم في تقصير المكالمة فعليًا | شهري |

إن Containment بدون معدل اتصال متكرر هو مقياس مضلل. تُحسب المكالمة التي تم إغلاقها بسرعة لأن العميل يئس كنجاح، لذا تُقرأ المقياسين دائمًا معًا.

عندما يتطلب الأمر مرافقة في اختيار السيناريوهات وتحديد مسارات التصعيد، فإن [خدمات Agentforce والذكاء الاصطناعي](/ar/agentforce-ai) هي المسار العملي للمضي قدمًا.

## قائمة مراجعة لاختيار السيناريو الأول

- ☐ يعتمد السيناريو على مصدر معلومات موثوق به واحد.
- ☐ لا يتضمن أي إجراء غير قابل للتراجع في الإصدار الأولي.
- ☐ الحجم الشهري يبرر الصيانة المستمرة.
- ☐ توجد مقالات معتمدة للسيناريوهات الشائعة فيه.
- ☐ تم تحديد محفزات التصعيد الأربعة.
- ☐ يتضمن التحويل إلى الوكيل ملخصًا للمحادثة.
- ☐ يعلن الوكيل أنه ليس إنسانًا في البداية.
- ☐ تم قياس خط أساس Containment والاتصالات المتكررة.
- ☐ تم تحديد الحد الأقصى لعدد السيناريوهات النشطة في وقت واحد.

### أسئلة وأجوبة
**ما هي أفضل حالة استخدام للبدء بها؟**
الاستفسارات المتعلقة بحالة الطلبات (Status Inquiries). هذه الاستفسارات تتميز بحجم مرتفع، وتعتمد على حقل واحد أو حقلين في CRM، ولا تتطلب إدخال كتابي معقد، ويسهل قياس نجاحها. كما أنها الحالة التي يكون فيها العميل أكثر تسامحًا، لأنه يتوقع معلومات وليس حلًا معقدًا.

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

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

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

**كم عدد حالات الاستخدام التي يوصى بتشغيلها بالتوازي في السنة الأولى؟**
من حالة إلى ثلاث حالات. تتطلب كل حالة استخدام محتواها الخاص، واختباراتها، ومراقبتها؛ والمنظمة التي تشغل ست حالات بالتوازي ستجد أنها لا تملك القدرة على صيانتها بشكل صحيح. التوسع الصحيح يأتي بعد أن تصبح الحالة الأولى مستقرة لمدة ربع كامل.

---

## Grounding وRAG في Agentforce: كيف نربط Agent بمعرفة موثوقة
URL: https://hpi.pro/ar/insights/agentforce-grounding-rag
لا يقوم Agent باختراع الإجابات عن سوء نية، بل يفعل ذلك عندما يكون مصدر المعلومات جزئيًا أو متناقضًا أو غير مصرح به. يستعرض هذا الدليل طبقة الـ Grounding ومكوناتها: ما هي المصادر التي يجب ربطها، وكيفية تقسيم المحتوى وتصنيفه، وكيفية الحفاظ على الصلاحيات في الاسترجاع، وكيفية قياس الدقة قبل السماح للـ Agent بالتفاعل مع العميل.

## الإجابة المختصرة

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

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

للمزيد حول النطاق الواسع لاختيار حالة الاستخدام (Use Case)، يُرجى مراجعة [Agentforce للمؤسسات](/ar/insights/agentforce-for-enterprises).

## الطبقات الأربع للتأصيل (Grounding)

| الطبقة | ماذا تُحدد | علامة على وجود خلل | دليل على فعاليتها |
| --- | --- | --- | --- |
| المصادر | ما هي المستودعات المُعلنة كمصادر موثوقة ومن هو المالك | إجابتان متضاربتان لنفس السؤال | قائمة مصادر مع مالك وتاريخ مراجعة |
| التمثيل | التجزيء (Chunking)، البيانات الوصفية (Metadata)، والتصنيف حسب المنتج، اللغة، والإصدار | المقطع المسترجع لا يتعلق بالسؤال | قياس الاستدعاء (Recall) على مجموعة أسئلة معروفة |
| الأذونات | كيف يحد سياق المستخدم من الاسترجاع | ظهور محتوى داخلي في إجابة لعميل | اختبار الشخصية (Persona) لكل مستوى إذن |
| الشفافية | الاستشهادات (Citations)، التحديث (Freshness)، ومسار الاحتياط (Fallback) | إجابة بلا مصدر وبدون إقرار بعدم وجود معرفة | نسبة الإجابات ذات الاستشهاد الصالح |

## الطبقة 1: الإعلان عن مصادر الحقيقة

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

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

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

تُفصل أساسيات تنظيف وتأهيل قاعدة المعرفة في [جاهزية المعرفة لـ Agentforce](/ar/insights/agentforce-knowledge-readiness).

## الطبقة 2: التجزيء (Chunking)، البيانات الوصفية (Metadata)، والأهمية (Relevance)

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

تُعد البيانات الوصفية (Metadata) هي ما يُمكّن من تقليص مساحة البحث قبل حتى أن يدخل النموذج في الصورة. تتضمن العلامات الدنيا المطلوبة: المنتج أو خط الخدمة، السوق أو الدولة، اللغة، الجمهور المستهدف (عميل أو داخلي)، تاريخ الصلاحية، وحالة الاعتماد. بدون وسم السوق واللغة، سيخلط العامل الآلي في مؤسسة عالمية بين سياسات دولتين في الإجابة نفسها.

فحص الأهمية كمي وليس شعوريًا: تُبنى مجموعة من 50 إلى 100 سؤال حقيقي مع الإجابة الصحيحة والمصدر الصحيح، ويُقاس كم مرة ظهر المقتطف الصحيح في الاسترجاع. تشير نسبة استدعاء (Recall) منخفضة إلى مشكلة في التمثيل، ومعالجتها أقل تكلفة بكثير من استبدال النموذج أو إعادة كتابة التعليمات.

## الطبقة 3: الأذونات لحظة الاسترجاع

هذه هي الطبقة التي تُسقط المشاريع التجريبية في مراجعات الأمان. القاعدة بسيطة: يجب أن يعمل الاسترجاع في سياق أذونات المستخدم، وليس في سياق حساب تكامل واسع. إذا كان جزء من المعلومات مخفيًا عن المستخدم في الواجهة، فيجب أن يكون مخفيًا أيضًا عن إجابة العامل الآلي.

في الواقع، هناك حاجة إلى ثلاثة فحوصات. أولاً، تحديد الصلة بين مستويات التصنيف في المصدر الخارجي و"الملفات الشخصية" (Profiles) و"مجموعات الأذونات" (Permission Sets) في Salesforce. ثانيًا، اختبار الشخصية (Persona): تُشغل نفس الأسئلة العشرة بهوية ممثل ومسؤول وعميل خارجي وتُقارن الإجابات. ثالثًا، التعامل مع المحتوى المختلط - يجب قطع مستند يكون معظمه عامًا وجزء منه حساس، أو عدم إدخاله على الإطلاق.

في القناة العامة، الافتراضي الآمن هو قائمة السماح: فقط المحتوى الذي تم وسمه صراحةً على أنه معتمد للعميل يدخل في فهرس متاح للعامل الآلي الخارجي. منهج قائمة الحظر سيفوت دائمًا مستندًا واحدًا.

تُفصّل نماذج المسؤولية بين المؤسسة وSalesforce ومزود النموذج في [أمان Agentforce والمسؤولية المشتركة](/ar/insights/agentforce-security-shared-responsibility).

## الطبقة 4: الاستشهادات (Citations)، التحديث (Freshness)، والاحتياط (Fallback)

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

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

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

## سيناريو: شركة تأمين تضم 900 مقال معرفي

أرادت شركة تأمين عاملًا آليًا للإجابة على استفسارات ممثلي مركز الاتصال حول شروط بوليصة التأمين. فشل المشروع التجريبي الأول: 40% من الإجابات كانت خاطئة أو جزئية. أظهر التحليل أن المشكلة برمتها تكمن في طبقة المصادر – من بين 900 مقال، لم يتم تحديث 380 منها لأكثر من ثلاث سنوات، و60 منها كانت متناقضة مع مقالات أحدث حول نفس الموضوع.

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

وصلت الجولة الثانية على نفس مجموعة الاختبار المكونة من 80 سؤالًا إلى دقة أعلى بكثير، والأهم من ذلك – في الحالات التي لم يكن فيها مصدر، أحال العامل الآلي إلى شخص بدلاً من التخمين. لم تكن النتيجة التي أدت إلى التوسع "لقد تحسن الذكاء الاصطناعي" بل "نحن نعرف على ما يعتمد".

## المخاطر والإجراءات الوقائية

| المخاطرة | كيف تُكتشف متأخرة | الإجراء الوقائي |
| --- | --- | --- |
| مصادر متضاربة | إجابات مختلفة لنفس السؤال بين الممثلين | أرشفة الإصدارات القديمة ومصدر حقيقي وحيد لكل موضوع |
| تجزيء يفسد الهيكل | إجابات جزئية في العمليات متعددة الخطوات | تجزيء حسب الفقرة مع حفظ عنوان السياق |
| أذونات على مستوى التكامل | الكشف عن محتوى داخلي في قناة العميل | استرجاع في سياق المستخدم واختبارات الشخصية (Persona) |
| لا يوجد تاريخ صلاحية | الاستشهاد بسياسة تم إلغاؤها بالفعل | اتفاقية مستوى خدمة (SLA) للتحديث والإزالة التلقائية من الفهرس |
| مسار احتياط غير محدد | صياغة إجابة مقنعة بدون مصدر | مسار "لا توجد معلومات معتمدة" يتم اختباره في كل إصدار |

## مقاييس طبقة التأصيل (Grounding)

| المقياس | التعريف | التكرار |
| --- | --- | --- |
| دقة الاسترجاع (Retrieval recall) | نسبة الأسئلة التي تم استرجاع الجزء الصحيح فيها | في كل إصدار |
| صلاحية الاستشهاد (Citation validity) | نسبة الإجابات التي تحتوي على مصدر موجود وصالح | أسبوعيًا |
| حداثة المحتوى (Content freshness) | نسبة المقالات في الفهرس ضمن تاريخ الصلاحية | شهريًا |
| معدل الاحتياط (Fallback rate) | نسبة الطلبات التي تم تحويلها إلى شخص في غياب مصدر | أسبوعيًا |
| تسرب الأذونات (Permission leakage) | عدد نتائج الكشف في اختبارات الشخصية (Persona) | في كل إصدار |

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

عندما تكون القدرة الداخلية على تأسيس طبقة تأصيل مُحكَمة غائبة، فإن [خدمة Agentforce والذكاء الاصطناعي](/ar/agentforce-ai) هي المسار العملي للمضي قدمًا.

## قائمة المراجعة قبل ربط عامل آلي بالمصادر

- ☐ تم تحديد المصادر الحالية للإجابات على الأسئلة العشرين الأكثر شيوعًا.
- ☐ لكل مصدر في الفهرس مالك مُحدد بالاسم وتكرار تحديث.
- ☐ تم تحديد المصادر المتضاربة وأرشفتها.
- ☐ يتوفر وسم للمنتج، السوق، اللغة، الجمهور، وتاريخ الصلاحية.
- ☐ التجزيء يحافظ على الجداول وقوائم الخطوات.
- ☐ يعمل الاسترجاع في سياق أذونات المستخدم.
- ☐ تم إجراء اختبار الشخصية (Persona) لكل مستوى إذن ذي صلة.
- ☐ تتوفر مجموعة اختبار مكونة من 50 سؤالًا مع الإجابة الصحيحة والمصدر.
- ☐ الاستشهادات (Citations) تشير إلى المقطع الذي تم استرجاعه فعليًا.
- ☐ مسار الاحتياط (Fallback) مُصاغ ومُختبر في قناة العميل.

### أسئلة وأجوبة
**ما هو الفرق الرئيسي بين Grounding وRAG؟**
RAG هو آلية: حيث يتم استرجاع أجزاء ذات صلة من المعلومات وربطها بالـ prompt. أما Grounding فهو الالتزام التجاري بأن المعلومات المسترجعة هي مصدر حقيقي معتمد ومحدث ومصرح به للمستخدم المحدد. يمكن تطبيق RAG ممتاز على مستودع مستندات قديم والحصول على إجابات خاطئة بثقة تامة.

**كم عدد مقالات المعرفة المطلوبة قبل البدء؟**
أقل مما قد يبدو. من الأفضل أن يكون لديك عشرون مقالاً محدثاً يغطي السيناريوهات العشرة الأكثر شيوعاً، بدلاً من ألف مقال نصفها كُتب قبل أربع سنوات. المقال المتضارب يكون أكثر ضرراً من عدم وجود مقال، لأن Agent لا يستطيع الفصل بين نسختين مختلفتين.

**هل يمكن ربط Agent مباشرة بـ SharePoint أو Confluence؟**
تقنياً نعم، من خلال الفهرسة أو ربط البيانات. السؤال الحقيقي يتعلق بالصلاحيات: إذا كان نموذج الصلاحيات في المصدر الخارجي لا يمكن ربطه بالمستخدم في Salesforce، فقد يكشف الاسترجاع محتوى لا ينبغي للمستخدم رؤيته. في هذه الحالة، يتم مزامنة مجموعة فرعية مصنفة علنياً-داخلياً فقط.

**لماذا يعطي Agent إجابة عامة على الرغم من وجود المعلومات في المقال؟**
غالباً ما تكون هذه مشكلة Chunking أو Metadata وليست مشكلة نموذج. إذا تم تقسيم المقال في منتصف جدول، أو لم يكن هناك تصنيف للمنتج، البلد، والإصدار، فإن الاسترجاع سيجلب جزءاً غير ذي صلة. فحص سريع: انظر إلى Trace لمعرفة الأجزاء التي تم استرجاعها فعلياً قبل إلقاء اللوم على النموذج.

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

---

## العنصر البشري في Agentforce: أين يجب على الذكاء الاصطناعي التوقف والموافقة
URL: https://hpi.pro/ar/insights/agentforce-human-in-the-loop
الموافقة البشرية على كل إجراء تقضي على القيمة؛ والموافقة على لا شيء تخلق المخاطر. يقدم هذا الدليل منهجية لتحديد نقاط التوقف بناءً على قابلية الإلغاء والتأثير والحساسية، وثلاثة أنماط موافقة مختلفة، وشروط قابلة للقياس لإزالة نقطة الموافقة دون التخلي عن الرقابة.

## الإجابة المختصرة

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

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

الإطار الحوكمي الذي يتم بموجبه اتخاذ هذه القرارات مفصّل في [حوكمة الذكاء الاصطناعي لـ Agentforce](/ar/insights/agentforce-ai-governance).

## مصفوفة القرار: قابلية الإلغاء مقابل التأثير

| | تأثير منخفض | تأثير مرتفع |
|---|---|---|
| **يمكن التراجع عنه بسهولة** | بلا مصادقة، مراقبة فقط | أخذ عينات من نسبة مئوية من الحالات للمراجعة |
| **يمكن التراجع عنه بتكلفة** | تدقيق بعدي | مصادقة حظر قبل التنفيذ |
| **غير قابل للإلغاء** | مصادقة حظر قبل التنفيذ | مصادقة حظر + مبرر مكتوب + سجل تدقيق |

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

## أنماط المصادقة الثلاثة

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

يتيح التدقيق بعد الإجراء للعامل التصرف وتقديم النتيجة للمراجعة ضمن نافذة زمنية محددة. يناسب العمليات القابلة للإلغاء وذات التكلفة المنخفضة، ويتطلب شرطين: نافذة زمنية قصيرة، وزر إلغاء يعمل حقًا.

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

## تصميم شاشة القرار

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

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

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

يشرح [قابلية المراقبة لوكلاء الذكاء الاصطناعي](/ar/insights/agentforce-observability) كيفية مراقبة هذه القرارات بمرور الوقت.

## منع "الختم المطاطي"

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

المعالجة ليست في التدريب بل في التصميم. يتم تقليل عدد الموافقات عن طريق إزالة التوقفات غير الضرورية في العمليات القابلة للإلغاء، وإضافة أخذ عينات لاحقة تخلق المساءلة، وتقديم ملاحظات للموافق حول جودة قراراته. عندما يعلم الموافق أن نسبة مئوية من القرارات يتم مراجعتها، تعود الحاجة إلى القراءة.

مقياس رئيسي: إذا كان معدل التصحيحات صفرًا لعدة أشهر، فإما أن العامل ممتاز ويمكن تقليل التوقفات، أو أن لا أحد يقرأ. أخذ العينات هو ما يميز بين الاثنين.

## متى وكيف تتم إزالة نقطة المصادقة

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

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

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

## سيناريو: مركز خدمة قام بإزالة المصادقة الخاطئة

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

قام الفريق بتحليل 4000 مصادقة واكتشف أن 78% منها كانت تتعلق بالردود المعلوماتية فقط - وهي قابلة للإلغاء بالكامل وذات تأثير منخفض. كان معدل التصحيح في هذه الفئة أقل من واحد بالمائة. بالمقابل، في فئة الخصومات، كان معدل التصحيح أعلى بكثير.

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

## المخاطر والإجراءات الوقائية

| المخاطرة | كيف تظهر | الإجراء الوقائي |
|---|---|---|
| المصادقة على كل شيء | تفقد القيمة ويتجاوزها المستخدمون | مصفوفة قابلية الإلغاء مقابل التأثير لكل عملية |
| التوقيع التلقائي | وقت قرار بالثواني وصفر رفض | أخذ عينات بعدي وملاحظات شخصية للمصادق |
| شاشة بدون تبرير | لا يستطيع المصادق الحكم بصدق | عرض التبرير، المصدر، ومستوى اليقين في شاشة واحدة |
| الإزالة المبكرة | خلل في الإنتاج بعد عدة أسابيع جيدة | عتبات إزالة قابلة للقياس، توسيع تدريجي، وشرط للعودة |
| عدم توثيق حالات الرفض | لا يوجد ما نتعلمه للإصدار التالي | قائمة قصيرة لأسباب الرفض ومراجعة أسبوعية |

## المقاييس

| المقياس | ما يكشفه | التكرار |
|---|---|---|
| معدل التوقف | نسبة العمليات التي تطلبت موافقة | أسبوعي |
| معدل التصحيح | نسبة الحالات التي غيرها أو رفضها الموافق | أسبوعي |
| متوسط وقت القرار | هل يقرأ الموافق حقًا | أسبوعي |
| نتائج أخذ العينات | الأخطاء التي تجاوزت المصادقة | شهري |
| وقت الإلغاء الفعلي | هل تعمل آلية الإرجاع | في كل إصدار |

عند الحاجة إلى الدعم في تخطيط نقاط المصادقة وتكييفها مع اللوائح المعمول بها في المؤسسة، فإن [خدمة Agentforce والذكاء الاصطناعي](/ar/agentforce-ai) هي المسار العملي للمضي قدمًا.

## قائمة التحقق

- ☐ تم تقسيم العملية إلى خطوات فردية
- ☐ تم تصنيف كل عملية بناءً على قابلية الإلغاء والتأثير
- ☐ تم اختيار نمط مصادقة لكل عملية: حظر، بعدي، أو عشوائي
- ☐ تم تحديد الموافق وفقًا للصلاحية الحالية في العملية
- ☐ تعرض شاشة القرار الإجراء، التبرير، المصدر، ومستوى اليقين
- ☐ تتوفر إمكانية التصحيح وليس فقط المصادقة أو الرفض
- ☐ يتم توثيق أسباب الرفض في قائمة قصيرة
- ☐ تم تحديد عتبات قابلة للقياس لإزالة المصادقة وشروط للعودة
- ☐ تم اختبار آلية الإلغاء فعليًا ولم يتم فقط تخطيطها

### أسئلة وأجوبة
**ألا تلغي الموافقة البشرية ميزة الوكيل؟**
ليس عندما تكون في الموضع الصحيح. لا يزال الوكيل يوفر جمع المعلومات والتحليل والصياغة - وهي غالبية الوقت. يتخذ الإنسان قرارًا جاهزًا ويوافق عليه في ثوانٍ. تُفقد القيمة فقط عندما تتطلب الموافقة من الإنسان مراجعة كل ما فعله الوكيل مرة أخرى.

**من يجب أن يوافق - الممثل أم المدير؟**
بشكل عام، من كان سيوافق على الإجراء حتى بدون وكيل. إذا كان الممثل مخولًا بخصم مبلغ معين، فهو الموافق هنا أيضًا. يتطلب التصعيد إلى المدير فقط عندما يتجاوز المبلغ أو الحساسية السلطة العادية، وإلا فإنه يخلق عنق زجاجة لم يكن موجودًا من قبل.

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

**متى يمكن إزالة نقطة الموافقة؟**
عندما يكون هناك حجم كافٍ من القرارات الموثقة، ومعدل التصحيحات من قبل المراجع منخفض ومستقر على مدى عدة أشهر، وتتوفر آلية إلغاء سريعة. تتم الإزالة على مراحل - أولاً لمجموعة فرعية ضيقة من الحالات، وليس للعملية بأكملها دفعة واحدة.

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

---

## تطبيق Sales Cloud: عملية صحيحة من Lead إلى Forecast
URL: https://hpi.pro/ar/insights/sales-cloud-implementation
غالبًا ما يفشل تطبيق Sales Cloud ليس بسبب إعدادات خاطئة، بل بسبب مراحل المبيعات التي لا يعرف أحد متى ينتقل بينها بالضبط. يوضح الدليل كيفية بناء سلسلة واحدة – Lead, Opportunity, Forecast – حيث لكل مرحلة معيار خروج قابل للقياس، ولماذا هذا هو الشرط المسبق لتوقعات يمكن الوثوق بها.

## الإجابة المختصرة

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

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

## أين تظهر المشكلة فعليًا

في مؤسسة B2B نموذجية، قبل أي تدخل، قد نرى الوضع كالتالي: 40% من الصفقات في مسار المبيعات (Pipeline) قد تجاوزت تاريخ الإغلاق المحدد، ومرحلة "التفاوض" تشمل كلًا من المحادثات الأولية والعقود قيد التوقيع، ومدير المبيعات يدير التوقعات في جدول بيانات منفصل لأنه لا يثق بالنظام. لا تعتبر أي من هذه المشكلات خللاً فنيًا – بل هي جميعًا نتيجة لتعريفات لم يتم حسمها.

## مراحل المبيعات: معيار خروج لكل مرحلة

القاعدة البسيطة: يتم تعريف المرحلة بما فعله المشتري، وليس بما يشعر به البائع. "العميل مهتم" ليس معيارًا. "تم تحديد صانع قرار وتم تخصيص ميزانية" هو كذلك.

| المرحلة | معيار خروج قابل للقياس | الدليل في النظام | الاحتمالية (Probability) |
|---|---|---|---|
| Qualification | تم تحديد الحاجة والميزانية وصاحب القرار | حقول Budget و Decision Maker مملوءة | 10% |
| Discovery | تم تقديم خارطة طريق للاحتياجات موافق عليها من العميل | مستند أو ملاحظة (Note) مرتبطة | 25% |
| Proposal | تم إرسال عرض مع تسعير ونطاق عمل | عرض أسعار (Quote) نشط | 50% |
| Negotiation | العميل قدم ملاحظات تجارية أو قانونية | Activity موثق خلال الأسبوعين الماضيين | 75% |
| Closed Won | توقيع أو أمر شراء (PO) | ملف مرفق | 100% |

الاحتمالية (Probability) ليست شعور المندوب بل هي مشتقة من المرحلة. بمجرد السماح للمندوب بتعديلها يدويًا، يصبح التوقع شخصيًا مرة أخرى.

## Lead مقابل Opportunity: الحد الذي يحدد جودة مسار المبيعات (Pipeline)

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

تعريف عملي: يبقى Lead Lead حتى تتحقق ثلاثة شروط – جهة اتصال محددة ذات سلطة، حاجة مصاغة بكلمات العميل، وأفق زمني معين. يتم إدارة الاستفسار الذي لا يفي بذلك كـ Lead في مرحلة Nurture، وليس كصفقة. هذا أيضًا ما يسمح بقياس معدل التحويل بين التسويق والمبيعات بشكل حقيقي بدلاً من قياس سخاء التحويل.

سيجد من يقوم ببناء نموذج البيانات وراء ذلك خلفية في [تصميم نماذج بيانات Salesforce](/ar/insights/salesforce-data-model-design).

## الأنشطة (Activities): إلزام القليل، في الأماكن الحاسمة

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

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

## التوقعات (Forecast): ما يجب أن يكون جاهزًا قبل التشغيل

يتطلب التنبؤ الموثوق به أربعة شروط مسبقة، وكلها تتصرف كسلسلة – الحلقة المفقودة تلغي البقية:

1.  **تسلسل هرمي للمستخدمين صحيح** - Forecast في Salesforce يُحسب وفقًا لـ Role Hierarchy، وليس وفقًا لهيكل تنظيمي في جدول بيانات.
2.  **تواريخ إغلاق نظيفة** - قاعدة تشغيلية لا تسمح للصفقة بالبقاء بتاريخ منتهي لأكثر من أسبوع.
3.  **فئات توقعات محددة (Forecast Categories)** - Pipeline، Best Case، Commit، Closed - مع تعريف متفق عليه لمن ينقل الصفقة إلى Commit ومتى.
4.  **دورة مراجعة منتظمة** - اجتماع أسبوعي لمسار المبيعات (Pipeline) يُدار من داخل النظام وليس من جدول بيانات موازٍ.

النقطة الأخيرة هي الحاسمة. ما دامت هناك جداول بيانات "خفية"، يعلم المندوبون أن النظام ليس مصدر الحقيقة ويقومون بتحديثه متأخرًا.

## ما يجب قياسه بعد الانطلاق

| المقياس | ما يكشف عنه | عتبة المشكلة |
|---|---|---|
| دقة التوقعات (Forecast accuracy) | الفجوة بين توقع Commit والنتيجة | انحراف يزيد عن 20% ربع سنويًا |
| عمر المرحلة (Stage aging) | الصفقات العالقة في مرحلة ما | أكثر من ضعف المتوسط |
| التحديث خلال 7 أيام | هل يعكس النظام الواقع؟ | أقل من 70% من الصفقات النشطة |
| اكتمال البيانات (Data completeness) | الحقول الإلزامية في المراحل المتقدمة | أقل من 90% |

تتوفر مقاييس اعتماد (Adoption) أكثر تفصيلاً في [مقاييس اعتماد Salesforce](/ar/insights/salesforce-adoption-metrics).

## ما لا يجب فعله في المرحلة الأولى

إدارة الأقاليم (Territory Management) المعقدة، ونماذج التوقعات المتعددة (multiple Forecast models)، وCPQ الكامل، والتسجيل التلقائي (Automatic Scoring) هي كلها قدرات من الصواب إضافتها – بعد أن تستقر العملية الأساسية وتمر دورتين مبيعات. إضافتها في المرحلة الأولى ترسخ افتراضات لم يتم اختبارها بعد، وتزيد تكلفة أي تغيير مستقبلي بشكل كبير.

## الخلاصة

إن تنفيذ Sales Cloud هو في الأساس مهمة تحديدات أعمال: متى تنتقل الصفقة إلى المرحلة التالية، متى يصبح الاستفسار صفقة، وما الذي يتطلب التوثيق. تحدد هذه القرارات الثلاثة ما إذا كان التوقع سيكون أداة إدارية أم مجرد تمرين لإعداد التقارير. ستدعم الأداة نفسها أي تعريف تختاره – بما في ذلك التعريف السيئ.

### أسئلة وأجوبة
**كم عدد مراحل Opportunity التي يفضل تحديدها؟**
عادةً ما بين أربع إلى ست مراحل. عدد أكبر قد يبدو دقيقًا ولكنه يخلق مراحل يصعب التمييز بينها، مما يؤدي إلى تحديث المندوبين لها متأخرًا أو دفعة واحدة قبل اجتماع Pipeline.

**ما الفرق العملي بين Lead و Opportunity؟**
الـ Lead هو اهتمام لم يتم إثباته بعد، بينما الـ Opportunity هي صفقة مع طرف مشترٍ محدد، حاجة واضحة، وأفق زمني. إذا تم التحويل تلقائيًا لكل استفسار، سيتضخم الـ Pipeline وستفقد التوقعات معناها.

**هل التسجيل الإلزامي للأنشطة ضروري؟**
التسجيل الإلزامي الشامل يولد توثيقًا رسميًا عديم القيمة. الأفضل هو فرض التوثيق عند النقاط التي تؤثر فيها على القرار – انتقال Stage، تغيير المبلغ، تأجيل تاريخ الإغلاق.

**متى يتم ربط CPQ أو التسعير؟**
فقط بعد أن تصبح مراحل المبيعات وهيكل المنتجات مستقرة. ربط التسعير بعملية لا تزال تتغير يضاعف تكلفة التغيير ويثبت الافتراضات المؤقتة.

**كم من الوقت يستغرق حتى تصبح التوقعات موثوقة؟**
عادةً ما بين دورتين وثلاث دورات مبيعات كاملة بعد التشغيل الفعلي. قبل ذلك، لا توجد صفقات كافية تمت إدارتها وفقًا للإعدادات الجديدة لمقارنة التوقعات بالنتائج.

---

## تطبيق Service Cloud: الحالات، اتفاقيات مستوى الخدمة، التوجيه، والمعرفة
URL: https://hpi.pro/ar/insights/service-cloud-implementation
تُطبق العديد من مراكز الخدمة حل Service Cloud وتكتشف أن زمن الاستجابة لم يتحسن. والسبب في ذلك لا يكمن غالبًا في الأداة نفسها، بل في أربعة قرارات حاسمة لم تُحسم بعد: ما الذي يُعتبر "حالة" (Case)؟ من يتلقى "الحالة"؟ متى يبدأ احتساب الوقت؟ وماذا يحدث عندما تكون الإجابة موجودة بالفعل؟ يستعرض هذا الدليل هذه القرارات الأربعة ويحولها إلى مخرجات قابلة للقياس والتدقيق.

## الإجابة المختصرة

إن Service Cloud لا يقلل من أوقات الاستجابة بمفرده. بل يفرض الإعدادات التي قمت بتكوينها. إذا لم يتم تحديد تعريف Case، ومن يستقبله، ومتى يتم احتساب الوقت – فإن النظام سيقوم بقياس عملية غير محددة بدقة، وستبدو المقاييس أفضل من الواقع أو أسوأ منه، دون علاقة بالخدمة الفعلية.

تحدد أربع قرارات رئيسية النتيجة: تعريف Case، نموذج التخصيص، ساعة SLA، ومكان المعرفة. أما بقية التنفيذ – مثل الشاشات، القنوات، والأتمتة – فتنبثق عنها.

## القرار 1: ما الذي يُعتبر Case

تُنشئ العديد من مراكز الاتصال Case لكل تفاعل بحجة "للحصول على بيانات". لكن النتيجة تكون عكسية: آلاف السجلات التي تُغلق في دقيقة تضخم الحجم، تحسن بشكل مصطنع متوسط وقت الحل، وتخفي الاستفسارات التي تواجه بالفعل صعوبات.

التعريف الفعال يميز بين ثلاثة أنواع:

| نوع التفاعل | هل يُفتح Case | السبب |
| --- | --- | --- |
| سؤال تمت الإجابة عليه أثناء المحادثة | لا، يُسجل كتفاعل Interaction | لا يوجد تتبع ولا التزام |
| طلب يتطلب إجراءً أو انتظارًا | نعم | يتطلب تتبعًا وSLA |
| عطل قد يتكرر | نعم، مع تصنيف السبب | يتطلب تحليل الاتجاهات |

## القرار 2: من يستقبل الاستفسار

الخطأ الشائع هو التوجيه بناءً على القسم فقط، مما ينتج عنه قائمة انتظار كبيرة يختار منها الموظفون الحالات السهلة. تبقى الحالات المعقدة في أسفل قائمة الانتظار حتى يقوم أحدهم بتصعيدها هاتفيًا – ويتحول نظام SLA بأكمله إلى مجرد مسرحية.

نموذج التخصيص الصحيح يحدد ثلاثة أبعاد: المهارة المطلوبة، السعة الفعلية للموظف (وليس عدد Cases بل الوزن)، وقواعد التصعيد القائمة على الوقت. يدعم Omni-Channel Routing الأبعاد الثلاثة، ولكن فقط إذا تم تعريف المهارات الحقيقية. تعريف "مهارة: دعم" لجميع الموظفين يعادل عدم التعريف.

للحصول على تفاصيل كاملة حول التخصيص متعدد القنوات، يرجى زيارة [Omnichannel و-SLA في Service Cloud](/ar/insights/service-cloud-omnichannel-sla).

## القرار 3: متى يتم احتساب الوقت

هذا هو القرار الذي تتجاهله معظم المؤسسات، وهو الذي يحدد مصداقية المقاييس. يجب الإجابة كتابيًا على الأسئلة التالية:

1.  **متى يبدأ احتساب الوقت** – عند استلام الاستفسار أم عند بداية ساعات العمل التالية؟ يجب تعريف Business Hours لكل منطقة زمنية ذات صلة.
2.  **متى يتوقف** – يجب تجميد عداد Case الذي ينتظر رد العميل، وإلا فإن مركز الاتصال يعاقب على تباطؤ العميل.
3.  **ما الذي يتم قياسه بالضبط** – وقت الاستجابة الأول، وقت الحل، أم كلاهما مع أهداف منفصلة لكل مستوى خطورة.
4.  **ماذا يحدث قبل التجاوز** – Milestone الذي ينشئ تنبيهًا عند 80% من الوقت المخصص أفضل من تقرير التجاوزات الشهري.

تُطبق Entitlements وMilestones هذه النقاط الأربع. تفعيلها دون قرار مكتوب مسبقًا ينتج عنه تنبيهات يتم تجاهلها في غضون أسبوعين.

## القرار 4: أين توجد المعرفة

قاعدة المعرفة (Knowledge Base) ليست مشروعًا منفصلاً بل هي شرط لتقليل العبء. الفشل المعتاد: تُكتب المقالات عند الإطلاق، ولا يقوم أحد بتحديثها، وفي غضون ستة أشهر، يعود الموظفون للسؤال عبر الدردشة الداخلية.

ما ينجح: دورة حياة محددة لكل مقال – مالك (Owner)، تاريخ إعادة المراجعة، ومقياس الاستخدام. يُعد Case الذي يُغلق دون مقال مرتبط ويظهر خمس مرات في نفس الربع دافعًا تلقائيًا لإنشاء مقال. تُعرض تفاصيل أعمق حول هذا الموضوع في [إدارة المعرفة في Salesforce](/ar/insights/salesforce-knowledge-management).

## مقاييس التشغيل

| المقياس | التعريف | الحد لمراجعة البيانات |
| --- | --- | --- |
| First response time | حتى أول اتصال بشري | تجاوز 10% من الاستفسارات |
| First contact resolution | يُغلق دون تحويل | أقل من 60% |
| Reopen rate | Case يُعاد فتحه خلال 7 أيام | أكثر من 8% |
| Backlog aging | Cases مفتوحة تتجاوز SLA | اتجاه تصاعدي أسبوعي |
| Knowledge attach rate | Cases ذات مقال مرتبط | أقل من 30% |

معدل إعادة الفتح (Reopen rate) هو المقياس الأكثر أهمية وعادة ما يكون الأكثر إهمالاً: فهو يكشف عن الإغلاقات المبكرة التي تتم لتحقيق هدف الوقت.

## ترتيب العمل الموصى به

الموجة الأولى: تعريف Case، قناة أو اثنتين، توجيه أساسي، SLA لمستوى خطورة واحد، وعشرة مقالات Knowledge للاستفسارات الشائعة. الموجة الثانية: قنوات إضافية، مهارات، Entitlements كاملة، Self-Service. تفعيل كل شيء دفعة واحدة ينتج عنه مركز يقوم بمعالجة تغيير العملية، تغيير الأدوات، وتغيير القياس في نفس الأسبوع – وعادة ما يعود إلى العمل بطريقة التفافية.

## الخلاصة

يُقاس نجاح تنفيذ Service Cloud بسؤال واحد: هل يستطيع مدير مركز الاتصال أن يظهر، من النظام وبدون جدول مساعد، أين توجد الاستفسارات التي تتجاوز المعايير ولماذا. إذا تم الانتهاء من القرارات الأربعة، فإن الإجابة موجودة. إذا لم يكن كذلك، فهناك نظام جديد ونفس مركز الاتصال.

### أسئلة وأجوبة
**هل يجب فتح كل استفسار كـ"حالة" (Case)؟**
لا. الاستفسار الذي تتم الإجابة عليه أثناء المكالمة ولا يتطلب متابعة ليس "حالة" (Case). الفتح العشوائي للحالات يؤدي إلى تضخيم البيانات وتشويه مقاييس الحجم والحل. القاعدة العملية: تُفتح "الحالة" (Case) عندما تكون هناك حاجة للمتابعة، أو التزام زمني محدد، أو توثيق لأغراض التحليل.

**توجيه قائم على قائمة الانتظار (Queue-based) أم توجيه متعدد القنوات (Omni-Channel Routing)؟**
التوجيه القائم على قائمة الانتظار (Queue) مناسب لمركز خدمة صغير يضم وكلاء متعددي الاختصاصات. بينما يُعد التوجيه متعدد القنوات (Omni-Channel) ضروريًا عند وجود قنوات متوازية، أو مهارات مختلفة للوكلاء، أو الحاجة إلى موازنة العبء بناءً على القدرة الفعلية.

**هل من الضروري تفعيل الاستحقاقات (Entitlements) لإدارة اتفاقيات مستوى الخدمة (SLA)؟**
يمكن قياس اتفاقيات مستوى الخدمة (SLA) باستخدام التقارير فقط، ولكن الاستحقاقات (Entitlements) والمعالم (Milestones) هي التي تتيح إشعارات استباقية وتصعيدًا قبل تجاوز الاتفاقية، وليس فقط الإبلاغ عنها بأثر رجعي.

**متى يجب إضافة بوابة (Portal) أو خدمة ذاتية (Self-Service)؟**
بعد أن تحتوي قاعدة المعرفة (Knowledge Base) على إجابات حقيقية للاستفسارات الشائعة. فالبوابة التي توجه إلى مستودع فارغ تزيد من عدد الاستفسارات الواردة عبر القنوات الأخرى.

**كم عدد أنواع الحالات (Case types) التي يُنصح بتحديدها؟**
يُنصح بتحديد عدد قليل - عادةً من ثلاثة إلى خمسة أنواع - مع حقل تصنيف ثانوي. فالتصنيف التفصيلي المبالغ فيه يدفع الوكلاء لاختيار الخيار الأول في القائمة، مما يفقد قيمة التحليل.

---

## Sales Cloud مقابل Service Cloud: ما هو الفرق وما الذي تحتاجه مؤسستك؟
URL: https://hpi.pro/ar/insights/sales-cloud-vs-service-cloud
يبدو السؤال عن أي من منتجات Cloud يجب شراؤها وكأنه مقارنة بين منتجين، لكنه في الواقع سؤال حول هيكل العمل: هل الوحدة التي تتم إدارتها هي صفقة ذات تقدم، أم استفسار له وقت استجابة؟ يفصل هذا الدليل بين الاثنين بناءً على الكائنات والمقاييس والترخيص، ويوضح متى تحتاج إليهما وكيفية ربطهما دون تكرار البيانات.

## الإجابة المختصرة

يدير Sales Cloud **صفقة تتقدم** – وهي وحدة عمل تستمر لأسابيع أو أشهر، وتُقاس باحتمالية الإغلاق، وتنجح عند إغلاقها. ويدير Service Cloud **طلبًا يتم حله** – وهي وحدة عمل تستمر لساعات أو أيام، وتُقاس بوقت الاستجابة والحل، وتنجح عندما تُغلق بسرعة ودون تكرار.

هذا الاختلاف، وليس قائمة الميزات، هو ما يحدد الاختيار. إذا كنت تدير مسار مبيعات (Pipeline) – فSales Cloud هو المناسب. إذا كنت تدير قائمة انتظار مع اتفاقية مستوى خدمة (SLA) – فService Cloud هو المناسب. إذا كنت تدير عميلاً يشتري ويقدم شكاوى أيضًا – فكلاهما، على نفس حساب العميل (Account).

## الاختلاف في المصطلحات التشغيلية

| البعد | Sales Cloud | Service Cloud |
|---|---|---|
| الكائن المركزي | الفرصة (Opportunity) | الحالة (Case) |
| دورة الحياة | أسابيع إلى أشهر | ساعات إلى أيام |
| المؤشر الرئيسي | معدل الفوز، دقة التنبؤ | الاستجابة الأولى، الحل عند الاتصال الأول (FCR)، رضا العملاء (CSAT) |
| آلية التخصيص | ملكية شخصية على المدى الطويل | توجيه ديناميكي حسب التوافر |
| مصدر العبء | عدد الصفقات النشطة | ذروات غير متوقعة عبر القنوات |
| مكون المعرفة | أدلة العمل والتسعير (Playbooks) | قاعدة معرفة مدمجة (Knowledge Base) |

السطر الأكثر أهمية هو آلية التخصيص. في المبيعات، الملكية الشخصية هي قيمة – فالعميل يريد نقطة اتصال ثابتة. في الخدمة، الملكية الشخصية هي عيب – فهي تخلق قوائم انتظار شخصية تتعطل عندما يكون الممثل في إجازة.

## متى يكون الاختيار واضحًا

**Sales Cloud فقط** يناسب المؤسسة التي تبيع في عملية مستمرة ويكون الدعم بعد البيع فيها ضئيلاً أو يتم التعامل معه من قبل شريك – على سبيل المثال، مورد معدات يبيع من خلال موزعين ولا يدير مركز اتصال.

**Service Cloud فقط** يناسب المؤسسة التي يكون جميع تفاعلاتها مع العميل عبارة عن معالجة طلبات – مثل شركة خدمات تشغيلية، أو هيئة عامة، أو مورد بنية تحتية بعقود قائمة.

**كلاهما** مطلوب عندما يكون هناك تجديد، أو بيع إضافي (Upsell)، أو احتفاظ بالعملاء: بمجرد أن يحتاج ممثل الخدمة إلى معرفة أن العميل يمر بعملية تجديد، ويحتاج ممثل المبيعات إلى معرفة أن العميل قد فتح ثلاث حالات خطيرة هذا الشهر – يصبح الفصل عائقًا.

## كيفية الربط دون تكرار البيانات

هذه هي النقطة التي تفشل فيها عمليات التنفيذ المتكاملة. القاعدة هي: **Account وContact هما طبقة مشتركة واحدة**. لا يوجد "عميل مبيعات" و"عميل خدمة" منفصلان.

ومن هنا تنبثق ثلاثة قرارات:

1.  **ملكية سجل العميل** – من يقوم بتحديث معلومات الاتصال، العنوان، والهيكل التنظيمي. عادةً ما يكون قسم الخدمة، لأنه يتحدث مع العميل بتواتر أكبر.
2.  **الرؤية المتبادلة** – يرى ممثل الخدمة الصفقات المفتوحة بمستوى قراءة فقط؛ ويرى ممثل المبيعات الحالات المفتوحة ومؤشر رضا العملاء. يتم تحديد كلا الاتجاهين في نموذج المشاركة (Sharing Model)، وليس عن طريق نسخ الحقول.
3.  **المحفزات الشاملة (Cross-domain triggers)** – حالة حرجة لدى عميل يمر بعملية تجديد تولد تنبيهًا لمدير الحساب. هذه الآلية أكثر قيمة من أي لوحة تحكم متكاملة.

يتوفر تفصيل حول موضوع الأذونات والرؤية في [نموذج المشاركة والرؤية في Salesforce](/ar/insights/salesforce-sharing-visibility-design).

## الترخيص: ما يجب معرفته قبل مقارنة الأسعار

ترخيص Service Cloud شامل للمجموعات – فهو يتضمن القدرات الأساسية لـ Sales Cloud، وبالتالي فإن المستخدم الذي يحتاج إلى كليهما لا يحتاج إلى ترخيصين. الاتجاه المعاكس غير موجود: ترخيص Sales لا يتضمن إدارة الحالات (Case management)، أو المؤهلات (Entitlements)، أو قاعدة المعرفة (Knowledge).

المعنى العملي: يبدأ حساب التكلفة الصحيح بتصنيف المستخدمين بناءً على ما يقومون به بالفعل، وليس بناءً على القسم الذي ينتمون إليه. الممثل الذي يتفاعل مع الصفقة مرتين في السنة ليس مستخدم مبيعات.

## ترتيب التنفيذ عند الحاجة إلى كليهما

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

الترتيب الموصى به هو البدء بالجانب الذي يعاني من الألم الأكثر قابلية للقياس – عادةً الخدمة، لأن وقت الاستجابة ومعدل التوقف يتم قياسهما بالفعل – وإضافة الجانب الآخر بعد شهرين من التشغيل المستقر. يتم بناء الطبقة المشتركة (Account، Contact، الأذونات) في المرحلة الأولى حتى لو تم إطلاق جانب واحد فقط، وإلا فإن المرحلة الثانية ستتطلب إعادة الهيكلة.

## الملخص

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

### أسئلة وأجوبة
**هل يمكن إدارة استفسارات الخدمة في Sales Cloud بدون Service Cloud؟**
من الناحية الفنية نعم، عبر كائن مخصص أو مهمة (Task). ولكن بمجرد الحاجة إلى اتفاقيات مستوى الخدمة (SLA)، أو التوجيه بناءً على التوفر (Routing)، أو قاعدة المعرفة (Knowledge)، أو القنوات، فإن تكلفة الإنشاء الذاتي تفوق الفارق في الترخيص.

**هل أحتاج إلى بيئتين (Org) منفصلتين؟**
غالبًا لا. يتعايش كلا منتجي Cloud في نفس البيئة (Org) ويشاركان كائني Account وContact. لا يتم النظر في فصل البيئتين إلا لاعتبارات تنظيمية أو لشركات مستقلة تمامًا.

**ماذا يحدث للمستخدم الذي يحتاج إلى كلا المنتجين؟**
يحصل المستخدم الذي يمتلك ترخيص Service Cloud على القدرات الأساسية لـ Sales Cloud أيضًا. العكس غير صحيح؛ ترخيص Sales لا يشمل إدارة الحالات (Case management) بالكامل.

**ما هو الفرق في تعريف النجاح بين الاثنين؟**
تقاس المبيعات بالتقدم ونسبة الإغلاق على مدار أسابيع؛ بينما تقاس الخدمة بوقت الاستجابة، والحل في التفاعل الأول، ورضا العميل في غضون ساعات. يؤثر هذا الاختلاف في الوتيرة على تكرار القياس، وعبء الأتمتة، وتخطيط الأداء.

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

---

## إدارة التغيير في تطبيق Salesforce: خطة عمل قبل وبعد التشغيل الفعلي
URL: https://hpi.pro/ar/insights/salesforce-change-management-plan
إدارة التغيير ليست مجرد أسبوع تدريبي قبل الانطلاق. نقدم خطة عمل من أربع مراحل – تحديد الأثر، إشراك أصحاب المصلحة، التواصل، ودورة الإدارة – مع مخرجات ومسؤوليات ومؤشرات أداء لكل مرحلة.

## الإجابة المختصرة

إدارة التغيير ليست نشاطًا تواصليًا يُلحق بنهاية المشروع. إنها سير عمل متوازٍ يبدأ بمرحلة "الاكتشاف" وينتهي بعد أشهر من إطلاق النظام (Go-Live). الفجوة بين المشاريع الناجحة والفاشلة تكمن في هذا الجانب تقريبًا، لا في الكود البرمجي.

تتكون إدارة التغيير من أربع مراحل، لكل منها مخرجات محددة: تحديد الأثر، استقطاب أصحاب المصلحة، التواصل والتدريب، ودورة إدارية مستمرة.

## المرحلة الأولى – تحديد الأثر حسب الدور الوظيفي

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

| الدور الوظيفي | ما الذي يتغير؟ | المخاطر الرئيسية | الاستجابة المخطط لها |
|---|---|---|---|
| مندوب مبيعات | إدخال البيانات في النظام بدلاً من ملف Excel شخصي | عبء الإدخال، فقدان السيطرة | نموذج مبسط، قيمة يومية متكررة |
| مدير المبيعات | التنبؤات المعتمدة على النظام | انكشاف على أرقام غير مرضية | تحضير مسبق، لوحة معلومات خاصة (Dashboard) للفترة الانتقالية |
| الدعم الإداري (Back Office) | عملية موافقة جديدة | تأخيرات في الفترة الانتقالية | تدريب مسبق، إجراءات استثنائية |
| الإدارة العليا | مصدر واحد موثوق للتقارير | فجوات مقارنة بالتقارير القديمة | مقارنة متوازية لمدة ربع كامل |

المُخرج الرئيسي هو مستند من صفحتين إلى أربع صفحات، يُستخدم كمدخل لتخطيط الحل.

## المرحلة الثانية – أصحاب المصلحة والرعاية التنفيذية (Sponsorship)

الراعي التنفيذي الحقيقي (Sponsor) هو من لديه القدرة على تغيير عملية أو هدف أو مكافأة. الراعي التنفيذي الذي يظهر فقط في رسالة افتتاحية ليس راعيًا تنفيذيًا حقيقيًا. يجب الحصول على ثلاثة التزامات كتابية كحد أدنى:

- المشاركة في المراجعة الشهرية للمشروع واتخاذ القرارات العالقة.
- إعلان صريح عن المصدر الوحيد للمعلومات ووقف التقارير الموازية في تاريخ محدد.
- دعم تغيير العملية حتى لو كان ذلك غير مريح لقسم معين.

إلى جانب الراعي التنفيذي، يتم بناء شبكة من "الأبطال" (Champions) في الميدان تعمل كقناة ثنائية الاتجاه، ويمكن العثور على التفاصيل في [بناء شبكة Champions في Salesforce](/ar/insights/salesforce-champions-network).

## المرحلة الثالثة – التواصل بطريقة مختلفة عن المعتاد

التواصل الفعال يجيب على سؤال واحد يطرحه المستخدم: ما هو تأثير ذلك عليّ؟ الرسائل التي تتحدث عن "التحول الرقمي" تُعتبر مزعجة. هناك ثلاثة مبادئ:

1. **التجزئة حسب الدور الوظيفي** – رسالة واحدة للمؤسسة بأكملها لا تنجح. يجب إطلاع مندوب المبيعات على ما سيتغير في شاشته، وإبلاغ المدير بما سيتغير في مراجعته.
2. **الاعتراف بالتكلفة** – يجب التصريح بوضوح بما سيصبح أكثر صعوبة. إنكار الحقائق يقوض الثقة أسرع من أي عيب حقيقي.
3. **وتيرة منتظمة** – تحديثات قصيرة كل أسبوعين من مرحلة الاكتشاف (Discovery) وحتى مرحلة الدعم المكثف (Hypercare)، حتى لو لم تكن هناك أخبار درامية.

يُبنى التدريب نفسه حول سيناريوهات العمل بدلاً من الشاشات، والهيكل الموصى به مفصل في [تدريب Salesforce حسب الدور الوظيفي](/insights/salesforce-دور-قائم-على التدريب).

## المرحلة الرابعة – الدورة الإدارية بعد الإطلاق (Go-Live)

هذه هي المرحلة الأكثر إغفالًا والأكثر حسمًا. يتأصل التغيير فقط عندما يصبح جزءًا من الروتين الإداري:

- مراجعة أسبوعية للفريق من لوحة معلومات (Dashboard) داخل النظام، وليس من ملف خارجي.
- تقرير شهري للإدارة يُستخرج من النظام فقط.
- قناة مفتوحة لطلبات التعديل مع إصدارات دورية وتواصل بشأن ما تم إصلاحه.
- قياس شهري للتبني (Adoption) استنادًا إلى [مقاييس تبني Salesforce](/ar/insights/salesforce-adoption-metrics).

التاريخ المستهدف المهم ليس تاريخ الإطلاق (Go-Live)، بل هو اليوم الذي تتوقف فيه التقارير الموازية. طالما يوجد تقرير "ظل" مشروع، يظل النظام نظامًا ثانويًا.

## المخاطر الشائعة وعلامات الإنذار المبكر

| علامة إنذار | المعنى | الاستجابة |
|---|---|---|
| الراعي التنفيذي (Sponsor) يتغيب عن مراجعتين متتاليتين | لا يوجد ولاء أو ملكية تجارية | طرح القضية على الإدارة العليا قبل اختبار UAT |
| تتراكم طلبات "حقل إضافي واحد فقط" | لم يتم الاتفاق على العملية | تجميد وإعادة تقييم العملية |
| تم تأجيل التدريب بسبب ضغط الجداول الزمنية | سيتم إطلاق المشروع دون جاهزية | تأجيل تاريخ الإطلاق (Go-Live) للفريق المعني فقط |
| يطلب المديرون "التقرير القديم أيضًا" | انعدام الثقة في البيانات | تصحيح البيانات قبل توسيع نطاق العمل (Scope) |

## مقاييس خطة التغيير

يتم قياس أربعة عناصر: نسبة المستخدمين الذين أكملوا التدريب القائم على السيناريوهات، ومعدل إنجاز العمليات الأساسية في الأسبوعين الأولين، وعدد ملفات "الظل" النشطة، ومتوسط ​​الوقت لإغلاق طلب التغيير. الثلاثة الأولى تشير إلى الاستيعاب، والرابع يشير إلى الثقة في القناة.

## الملخص

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

### أسئلة وأجوبة
**متى تبدأ إدارة التغيير في مشروع Salesforce؟**
تبدأ في مرحلة الاستكشاف (Discovery)، بالتزامن مع جمع المتطلبات. فتحديد الأثر على الأدوار هو مدخل لتخطيط الحل وليس مخرجه. البدء في مرحلة الاختبارات يؤخر المشروع حوالي ثلاثة أشهر.

**كم تبلغ الميزانية المخصصة لإدارة التغيير؟**
يتراوح النطاق المقبول بين 10% و15% من ميزانية المشروع في التطبيقات متوسطة الحجم، ويزداد هذا النطاق عند تغيير الهيكل التنظيمي أو نظام المكافآت. في المشاريع التي تُخفض فيها هذه الميزانية، تعود التكلفة لاحقًا في صورة مشروع تعافٍ وإصلاح.

**من المسؤول عن إدارة التغيير – الموارد البشرية، مكتب إدارة المشاريع (PMO)، أم فريق CRM؟**
المسؤولية النهائية عن النتائج تقع على عاتق الراعي التجاري (Business Sponsor). بينما توفر الموارد البشرية أو مكتب إدارة المشاريع المنهجية والأدوات، ويقدم فريق CRM المحتوى، إلا أن القرارات المتعلقة بتغيير العمليات والمكافآت يجب أن تُتخذ على المستوى التجاري.

**كيف نتعامل مع مقاومة المديرين المتوسطين؟**
يقاوم المديرون المتوسطون بشكل أساسي عندما يؤدي النظام إلى شفافية تهددهم أو يزيد من أعباء عملهم. يكمن الحل في تزويدهم بقيمة إدارية أولية – لوحة تحكم (Dashboard) تلغي حاجتهم إلى التقارير اليدوية.

**ما الذي يستمر بعد فترة Hypercare؟**
تتواصل ثلاثة أمور: دورة مراجعة إدارية منتظمة من داخل النظام، قناة مفتوحة لطلبات التحسين مع إصدارات دورية، وقياس شهري لاعتماد النظام. بدون هذه العناصر، يتراجع التغيير في غضون ربعين.

---

## تدريب Salesforce حسب الدور الوظيفي: كيف تبني برنامجًا يعزز الاستقلالية
URL: https://hpi.pro/ar/insights/salesforce-role-based-training
التدريب الذي يشرح الشاشات ينسى في غضون أسبوع. إليك هيكل لبرنامج تدريبي قائم على السيناريوهات: مسار منفصل لكل دور وظيفي، تدريب عملي على بيانات حقيقية في بيئة Sandbox، اختبار الاستقلالية، وصيانة مستمرة للمنضمين الجدد.

## الإجابة المختصرة

إن التدريب الذي يشرح موقع كل زر يُنسى بنهاية الأسبوع. أما التدريب الذي يركز على سيناريوهات العمل الحقيقية للمستخدمين—مثل "عميل يتصل لطلب عرض سعر"، "صفقة متوقفة"، أو "إغلاق طلب خدمة مع استعادة"—فهو يدوم، لأنه يرتبط بذاكرة العمل نفسه.

النهج الموصى به: مسار تدريبي منفصل لكل دور وظيفي، يتراوح مدته بين ساعتين وأربع ساعات، يعتمد على التدريب العملي في بيئة Sandbox باستخدام بيانات مألوفة، وينتهي باختبار عملي لقياس الاستقلالية.

## لماذا يفشل التدريب العام

التدريب الموحد لجميع أفراد المؤسسة يعلم القاسم المشترك الأدنى—أي التنقل في النظام بشكل أساسي. يخرج كل دور وظيفي من هذا التدريب بنسبة 20% محتوىً ذا صلة و80% ضوضاء، ويصل إلى يوم العمل الأول دون القدرة على إنجاز مهامه من البداية إلى النهاية. والنتيجة هي اللجوء إلى الدعم لكل عملية، أو التراجع إلى طريقة العمل القديمة.

علاوة على ذلك، يخفي التدريب العام مشاكل واجهة المستخدم. إذا استغرق شرح كيفية إدخال فرصة بيع 40 دقيقة، فالمشكلة ليست في التدريب بل في الشاشة—وهو موضوع تمت مناقشته في [تبسيط تجربة المستخدم في Salesforce](/ar/insights/salesforce-ux-simplification).

## مسارات التدريب حسب الدور الوظيفي

| الدور الوظيفي | سيناريوهات العمل الأساسية | المدة | اختبار الاستقلالية |
|---|---|---|---|
| مندوب المبيعات | من عميل محتمل إلى فرصة، تقدم المرحلة، عرض السعر، توثيق النشاط | 3 ساعات | إغلاق دورة مبيعات كاملة دون مساعدة |
| مدير المبيعات | مراجعة Pipeline، التنبؤ، الموافقة على الاستثناءات، تحليل أداء الفريق | 3 ساعات | إدارة مراجعة أسبوعية من داخل النظام |
| ممثل خدمة العملاء | فتح Case، التصنيف، التصعيد، الإغلاق مع رمز السبب | 3 ساعات | التعامل مع ثلاث حالات دعم مختلفة ضمن الهدف الزمني |
| فريق Back Office | الموافقات، تصحيحات البيانات، الاستثناءات | ساعتان | التعامل مع قائمة الموافقات اليومية |
| الإدارة العليا | قراءة لوحات المعلومات (Dashboard)، الاستعلام عن البيانات | ساعة واحدة | اتخاذ قرار بناءً على بيانات النظام فقط |

## هيكل اجتماعات التدريب الفعال

تقسيم 20/60/20: عشرون بالمائة للسياق—لماذا حدث التغيير وما هي الفائدة؛ ستون بالمائة للتدريب العملي على السيناريوهات؛ عشرون بالمائة للأسئلة ومعالجة الاستثناءات. المحاضرة بدون تدريب عملي لا تعتبر تدريباً فعالاً.

يتم التدريب العملي في بيئة Sandbox مع بيانات تحاكي واقع المشاركين: أسماء عملاء مألوفة، مبالغ معقولة، ومنتجات حقيقية. تولد البيانات الوهمية العامة شعورًا بالانفصال وتجعل الانتقال إلى العمل الحقيقي صعبًا.

## اختبار الاستقلالية

يجب أن يحتوي برنامج التدريب على معيار إنجاز قابل للقياس. المعيار ليس الحضور ولا استبيان المعرفة—بل الأداء: يقوم المشارك بتنفيذ سيناريو عمله الأساسي من البداية إلى النهاية، بمفرده، في وقت معقول، ودون طرح أسئلة.

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

## مواد المساعدة: موجزة وحسب المهمة

بعد التدريب، ما هو مطلوب فعلاً هو وثيقة من صفحة واحدة لكل دور وظيفي ومكتبة فيديوهات تتراوح مدتها من دقيقة إلى ثلاث دقائق لكل مهمة. القاعدتان الأساسيتان: البحث بناءً على السؤال ("كيف أنقل صفقة إلى المرحلة التالية؟") وليس بناءً على الوحدة النمطية، وتحديد مالك مسؤول عن تحديث المواد مع كل تغيير في النظام.

إن دليل المستخدم المكون من 60 صفحة يُكتب مرة واحدة، ويصبح قديمًا في غضون شهرين، ولا يُقرأ. لا تستثمروا فيه.

## الدعم في الأسابيع الأولى

في الأسبوعين التاليين للإطلاق، يلزم وجود ممثلين ميدانيين يمكنهم تقديم المساعدة الفورية. هذه الشبكة—Champions—هي الذراع التنفيذية للتدريب، ويتم تفصيل بنائها في [شبكة Champions في Salesforce](/ar/insights/salesforce-champions-network). يعتبر التدريب بأكمله مكونًا ضمن خطة عمل أوسع: [إدارة التغيير في Salesforce](/ar/insights/salesforce-change-management-plan).

## المنضمون بعد الإطلاق

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

## القياس

قمنا بفحص ثلاثة مقاييس: نسبة النجاح في اختبار الاستقلالية، حجم استفسارات الدعم في الشهر الأول حسب الموضوع، ومعدل تنفيذ الإجراءات الأساسية في الأسبوعين الأولين وفقًا [لمقاييس تبني Salesforce](/ar/insights/salesforce-adoption-metrics). غالبًا ما يشير تجميع الاستفسارات حول موضوع واحد إلى حاجة لتصحيح في النظام وليس في التدريب.

## الخلاصة

قم بإنشاء مسار تدريبي لكل دور وظيفي حول سيناريوهات العمل، وتدرب في بيئة Sandbox باستخدام بيانات مألوفة، واختتم باختبار استقلالية عملي، وحافظ على مسار تأهيل للمنضمين الجدد. التدريب الجيد لا يعلم النظام—بل يعلم كيفية إنجاز العمل بداخله.

### أسئلة وأجوبة
**كم ساعة تدريب يحتاجها المستخدم النهائي؟**
تتراوح بين ساعتين إلى أربع ساعات لسيناريوهات العمل الأساسية، مقسمة على جلستين قصيرتين بدلاً من جلسة واحدة طويلة. يحتاج المديرون إلى ساعة إضافية للتقارير والمراجعة. الزيادة عن ذلك تؤدي إلى النسيان، لا المعرفة.

**هل الأفضل فيديو مسجل أم تدريب مباشر؟**
مزيج من الاثنين. التدريب المباشر لممارسة السيناريوهات الرئيسية لأنه يسمح بطرح الأسئلة، وفيديوهات قصيرة من دقيقة إلى ثلاث دقائق كمكتبة مرجعية لكل مهمة. الفيديوهات الطويلة التي تتجاوز 40 دقيقة نادرًا ما يشاهدها أحد.

**متى يتم تقديم التدريب بالمقارنة مع تاريخ الإطلاق (Go Live)؟**
قبل أسبوع إلى عشرة أيام. التدريب قبل شهر من الإطلاق ينسى، والتدريب قبل يوم واحد يتعارض مع ضغط الإطلاق. يخضع المنضمون الجدد بعد الإطلاق للمسار التدريبي نفسه في غضون أسبوعين من تسلم مهامهم.

**كيف يتم التدريب عندما يكون النظام لا يزال قيد التغيير؟**
يتم تجميد العمليات الرئيسية قبل أسبوعين من التدريب، وتوثق التغييرات اللاحقة كقائمة موجزة للفروقات (delta list). التدريب على نظام متغير باستمرار يولد عدم ثقة فورية.

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

---

## مقاييس تبني Salesforce: لماذا لا يكفي تسجيل الدخول؟
URL: https://hpi.pro/ar/insights/salesforce-adoption-metrics
تسجيل الدخول هو مقياس حضور، وليس مقياس قيمة. دليل عملي لبناء مجموعة من مقاييس التبني التي تقيس الإجراءات الأساسية وجودة البيانات والنتائج التجارية — بما في ذلك خط الأساس، والتجزئة حسب الدور، وخطة عمل لكل نتيجة.

## الإجابة المختصرة

يثبت تسجيل الدخول (Login) أن شخصًا ما قد وصل إلى النظام. لكنه لا يثبت أن العمل قد أُنجز بداخله، أو أن البيانات المُدخلة موثوقة، أو أن المدير يمكنه اتخاذ قرار بناءً عليها. إن المنظمة التي تبلغ عن 92% من تسجيلات الدخول وتدير في الوقت نفسه توقعاتها عبر جداول Excel، لم تتبنَّ Salesforce بالفعل، بل قامت فقط بفتحه.

مقياس التبني الفعال يجيب على سؤال واحد: **هل العملية التجارية تعمل داخل النظام من البداية إلى النهاية، بجودة تسمح بالاعتماد عليها؟** ومن هنا، تنبع أربع طبقات للقياس: العمليات الأساسية، جودة البيانات، سرعة العملية، والنتيجة التجارية.

## ثلاث مستويات من التبني

| المستوى | ما يتم قياسه | مثال | ماذا يعني ذلك |
| --- | --- | --- | --- |
| الحضور | تسجيل الدخول (Login)، وقت البقاء | 92% قاموا بتسجيل الدخول هذا الأسبوع | لا شيء تقريبًا |
| الاستخدام النشط | العمليات الأساسية لكل دور | 78% من الصفقات تم تحديثها خلال 7 أيام | العملية تعمل |
| القيمة | النتيجة التجارية + الجودة | انخفض انحراف التوقعات من 31% إلى 12% | التبني أثمر |

تتعثر معظم المنظمات في المستوى الأول لأنه الوحيد المتاح دون جهد. يتطلب المستويان التاليان قرارًا مسبقًا: ما هي "العملية الأساسية" لكل دور.

## كيفية تعريف العملية الأساسية

العملية الأساسية هي العملية التي بدونها تتعطل العملية برمتها. ليست العملية الأكثر شيوعًا، بل العملية الأكثر أهمية. بالنسبة لممثل المبيعات، يكون هذا عادةً تحديث المرحلة وتاريخ الإغلاق؛ وبالنسبة لمدير المبيعات، فهو مراجعة Pipeline الأسبوعية داخل Salesforce؛ وبالنسبة لممثل خدمة العملاء، فهو إغلاق الحالة (Case) برمز سبب صحيح.

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

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

## طبقة جودة البيانات

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

- نسبة الصفقات ذات تاريخ إغلاق مُنصرم – مقياس لتدهور Pipeline.
- نسبة الحالات (Cases) التي أُغلقت برمز سبب عام من نوع "أخرى" – مقياس لتصنيف معطل.
- نسبة العملاء بدون جهة اتصال نشطة – مقياس لنقص البيانات الأساسية.
- نسبة السجلات المكررة التي أُنشئت يدويًا – مقياس لفشل في عملية الإدخال.

تكشف هذه المقاييس الأربعة في غضون أسبوع واحد ما إذا كان النظام مستخدمًا فعليًا أو مجرد استخدام شكلي. لمزيد من التفاصيل حول معالجة المشكلة الجذرية، يرجى الاطلاع على [تحسين تبني Salesforce](/ar/insights/recover-salesforce-user-adoption).

## التقسيم: المتوسط يخدع

يمكن لمتوسط تبني على مستوى المنظمة بنسبة 70% أن يخفي فريقًا بنسبة 95% وآخر بنسبة 20%. يجب أن يكون كل قياس مقسمًا حسب ثلاثة محاور على الأقل:

1. **الدور الوظيفي** – ممثل، مدير، Back Office. لكل منهم توقعات مختلفة.
2. **الفريق أو المدير المباشر** – الفرق الأكبر في التبني يكون دائمًا تقريبًا في المدير المباشر، وليس في التدريب.
3. **الأقدمية في النظام** – المستخدمون الذين انضموا بعد تاريخ الإطلاق (Go Live) لم يتلقوا نفس التدريب، وتشير بياناتهم إلى عملية الإعداد لديهم.

عندما يكون الفرق بين الفريق الرائد والفريق المتأخر أكبر من الضعف، تكون المشكلة إدارية وليست نظامية، ويكون الاستثمار الصحيح في طبقة الإدارة وليس في تطوير إضافي.

## الأساس (Baseline): الخطأ الذي لا يمكن إصلاحه لاحقًا

المقياس بدون نقطة مرجعية هو رقم لا معنى له. يتم قياس الأساس (Baseline) قبل التغيير – حتى لو تم قياسه يدويًا، وحتى لو كان تقديريًا. اسأل: كم من الوقت يستغرق اليوم لإغلاق حالة (Case)؟ كم عدد الصفقات التي يتم تحديثها في الوقت المحدد؟ ما هو انحراف التوقعات في الأرباع الثلاثة الماضية؟

إذا لم يتم قياس الأساس قبل الإطلاق، يمكن استعادته جزئيًا من البيانات التاريخية، ولكن لا يمكن استعادة المقاييس السلوكية. هذا هو السبب في أن قياس التبني هو قرار يتم اتخاذه في مرحلة التخطيط، وليس في مرحلة الإطلاق (Go Live).

## من النتائج إلى الإجراء

يسرد الجدول التالي النتائج الشائعة المقابلة للإجراء الصحيح. المنطق: نادرًا ما يتم حل أي نتيجة تتعلق بالتبني من خلال تدريب إضافي.

| النتيجة | السبب الجذري المحتمل | الإجراء الموصى به |
| --- | --- | --- |
| ارتفاع معدلات تسجيل الدخول (Logins)، وانخفاض عمليات العمل الأساسية | النظام ليس جزءًا من سير العمل اليومي | التكامل في العملية: التنبيهات، المسار (Path)، قوائم المهام |
| تنفيذ العمليات ولكن بتأخير لأسابيع | لا توجد دورة إدارية تعتمد على البيانات | مراجعة Pipeline الأسبوعية من خلال لوحة المعلومات (Dashboard) |
| جودة منخفضة في حقل معين | الحقل غير ذي صلة أو غير واضح | تقليله، تغييره إلى قائمة منسدلة (Picklist)، أو إزالته |
| فريق معين متأخر | المدير المباشر لا يستخدم النظام | العمل مع المدير، وليس مع الفريق |
| جميع الحقول مملوءة ولكن الإدارة لا تثق | عدم تطابق بين المقياس والسؤال التجاري | إعادة تعريف مقياس النتيجة |

## كيف تبدو في تقرير شهري

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

يتم تفصيل الارتباط بين القياس وخطة عمل المنظمة في [إدارة التغيير في Salesforce](/ar/insights/salesforce-change-management-plan)، ويتوفر تخطيط التدريب المستمد من النتائج في [تدريب Salesforce المستند إلى الدور](/ar/insights/salesforce-role-based-training).

## الخلاصة

مقاييس التبني ليست تقرير درجات للمستخدمين، بل هي نظام اكتشاف الأخطاء في العملية. إذا لم يؤدِ القياس إلى تغيير في العملية أو الواجهة أو الطبقة الإدارية، فإنه لا ينتج سوى عبء عمل. ابدأ بأربعة مقاييس، قسّم حسب الفريق، حدد أساسًا (Baseline)، واربط كل نتيجة بإجراء ومسؤول.

### أسئلة وأجوبة
**كم عدد مقاييس التبني التي يجب قياسها؟**
بين أربعة وستة مقاييس. مقياس واحد للإجراءات الأساسية لكل دور رئيسي، مقياس واحد لجودة البيانات، مقياس واحد لسرعة العملية، ومقياس واحد للنتائج التجارية. أكثر من ذلك ينتج لوحة معلومات لا يفتحها أحد.

**ماذا نفعل عندما تظهر البيانات تبنياً عالياً ولكن الإدارة غير راضية؟**
هذه علامة شبه دائمة على أنك قست النشاط وليس النتيجة. تحقق مما إذا كانت الإجراءات المقاسة تؤثر بالفعل على الأرقام التجارية — على سبيل المثال، هل تحديث مرحلة الصفقة يحسن دقة التوقعات، أم أنه مجرد ملء حقل؟

**هل يمكن قياس التبني بدون أداة تحليل مخصصة (Analytics tool)؟**
نعم. التقارير ولوحات المعلومات القياسية (Reports and Dashboards) مع أنواع التقارير التي تعتمد على سجل الحقول (Report Types on field history) كافية لمعظم المؤسسات. الأداة الخارجية مطلوبة بشكل أساسي عندما يكون هناك حاجة لتحليل الشاشة وتسلسل النقرات على مستوى المستخدم.

**متى يتم القياس لأول مرة بعد إطلاق النظام (Go Live)؟**
بعد أسبوعين من انتهاء فترة الدعم المكثف (Hypercare)، وليس قبل ذلك. في الأسابيع الأولى، تكون الأرقام مشوهة بسبب الدعم الوثيق، وتصحيحات البيانات، والحماس الأولي.

**كيف نمنع أن يصبح المقياس مجرد لعبة أرقام؟**
يجب أن يكون كل مقياس كمي مصحوباً بمقياس جودة. إذا كنت تقيس عدد الأنشطة (Activities)، فقم بقياس نسبة الأنشطة ذات المحتوى الهادف أو المرتبطة بفرصة. المقياس الفردي سيخلق دائماً ضغطاً اصطناعياً.

---

## 8 علامات تدل على أن نظام Salesforce الحالي لديك بحاجة إلى الترقية
URL: https://hpi.pro/ar/insights/salesforce-system-upgrade-signs
نادراً ما يتعطل نظام إدارة علاقات العملاء (CRM) فجأة. بل يتآكل تدريجياً، والمستخدمون اليوميون قد لا يلاحظون ذلك. العلامات الثماني المذكورة هنا قابلة للقياس دون الحاجة لاستطلاعات أو استشاريين، وكل منها يشير إلى جذر مشكلة مختلف: العمليات، البيانات، البنية، أو الحوكمة.

## الإجابة المختصرة

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

## العلامات الثمانية

| # | العلامة | ما تكشفه |
| --- | --- | --- |
| 1 | جداول بيانات موازية لإدارة التوقعات أو قوائم الانتظار | المنظومة ليست المصدر الفعلي للحقيقة |
| 2 | تقارير تعرض أرقامًا متضاربة | تعريفات مقاييس غير موحدة أو ازدواجية البيانات |
| 3 | كل طلب تغيير يستغرق أسابيع | تراكم ديون الأتمتة، عدم وجود بيئة اختبار سليمة |
| 4 | شاشات تحتوي على عشرات الحقول التي لا يملؤها أحد | تراكم المتطلبات دون تنظيف |
| 5 | تحميل بطيء وملحوظ للسجلات | Trigger مكرر، Flows متسلسلة، استعلامات غير فعالة |
| 6 | عمليات يدوية تتكرر يوميًا | عملية لم يتم تطبيقها، بل تم توثيقها فقط |
| 7 | صلاحيات تُمنح "للحصول على حل" | نموذج رؤية فقد منطقه |
| 8 | المعرفة محصورة بشخص واحد فقط | غياب التوثيق والحوكمة |

## كيف تُقرأ الصورة

تنقسم العلامات إلى أربع مجموعات، وهذا ما يحدد نوع العمل:

**العمليات (1، 6)** - المنظومة مبنية حول عملية ليست العملية الحقيقية. الحل هو إعادة تخطيط، وليس تطوير.

**البيانات (2)** - المشكلة في التعريفات والجودة، وليست في أدوات الإبلاغ. توسع في [مقاييس جودة بيانات Salesforce](/ar/insights/salesforce-data-quality-metrics).

**الهندسة المعمارية (3، 5)** - تراكم الديون في الأتمتة والكود. توسع في [تحسين أداء Salesforce](/ar/insights/salesforce-performance-optimization).

**الحوكمة (4، 7، 8)** - لا يوجد من يقرر ما يتم إدخاله، من يرى ماذا، ومن يوّثق. هذه هي المجموعة التي إذا لم تُعالج، فإن باقي الإصلاحات ستتكرر.

## العلامة الأكثر دلالة

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

## ما يجب فعله قبل الإصلاح

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

بعد القياس، تأتي اتخاذ القرار بين الإصلاح الموجه والعمل الهيكلي، المفصل في [إصلاح أم إعادة بناء Salesforce](/ar/insights/salesforce-rebuild-vs-refactor).

## الملخص

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

### أسئلة وأجوبة
**كم عدد العلامات التي يجب أن تكون موجودة لتبرير الفحص؟**
ثلاث من العلامات الثماني، أو علامة واحدة ذات تأثير كبير – مثل تقارير الإدارة المتضاربة. العلامة الفردية الضعيفة غالباً ما تكون مشكلة محددة وليست مشكلة نظامية.

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

**ما الفرق بين الترقية والصيانة الدورية؟**
تتعامل الصيانة مع الأعطال والطلبات المحددة. بينما تغير الترقية الهيكل – مثل النموذج، الأتمتة، أو الصلاحيات – لإزالة السبب الجذري الذي ينتج عنه هذه الطلبات.

**هل يمكن التعرف على العلامات بدون الوصول إلى النظام؟**
نعم. فمعظمها يمكن ملاحظته من الخارج: مدة الاجتماعات اليدوية، عدد الملفات المرسلة عبر البريد الإلكتروني، الوقت المستغرق للحصول على إجابة لسؤال تقرير بسيط.

**ماذا نفعل بعد التعرف على المشكلات؟**
نقوم بالقياس قبل الإصلاح. يوفر جمع البيانات لمدة أسبوعين عن أهم ثلاث علامات أساساً (Baseline) لا يمكن بدونه إثبات التحسين لاحقاً.

---

## استراتيجية Sandboxes و DevOps لمنصة Salesforce في المؤسسات
URL: https://hpi.pro/ar/insights/salesforce-sandbox-devops-strategy
إن مسار التغيير من التطوير إلى الإنتاج هو ما يحدد إمكانية النشر بثقة. يوضح هذا الدليل أنواع Sandboxes المطلوبة في كل مرحلة، وكيفية بناء مسار عمل Source-Driven باستخدام Git و CI، وكيفية التعامل مع التكوينات التي تتم يدوياً في بيئة الإنتاج.

## الإجابة المختصرة

تُعالِج استراتيجية البيئات المُحكَمة ثلاثة أسئلة رئيسية: أين يُنفّذ كل نوع من العمل، وكيف تنتقل التغييرات، وكيف يمكن التراجع في حال حدوث خطأ. الهيكل الأمثل لمعظم المؤسسات يتضمّن بيئة Developer لكل مطور، بيئة تكامل مشتركة، بيئة UAT ببيانات تمثيلية، وبيئة Production — مع استخدام Git كمصدر وحيد للحقيقة والنشر الآلي حتى بيئة UAT على الأقل.

## خريطة البيئات

| البيئة | النوع | ما يحدث فيها | البيانات |
|---|---|---|---|
| تطوير فردي | Developer | البناء، التجارب، اختبارات الوحدات | البيانات الوصفية فقط |
| التكامل | Developer Pro | دمج أعمال الفريق بالكامل، CI | عينة صغيرة توليفية |
| UAT | Partial أو Full | القبول من الأعمال، التدريب، سيناريوهات حافة | بيانات حقيقية مُخفّاة |
| Staging / Full | Full | بروفة نهائية للإصدار، اختبارات الحجم | نسخة كاملة مُخفّاة |
| Production | — | العمليات اليومية | بيانات حقيقية |

يُوصى باستخدام Sandbox لـ Hotfix للمؤسسات التي تستغرق إصداراتها أكثر من أسبوعين: فبدونها، يستلزم أي إصلاح عاجل نشر عمل لم ينضج بعد.

## من Change Sets إلى Source-Driven

يتم الانتقال على ثلاث مراحل. أولاً، يتم تصدير البيانات الوصفية الحالية إلى Repo وتثبيت بنية بسيطة واستراتيجية فروع – فرع رئيسي، فرع إصدار (Release)، وفروع ميزات (Feature) قصيرة الأجل. بعد ذلك، يتم ربط CI الذي يقوم بتشغيل Validation Deploy مقابل بيئة التكامل، واختبارات Apex، والاختبارات الثابتة عند كل طلب سحب (Pull Request). في المرحلة الثالثة، يتم ربط النشر التلقائي إلى UAT، مع الإبقاء على النشر إلى Production كإجراء يدوي معتمد ضمن نافذة إصدار محددة.

العقبة أمام هذا الانتقال ليست الأداة، بل النطاق: محاولة تضمين المنظمة بأكملها (Org) في Repo دفعة واحدة تخلق آلاف الملفات التي لا يستطيع أحد مراجعتها. من الأفضل البدء بمجموعة من البيانات الوصفية لقطاع عمل واحد والتوسع تدريجياً.

## ما لا يدخل إلى Repo

بعض الحالات لا تُمثّل بيانات وصفية يمكن نشرها: سجلات التكوين في Custom Settings و Custom Metadata التي تعتمد على البيئة، قيم Named Credentials، قواعد التعيين (Assignment Rules) المتغيرة باستمرار، ومحتوى Knowledge. لكل فئة من هذه الفئات، يجب أن تكون هناك وثيقة موجزة تحدد من يقوم بالتحديث، وأين يتم ذلك، وكيف يتم المزامنة بين البيئات. إن غياب هذا التعريف هو السبب الأكثر شيوعًا للمشاكل التي تظهر فقط في Production.

ترتبط العلاقة بين وتيرة الإصدارات ومنهجية العمل بالتفصيل في [Agile مقابل Waterfall الهجين](/ar/insights/salesforce-agile-waterfall-hybrid) وفي [دليل تنفيذ Salesforce](/ar/insights/salesforce-implementation-guide).

## تحديث البيئات وصيانتها

بيئة Sandbox لم يتم تحديثها لمدة تسعة أشهر لم تعد تمثل بيئة Production، وأي اختبار فيها يعطي ثقة زائفة. القاعدة البسيطة هي: تحديث بيئة UAT قبل كل إصدار مهم، وتحديث بيئات التطوير عند الانتهاء من كل دورة. من المهم التخطيط مسبقاً لما يضيع عند التحديث – بيانات الاختبار، المستخدمون، الإعدادات – والاحتفاظ بسكربت Post-Refresh يعيد استعادتها في غضون ساعة بدلاً من ثلاثة أيام.

## المخاطر الشائعة والإجراءات الوقائية

الخطر الأول هو الانجراف (Drift): الفروقات التي تتراكم بصمت بين Production و Repo. مقارنة البيانات الوصفية الأسبوعية الآلية مع إشعار هي الدفاع الوحيد الفعال.

الخطر الثاني هو اختبارات Apex التي كُتبت فقط لتجاوز عتبة التغطية. إن تغطية بنسبة 75% بدون تأكيدات (Assertions) حقيقية ليست شبكة أمان، بل تمنح ثقة زائفة بالضبط في اللحظة التي تتطلب فيها ثقة حقيقية. الخطر الثالث هو عنق الزجاجة البشري: شخص واحد فقط مُصرح له بالنشر. يجب أن يكون هناك اثنان على الأقل، مع صلاحيات موثقة.

## كيف نقيس النجاح؟

أربعة مقاييس: تكرار الإصدار، الوقت من الدمج إلى Production، نسبة عمليات النشر الفاشلة، وعدد الإصلاحات العاجلة (Hotfixes) في الشهر التالي لكل إصدار. يتحقق التحسن الحقيقي عندما: يرتفع التكرار، وينخفض الوقت، وتنخفض نسبة الفشل والإصلاحات العاجلة بالتوازي. أما الزيادة في التكرار مصحوبة بزيادة في الإصلاحات العاجلة فتعني أن المسار أسرع ولكن الاختبارات غير كافية.

### أسئلة وأجوبة
**كم عدد Sandboxes المطلوب حقًا؟**
الحد الأدنى العملي لمؤسسة متوسطة: Sandbox من نوع Developer لكل مطور، و Sandbox من نوع Developer Pro واحد للتكامل، و Sandbox إما Full أو Partial واحد لاختبار قبول المستخدم (UAT) واختبارات الحجم. يمكن لمؤسسة صغيرة الاكتفاء باثنين؛ بينما تحتاج المؤسسة التي تضم عدة فرق تعمل بالتوازي إلى Sandbox مخصص للإصلاحات العاجلة (Hotfix).

**هل الانتقال إلى Git والنشر التلقائي إلزامي؟**
ليس في اليوم الأول، ولكن نعم قبل أن يصبح هناك أكثر من شخصين يتعاملان مع البيانات الوصفية (Metadata). حتى ذلك الحين، تعد Change Sets كافية. بخلاف ذلك، بدون مصدر حقيقي للتعليمات البرمجية، لا توجد طريقة لمعرفة من غيّر ماذا، ولا يمكن التراجع بثقة.

**ماذا نفعل عندما يقوم شخص بتغيير شيء يدويًا في بيئة الإنتاج (Production)؟**
يتم الكشف عن ذلك من خلال مقارنة البيانات الوصفية أسبوعيًا، وإعادة التغيير إلى الفرع الرئيسي كالتزام موثق (documented Commit)، وإذا لم يكن مرغوبًا فيه – يتم التراجع عنه. ما لا يُطاق هو أن يظل التغيير موجودًا في الإنتاج وغير موجود في المستودع (Repo)، لأن النشر القادم سيلغيه عندها.

**هل يحتوي Full Sandbox على بيانات حقيقية وماذا عن اللوائح؟**
نعم، ولذلك يتطلب إخفاء البيانات (Data Masking) قبل منح وصول واسع. في البيئات التي تحتوي على معلومات شخصية، يعد إخفاء البيانات أو استخدام Partial Sandbox مع عينة تمثيلية هو الخيار الافتراضي الصحيح، وليس استخدام Full Sandbox بنسخة حية.

**كم من الوقت يستغرق إنشاء مسار DevOps أساسي؟**
من أربعة إلى ثمانية أسابيع: أسبوعان لهيكل المستودع (Repo) واستراتيجية الفروع، وأسبوعان للتكامل المستمر (CI) والاختبارات الآلية، والباقي للتطبيق في الفريق. الجزء البطيء دائمًا هو العادات، وليس الأدوات.

---

## Hypercare بعد إطلاق Salesforce: كيف تحقق الاستقرار دون خلق تبعية
URL: https://hpi.pro/ar/insights/salesforce-hypercare-plan
Hypercare ليس امتدادًا للمشروع، بل هو جسر مُخطط جيدًا نحو استمرارية العمل (BAU). هيكلة فترة الاستقرار تتضمن: تشكيل الفريق، اتفاقيات مستوى خدمة (SLA) مؤقتة، الفرز اليومي (Triage)، معايير خروج قابلة للقياس، ونقل ملكية منظم للفريق الداخلي.

## الإجابة المختصرة

إن مرحلة ما بعد الإطلاق (Go Live) ليست نهاية المشروع، بل هي المرحلة التي تتكشف فيها حقيقة ما تم بناؤه. فترة Hypercare هي فترة مخططة يظل فيها الفريق الذي أنشأ النظام متاحًا، ويعالج الفجوات بوتيرة سريعة، وفي نفس الوقت ينقل الملكية إلى الفريق الذي سيتولى صيانته.

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

## ما يميز هذه الفترة

| الجانب | Hypercare | العمليات الاعتيادية (BAU) |
| --- | --- | --- |
| قناة التواصل | مباشرة مع فريق المشروع + تواجد ميداني | طابور دعم اعتيادي |
| زمن الاستجابة لعطل يعيق العمل | حتى ساعة واحدة | حسب اتفاقية مستوى الخدمة (SLA) الجارية |
| وتيرة إصدار الإصلاحات | يوميًا أو كل يومين | دورة مجدولة |
| صلاحية اتخاذ القرار | مالك العملية متاح يوميًا | لجنة التغيير |
| التركيز | الاستقرار والإصلاح | التحسين والتطوير |

## الاجتماع اليومي للفرز هو جوهر العمل

اجتماع يومي لمدة 20 دقيقة كل صباح، في وقت ثابت، للإجابة على ثلاثة أسئلة: ما الذي تم فتحه أمس؟ ما الذي يعيق العمل الآن؟ وما الذي سيتم إطلاقه اليوم؟ يتم تصنيف كل استفسار إلى أربع فئات:

1.  **عطل يعيق العمل** — لا يمكن إتمام عملية تجارية. يتم معالجته فورًا.
2.  **فجوة في البيانات** — نتج عن الترحيل أو التكامل بيانات خاطئة. أولوية عالية لأنها تضعف الثقة.
3.  **فجوة في التدريب** — النظام يعمل كما هو مخطط له، لكن المستخدم لم يكن على دراية به. يتم تقديم إجابة فورية وتسجيل الحاجة لتعديل المواد التعليمية.
4.  **طلب تحسين** — يتم إضافته إلى قائمة المتطلبات المتأخرة (Backlog)، ولا يتم تنفيذه خلال هذه الفترة.

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

## تكوين الفريق والتواجد الميداني

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

ممثلون ميدانيون يرافقون الفريق هم شبكة الأبطال (Champions)، ولذلك يخضعون لتدريب مبكر ويحصلون على قناة اتصال مباشرة. تفاصيل إضافية متوفرة في [شبكة Champions على Salesforce](/ar/insights/salesforce-champions-network).

## معايير الخروج

الخروج من مرحلة Hypercare هو قرار قابل للقياس. مجموعة المعايير المقبولة:

*   صفر أعطال مفتوحة تعيق العمل لمدة خمسة أيام عمل متتالية.
*   انخفاض بنسبة 60% أو أكثر في حجم الاستفسارات اليومية مقارنة بذروة الأسبوع الأول.
*   معدل إنجاز العمليات الأساسية حسب الدور أعلى من الهدف المحدد.
*   المؤشرات الثلاثة الرئيسية لجودة البيانات ضمن النطاق المتفق عليه.
*   تعامل فريق الدعم الداخلي بشكل مستقل مع 80% من الاستفسارات في الأسبوع الأخير.

المعيار الأخير هو الفارق بين نقل الملكية الحقيقي والتخلي في تاريخ عشوائي. يعتمد القياس على نفس الإطار الموصوف في [مقاييس تبني Salesforce](/ar/insights/salesforce-adoption-metrics).

## نقل الملكية المنظم

يبدأ نقل الملكية من الأسبوع الأول وليس في اليوم الأخير. آلية بسيطة: اعتبارًا من الأسبوع الثاني، يتعامل فريق الدعم الداخلي مع الاستفسارات أولاً، ويقدم فريق المشروع الدعم من الخلف. يتم توثيق كل استفسار تم حله في قاعدة معرفية داخلية بثلاثة أسطر: الأعراض، السبب، الحل.

مخرجات نقل الملكية: وثيقة بنية (Architecture Document) محدثة، قائمة بالتكاملات مع نقاط الفشل المعروفة، إجراءات التشغيل الدورية، قائمة بالديون التقنية المتراكمة تحت الضغط، وأذونات الوصول والصلاحيات التشغيلية.

## الاعتماد على طريقة الإطلاق

في إطلاق Big Bang، تكون فترة Hypercare مكثفة وقصيرة نسبيًا، مع فريق كبير. في الإطلاق المرحلي، تتكرر هذه الفترة في كل مرحلة، ولكن بنطاق أصغر، ويتم التعلم من مرحلة إلى أخرى. هذا التداعيات هو أحد الاعتبارات عند اختيار الاستراتيجية، راجع [Big Bang أم Rollout مرحلي](/ar/insights/salesforce-big-bang-vs-phased-rollout).

## ما يتم عده كل أسبوع

حجم الاستفسارات اليومية حسب الفئة، متوسط زمن حل عطل يعيق العمل، نسبة الاستفسارات التي عالجها الفريق الداخلي، وعدد الديون التقنية المفتوحة. تقيس الثلاثة الأولى الاستقرار؛ أما الأخيرة فتمنع أن تترك الفترة ألغامًا.

## الخلاصة

خططوا لمرحلة Hypercare كمرحلة ذات ميزانية، فريق، اجتماع فرز يومي ومعايير خروج رقمية. صنفوا كل استفسار، لا تطوروا تحسينات خلال هذه الفترة، وانقلوا الملكية تدريجيًا بدءًا من الأسبوع الثاني. النظام المستقر ليس الذي لا يحتوي على أعطال، بل هو الذي تعرف المنظمة كيف تصلحه بنفسها.

### أسئلة وأجوبة
**ما هي المدة المثلى لفترة Hypercare؟**
تتراوح من أسبوعين إلى أربعة أسابيع للتطبيقات متوسطة الحجم، ومن ستة إلى ثمانية أسابيع للإطلاقات متعددة المواقع أو التي تتضمن ترحيلًا كبيرًا للبيانات. يتم تحديد مدة الفترة بناءً على معايير الخروج وليس فقط بناءً على تاريخ محدد.

**ما الفرق بين Hypercare والدعم المستمر؟**
في Hypercare، يكون الفريق الذي بنى النظام متاحًا بشكل مباشر، وتكون أوقات الاستجابة قصيرة للغاية، ويتم إطلاق الإصلاحات بشكل شبه فوري. في استمرارية العمل (BAU)، تمر الطلبات عبر قائمة دعم عادية مع دورة إطلاق مجدولة.

**من يجب أن يكون ضمن فريق Hypercare؟**
مطور أو مسؤول نظام (Admin) على دراية بالتنفيذ، مالك العملية التجارية المخول باتخاذ القرارات المتعلقة بالمحتوى، ممثل ترحيل البيانات خلال الأسبوعين الأولين، ومنسق يدير الفرز اليومي (Triage).

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

**ماذا نفعل بطلبات التحسينات خلال فترة Hypercare؟**
يتم تسجيلها في قائمة المهام (Backlog) ولا يتم تنفيذها. Hypercare مخصص للأعطال والعوائق فقط؛ فتنفيذ التحسينات خلال هذه الفترة يقوض الاستقرار الذي صممت لتحقيقه.

---

## User Stories و Backlog في مشروع Salesforce: دليل لمديري العمليات
URL: https://hpi.pro/ar/insights/salesforce-user-stories-backlog
يفشل Backlog مشروع Salesforce غالبًا في نفس النقطة: قصص تصف الشاشة بدلًا من النتيجة، ومعايير قبول تُكتب بعد التطوير. يقدم الدليل هيكل قصة قابل للاختبار، ومنهجية تقسيم عبر Vertical Slice، وتحديد أولويات يبقى ثابتًا حتى مع تزايد الضغط.

## الخلاصة

السرد الفعال في Salesforce يصف بوضوح **من هو المستخدم، وماذا يسعى لتحقيقه، وما هو الوضع الصحيح بعد الإجراء** – لا يحدد أي حقل يظهر في أية شاشة. الاختبار البسيط: إذا أمكن كتابة معايير القبول دون معرفة ما إذا كان التنفيذ سيكون عبر Flow أو Validation Rule أو Apex، فإن السرد قد صيغ بشكل صحيح.

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

## هيكل فعال

| المكون | وظيفته | معيار الجودة |
|---|---|---|
| السياق | من هو المستخدم ومتى يكون موجودًا | دور حقيقي، وليس مجرد "مستخدم" |
| القصد | ما الذي يحاول تحقيقه | يُصاغ بلغة العمل |
| معايير القبول | ما الذي يتم اختباره | يمكن تنفيذه كسيناريو ببيانات اختبار |
| حالات الحافة | ما الذي يفشل عن قصد | على الأقل حالة سلبية واحدة |
| خارج النطاق | ما هو غير متضمن صراحة | يمنع الجدل عند القبول |

السطر الأخير يوفر معظم النزاعات. تصريح صريح بأن ما لم يتم تضمينه غير متضمن يساوي أكثر من ثلاث فقرات وصفية.

## التفكيك: شريحة عمودية وليس طبقات

الإغراء في مشاريع CRM هو التفكيك بناءً على المكونات التقنية – أولاً نموذج البيانات، ثم الأتمتات، وأخيراً التقارير. النتيجة هي أنه لا يوجد شيء لعرضه حتى النهاية، ولا أحد يعرف ما إذا كانت العملية تعمل.

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

## تحديد الأولويات عندما يكون كل شيء عاجلاً

ثلاثة معايير كافية، بهذا الترتيب:

1.  **هل يمنع الإطلاق؟** – بدونه، العملية ليست كاملة. لا يوجد مجال للمساومة.
2.  **كم عدد المستخدمين يوميًا؟** – التكرار يتجاوز شدة الشكوى. بند يؤثر على 80 مندوبًا يوميًا يسبق طلب مدير واحد.
3.  **ما هي تكلفة التأجيل؟** – هل تزيد تكلفة التنفيذ إذا قمنا به بعد الإطلاق؟ تغيير في نموذج البيانات نعم، تغيير في تقرير لا.

ما لا يجتاز هذه المعايير الثلاثة ينتقل إلى Waiting List. هذا الفصل يمنع تراكم المهام الذي يتحول إلى أرشيف للأمنيات. المزيد حول إدارة تغيير النطاق متاح في دليل [Scope Creep وضبط التغييرات](/ar/insights/salesforce-scope-creep-change-control).

## دين المتطلبات: الفشل الصامت

يتكون دين المتطلبات عندما يتم إغلاق قصة دون اتخاذ قرار بشأن ما يحدث في حالة الحافة – يظل "سنتعامل مع ذلك لاحقًا". بعد الإطلاق، تصبح حالات الحافة هذه هي غالبية طلبات الدعم.

الضابط البسيط: لا يُغلق بند دون قرار موثق لكل سؤال مفتوح مسجل فيه، حتى لو كان القرار هو "لا تتم معالجته عن عمد". توثيق التنازل يساوي أكثر من عدم وجود توثيق.

## العلاقة مع الاختبارات

معايير القبول المكتوبة بشكل صحيح هي في الواقع سيناريوهات UAT. عندما تُكتب بعد التطوير، يتحول UAT إلى عرض لما تم بناؤه بدلاً من اختبار ما هو مطلوب. التسلسل مفصل في [دليل UAT](/ar/insights/salesforce-uat-guide).

## الملخص

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

### أسئلة وأجوبة
**ما مدى التفصيل المطلوب للقصة قبل البدء في البناء؟**
يجب أن تكون مفصلة بما يكفي ليَعرف المطور ما الذي سيتم بناؤه ويَعرف المختبر ما الذي سيفشل. إذا لم تكن معايير القبول قابلة للتنفيذ كسيناريو، فالقصة ليست جاهزة بعد - حتى لو كانت طويلة.

**من يكتب معايير القبول؟**
مدير العملية يصوغ ما سيعتبر نجاحًا، ويضيف المختبر أو المهندس المعماري الحالات الهامشية. الكتابة من قبل المطور وحده تنتج معيارًا يصف ما تم بناؤه، وليس ما هو مطلوب.

**ماذا نفعل بخصوص متطلب هو في الأساس سؤال مفتوح؟**
هذا ليس قصة بل Spike - مهمة استكشافية محددة بوقت، ونتيجتها قرار موثق. يساهم خلط الاستكشاف والبناء في نفس العنصر في إخفاء المخاطر في التقدير.

**هل نحتاج إلى Story Points في Salesforce؟**
التقييم النسبي يساعد بشكل خاص في الكشف عن عدم الاتفاق على النطاق. لا تكمن القيمة في دقة الرقم، بل في النقاش الذي ينشأ عندما تكون التقديرات متباعدة.

**كيف نمنع تضخم Backlog ليحتوي على ألف عنصر؟**
قيد العمق: سيتم نقل ما لم تتم مراجعته للربع القادم إلى منطقة انتظار منفصلة (Parking Lot). فـ Backlog الذي لا يراجعه أحد بالكامل لم يعد أداة لتحديد الأولويات بل أصبح أرشيفًا.

---

## تفشي النطاق (Scope Creep) في مشاريع Salesforce: كيف تدير التغيير دون شل المشروع
URL: https://hpi.pro/ar/insights/salesforce-scope-creep-change-control
لا ينبع تفشي النطاق (Scope Creep) من كثرة الطلبات، بل من غياب آلية تسعيرها في الوقت الفعلي. يقدم هذا الدليل خط أساس (Baseline) ثابتًا، ونموذج طلب تغيير (Change Request) موجزًا، ومجلس تغييرات يجتمع أسبوعيًا، وميزانية تغيير مخصصة مسبقًا – ليمكنك قول 'نعم' دون المساس بالموعد النهائي.

## الإجابة المختصرة

ينشأ "Scope Creep" (تضخم النطاق) عندما لا يكون هناك فارق واضح بين ما تم التعهد به وما تم بناؤه. تعالج هذه المشكلة ثلاث آليات: خط الأساس الموثق (Baseline) الذي يراه الجميع، ونموذج طلب تغيير (Change Request) من نصف صفحة يتضمن تقديرًا للجهد، وقاعدة استبدال تنص على أن كل إضافة تدفع شيئًا ذا حجم مماثل خارج النطاق أو تستهلك ميزانية تغيير مخصصة مسبقًا. بدون هذه الآليات الثلاث، يختفي كل "طلب صغير" داخل السبرنت ولا يكتشف إلا في الموعد النهائي.

## لماذا يحدث هذا في Salesforce بالتحديد؟

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

## إطار تحكم من أربعة مكونات

| المكون | ما يتضمنه | المسؤول | المنتج |
|---|---|---|---|
| خط أساس مجمد | قائمة القدرات، السيناريوهات، و"خارج النطاق" الصريح | مالك المنتج (Product Owner) | وثيقة موقعة في نهاية مرحلة الاكتشاف (Discovery) |
| طلب التغيير | الوصف، الدافع التجاري، تقدير الجهد، التأثير على التاريخ | الُمقدم + القائد التقني (Tech Lead) | نموذج من نصف صفحة |
| مجلس التغييرات | اجتماع أسبوعي لمدة 30 دقيقة لمناقشة جميع الطلبات المفتوحة | الراعي (Sponsor)، مالك المنتج، القائد التقني | قرار: معتمد / مرفوض / للموجة التالية |
| ميزانية التغيير | 10%–20% من النطاق، تخصص في بداية المشروع | الراعي | تتبع الرصيد الأسبوعي |

## قوة "خارج النطاق" الصريح

أهم بند في وثيقة خط الأساس ليس ما هو مشمول، بل ما هو صراحة غير مشمول. جمل مثل "تكامل نظام الرواتب غير مشمول في الموجة الأولى" أو "ترحيل النشاط قبل عام 2022 غير مشمول" توفر أسابيع من الجدال. القاعدة: كل ما قد يفترض صاحب المصلحة خطأً أنه مشمول – يجب أن يظهر في قائمة الاستثناءات باسمه الكامل.

## كيف تقول "نعم" دون أن تدفع ثمن ذلك

الرفض المطلق يؤدي إلى مشروع ينتهي في الوقت المحدد ولكن لا يستخدمه أحد. النهج الفعال هو قبول كل طلب في مستودع، وتسعيره بشفافية، وترك الخيار لصاحب المصلحة: إما أن يدخل الآن على حساب بند آخر، أو ينتظر الموجة التالية، أو يستهلك من ميزانية التغيير. عندما يكون الخيار شفافًا، ينتقل النقاش من العاطفي إلى الاقتصادي – وعملياً، يتخلى حوالي ثلث الطلبات بمجرد رؤية السعر.

توسع حول تعريف خط الأساس متاح في [تعريف MVP](/ar/insights/salesforce-mvp-scope) وفي [Discovery لـ CRM](/ar/insights/crm-discovery-guide).

## المخاطر الشائعة والإجراءات الوقائية

الخطر الرئيسي هو التحكم المفرط. عملية تتطلب ثلاثة نماذج وأسبوعين من الانتظار تدفع الفرق لتجاوزها – وتستمر التغييرات، ولكن بدون توثيق. نصف صفحة ونقاش أسبوعي هما السقف العملي.

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

## كيف نقيس النجاح

تتم متابعة أربعة أرقام في تقرير أسبوعي: عدد الطلبات المفتوحة، النسبة المئوية المعتمدة، التغيير التراكمي في النطاق مقارنة بخط الأساس، والرصيد المتبقي من ميزانية التغيير. يُظهر المشروع الصحي تغييرًا تراكميًا يصل إلى 15% ورصيد ميزانية إيجابي في مرحلة UAT. يشير التغيير التراكمي الذي يزيد عن 30% إلى أن مرحلة الاكتشاف (Discovery) كانت سطحية جدًا، وليس أن الفريق غير منضبط.

### أسئلة وأجوبة
**ما الفرق جوهريًا بين تفشي النطاق (Scope Creep) والتعلم المشروع؟**
التعلم يغير الحل ضمن نفس النتيجة التجارية (Outcome)، بينما تفشي النطاق (Scope Creep) يضيف نتيجة جديدة دون تغيير تاريخ أو ميزانية. الاختبار العملي: إذا كان الطلب نابعًا مما تم اكتشافه في مرحلة الاستكشاف (Discovery) أو اختبار قبول المستخدم (UAT)، فهو تعلم. أما إذا كان نابعًا من قسم انضم متأخرًا، فهو توسيع للنطاق.

**كم يجب تخصيص من ميزانية التغيير مسبقًا؟**
بين 10% إلى 20% من إجمالي ميزانية المشروع، اعتمادًا على مستوى عدم اليقين. مشروع ذو مرحلة استكشاف (Discovery) معمقة وعمليات معروفة قد يكتفي بـ 10%؛ أما مشروع يتضمن عدة وحدات أعمال أو ترحيلًا من نظام غير موثق، فيتطلب ما يقرب من 20%.

**من المخول بالموافقة على التغيير؟**
يوافق مالك المنتج (Product Owner) على الاستبدال ضمن خط الأساس (Baseline) دون تغيير في التاريخ والتكلفة. يوافق المسؤول التنفيذي (Sponsor) على أي شيء يغير التاريخ أو الميزانية أو النتيجة (Outcome). التسلسل الواضح للسلطة هو الدفاع الأكثر فعالية ضد تفشي النطاق (Scope Creep).

**ماذا نفعل عندما يدعي المورد 'هذا ليس ضمن العرض'؟**
نتحقق من بيان العمل (SOW) ومن وثائق مرحلة الاستكشاف (Discovery). إذا كان الأمر حقًا توسيعًا، يتم تسعيره كتغيير؛ وإذا كان فجوة ناجمة عن تعريف غامض في العرض، فهي مسؤولية مشتركة. توثيق الافتراضات في العقد هو ما يمنع هذا النقاش من الأساس.

**هل تلغي منهجية Agile الحاجة إلى التحكم في التغييرات؟**
لا. تسمح Agile بتبديل العناصر في قائمة المهام المتراكمة (Backlog) بسهولة، لكن الميزانية والتواريخ النهائية تظل ثابتة. التحكم في التغييرات في Agile هو قاعدة الاستبدال – كل عنصر يدخل يدفع عنصرًا مشابهًا في الحجم إلى الخارج.

---

## Agile أم Waterfall أم Hybrid في مشروع Salesforce؟ اختيار نموذج التسليم
URL: https://hpi.pro/ar/insights/salesforce-agile-waterfall-hybrid
الجدال حول المنهجية في مشروع Salesforce غالبًا ما يدور حول أمور أخرى: كم من القرارات يمكن تأجيلها، والوقت المتاح فعليًا للمستخدمين. يحلل هذا الدليل عملية الاختيار إلى ثلاثة متغيرات حاسمة ويصف النموذج الهجين الذي تتبناه معظم المؤسسات عمليًا.

## الإجابة المختصرة

الاختيار ليس بين منهجيتين، بل بين نوعين من القرارات. هناك قرارات تزداد تكلفة تغييرها بشكل حاد مع مرور الوقت – مثل نموذج البيانات، والصلاحيات، والتكاملات – ويجب تثبيتها مبكرًا. وهناك قرارات تكون تكلفة تغييرها منخفضة – مثل الشاشات، والحقول، والتقارير، والصياغات – ويفضل اكتشافها تدريجيًا.

لذا، فإن النموذج المتبع في معظم مشاريع Salesforce هو نموذج هجين ليس من باب التسوية ولكن بحكم الهيكلية: **إطار عمل ثابت، ومحتوى تكراري**.

## المتغيرات الثلاثة الحاسمة

| المتغير | يدفع نحو التخطيط المسبق | يدفع نحو التكرارات |
| --- | --- | --- |
| وضوح العملية | عملية منظمة وموثقة | عملية متغيرة أو غير متفق عليها |
| توفر المستخدمين | منخفض، وقت محدود | مرتفع، يمكن المراجعة أسبوعيًا |
| التعرض التنظيمي | تدقيق، امتثال، موافقات | الحد الأدنى |

المتغير الثاني أكثر أهمية مما هو مفترض. منهجية Agile بدون توفر المستخدمين ليست Agile – إنها سلسلة من السبرنتات التي في نهايتها لم يقم أحد بالمراجعة، وتأتي جميع الملاحظات دفعة واحدة في اختبار قبول المستخدم (UAT).

## النموذج الهجين في الممارسة العملية

النهج الفعال يقسم المشروع إلى جزأين بوتيرة مختلفة:

**مرحلة الإطار (4-6 أسابيع، تخطيطية)** – نموذج البيانات، نموذج الصلاحيات والرؤية، تخطيط التكاملات، استراتيجية ترحيل البيانات، وتحديد العمليات التي ستدخل في الدفعة الأولى. يتم توثيق مخرجات هذه المرحلة والموافقة عليها.

**دفعات التسليم (سبرنتات لمدة أسبوعين)** – يقدم كل دفعة سيناريو كاملاً لملف تعريف المستخدم، بما في ذلك الاختبار والملاحظات. التغييرات ضمن الدفعة لا تتطلب إعادة موافقة ما دامت لا تمس الإطار العام.

القاعدة التي تحكم ذلك: **تغيير في الإطار هو قرار إداري، وتغيير في المحتوى هو عمل مستمر**. بدون هذا التمييز، سيصل كل طلب صغير إلى اللجنة التوجيهية، ويمر كل تغيير هيكلي دون رقابة.

## أين ينكسر كل نموذج

**نموذج Waterfall النقي** ينكسر في UAT: الفجوة بين ما كُتب في المستند قبل ستة أشهر وما يتوقعه المستخدم تظهر متأخرة جدًا بحيث لا يمكن إصلاحها بتكلفة منخفضة.

**نموذج Agile النقي** ينكسر في نموذج البيانات: بعد ستة سبرنتات من القرارات المحلية، يتضح أن الهيكل لا يدعم إعداد التقارير عبر العمليات، ويتطلب الإصلاح ترحيل بيانات.

**النموذج الهجين** ينكسر عندما لا يتم إغلاق الإطار بشكل فعال – عندما يكون "إطارًا" بالاسم ولكنه يُفتح من جديد في كل دفعة. حينها، نتحمل عيوب كلا النموذجين.

## ما يجب قياسه على طول الطريق

تكفي ثلاثة مقاييس لمعرفة ما إذا كان النموذج يعمل: النسبة بين العناصر المكتملة والعناصر التي أعيد فتحها، الوقت المستغرق من تلقي ملاحظات المستخدم حتى الإصلاح، وعدد التغييرات التي مست الإطار. الزيادة في المقياس الثالث هي العلامة المبكرة على أن التخطيط المسبق كان سطحيًا. يمكن الاطلاع على العلاقة بإدارة النطاق في [Scope Creep وضبط التغييرات](/ar/insights/salesforce-scope-creep-change-control) والجداول الزمنية في [الجدول الزمني لمشروع Salesforce](/ar/insights/salesforce-project-timeline).

## الملخص

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

### أسئلة وأجوبة
**هل يمكن تنفيذ Agile حقيقي عندما تكون الميزانية معتمدة مسبقًا كسعر ثابت؟**
نعم، بشرط أن يحدد العقد النتائج وليس قائمة بالمخرجات. السعر الثابت مقابل قائمة مفتوحة من المهام (Backlog) يخلق توترًا داخليًا حيث يصبح أي تغيير نقاشًا تجاريًا بدلًا من كونه نقاشًا مهنيًا.

**ما الذي يبقى Waterfall حتى في مشروع Agile؟**
نموذج البيانات، وهيكلية الصلاحيات، وتخطيط التكاملات. هذه العناصر الثلاثة مكلفة جدًا للتغيير في مراحل متأخرة، ولذلك يتم حسمها مبكرًا حتى عندما تكون باقي العناصر تكرارية.

**ما هي المدة المناسبة لـ Sprint في مشروع Salesforce؟**
أسبوعان في معظم الحالات. أسبوع واحد لا يكفي للتكوين، والاختبار، والتغذية الراجعة؛ وثلاثة أسابيع تبعد التغذية الراجعة لدرجة يجعل تصحيح الأخطاء مكلفًا.

**ماذا نفعل عندما لا يتوفر المستخدمون للمراجعات؟**
نقلص مدة المراجعة إلى 30 دقيقة ونضيف قرارًا موثقًا: ما لم تتم مراجعته خلال هذا الوقت يعتبر معتمدًا. عدم التوفر الذي لا يتم التعامل معه يتحول لاحقًا إلى ادعاء 'لم نطلب هذا'.

**هل تمنع لوائح التنظيم (الرجولة) منهجية Agile؟**
لا. هي تتطلب التوثيق والموافقات في نقاط محددة، وهذا يتوافق مع التكرارات طالما أن بوابة الموافقة محددة سلفًا ولا تُضاف في المنتصف.

---

## نهج Big Bang أم Rollout المرحلي في تطبيق Salesforce؟
URL: https://hpi.pro/ar/insights/salesforce-big-bang-vs-phased-rollout
يعتمد قرار اعتماد أي من النهجين على ترابط البيانات والعمليات، وليس على الأفضلية المنهجية. نقدم إطارًا للاختيار بين الإطلاق الشامل والإطلاق المرحلي — بما في ذلك تكلفة التعايش (Coexistence)، ومخاطر الترحيل (Migration)، وجدول اتخاذ القرار حسب نوع المؤسسة.

## الإجابة المختصرة

غالبًا ما يُطرح النقاش بين تنفيذ Big Bang والاطلاق المرحلي كمسألة مخاطر، ولكنه في الأساس مسألة تبعية. إذا كانت وحدتان تتقاسمان نفس السجل ونفس العملية، فإن تقسيمهما إلى موجات مختلفة يخلق فترة انتقالية مكلفة وعرضة للأخطاء. أما إذا كانت الوحدات مستقلة، فلا يوجد سبب لإطلاقها جميعًا في وقت واحد.

القاعدة العملية: **أولاً، حدد التبعيات، ثم اختر الاستراتيجية.**

## لمحة موجزة عن المقاربتين

يقوم إطلاق Big Bang بنشر جميع الوحدات في تاريخ واحد. الميزة هي الانتهاء السريع، ومصدر وحيد للحقيقة من اليوم الأول، وتكلفة صفرية للفترة الانتقالية. العيب هو تركيز المخاطر: أي خطأ يؤثر على الجميع في نفس اللحظة، والتعافي معقد.

ينشر الاطلاق المرحلي وحدة أو عملية في كل موجة. الميزة هي التعلم من موجة إلى أخرى، ومخاطر محدودة، وفريق يتحسن. العيب هو فترة مشروع أطول، وإرهاق تنظيمي، وفترة طويلة تعمل فيها نظامان بالتوازي.

## تحديد التبعيات – الاختبار الحاسم

| السؤال | الإجابة التي تؤدي إلى Big Bang | الإجابة التي تؤدي إلى موجات |
| :-- | :-- | :-- |
| هل تتم معالجة نفس السجل في وحدتين؟ | نعم، بشكل روتيني | لا، بتكلفة واضحة |
| هل تمر العملية بين الأقسام؟ | نعم، من البداية إلى النهاية | عمليات منفصلة |
| هل يجمع التقرير الإداري بينها كلها؟ | نعم، يوميًا | تقرير على مستوى الوحدة |
| هل يمكن المزامنة ثنائية الاتجاه بتكلفة معقولة؟ | لا | نعم |
| هل تشترك الوحدات في نفس كتالوج المنتجات والتسعير؟ | نعم | لا |

ثلاث إجابات أو أكثر في العمود الأيسر – التجزئة إلى موجات ستكلف أكثر مما توفره.

## تكلفة التعايش

هذا هو البند الذي يحسم العديد من القرارات، ومع ذلك يتم نسيانه في التخطيط. تشمل الفترة الانتقالية: المزامنة ثنائية الاتجاه بين Salesforce والنظام القديم، وإنشاء تقارير موحدة من مصدرين، ودعم بيئتين، وتدريب مزدوج للمستخدمين الذين يعملون مع كليهما، ومعالجة تعارضات التحديث.

يتراوح التقدير الواقعي بين 10% و 25% من ميزانية المشروع، ويزداد كلما طالت الفترة. إذا كانت الخطة تتضمن عامًا من التعايش، فيجب دراسة ما إذا كان تقصير هذه الفترة يستحق المخاطر الإضافية للإطلاق الأوسع.

## مخاطر ترحيل البيانات في كل مقاربة

في Big Bang، يكون ترحيل البيانات حدثًا واحدًا وكبيرًا في نافذة زمنية قصيرة. يتطلب هذا تكرارات كاملة (Mock Cutover) وخطة استرجاع مثبتة. في الاطلاق المرحلي، يتكرر ترحيل البيانات في كل موجة، ولكن بنطاق أصغر – وفي كل مرة يجب تحديد ما يحدث للسجلات التي تلامس وحدات لم يتم نشرها بعد.

في كلتا الحالتين، جودة البيانات هي العامل الحاسم في يوم الاطلاق. التفاصيل التخطيطية موجودة في [دليل تنفيذ Salesforce](/ar/insights/salesforce-implementation-guide).

## مصفوفة القرار حسب نوع المنظمة

| السياق | التوصية | السبب الرئيسي |
| :-- | :-- | :-- |
| حتى 150 مستخدمًا، عملية موحدة | Big Bang | تكلفة التعايش تتجاوز المخاطر |
| مواقع أو دول متعددة | موجات حسب الموقع | اختلافات تنظيمية وعملياتية |
| أقسام متعددة ذات عملية مشتركة | جوهر مشترك ثم موجات | يمنع المزامنة ثنائية الاتجاه |
| تاريخ نهائي ثابت لعقد قائم | Big Bang بنطاق محدود | لا يوجد وقت للفترة الانتقالية |
| منظمة ليس لديها خبرة سابقة في Salesforce | موجة أولى صغيرة | بناء القدرات الداخلية |
| ترحيل بيانات معقد من مصادر متعددة | موجات |D_2 توزيع مخاطر البيانات |

## المقاربة الهجينة التي تعمل في الواقع

تجمع معظم عمليات تنفيذ Salesforce الكبيرة الناجحة بين: طبقة أساسية موحدة – نموذج البيانات، العملاء، الأذونات، التقارير الأساسية – يتم إطلاقها للمؤسسة بأكملها في وقت واحد؛ وفوقها موجات حسب الوحدة للعمليات المحددة. يمنع هذا المزامنة ثنائية الاتجاه للبيانات المشتركة، ومع ذلك يحافظ على التعلم التدريجي.

يعد اختيار النطاق الأدنى للموجة الأولى قرارًا بحد ذاته، ويتم تفصيله في [تحديد MVP في Salesforce](/ar/insights/salesforce-mvp-scope). في المؤسسات الكبيرة، تكون الآثار أوسع وتناقش في [تنفيذ Salesforce في المؤسسات الكبيرة](/ar/insights/enterprise-salesforce-implementation).

## الآثار على فترة الاستقرار

تحدد الاستراتيجية أيضًا هيكل دعم Hypercare: في Big Bang، يلزم فريق كبير لفترة مكثفة وقصيرة؛ في الموجات، يلزم فريق صغير يعود في كل موجة وتتراكم لديه المعرفة. في كلتا الحالتين، تتطلب معايير خروج محددة، كما هو مفصل في [Hypercare بعد Go Live](/ar/insights/salesforce-hypercare-plan).

## الخلاصة

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

### أسئلة وأجوبة
**ما هو العامل الحاسم في الاختيار بين النهجين؟**
مدى الاعتماد المتبادل بين الوحدات. عندما تمر عملية واحدة عبر أقسام متعددة ويتم التعامل مع نفس السجل فيها، فإن التقسيم إلى مراحل يتطلب مزامنة ثنائية الاتجاه باهظة الثمن، وفي بعض الأحيان يرجح كفة نهج Big Bang.

**كم تبلغ تكلفة فترة التعايش (Coexistence)؟**
عادة ما تتراوح بين 10% إلى 25% من ميزانية المشروع: مزامنة ثنائية الاتجاه، ازدواجية التقارير، دعم نظامين، وارتباك المستخدمين. هذا هو البند الذي غالبًا ما يتم التقليل من تقديره عند اتخاذ قرار الإطلاق المرحلي.

**هل يجب أن يكون الفريق الأكبر هو ضمن المرحلة الأولى؟**
لا. يجب أن تكون المرحلة الأولى وحدة تمثل جزءًا كافيًا للتعلم منها، ولكنها صغيرة بما يكفي للتعافي من الأخطاء. وحدة تتكون من 20 إلى 50 مستخدمًا مع عملية كاملة تعتبر خيارًا جيدًا.

**متى يكون نهج Big Bang هو الخيار الصحيح؟**
عندما يتعلق الأمر بمؤسسة تضم ما يصل إلى 150 مستخدمًا، عملية موحدة، ترحيل يمكن التحكم فيه، وتاريخ محدد ينجم عن انتهاء عقد نظام سابق. في هذه الظروف، تتجاوز تكلفة التعايش مخاطر الإطلاق.

**هل يمكن الجمع بين النهجين؟**
نعم، وهذا هو الخيار الشائع عمليًا: إطلاق Core موحد للمؤسسة بأكملها دفعة واحدة، يليه إطلاق مراحل حسب الوحدة للمكونات والعمليات الفريدة.

---

## عائد الاستثمار (ROI) لمشروع Salesforce: كيف تُحدّد وتقيس القيمة الحقيقية؟
URL: https://hpi.pro/ar/insights/salesforce-roi-kpis
غالبًا ما تُكتب معظم حسابات عائد الاستثمار لمشاريع CRM مرة واحدة فقط، ضمن شريحة الموافقة على الميزانية، ثم تُهمل. يقدم هذا الدليل هيكلًا مختلفًا: أربعة أنواع من القيمة تُقاس بطرق مختلفة، وخط أساس (Baseline) يُحدد قبل الإطلاق، وقواعد إسناد لمنع نسب أي تحسين تجاري للنظام.

## الإجابة المختصرة

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

القاعدة العملية: يتم قياس ستة مؤشرات كحد أقصى، لكل منها خط أساس (Baseline) يتم جمعه قبل بدء التشغيل، ومالك لا يكون هو نفسه من بنى النظام، وهو المسؤول عن التقارير.

## تدفقات القيمة الأربعة

| التدفق | مثال على المؤشر | متى يُقاس | مستوى اليقين |
|---|---|---|---|
| الكفاءة التشغيلية | دقائق التعامل مع الاستفسار، وقت إعداد العرض | الربع الأول | مرتفع |
| الإيرادات | نسبة الفوز (Win Rate)، متوسط حجم الصفقة، دورة المبيعات | 2-3 دورات مبيعات | متوسط |
| المخاطر والامتثال | نتائج التدقيق، التعرض للمخاطر في الأذونات | سنوياً | منخفض كمياً، مرتفع التأثير |
| تكلفة الأنظمة | التراخيص الملغاة، الواجهات المزالة | فور الإيقاف | مرتفع جداً |

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

## خط الأساس (Baseline): النقطة التي تحدد إمكانية القياس من الأساس

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

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

## قاعدة الإسناد

بعد الإطلاق الناجح، يكون هناك إغراء لربط كل تحسن بالنظام. تقوم ثلاثة فلاتر بالحد من ذلك:

1.  **فلتر السببية** - هل توجد آلية مفهومة تربط التغيير في النظام بالتغيير في المؤشر؟ إذا لم يكن كذلك، فهذه مجرد علاقة ارتباط (Correlation).
2.  **فلتر المجموعة التجريبية** - هل تظهر مجموعة لم يتم انتقالها بعد نفس الاتجاه؟ إذا كان الأمر كذلك، فالسبب خارجي.
3.  **فلتر الحجم** - هل ارتفع المؤشر أم ارتفعت وتيرة النشاط؟ تطبيع المؤشر حسب الحجم يزيل معظم الأوهام.

من يستعد للإعلان "هذا التحسن ليس من عملنا" يكسب الثقة حتى عندما يدعي تحسناً يعود إليه.

## جانب التكلفة: ما يُغفل من الحساب

تكلفة المشروع ليست سعر العقد. يشمل الحساب الكامل الترخيص على مدار ثلاث سنوات، ونسبة صيانة وتغييرات سنوية (في الواقع 15%-25% من تكلفة التركيب)، والوقت الداخلي للموظفين في الاجتماعات، واختبار القبول من المستخدم (UAT)، والتدريب، وتكلفة التشغيل المتوازي خلال الفترة الانتقالية.

الحساب الذي يتجاهل بند الصيانة يعرض عائداً سريعاً في السنة الأولى وخسارة في الثانية. تظهر تفاصيل هياكل التكلفة في [تكلفة تنفيذ Salesforce](/ar/insights/salesforce-implementation-cost).

## ماذا يُقاس في الربع الأول

في الربع الأول، لا توجد قيمة أعمال قابلة للقياس الملموس بعد، ولذلك تُقاس المؤشرات الرئيسية (Lead Indicators) بدلاً من النتائج: نسبة العمليات التي تتم داخل النظام بدلاً من خارجه، جودة البيانات في الحقول التي تُدخل في التقارير، وعدد طلبات التغيير التي تشير إلى فجوة إجرائية. هذه الثلاثة تتنبأ بما إذا كانت القيمة ستتحقق أم لا. تظهر مؤشرات التبني المفصلة في [مقاييس تبني Salesforce](/ar/insights/salesforce-adoption-metrics).

## الخلاصة

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

### أسئلة وأجوبة
**متى يجب قياس خط الأساس (Baseline)؟**
قبل أن يلامس النظام الجديد العملية - عادةً في مرحلة الاكتشاف (Discovery). خط الأساس الذي يُجمع بعد الإطلاق يكون ملوثًا بتغيير السلوك ولا يُستخدم للمقارنة.

**كيف نميز بين تأثير النظام وتأثير السوق؟**
بثلاث طرق: المقارنة بمجموعة تحكم لم تشهد التغيير بعد، التطبيع بناءً على حجم النشاط، والتركيز على مقاييس العملية (وقت الدورة، معدل اللمس المتكرر) الأقل حساسية لتقلبات الطلب.

**هل توفير وقت الممثل يُعد عائد استثمار (ROI)؟**
فقط إذا خُصص الوقت المتوفر لنشاط قابل للقياس أو إذا منع توفير هذا الوقت توظيفًا إضافيًا. عشر دقائق يوميًا لممثل يبقى في نفس الدور وبنفس الإنتاجية لا تُشكل توفيرًا في التدفق النقدي.

**ما هو النطاق الزمني المعقول لاسترداد الاستثمار؟**
في مشروع متوسط الحجم، تتحرك مقاييس العملية في غضون ربع سنة، ومقاييس الإيرادات خلال دورتين إلى ثلاث دورات مبيعات، وعادةً ما يُقاس الاسترداد النقدي الكامل على مدى 18 إلى 30 شهرًا، بما في ذلك تكلفة التشغيل المستمرة.

**ماذا يشمل جانب التكلفة الذي تنساه معظم المؤسسات؟**
التراخيص المستمرة، والصيانة والتغييرات بعد الإطلاق، والوقت الداخلي للموظفين في المشروع والتدريب، وتكلفة التكاملات التي تستمر في طلب الصيانة. تجاهل هذه الجوانب يُنتج عائد استثمار يبدو جيدًا على الورق فقط.

---

## طلب تقديم العروض (RFP) لتنفيذ Salesforce: الهيكل والأسئلة والنتائج الأساسية
URL: https://hpi.pro/ar/insights/salesforce-rfp-guide
يؤدي طلب تقديم العروض (RFP) الذي يسرد المتطلبات إلى تلقي قائمة من الوعود. بدلاً من ذلك، تصف وثيقة RFP الجيدة العمليات والأحجام والقرارات المفتوحة، وتُلزم كل مُورِّد بإظهار طريقة تفكيره. نُقدم هنا هيكل وثيقة من تسعة أجزاء، والأسئلة التي تميز بين الموردين، وما يجب أن تطلبه كنتيجة في العرض.

## ما الذي يجب أن يحققه طلب تقديم العروض الجيد (RFP)

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

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

## الأجزاء التسعة لوثيقة RFP خاصة بـ Salesforce

**1. الخلفية والهدف التجاري.** ما الذي تفعله المنظمة، ما هي المشكلة، وما الذي سيعتبر نجاحًا بعد عام واحد. فقرة إلى صفحة واحدة.

**2. الوضع الحالي.** الأنظمة المستخدمة، عدد المستخدمين، ما الذي يعمل حاليًا وما الذي لا يعمل. إذا كانت بيئة Salesforce موجودة، اذكروا الإصدار، عمرها، ومستوى التخصيص.

**3. العمليات الأساسية ضمن النطاق.** من ثلاث إلى سبع عمليات، كل منها في فقرة: من يقوم بالتنفيذ، ما هي نقاط القرار، وماذا يحدث عندما ينحرف شيء ما.

**4. الحجوم والبيانات.** عدد السجلات في كل كيان رئيسي، معدل الإنشاء الشهري، سنوات التاريخ التي يجب الاحتفاظ بها، وحالة الجودة المعروفة. هذا هو الجزء الأكثر تأثيرًا على دقة التسعير والأكثر عرضة للإهمال.

**5. التكاملات.** لكل نظام: الاسم، نوع الواجهة إذا كان معروفًا، الاتجاه، التردد المطلوب، ومن هو المالك داخل المنظمة.

**6. القيود.** اللوائح التنظيمية، أمن المعلومات، موقع التخزين، اللغات، سهولة الوصول، الجداول الزمنية غير القابلة للتغيير.

**7. ما المطلوب من مقدم العرض.** النهج المقترح، خطة المراحل، تشكيل الفريق بالأسماء والوظائف، الافتراضات، المخاطر، والتسعير وفقًا لهيكل ثابت.

**8. طريقة التقييم.** معايير وأوزان، يتم الإعلان عنها مسبقًا. هذا يؤدي إلى عروض مركزة ويقلل من النزاعات بعد الفوز.

**9. الجدول الزمني للمناقصة.** موعد طرح الأسئلة، موعد الردود، موعد التقديم، موعد العروض التوضيحية، موعد القرار.

## البيانات التي يجب الكشف عنها للحصول على تسعير حقيقي

| البيانات | لماذا هي حاسمة | ماذا يحدث بدونها |
|---|---|---|
| عدد المستخدمين حسب النوع | يحدد الترخيص، التدريب، والصلاحيات | عروض ضمن نطاق واسع للغاية |
| حجم السجلات والتاريخ | يحدد جهد ترحيل البيانات | يتم تسعير ترحيل البيانات بتقدير تقريبي |
| عدد الأنظمة المصدرية | يحدد التعقيد والتكامل | مفاجآت بعد التوقيع |
| مستوى التوثيق الحالي | يحدد مقدار الاكتشاف المطلوب | الموردون يفترضون وجود توثيق |
| توفر أصحاب العمليات | يحدد سرعة اتخاذ القرارات | جدول زمني غير واقعي متفق عليه من الطرفين |
| الميزانية أو النطاق | يركز الحل | عروض غير قابلة للمقارنة |

## الأسئلة التي تميز بين الموردين

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

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

السؤال الأخير هو اختبار جيد لطبيعة العلاقة. المورد الذي يتجنبه يخطط للاعتمادية.

## ما يجب طلبه كناتج في العرض

- **مخطط معماري مبدئي** على مستوى الكتل، بما في ذلك مصادر الحقيقة.
- **خطة مراحل** مع محتوى كل مرحلة وليس فقط التواريخ.
- **تفصيل تسعير بهيكل موحد** تحددونه أنتم، حسب المرحلة وحسب الدور.
- **قائمة مفصلة بالافتراضات.**
- **خريطة للمخاطر** مع طريقة التعامل معها.
- **نموذج لناتج حقيقي** من مشروع سابق، بأسماء مخفية — على سبيل المثال، وثيقة قرارات أو خطة اختبار.

العنصر الأخير ربما هو الأكثر تميزًا، لأنه يظهر مستوى العمل وليس مجرد وعد.

## هيكل تسعير موحد — الأداة التي تمنع مقارنة التفاح بالبرتقال

حددوا بأنفسكم الجدول الذي يجب على كل مقدم عرض ملؤه:

| المرحلة | ساعات كبار الموظفين | ساعات صغار الموظفين | التكلفة | ما الذي يعتبر مكتملًا |
|---|---|---|---|---|
| تحليل المتطلبات | | | | |
| التهيئة والتطوير للمرحلة 1 | | | | |
| التكاملات | | | | |
| ترحيل البيانات | | | | |
| الاختبارات وUAT (اختبار قبول المستخدم) | | | | |
| التدريب والاعتماد | | | | |
| الاستقرار بعد الإطلاق | | | | |
| إدارة المشروع | | | | |

المورد الذي يرفض تقسيم السعر وفقًا لهذا الهيكل ليس بالضرورة غاليًا — لكن لا يمكن مقارنته، وهذا سبب كافٍ للعودة إليه بطلب التوضيح.

## مثال توضيحي: صندوق تقاعد متوسط الحجم

السيناريو افتراضي ويهدف للتوضيح. أصدرت جهة مالية طلب تقديم عروض (RFP) تضمن ثمانين متطلبًا وظيفيًا في جدول. أشار مقدمو العروض الأربعة إلى "متوافق" في كل سطر تقريبًا، واختلفت العروض فقط في السعر وعدد الساعات.

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

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

## أخطاء شائعة في كتابة RFP (طلب تقديم العروض)

- نسخ وثيقة من مشروع آخر دون تعديل الحجوم والعمليات.
- طلب قائمة العملاء بدلاً من أمثلة المنتجات.
- معايير تقييم يتم صياغتها بعد استلام العروض.
- جدول زمني لا يترك وقتًا للأسئلة والأجوبة.
- تفضيل خفي لمورد حالي، مما يجعل الآخرين يستثمرون عبثًا ويضر بجودة العروض في المستقبل.

## ماذا يحدث بعد التقديم

وثيقة جيدة هي نصف العمل فقط. الخطوة التالية هي توحيد العروض ومقارنتها على نفس الأساس، كما هو مفصل في [دليل مقارنة عروض Salesforce](/ar/insights/compare-salesforce-proposals)، ومن ثم تحديد النقاط بشكل منظم وفقًا لأوزان محددة مسبقًا، كما هو مفصل في [دليل بطاقة نقاط اختيار المورد](/ar/insights/salesforce-vendor-scorecard).

تأتي قاعدة المعلومات لكتابة الوثيقة نفسها غالبًا من عملية استشارية قصيرة، كما هو موضح في [دليل استشارات Salesforce](/ar/insights/salesforce-consulting-guide)، وتتركز معايير فحص الشركة في [دليل اختيار شركة تنفيذ Salesforce](/ar/insights/choose-salesforce-implementation-company).

## الخطوة التالية

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

### أسئلة وأجوبة
**كم عدد الموردين الذين ينبغي دعوتهم لتقديم عروض لتنفيذ Salesforce؟**
من ثلاثة إلى خمسة موردين. أقل من ثلاثة لا يوفر أساسًا للمقارنة، وأكثر من خمسة يخلق عبئًا تقييميًا يجعل اللجنة تعتمد على السعر بدلاً من المحتوى. إذا كان هناك المزيد من المرشحين المؤهلين، فمن الأفضل إجراء جولة تصفية قصيرة بناءً على استبيان مختصر قبل إرسال الوثيقة الكاملة.

**هل يجب الكشف عن الميزانية في طلب تقديم العروض (RFP)؟**
من الأفضل الكشف عن نطاق أو سقف للميزانية. يمنع الكشف عن الميزانية تقديم عروض غير ذات صلة ويسمح للموردين باقتراح تقسيم العمل على مراحل ضمن الإطار المحدد. عدم الكشف عن الميزانية يؤدي عادةً بالموردين إلى تحديد أسعار لما يتوقعون أنك ستوافق عليه، وليس لما هو مطلوب لحل المشكلة.

**ماذا نفعل إذا طرح الموردون أسئلة تكشف عن فجوات في الوثيقة؟**
يجب نشر جميع الأسئلة والأجوبة لجميع مقدمي العروض في نفس الوقت، وتحديث الوثيقة إذا لزم الأمر. السؤال الجيد من المورد هو مؤشر إيجابي عليه، ولذلك يستحسن توثيق من طرح أي سؤال – فهذا أحد أفضل المقاييس لعمق فهمه.

**هل يجب طلب عرض توضيحي مباشر كجزء من طلب تقديم العروض (RFP)؟**
نعم، ولكن ليس عرضًا توضيحيًا للمنتج. اطلب من مقدم العرض حل سيناريو قصير من واقع عملك وشرح اعتبارات التنفيذ. العرض التوضيحي القياسي للمنتج يظهر ما يمكن أن تفعله Salesforce، وهذه معلومة لا تفرق بين الموردين؛ حل سيناريو يظهر كيف يفكر المورد.

**كم من الوقت يجب منحه للموردين لتقديم عروضهم؟**
من ثلاثة إلى أربعة أسابيع لمشروع متوسط، بما في ذلك جولة أسئلة وأجوبة في المنتصف. تؤدي الفترة الزمنية القصيرة جدًا إلى عروض مبنية على قوالب، وهذا بالضبط ما تحاولون تجنبه. إذا كان الجدول الزمني ضيقًا، فمن الأفضل تقليل نطاق المعلومات المطلوبة في العرض بدلاً من تقليل وقت التحضير.

---

## كيفية مقارنة عروض أسعار مشاريع Salesforce دون الوقوع في فخ السعر الأقل
URL: https://hpi.pro/ar/insights/compare-salesforce-proposals
العرض الأقل سعرًا بنسبة 30% هو دائمًا تقريبًا عرض مختلف، وليس عرضًا أفضل. تبدأ المقارنة الصحيحة بالتوحيد: نفس النطاق، نفس فترة الضمان، نفس المكونات الخفية. إليك طريقة توحيد من ست خطوات، وخريطة للتكاليف المخفية في العرض، ونموذج مقارنة للتكلفة على مدى ثلاث سنوات.

## لماذا تكاد عروض Salesforce لا تكون قابلة للمقارنة

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

أحد الموردين أدرج ترحيل بيانات يتضمن ثلاث سنوات من السجل، بينما افترض الآخر سنة واحدة. أحدهم أدرج ستة أسابيع من الاستقرار بعد الإطلاق، بينما الآخر سلم المشروع وأنهى عمله. أحدهم أحصى أربع عمليات تكامل، بينما الآخر اثنتين، لأنه افترض تقريرًا يوميًا بدلاً من واجهة حية. لم يضلل أي منهم – ببساطة لم يُطلب منهم خلاف ذلك.

لذلك، تبدأ المقارنة بالتوحيد القياسي، وليس بجدول الأسعار.

## طريقة التوحيد القياسي في ست خطوات

**1. تحديد قائمة موحدة من المكونات.** أحد عشر سطرًا كافية: التحليل، التهيئة (Configuration)، التطوير (Development)، عمليات التكامل (Integrations)، ترحيل البيانات (Migration)، الاختبارات (Testing)، التدريب (Training)، إدارة المشروع (Project Management)، الاستقرار (Stabilization)، التوثيق (Documentation)، نقل المعرفة (Knowledge Transfer).

**2. تحديد ما هو مشمول، وما هو جزئي، وما هو مفقود لكل عرض.** لا تملأ المبالغ في هذه المرحلة.

**3. تسعير المكونات المفقودة.** لكل مكون غير مشمول في العرض، استخدم التكلفة من عرض آخر كتقدير وأضفه.

**4. تسوية الافتراضات.** عدد المستخدمين، الإصدار، سنوات السجل التاريخي، عدد الوحدات التجارية، اللغات.

**5. تسوية فترة الضمان.** فترة مختلفة تعني تكلفة مختلفة. فرق شهرين في الاستقرار هو مكون تكلفة حقيقي.

**6. حساب متوسط التكلفة لكل ساعة ومزيج الفريق** في كل مرحلة، وليس المجموع الكلي.

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

## المكونات التي تختفي من العروض — وتظهر في الفاتورة

| المكون | لماذا تم حذفه | حجمه النسبي |
| --- | --- | --- |
| تنقية البيانات قبل الترحيل | يعتبر مسؤولية العميل | قد يكون كبيرًا جدًا أحيانًا |
| جولة ثانية من اختبار قبول المستخدم (UAT) | يُفترض جولة واحدة | منخفض ولكنه يعيق الجدول الزمني |
| التدريب حسب الدور | يتم تسعيره كورشة عمل واحدة | متوسط |
| دعم مكثف في الأسابيع الأولى | غير محدد | متوسط إلى مرتفع |
| التوثيق المملوك للمنظمة | يعتبر أمرًا بديهيًا | منخفض، حاسم لاحقًا |
| معالجة أخطاء التكامل والمراقبة | يشمل فقط "المسار الصحيح" | متوسط |
| البيئات وDevOps | يُفترض وجودها | منخفض إلى متوسط |
| ساعات الإدارة الداخلية للمنظمة | لا تظهر في العرض على الإطلاق | مرتفع، وموجود دائمًا |

السطر الأخير هو ما تفاجأ به الإدارة. يستهلك مشروع Salesforce وقتًا كبيرًا من أصحاب العمليات ومكتب إدارة المشاريع (PMO)، وهذه تكلفة حقيقية حتى لو لم تظهر في أي فاتورة.

## من مقارنة الأسعار إلى مقارنة التكاليف على مدى ثلاث سنوات

يتم تقييم العرض بشكل صحيح على مدى ثلاث سنوات، وليس على مدى المشروع. هيكل حساب بسيط:

| المكون | السنة الأولى | السنة الثانية | السنة الثالثة |
| --- | --- | --- | --- |
| تكلفة التنفيذ | كاملة | — | — |
| الترخيص | حسب عدد المستخدمين | يشمل النمو المتوقع | يشمل النمو المتوقع |
| الصيانة والمتابعة | جزئية | كاملة | كاملة |
| التحسينات المخطط لها | — | نطاق تقديري | نطاق تقديري |
| تكلفة الإدارة الداخلية | مرتفعة | متوسطة | متوسطة |

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

## علامات حمراء في العرض

- ترحيل البيانات مسعر بمبلغ مقطوع دون سؤال عن الحجم أو الجودة.
- لا توجد فترة ضمان، أو أنها معرفة على أنها "معالجة الأخطاء" دون تحديد ماهية "الخطأ".
- عرض يشمل ساعات التطوير فقط ولا يحتوي على بند لإدارة المشروع.
- تشكيلة فريق بدون أسماء، أو أسماء غير ملزمة بموجب العقد.
- سعر منخفض بشكل خاص لمرحلة التحليل، والتي غالبًا ما تكون بابًا لمشروع سيتم تسعيره لاحقًا.
- لا توجد افتراضات صريحة. عرض بدون افتراضات هو عرض لم يتم فحصه.

## مثال توضيحي: شركة طاقة متجددة

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

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

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

## ماذا نفعل بالفجوة المتبقية؟

بعد التوحيد القياسي، تبقى عادة فجوة حقيقية. ترجمها إلى أسئلة وليس افتراضات:

- لماذا تقديركم لعملية التكامل أقل من تقدير الآخرين – ماذا تعرفون ولا يعرفونه؟
- ماذا يحدث إذا لم يكن الافتراض حول جودة البيانات صحيحًا؟
- كم جولة اختبار خططتم لها؟
- من من الفريق الذي تم تقديمه سيرافق المشروع من بدايته إلى نهايته؟

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

## الربط بالقرار النهائي

توفر المقارنة المنظمة الجانب التجاري فقط. يتم تقييم الجانب المهني بشكل منفصل، وفقًا لأوزان محددة مسبقًا، والسعر هو واحد منها فقط – التفاصيل في [دليل اختيار شركة تنفيذ Salesforce](/ar/insights/choose-salesforce-implementation-company). فهم ما يشكل التكلفة في المقام الأول مفصل في [دليل تكلفة تنفيذ Salesforce](/ar/insights/salesforce-implementation-cost)، واختيار نموذج التعاقد في [دليل تسعير المشروع](/ar/insights/salesforce-project-pricing-models).

ما تم الاتفاق عليه في المقارنة يجب أن يدرج في العقد بصياغة دقيقة، وإلا فإنه غير موجود – البنود ذات الصلة مجمعة في [دليل العقد وبيان العمل (SOW)](/ar/insights/salesforce-sow-contract-clauses).

## الخطوة التالية

قم ببناء جدول التوحيد القياسي قبل فتح مظاريف الأسعار. من يبنيه بعد رؤية المبالغ، يبنيه - عن غير قصد - بطريقة تبرر العرض الذي أعجبه بالفعل.

### أسئلة وأجوبة
**فجوة بنسبة 40% بين عروض Salesforce — ماذا يعني ذلك عادةً؟**
يعني دائمًا تقريبًا أن العروض تشير إلى نطاق مختلف، وليس أن موردًا واحدًا أكثر كفاءة بمرة ونصف. الفجوات الشائعة هي ترحيل البيانات الذي تم تضمينه أو لا، عدد عمليات التكامل التي تم حسابها، فترة الاستقرار بعد الإطلاق، والتدريب. قبل التفاوض على السعر، يجب التأكد من أن هذه الثلاثة محددة بنفس الطريقة في جميع العروض.

**كيف تقارن العروض ذات التشكيلة المختلفة من الفريق؟**
قم بحساب متوسط التكلفة بالساعة وانظر إلى نسبة الخبرة (كبير-صغير) في كل مرحلة. العرض ذو السعر المنخفض بالساعة وتشكيلة الفريق الذي يعتمد بالكامل على الموظفين ذوي الخبرة الأقل قد يتطلب ساعات عمل أكثر لنفس المهمة. ما يهم هو من سيقود قرارات الهندسة المعمارية بالفعل ونسبة وقته المخصصة للمشروع.

**هل يجب طلب من الموردين تصحيح العرض بعد المقارنة؟**
نعم، جولة واحدة من التوضيحات ممارسة صحيحة ومفيدة. أرسل لكل مقدم عرض الفجوات التي حددتها في نطاقه فقط، دون الكشف عن أسعار الآخرين، واطلب عرضًا محدثًا بنفس الهيكل. عادة ما تقلل هذه الجولة الفجوة بين العروض بشكل كبير وتكشف من فهم المشروع حقًا.

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

**هل يتم تضمين تكلفة ترخيص Salesforce في عرض المدمج (Integrator)؟**
عادة لا يتم تضمينها، ويتم شراؤها بشكل منفصل. من المهم التأكد من أن جميع مقدمي العروض افترضوا نفس الإصدار ونفس عدد المستخدمين، لأن الافتراضات المختلفة تغير أيضًا نطاق العمل: ميزة موجودة في إصدار أعلى قد تتطلب تطويرًا في إصدار أقل.

---

## عقد وSOW لمشروع Salesforce: بنود تحمي التسليم
URL: https://hpi.pro/ar/insights/salesforce-sow-contract-clauses
معظم النزاعات في مشاريع Salesforce لا تتعلق بالسعر، بل بما يُعتبر إنجازًا مكتملًا. يُعرّف خطاب العمل (SOW) الجيد معايير القبول والتبعيات المتبادلة وملكية المخرجات والإنهاء المنظم. إليك اثنا عشر بندًا مع صياغة موصى بها وشرح لما يجنبه كل بند عمليًا.

## ما الذي يُفشل مشاريع Salesforce التعاقدية حقًا

لا يكاد أي نزاع في مشروع Salesforce يبدأ بسؤال "كم التكلفة". بل يبدأ بسؤال "هل انتهى العمل". يرى المورد أن المنتج قد سُلّم؛ وترى المنظمة أنه غير قابل للاستخدام. كلا الطرفين محقان من منظورهما، لأنه لم يحدد أي منهما مسبقًا ما الذي سيعتبر مكتملاً.

من هنا، ينبع مبدأ واحد يوجه جميع بنود هذه المقالة: **العقد الجيد لا يحمي طرفك في النزاع — بل يمنع النزاع من الأساس.**

## اثنا عشر بندًا

### 1. تعريف معايير القبول لكل مخرج

هذا هو البند الأكثر أهمية. يتطلب كل مخرج معيارًا قابلاً للملاحظة: ليس "شاشة إدارة العملاء"، بل "يمكن للمستخدم ذي الملف X تنفيذ السيناريو Y والحصول على النتيجة Z، كما هو محدد في معايير القبول المعتمدة."

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

### 2. آلية طلبات التغيير

تحدد من يحق له طلب التغيير، من يقوم بتقييمه، في غضون كم من الوقت، وبأي معدل سعر. يجب تحديد معدل السعر عند توقيع العقد وليس عند الحاجة.

### 3. التبعية ثنائية الاتجاه

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

صياغة متوازنة: الجدول الزمني مشروط باستجابة محددة من العميل (وقت الموافقة، توفر مالك العملية، تسليم البيانات)، والتأخير عن الموعد المحدد يؤجل نقطة الإنجاز بإشعار كتابي.

### 4. ملكية الكود، التهيئة، والتوثيق

الفصل بين المخرجات المخصصة والمكونات العامة للمورد، مع ترخيص استخدام غير محدود زمنيًا للمكونات العامة، غير مشروط باستمرارية العلاقة التعاقدية.

### 5. التوثيق كمخرج إلزامي

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

### 6. الضمان وإصلاح العيوب

فترة محددة، وتعريف واضح للعيوب مقابل التغيير. تعريف فعال: الفجوة بين السلوك الفعلي ومعايير القبول المعتمدة تعتبر عيبًا.

### 7. الموظفون الرئيسيون

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

### 8. الصلاحيات، البيئات، وأمن المعلومات

من يحصل على صلاحية وصول إلى أي بيئات، لمدة كم من الوقت، وماذا يحدث للصلاحيات عند الانتهاء، وكيف تُعالج البيانات الحقيقية في البيئات غير الإنتاجية.

### 9. الامتثال للمتطلبات التنظيمية والخصوصية

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

### 10. بوابات القرار ونقاط الخروج

الحق في التوقف عند نهاية نقطة إنجاز محددة، مع ترتيب دفع معروف مسبقًا. مثل هذا البند يقلل من مخاطر الطرفين، ولذلك فإن المورد الجيد لن يعترض عليه.

### 11. نقل المعرفة

ليس "تدريبًا"، بل: عدد الساعات، لمن، عن ماذا، وما هو المخرج. يُفضل أن ينتشر هذا النقل على مدار المشروع بدلاً من أن يتركز في نهايته.

### 12. الإنهاء والانسحاب

قائمة بالمخرجات المُسلّمة، التنسيق، فترة التداخل (Handover)، ومعدل سعر ساعات الدعم خلال عملية النقل. هذا هو البند الذي لا يرغب أحد في مناقشته عند التوقيع، ولهذا بالذات يجب الإصرار عليه حينها.

## خريطة المخاطر: ماذا يمنع كل بند

| البند | الفشل الذي يمنعه | تكلفة عدم وجوده |
| --- | --- | --- |
| تعريف القبول | الجدل حول "الانتهاء" | تأخير في الدفع والإطلاق |
| طلبات التغيير | التسعير في وقت الضيق | تكلفة إضافية غير محكومة |
| التبعية ثنائية الاتجاه | تبادل اللوم على التأخير | تأجيل الجدول الزمني بدون شفافية |
| الملكية والتوثيق | التبعية للمورد | تكلفة عالية عند استبدال المورد |
| الموظفون الرئيسيون | استبدال الفريق بصمت | فقدان السياق والمعرفة |
| الضمان | الجدل بين العيب والتغيير | دفع مضاعف للإصلاح |
| الخروج | التفاوض من موقف ضعف | تكلفة نقل غير متوقعة |

## صياغات يجب تجنبها

- "سيؤدي المورد العمل بمهنية مقبولة" — لا يمكن إنفاذها بدون معيار.
- "سيتفق الطرفان لاحقًا على..." — كل بند من هذا القبيل هو نزاع مستقبلي محتمل.
- "خاضع للتعاون الكامل من العميل" — بدون تعريف لما يعنيه ذلك، هذا دفاع أحادي الجانب.
- "سيُسلم المخرج في نهاية المشروع" — بدون تعريف لماهية النهاية.
- جدول الدفعات بناءً على تواريخ تقويمية بدلاً من معايير القبول.

## مثال توضيحي: سلسلة تجزئة

السيناريو افتراضي وهو لأغراض التوضيح فقط. وقعت سلسلة تجزئة على بيان عمل (SOW) تضمن "ترحيل بيانات العملاء من نظام قائم". كان افتراض المنظمة أن الترحيل يشمل تنقية التكرارات؛ وكان افتراض المورد أنه سينقل ما سُلّم إليه.

في الواقع، نُقلت مئات الآلاف من السجلات المتكررة. قرأ الطرفان نفس الجملة وفهماها بشكل معكوس. لم يكن هناك في العقد بند يحدد ما يعتبر سجلاً سليمًا.

التصحيح الذي أُجري في الاتفاقيات اللاحقة لتلك السلسلة كان موجزًا: ملحق يحدد عتبة جودة قابلة للقياس للتحميل — نسبة السجلات التي تجتاز عملية التحقق، قواعد تحديد التكرارات، ومن يوافق. حل هذا الملحق محل عشرات الساعات من الجدل.

## ما يجب التحقق منه قبل التوقيع

- كل مخرج في العرض يظهر في بيان العمل (SOW) مع معيار قبول.
- كل افتراض قُدم في العرض يظهر كافتراض صريح في العقد.
- جدول الدفعات مرتبط بمعايير القبول.
- يوجد بند الانسحاب وبند نقل المعرفة.
- تعريف العيب واضح بما فيه الكفاية لحسم الحالات الحدية.

ما اتفق عليه في مقارنة العروض ولم يُدرج في العقد — ببساطة غير موجود. عملية المقارنة بحد ذاتها مفصلة في [دليل مقارنة عروض Salesforce](/ar/insights/compare-salesforce-proposals)، وأساس صياغة المتطلبات محدد مسبقًا في وثيقة طلب تقديم العروض، كما هو مفصل في [دليل RFP](/ar/insights/salesforce-rfp-guide).

## العلاقة باختيار المورد

بعض البنود هنا تُستخدم أيضًا كأداة تقييم: المورد الذي يعترض على بند ملكية التوثيق أو بند الخروج يكشف لكم شيئًا عن نموذج عمله. يوضح [دليل بطاقة تقييم اختيار المورد](/ar/insights/salesforce-vendor-scorecard) كيفية دمج التقييم المهني مع الاستعداد التعاقدي، وتُجمع المعايير الواسعة لفحص الشركات في [دليل اختيار شركة التنفيذ](/ar/insights/choose-salesforce-implementation-company). تفصّل [دليل خدمات Salesforce](/ar/insights/salesforce-services-guide) كيفية ملاءمة نوع التعاقد مع نوع الخدمة المشتراة.

## الخطوة التالية

خذ بيان العمل (SOW) الذي بين يديك وعلّم كل مكان كُتب فيه "سيُسلم" أو "سيُنفذ" بدون ذكر كيفية التأكد من حدوث ذلك. كل علامة من هذه هي نزاع محتمل، وكل واحدة منها تستغرق خمس دقائق لإصلاحها الآن.

### أسئلة وأجوبة
**ما الفرق بين الاتفاقية الإطارية وSOW في مشروع Salesforce؟**
تحدد الاتفاقية الإطارية العلاقات القانونية: السرية، المسؤولية، التأمين، الملكية الفكرية، شروط الدفع، وتسوية المنازعات. بينما تحدد SOW العمل نفسه: المخرجات، المعالم، معايير القبول، الافتراضات، والنطاق. يمكن لنفس الاتفاقية الإطارية أن تخدم وثائق SOW متعددة، وهو هيكل مناسب عند العمل على مراحل.

**لمن يعود ملكية الكود والتكوين المطورين في مشروع Salesforce؟**
يتم تحديد ذلك في العقد فقط. الافتراضي لدى بعض الموردين هو أن المنتج المخصص للعميل، لكن المكونات العامة والبنى التحتية للمورد تبقى ملكًا له، بترخيص استخدام. من المهم التأكد من أن هذا الترخيص غير محدود زمنيًا وغير مشروط باستمرارية العلاقة، وإلا فإن تغيير المورد سيخلق مشكلة.

**ما هي فترة الضمان المعقولة بعد الإطلاق (Go-Live)؟**
تتراوح بين ثلاثين وتسعين يومًا، حسب التعقيد. الأهم من المدة هو التعريف: ما الذي يُعتبر عيبًا يتم إصلاحه بلا مقابل، وما الذي يُعتبر طلب تغيير. الصياغة العملية هي أن أي فجوة بين السلوك الفعلي ومعايير القبول المعتمدة تُعد عيبًا، وكل ما عدا ذلك يُعد تغييرًا.

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

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

---

## بطاقة تقييم لاختيار مورد Salesforce: المعايير والأوزان
URL: https://hpi.pro/ar/insights/salesforce-vendor-scorecard
لجنة الاختيار التي لا تعتمد نموذج تقييم متفقًا عليه غالبًا ما تصل إلى قرارات مبررة بأثر رجعي. تحدد بطاقة التقييم (Scorecard) المُعرفة مسبقًا ما يتم قياسه، والأدلة المطلوبة لكل درجة، وما يستبعد فوراً. نقدم هنا نموذجًا سُباعي الأبعاد مع أوزان تقديرية وعملية تقييم تمنع التحيز.

## لماذا تختار اللجان بشكل صحيح وتبرر بشكل خاطئ

في اجتماع قرار نموذجي، وبعد ثلاثة عروض تقديمية، يقول المشاركون عبارات مثل "لقد أعجبت بهم" أو "بداوا الأكثر احترافية". أحيانًا يكون الاختيار صحيحًا. المشكلة هي أنه لا توجد طريقة لمعرفة ذلك – ولا توجد طريقة لشرح القرار بعد عام، عندما يتعقد المشروع.

لا يهدف Scorecard إلى استبدال التقدير الشخصي. بل يهدف إلى التأكد من أن جميع مقدمي العروض قد تم فحصهم بناءً على نفس المعايير، وأن الدليل لكل درجة قد تم توثيقه، وأن ما اعتبرته اللجنة مهمًا قبل رؤية العروض التقديمية هو ما حدد القرار بعدها أيضًا.

## أبعاد التقييم السبعة

**1. فهم المشكلة.** هل يتناول العرض التقديمي عملياتكم وأحجامكم، أم أنه عام؟ هل حدد مقدم العرض تناقضًا أو فجوة في وثيقة الطلب؟

**2. جودة التصميم المعماري المقترح.** هل يوجد رسم تخطيطي؟ هل تم تحديد مصادر موثوقة للبيانات؟ هل تم النظر في البدائل وشرح سبب رفضها؟

**3. الفريق الفعلي.** من هو القائد؟ كم من الوقت يكرس؟ من يقوم بالتنفيذ؟ وما هي نسبة المهنيين ذوي الخبرة في مراحل اتخاذ القرار؟

**4. الخبرة ذات الصلة.** ليس عدد المشاريع، بل أوجه التشابه: الصناعة، تعقيد التكامل، الحجم، والامتثال التنظيمي.

**5. نموذج العمل والحوكمة.** وتيرة العروض التجريبية، إدارة القرارات، إدارة المخاطر، وكيفية التعامل مع التغييرات.

**6. نقل المعرفة والاستقلالية.** هل توجد خطة واضحة تمكنكم من الصيانة بدونهم؟

**7. الجانب التجاري.** السعر المعياري، نموذج التعاقد، المرونة التعاقدية، والاستعداد لبنود الحماية.

## أمثلة للأوزان – وكيفية تخصيصها

| البعد | مشروع جديد في مؤسسة بدون فريق | مشروع إنقاذ | توسع في مؤسسة ذات فريق قوي |
|---|---|---|---|
| فهم المشكلة | 20% | 25% | 15% |
| التصميم المعماري | 20% | 20% | 25% |
| الفريق الفعلي | 15% | 20% | 15% |
| الخبرة ذات الصلة | 10% | 10% | 10% |
| نموذج العمل والحوكمة | 10% | 10% | 10% |
| نقل المعرفة | 10% | 5% | 5% |
| الجانب التجاري | 15% | 10% | 20% |

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

حددوا الأوزان **قبل** استلام العروض وانشروها في وثيقة الطلب، كما هو مفصل في [دليل طلب تقديم العروض (RFP)](/ar/insights/salesforce-rfp-guide).

## مقياس التقييم مع الأدلة المطلوبة

المشكلة في مقياس 1-5 هي أن الجميع يسجلون 4. الحل هو ربط كل مستوى بدليل:

| الدرجة | المعنى | الدليل المطلوب |
|---|---|---|
| 1 | لم يتم الاستجابة | الموضوع غير مذكور في العرض |
| 2 | عام | نص جاهز بدون إشارة للمؤسسة |
| 3 | مقبول | إشارة صحيحة ولكن بدون عمق أو بدائل |
| 4 | جيد | إشارة محددة مع تبرير ومثال |
| 5 | ممتاز | بدائل تم النظر فيها، مخاطر تم تحديدها، وتوصية ضد شيء طلبتموه |

الدليل للدرجة 5 هو ما يجعل النموذج مفيدًا: المورد الذي يقول "هذا الجزء لا ينصح ببنائه الآن" يظهر فهمًا لا يمكن تزييفه.

## شروط الرفض – قبل التقييم

هناك أمور لا جدوى من تضمينها في التقييم، لأنها تؤدي إلى الرفض:

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

حددوا هذه الشروط مسبقًا. أي رفض يتقرر لاحقًا يبدو دائمًا وكأنه موجه ضد مورد معين.

## عملية تقييم تقلل التحيز

1.  يقوم كل عضو لجنة بالتقييم **بشكل منفصل** قبل المناقشة المشتركة.
2.  يُرفق التقييم بملاحظة قصيرة تستشهد بمصدر في العرض.
3.  تركز المناقشة فقط على الفروقات الكبيرة بين المقيمين – حيث توجد المعلومات.
4.  يتم الكشف عن السعر في هذه المرحلة وليس قبلها، إذا سمحت العملية بذلك.
5.  يتم توثيق الدرجة النهائية مع التبرير.

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

## مثال توضيحي: شركة أمن تجارية

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

خلال المناقشة، برزت حجة بأن الخبرة تعوض. عادت اللجنة إلى الأوزان التي حددتها قبل شهرين، والتي منحَت فهم المشكلة ضعف وزن الخبرة. بقي القرار على حاله.

ما منعه النموذج هنا لم يكن بالضرورة اختيارًا خاطئًا، بل تغيير قواعد اللعبة بعد معرفة النتيجة.

## ماذا نفعل بالنتيجة

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

يتم تطبيع الجانب التجاري بشكل منفصل قبل التقييم، كما هو مفصل في [دليل مقارنة عروض Salesforce](/ar/insights/compare-salesforce-proposals)، ويتم شرح العلاقة بين هيكل التكلفة والتقييم التجاري في [دليل تكلفة تنفيذ Salesforce](/ar/insights/salesforce-implementation-cost).

## الدمج مع مقابلة الخبراء

التقييم بناءً على الوثائق محدود. الإكمال الأساسي هو اجتماع حيث تُطرح أسئلة مفتوحة على المورد ويُختبر كيفية تفكيره في الوقت الفعلي. تظهر مجموعة كاملة من الأسئلة في [دليل الأسئلة قبل اختيار مُكامل](/ar/insights/questions-before-choosing-salesforce-integrator)، والمعايير العامة لفحص الشركة في [دليل اختيار شركة تنفيذ Salesforce](/ar/insights/choose-salesforce-implementation-company).

## الخطوة التالية

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

### أسئلة وأجوبة
**ما هو الوزن الذي يجب إعطاؤه للسعر عند اختيار مورد Salesforce؟**
في المشاريع التي تعتمد نتائجها بشكل أساسي على جودة القرارات، يكون الوزن من عشرين إلى ثلاثين بالمائة شائعًا وكافيًا. الوزن الأعلى يحول الاختيار إلى اختيار قائم على السعر، والوزن المنخفض جدًا يفصل القرار عن الواقع الميزاني. والأهم من الوزن هو أن السعر الذي يتم تقييمه يجب أن يكون طبيعيًا لنفس النطاق.

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

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

**ماذا نفعل عندما يحصل موردان على نقاط متقاربة جدًا؟**
لا تتم إضافة معيار جديد بأثر رجعي، لأن هذا هو بالضبط المكان الذي تتسلل فيه التفضيلات الشخصية. الأداة الصحيحة هي جولة مركزة: نفس السيناريو القصير لكليهما، نفس السؤال حول إدارة المخاطر، وتقييم الفريق الفعلي. الفرق الذي يظهر هناك عادة ما يكون أوضح من أي جدول.

**هل يفضل مورد كبير أم شركة بوتيك في مشروع Salesforce؟**
تعتمد الإجابة على نوع المخاطرة التي تقلقكم. المورد الكبير يقدم عمقًا في الموارد والاستمرارية، غالبًا بسعر أعلى ومرونة أقل. شركة البوتيك تقدم اتصالًا مباشرًا بكبار المسؤولين ومرونة، مع مخاطر الاعتماد على أفراد معينين. يمكن تقييم كلتا المخاطرتين بشكل صريح بدلاً من اتخاذ قرار بناءً على شعور بالحجم.

---

## حدود واجهة برمجة التطبيقات (API Limits) في Salesforce: تخطيط التكاملات للتعامل مع الأحمال والاسترداد
URL: https://hpi.pro/ar/insights/salesforce-api-limits-resilience
تحسب Salesforce استدعاءات واجهة برمجة التطبيقات (API Calls) ضمن نوافذ زمنية مدتها 24 ساعة، وعند تجاوز الحد الأقصى، تقوم بالحظر الفوري - ولا تتباطأ في ذلك. فالمؤسسة التي تقوم بتشغيل مزامنة ليلية، وWebhook وارد، وتقارير في وقت واحد تحتاج إلى ميزانية استدعاءات مخططة، لا مجرد محاولة إعادة (Retry) بعد نفاد الحصة. يشرح هذا الدليل الحدود الفعلية بالتفصيل: كيفية قياس الاستهلاك، ومتى يتم التحول إلى Bulk API، وكيفية بناء آلية تراجع (Backoff) لا تغرق النظام بموجة ثانية من الأعطال.

## ما الذي يتعطل أولاً عند تجاهل حدود واجهة برمجة التطبيقات (API Limits)

الشركة التي تدير ثلاث عمليات تكامل في وقت واحد - مزامنة ليلية لنظام تخطيط موارد المؤسسات (ERP)، وخطاف ويب (Webhook) من نظام دفع، ولوحة تحكم خارجية تسحب البيانات كل خمس دقائق - لا تتعطل تدريجياً. بل تعمل بشكل ممتاز حتى تتجاوز حداً معيناً، وعندئذٍ تُرفض كل استدعاء إضافي لواجهة برمجة التطبيقات (API) برمز `REQUEST_LIMIT_EXCEEDED` حتى يتم إعادة التعيين اليومي. لا يوجد إنذار مبكر مدمج يمنع ذلك مقدماً - هناك فقط لوحة تحكم (Dashboard) يمكن النظر إليها، إذا كان أحدهم قد بنى عملية للتحقق منها.

يختلف هذا النوع من الفشل عن معظم حالات الفشل في مشاريع Salesforce لأنه لا يعتمد على "رمز برمجي سيئ" أو تصميم معوج. بل يعتمد على التراكم: يتم بناء كل عملية تكامل جديدة دائماً في مقابل الوضع الحالي، دون التحقق من مقدار الموازنة اليومية التي استهلكتها العمليات الحالية بالفعل. والنتيجة هي أن عملية التكامل الخامسة "تكسر" العمليات الأربع التي سبقتها، على الرغم من أن أياً منها لم يتغير.

## خريطة الحدود ذات الصلة عملياً

ليس كل حد موجود في Salesforce مهم بنفس القدر لتصميم عمليات التكامل. هذه هي التي تحدد الهندسة المعمارية بالفعل:

| نوع الحد | ما يقيسه | من يتأثر به أولاً |
|---|---|---|
| طلبات API اليومية | إجمالي استدعاءات REST/SOAP خلال 24 ساعة | أي عملية تكامل متزامنة تعمل بتردد عالٍ |
| دفعات Bulk API | عدد الدفعات المفتوحة/اليومية | عمليات الدفعة الليلية (Batch) التي تغذي البيانات التاريخية |
| طلبات متزامنة طويلة المدى | الاستدعاءات التي تعمل لأكثر من 20 ثانية بالتوازي | التقارير الثقيلة أو Apex المتزامن المعقد |
| إرسال Platform Event | حجم الأحداث في اليوم لكل مشترك | Architecture التي تعتمد على الأحداث (Event-Driven) بين Salesforce والأنظمة الخارجية |
| صفوف SOQL لكل عملية (Transaction) | الصفوف التي يتم استردادها في عملية واحدة (50,000) | Logic الخاصة بلغة Apex التي تنفذ استعلامات داخل حلقة تكرارية |

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

## ميزانية الاستدعاءات: كيف تبنيها بشكل صحيح

الأداة الرئيسية لمنع الحظر ليست المراقبة بعد وقوع الحدث، بل هي ميزانية محددة مسبقاً لكل مستهلك لواجهة برمجة التطبيقات (API). المبدأ هو: كل نظام خارجي، وكل مستخدم تكامل (Integration User)، وكل عملية مجدولة تحصل على تخصيص محدد من الحصة الإجمالية، بدلاً من الحصول على "قدر ما يلزم".

يتضمن بناء الميزانية ثلاث مراحل:

1.  **رسم خرائط المستهلكين** - قائمة بكل عملية تستدعي واجهة برمجة التطبيقات (API): عمليات التكامل الخارجية، Apex المجدول (Scheduled Apex)، Data Loader اليدوي، أدوات ذكاء الأعمال (BI). لكل منها مستخدم تكامل (Integration User) منفصل لتمكين عزل الاستهلاك في Event Monitoring.
2.  **حساب الحمل بناءً على حجم العمل، وليس على الافتراضات** - كم عدد السجلات التي يتم نقلها يومياً، وكم عدد الاستدعاءات المطلوبة لكل سجل (بما في ذلك استرداد القوائم ذات الصلة)، وماذا يحدث في أوقات الذروة (نهاية الربع، Black Friday، إغلاق الشهر).
3.  **تخصيص احتياطي** - لا يتم تقسيم 100% من الحصة بين العمليات القائمة. يتم الاحتفاظ بـ 15% - 20% كاحتياطي للعمليات الطارئة، والتقارير المخصصة (ad-hoc)، والصيانة - وإلا فإن أي إضافة صغيرة تدفع المؤسسة إلى تجاوز الحد الأقصى.

لمن يرغب في التعمق في تصميم الطبقة التي تدير هذه الميزانية على مستوى المنصة، يفضل قراءة [دليل هندسة CRM](/ar/insights/crm-architecture-guide)، حيث يتم تقديم التقسيم بين طبقة التكامل وطبقة الأعمال.

## REST مقابل Bulk: متى يصبح التبديل مجدياً

الخطأ الأكثر شيوعاً هو استخدام واجهة برمجة تطبيقات REST API عادية لنقل البيانات بكميات كبيرة، لأن هذا هو ما يتم بناؤه أولاً ويعمل في إثبات المفهوم (PoC). تظهر المشكلة عندما يزداد الحجم: يحسب REST كل طلب (حتى 200 سجل في Composite) كاستدعاء منفصل مقابل الحصة، بينما ينفذ Bulk API 2.0 دفعات تصل إلى 10,000 سجل ويتم احتسابه بتكلفة أقل بكثير لكل سجل.

قاعدة إرشادية عملية: إذا كانت عملية واحدة تقوم بتحديث أكثر من حوالي 2000 سجل في تشغيل واحد، فإن الانتقال إلى Bulk API يكاد يكون مجدياً دائماً - حتى لو كان ذلك يعني تغيير رمز المستهلك للعمل بشكل غير متزامن مع الاستقصاء (Polling) حول حالة المهمة بدلاً من الاستجابة الفورية. الثمن هو زمن استجابة (Latency) أعلى (دقائق بدلاً من ثوانٍ)، ولذلك فإن Bulk API غير مناسب للعمليات التي تتطلب قراراً في الوقت الفعلي، مثل التحقق من المخزون قبل تأكيد الطلب.

## Backoff و Retry: منع الإغراق الذاتي

عندما يفشل استدعاء API بسبب تجاوز الحد الأقصى (Limit), فإن الاستجابة الفطرية لمعظم الفرق هي المحاولة مرة أخرى على الفور. هذا بالضبط هو السلوك الذي يحوّل الحظر المؤقت إلى مشكلة مستمرة: إذا حاولت عشر عمليات مرة أخرى في نفس اللحظة, فإنها تدفع النظام أعمق في الحظر بدلاً من السماح له بالتعافي.

تتطلب آلية Backoff الصحيحة ثلاثة مكونات معاً:

-   **Exponential Backoff** - يتزايد وقت الانتظار بين المحاولات بشكل أسي (على سبيل المثال 2, 4, 8, 16 ثانية), ولا يبقى ثابتاً.
-   **Jitter** - إضافة عشوائية صغيرة لوقت الانتظار, حتى لا تحاول العمليات المتوازية مرة أخرى في نفس الثانية بالضبط وتخلق موجة جديدة من الحمل.
-   **Circuit Breaker** - بعد عدد متتالٍ من الفشل (على سبيل المثال خمسة), تتوقف العملية تماماً عن المحاولة لفترة زمنية محددة وتبلغ عن ذلك لأنظمة المراقبة, بدلاً من الاستمرار في "طرق الباب".

بدون Circuit Breaker، فإن العملية التي تعمل كل خمس دقائق وتفشل باستمرار ستستمر في المحاولة مائة مرة في اليوم وتستهلك حصة على الفشل فقط - وهذا هو عكس ما يراد من الآلية منعه. تفاصيل إضافية حول معالجة الأخطاء على مستوى التكامل متوفرة في [إدارة أخطاء التكامل في Salesforce](/ar/insights/salesforce-integration-error-handling).

## سيناريو: تجارة تجزئة بثلاث نقاط تكامل

لنفترض أن هناك شبكة تجزئة متوسطة الحجم، تضم حوالي 40 فرعًا، وتدير Salesforce Service Cloud مع نظام نقطة البيع (POS) ونظام تخطيط موارد المؤسسات (ERP) للمخزون. ثلاث عمليات تكامل نشطة: مزامنة المخزون كل 15 دقيقة من نظام ERP (حوالي 8,000 منتج)، وخطاف ويب (Webhook) من نظام POS في كل معاملة تفشل (حوالي 300 في اليوم)، ولوحة تحكم خارجية لـ Power BI تسحب بيانات الخدمة كل ساعة.

في الشهر الذي أضافت فيه الشبكة برنامج ولاء جديدًا، دخلت عملية تكامل رابعة: التحقق من نقاط الولاء في الوقت الفعلي من Salesforce من كل نقطة بيع، ما أضاف حوالي 6,000 استدعاء إضافي يوميًا. في غضون أسبوعين، بدأت مزامنة المخزون تفشل حوالي الساعة 2-3 مساءً، وهي ساعة الذروة لنقاط البيع. قام الفريق في البداية بفحص نظام ERP وظنوا أن المشكلة هناك، لكن سجلات Salesforce أظهرت `REQUEST_LIMIT_EXCEEDED` بالضبط في هذه الفترة الزمنية.

لم يكن الحل هو شراء حصة إضافية، بل كان تغيير الأولويات: تم نقل التحقق من نقاط الولاء للاستخدام في Platform Cache للنتائج التي لا تتغير بشكل متكرر، مما قلل الاستدعاءات بحوالي 70%، وتم نقل مزامنة المخزون من REST إلى Bulk API مع تشغيل كل 30 دقيقة بدلاً من 15. النتيجة: نفس التغطية التجارية، استهلاك حصة أقل بنسبة 45%، واحتياطي حقيقي للنمو القادم.

## المخاطر وإجراءات الوقاية المحددة

| الخطر | كيف يتجلى عملياً | إجراء وقائي |
|---|---|---|
| عدم فحص تكامل جديد مقابل الميزانية الحالية | يظهر الحظر فقط بعد الانتقال إلى الإنتاج | طلب مراجعة القدرة (Capacity Review) لكل تكامل جديد قبل البدء الفعلي (Go Live) |
| إعادة المحاولة (Retry) بدون Backoff | يتحول الحظر المؤقت إلى عطل يستمر لساعات | Exponential Backoff مع Jitter و Circuit Breaker في كل مستهلك لواجهة برمجة التطبيقات (API) |
| استخدام REST للأحجام الكبيرة | عملية واحدة تستهلك عشرات النسب المئوية من الحصة اليومية | الانتقال إلى Bulk API عند تجاوز حد حجم محدد مسبقاً |
| عدم فصل مستخدمي التكامل (Integration Users) | عدم القدرة على معرفة أي تكامل يستهلك الحصة | مستخدم تكامل (Integration User) مخصص لكل نظام خارجي، يتم مراقبته بشكل منفصل |
| عدم وجود احتياطي في الميزانية | أي إضافة صغيرة تدفع إلى تجاوز الحد | تخصيص 15% - 20% من الحصة كاحتياطي ثابت لا يُخصص للعمليات اليومية |

## قائمة التحقق قبل إضافة تكامل جديد

- [ ] معرفة النسبة المئوية من الحصة اليومية المستهلكة حالياً، حسب Integration User
- [ ] فحص حجم الذروة (وليس متوسط الحجم) للتكامل الجديد
- [ ] اتخاذ قرار بين REST و Bulk API بناءً على حد الحجم، وليس بناءً على سهولة التطوير
- [ ] وجود آلية Backoff مع Jitter و Circuit Breaker في رمز المستهلك (Consumer Code)
- [ ] تعريف تنبيه عندما يتجاوز استهلاك الحصة اليومية 70%
- [ ] فحص الاستخدام المحتمل لـ Platform Cache لتقليل الاستدعاءات المتكررة
- [ ] وجود احتياطي بنسبة 15% - 20% من الحصة لم يُخصص مسبقاً
- [ ] تحديد مالك تشغيلي (Operational Owner) يتلقى التنبيه وليس فقط سجلاً تقنياً

## كيفية مراقبة ذلك بشكل مستمر

تتطلب المراقبة الموثوقة مزيجًا من ثلاثة مصادر: Event Monitoring (أو Shield Event Monitoring) لاستهلاك واجهة برمجة التطبيقات (API) الفعلي حسب المستخدم، و Apex Limits في الرمز البرمجي نفسه (`Limits.getLimitApiRequests()`) للتحقق المحلي في وقت التشغيل، ولوحة التحكم المدمجة تحت Company Information التي تعرض الاستهلاك مقابل الحصة على مستوى المؤسسة. لا يكفي أي من هذه المصادر بمفرده: الأول يظهر الاتجاه، والثاني يمنع الفشل داخل عملية واحدة، والثالث يعمل كحالة يومية لفريق التشغيل.

المقياس الذي يجب مراقبته على المدى الطويل ليس فقط "كم تم استهلاكه" بل "ما هو معدل النمو الشهري في الاستهلاك" - لأن هذا هو ما يسمح بالتنبؤ متى ستصل المؤسسة إلى الحد الأقصى، بدلاً من الاستجابة بعد وقوع الحظر بالفعل. عندما تكون هناك عدة أنظمة تعتمد على بعضها البعض، فمن المفيد أيضاً فحص نمط التكامل الكلي مقابل [ربط Salesforce بأنظمة ERP](/ar/insights/salesforce-erp-integration)، ومسألة التنفيذ - Flow مقابل Apex - والتي تؤثر أيضاً على كفاءة الاستدعاءات، في [Salesforce Flow أو Apex](/ar/insights/salesforce-flow-vs-apex).

## ملخص

Salesforce API Limits ليست مشكلة يتم حلها بمجرد اكتشافها - بل هي متغير يجب أن يكون جزءًا من كل قرار تكامل منذ اليوم الأول. ميزانية طلبات موثقة حسب Integration User، اختيار واعي بين REST و Bulk بناءً على الحجم، وآلية Backoff تمنع الإغراق الذاتي - هذه الثلاثة معًا هي ما يميز المؤسسة التي تكتشف المشكلة عندما تكون محظورة بالفعل، عن المؤسسة التي ترى المشكلة تقترب قبل شهر وتتصرف في الوقت المناسب.

### أسئلة وأجوبة
**كم عدد استدعاءات واجهة برمجة التطبيقات (API Calls) التي تتلقاها المؤسسة في Salesforce، وكيف يتم تحديثها؟**
تُشتق الحصة اليومية من نوع الإصدار وعدد التراخيص وتُعاد ضبطها كل 24 ساعة في وقت ثابت، وليس في منتصف الليل حسب وقت الخادم. يقوم الإضافة 'Additional API Calls' بإضافة حزم ثابتة إذا لزم الأمر المزيد، ولكنها حل قصير المدى فقط - فإذا زاد الاستهلاك مع كل عملية تكامل جديدة، فإن المشكلة تكون معمارية وليست كمية.

**ما الفرق العملي بين REST API العادي وBulk API في سياق الحدود؟**
يحسب REST API كل استدعاء على حدة مقابل الحصة اليومية، بحيث قد يؤدي تحديث 50,000 سجل على التوالي إلى استهلاك عشرات النسبة المئوية من الميزانية بمفرده. يعمل Bulk API 2.0 على دفعات (Batches) ويتم احتسابه بتكلفة أقل بكثير لكل سجل، ولكنه غير متزامن - يجب تكييف كود الاستهلاك مع الاستقصاء عن حالة المهمة (Job) وعدم توقع استجابة فورية.

**ماذا تفعل عند استقبال خطأ REQUEST_LIMIT_EXCEEDED في منتصف عملية عمل حاسمة؟**
أوقف سلسلة الطلبات، ولا تحاول مرة أخرى فورًا بنفس الشدة. طبق آلية التراجع الأسي (Exponential Backoff) مع التذبذب (Jitter)، أرسل الطلب إلى قائمة الانتظار، ونبّه فريق التشغيل إذا استمر الحظر بعد العتبة المحددة مسبقًا. العملية التي تستمر في المحاولة بوتيرة ثابتة لا تؤدي إلا إلى إطالة فترة الحظر وتعريض العمليات الأخرى التي تشترك في نفس الحصة للخطر.

**هل يتم احتساب Platform Events أو Change Data Capture ضمن حصة الـ API؟**
الأحداث التي يتم نشرها عبر Platform Events واستلامها في CometD لا تُحتسب كاستدعاءات API عادية، وبالتالي فهي طريقة فعالة لتدفق التحديثات في الوقت الفعلي دون استهلاك من الميزانية اليومية. ومع ذلك، فإن أي استدعاء REST يقوم به المستهلك استجابةً لحدث – مثل استرداد تفاصيل السجل الكاملة – يتم احتسابه، لذا يجدر النظر في تضمين الحقول المطلوبة في نص الحدث نفسه.

**كيف تعرف مسبقًا أن عملية تكامل جديدة ستدفع المؤسسة إلى تجاوز الحد؟**
قم بتشغيل توقع بسيط: حجم السجلات اليومي مضروبًا في استدعاءات السجل (بما في ذلك السجلات المرتبطة (Related Records) وعمليات البحث (Lookups) التي يتم استردادها بشكل منفصل)، وقارن ذلك بالمبلغ المتبقي بعد عمليات التكامل الحالية. إذا تجاوزت النتيجة 70%-80% من الحصة الإجمالية، يجب التخطيط لـ Bulk، أو التخزين المؤقت (Caching)، أو تقليل الحقول قبل الانتقال إلى الإنتاج - وليس بعد الحظر الأول.

---

## هندسة النظم القائمة على الأحداث في Salesforce: Platform Events وChange Data Capture
URL: https://hpi.pro/ar/insights/salesforce-event-driven-architecture
يُقدم كل من Platform Events وCDC حلًا لمشكلة واحدة: فصل الأنظمة التي لا تحتاج إلى انتظار بعضها البعض. تبدأ المشكلة عند الاختيار بينهما بناءً على الراحة التقنية وليس بناءً على ملكية البيانات، مستوى الموثوقية المطلوب، وماذا يحدث عندما تصل الرسالة مرتين أو لا تصل على الإطلاق.

## الاختيار الذي يتجاوز التكنولوجيا

عندما تبدأ المؤسسة في مناقشة هندسة Salesforce المعتمدة على الأحداث (Event-Driven Architecture)، غالبًا ما يتجه الحديث سريعًا نحو "Platform Events أو CDC؟" – كما لو كانت المسألة تتعلق فقط بالأدوات. في الواقع، إنها قضية مختلفة تمامًا: أي طرف في التكامل هو مصدر الحقيقة، ما الذي يمكن أن يفقده، ومن يتحمل التكلفة عندما تصل رسالة متأخرة، أو متكررة، أو لا تصل على الإطلاق.

الجواب المختصر: يُعد Change Data Capture مناسبًا عندما يحتاج نظام خارجي إلى معرفة أن Salesforce قد قام بتحديث سجل، ولا توجد حاجة لتضمين ذلك في منطق العمل. أما Platform Events المخصصة فهي مناسبة عندما يراد نشر حدث عمل ذي معنى – مثل "العميل قام بترقية باقته"، وليس "تغيير الحقل Status__c". لا تظهر التكلفة الحقيقية للاختيار الخاطئ في يوم الإطلاق؛ بل تظهر عندما يحتاج شخص ما إلى استعادة ما حدث بعد فشل جزئي، ويكتشف عدم وجود طريقة موثوقة لمعرفة ذلك.

للمزيد حول النظرة الشاملة لتكاملات Salesforce بما يتجاوز الأحداث، يمكن الرجوع إلى [دليل هندسة إدارة علاقات العملاء (CRM)](/ar/insights/crm-architecture-guide).

## ثلاثة أسئلة تحدد الهندسة قبل كتابة سطر واحد من التعليمات البرمجية

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

**من هو المالك للبيانات؟** إذا كان Salesforce هو مصدر الحقيقة لسجل العميل، فإن أحداث الخروج من Salesforce (مثل Platform Event أو CDC) هي الاتجاه الطبيعي. أما إذا كان نظام ERP هو المالك، فإن الاتجاه المعاكس صحيح، ويجب أن يستهلك Salesforce الأحداث بدلاً من نشرها لنفس الكيان.

**ما الذي يمكن قبوله من فقدان؟** يمكن لتنبيه لوحة معلومات إدارية أن يفقد رسالة واحدة دون ضرر. بينما لا يمكن لتحديث رصيد ائتماني قبل الموافقة على معاملة ذلك. هذا التمييز يحدد ما إذا كانت طريقة "أرسل وانسَ" (Fire-and-Forget) كافية، أم أن هناك حاجة لآلية تأكيد ومراقبة للفجوات (Reconciliation).

**ماذا يحدث عندما تصل الرسالة مرتين؟** تضمن Platform Events مبدأ "على الأقل مرة واحدة" (At-Least-Once) وليس "مرة واحدة فقط" (Exactly-Once). إذا كانت الإجابة "لا أعرف" – فإن الحل لا يزال غير جاهز للإنتاج، بغض النظر عن مدى نظافة التعليمات البرمجية.

## مقارنة بين Platform Events و CDC – جدول اتخاذ القرار

| المعيار | Platform Event مخصص | Change Data Capture |
|---|---|---|
| ما يتم نشره | حدث عمل محدد (حمولة مخصصة) | تغيير خام في السجل (قبل/بعد) |
| من يبني المنطق | مطور Salesforce، أثناء Trigger أو Flow | المنصة، تلقائيًا لكل DML معرف |
| الاقتران بالهيكل (Schema) | منخفض – الحمولة يتم التحكم فيها بواسطة الناشر | مرتفع – أي تغيير في بنية الكائن يؤثر على المستهلك |
| مناسب عندما... | يراد نشر نية عمل ("تم تأكيد الطلب") | يراد مزامنة بيانات خام بين الأنظمة |
| تكلفة الصيانة | أعلى في البداية (بناء الحمولة والمنطق) | منخفضة في البداية، عالية عند تغيير بنية الكائن |
| الاحتفاظ (Retention) | حسب تعريف الترخيص (ساعات إلى أيام) | حسب تعريف الترخيص، غالبًا ما يكون مماثلًا لـ Platform Events |
| الحجم الموصى به | أحداث النطاق (Domain Events) بتردد متوسط | تغييرات على مستوى السجل، بما في ذلك التردد العالي |

القاعدة العملية: إذا كان مستهلك الحدث بحاجة إلى فهم "لماذا" حدث ذلك وليس مجرد "ماذا" حدث – فأنت بحاجة إلى Platform Event مخصص. أما إذا كان المستهلك بحاجة فقط إلى نسخة محدثة من البيانات – فإن CDC يوفر طبقة تطوير كاملة.

## الترتيب، الإعادة، والتكرارية (Ordering, Replay, Idempotency): المفاهيم الثلاثة التي تحول النظرية إلى إنتاج مستقر

هذه ليست مواضيع للمراحل المتأخرة من المشروع – بل تحدد بنية المستهلك منذ اليوم الأول.

**الترتيب (Ordering).** تُرسل Platform Events بترتيب النشر داخل نفس الموضوع، ولكن الحمل الزائد والفشل الجزئي يمكن أن يعطل ترتيب الاستقبال على جانب المستهلك. الحل العملي: إرفاق ختم إصدار أو رقم تسلسلي (Sequence Number) من السجل الأصلي مع كل حدث، والسماح للمستهلك برفض حدث يكون إصداره أقل من أحدث إصدار تم معالجته بالفعل.

**الإعادة (Replay).** يحصل كل حدث على معرف إعادة (Replay ID). يجب على المستهلك الذي يتعطل حفظ آخر معرف إعادة عالجه بنجاح – ليس في الذاكرة، بل في مكان دائم (مثل Custom Object أو جدول خارجي) – والمتابعة من هناك عند التعافي. الاعتماد على أن "النظام سيبدأ من جديد" يعمل فقط ضمن نافذة الاحتفاظ (Retention Window)، وخارجها تكون الأحداث مفقودة.

**التكرارية (Idempotency).** يجب أن يتعرف كل مستهلك على حدث تم معالجته بالفعل، وعادةً ما يكون ذلك من خلال معرّف معاملة فريد يُرسل ضمن الحمولة (Payload). بدون ذلك، يصبح تكرار المحاولة التلقائي (Retry) من جانب المرسل – أو الإعادة اليدوية (Replay) بعد عطل – تحديثًا مزدوجًا، أو إنشاء سجل مزدوج، أو في أسوأ الأحوال، فاتورة مزدوجة.

نادرًا ما تظهر هذه الفجوة في العرض التوضيحي. إنها تظهر عند الحمل الزائد، أو في حالة فشل شبكة حقيقي، أو عند تغيير في بيئة الإنتاج، وعندئذ تشمل تكلفة الإصلاح بالفعل إصلاح البيانات أيضًا. تجد المؤسسات التي تواجه مشكلة مماثلة في طبقة الأتمتة تحليلًا إضافيًا في [الديون التقنية في Salesforce Flow و Apex](/ar/insights/salesforce-flow-apex-technical-debt).

## سيناريو مثال: شبكة تجزئة تضم 40 فرعًا ونظام مخزون منفصل

لنفترض شبكة تجزئة افتراضية، "تجزئة الشمال"، تدير Salesforce Sales Cloud لفرق المبيعات في 40 فرعًا، ونظام ERP منفصل يدير المخزون في الوقت الفعلي. حتى الآن، كل طلب يتم إغلاقه في Salesforce كان ينتقل إلى نظام ERP عبر مهمة مجدولة تعمل كل 15 دقيقة – وهو حل أدى أحيانًا إلى رؤية الممثلين لمخزون غير محدث والموافقة على طلبات لمنتج نفد.

اختار فريق الهندسة نشر Platform Event مخصص باسم `Order_Confirmed__e` عند كل تأكيد لطلب، مع حمولة تتضمن معرّف معاملة فريد، قائمة من الأصناف والكميات. يستمع نظام ERP إلى الحدث ويحدث المخزون في غضون ثوانٍ، مع التحقق من معرّف المعاملة مقابل جدول المعاملات التي تم معالجتها بالفعل – لمنع الخصم المزدوج إذا وصل الحدث مرتين.

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

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

## المخاطر الشائعة والإجراءات الوقائية

| المخاطرة | كيف تظهر عمليًا | إجراء وقائي |
|---|---|---|
| نشر حدث عند كل تغيير في الحقل | يتم تجاوز الحد اليومي للأحداث في غضون أيام قليلة | نشر أحداث نطاق (Domain Events) ذات معنى تجاري، وليس حدثًا تقنيًا عند كل DML |
| عدم وجود فحص للتكرار على جانب المستهلك | إدخال محاولة متكررة (Retry) أو إعادة (Replay) ينشئ سجلات أو تحديثات مكررة | إرفاق معرف معاملة فريد والتحقق منه قبل كل عملية |
| الاعتماد على ترتيب الوصول | تحديث قديم يلغي تحديثًا أحدث | إرفاق ختم إصدار ورفض الأحداث الأقدم من أحدث إصدار تم معالجته |
| عدم الاحتفاظ بمعرّف الإعادة (Replay ID) | بعد تعطل المستهلك، تفقد الأحداث بين التعطل ونافذة الاحتفاظ | حفظ Replay ID في مكان دائم وتشغيل Replay تلقائي عند إعادة التشغيل |
| CDC على كائن يتغير بشكل متكرر في بنيته | أي تغيير في الحقل يكسر المستهلك الخارجي دون تحذير | تحديد عقد بيانات صريح والإبلاغ عن تغييرات المخطط مسبقًا |
| عدم وجود مراقبة للأعمال، فقط مراقبة تقنية | التكامل "يعمل" لكن المخزون أو الطلبات الفعلية لا تتطابق | إضافة تسوية يومية تقارن النتائج التجارية بين الأنظمة |

## قائمة التحقق قبل البدء في تطوير طبقة الأحداث

- ☐ لكل حدث مالك واضح: من ينشر ومن هو المالك التجاري للبيانات.
- ☐ تم تعريف حمولة (Payload) ثابتة وموثقة، وليست بنية تتغير مع كل Sprint.
- ☐ تم الاختيار بين Platform Event مخصص و CDC بناءً على نية العمل مقابل التغيير الخام.
- ☐ لكل مستهلك يوجد معرف معاملة فريد وفحص للتكرار (Idempotency).
- ☐ تم تحديد معالجة الترتيب بناءً على ختم الإصدار، وليس ترتيب الوصول.
- ☐ يتم حفظ معرف الإعادة (Replay ID) في مكان دائم وتم تعريف واختبار عملية التعافي.
- ☐ توجد مراقبة للأعمال (Reconciliation) بالإضافة إلى المراقبة الفنية لصف الرسائل.
- ☐ تم اختبار سيناريو الحمل وسيناريو الفشل الجزئي، وليس المسار السعيد فقط.
- ☐ تم التحقق من الحد اليومي للأحداث (النشر والتقديم) مقابل الحجم المتوقع في الإنتاج.
- ☐ تم تحديد مالك تشغيلي للاستجابة عند اكتشاف فجوة في التسوية (Reconciliation).

## كيفية قياس مدى فعالية الهندسة المعمارية

| المجال | ما يتم قياسه | وتيرة الاختبار |
|---|---|---|
| موثوقية التسليم | نسبة الأحداث المكتملة دون إعادة محاولة، ونسبة النجاح بعد إعادة المحاولة | مستمر |
| فجوات التسوية (Reconciliation) | الفرق بين السجلات المؤكدة للمصدر والسجلات المستلمة في الوجهة | يومي |
| زمن الاستجابة الكلي (End-to-End Latency) | الوقت بين الحدث التجاري والتحديث الفعلي لدى المستهلك | مستمر |
| استهلاك حد الأحداث | النسبة المئوية للحد اليومي المستهلك فعليًا | أسبوعي |
| التكرارات التي تم تجنبها | عدد الأحداث التي تم تحديدها على أنها مكررة وتم حظرها قبل التنفيذ | أسبوعي |

يُوصى باختيار ما لا يزيد عن ثلاثة إلى أربعة مقاييس للإصدار الأول، وقياسها مقابل خط أساس تم جمعه قبل الانتقال إلى معمارية الأحداث – وليس مقابل شعور عام بأن "الآن أصبح أسرع".

لتخطيط هيكل تنظيمي أوسع لعمليات تكامل متعددة، يُنصح بمراجعة [أنماط تكامل Salesforce](/ar/insights/salesforce-integration-patterns) والآثار المترتبة على [هندسة Salesforce ذات المؤسسة الواحدة مقابل المؤسسات المتعددة](/ar/insights/salesforce-single-org-vs-multi-org)، حيث أن قرار الأحداث غالبًا ما يتجاوز الحدود التنظيمية.

## الخلاصة

إن الاختيار بين Platform Events و CDC ليس مجرد سؤال تقني يتم فحصه لفترة قصيرة في بداية المشروع – بل يحدد من هو مصدر الحقيقة، ما الذي يمكن قبوله من فقدان، وكيف يتصرف النظام عندما يفشل شيء ما في المنتصف. المؤسسة التي تخطط مسبقًا للترتيب، الإعادة، والتكرارية (Ordering, Replay, Idempotency)، وتضيف طبقة تسوية تجارية (Business Reconciliation) إلى جانب المراقبة التقنية، ستحصل على تكامل يتحمل الحمل والفشل الجزئي. أما المؤسسة التي تتخطى هذه الخطوات فستحصل على نظام يبدو سليمًا في الاختبارات ولكنه ينهار بصمت في الإنتاج، وعادةً دون أن يلاحظ أحد حتى يحدث الضرر بالفعل.

يمكن للمؤسسات التي ترغب في الحصول على الدعم في بناء طبقة أحداث موثوقة في Salesforce التواصل عبر [خدمة هندسة إدارة علاقات العملاء (CRM)](/ar/crm-architecture).

### أسئلة وأجوبة
**متى يكون استخدام Change Data Capture أفضل من Platform Event مخصص؟**
عندما يكون Salesforce هو مصدر الحقيقة ويحتاج النظام المستهدف إلى معرفة أن سجلًا قد تغير، دون الحاجة إلى بناء منطق ينشر ذلك يدويًا. يوفر CDC هذه الطبقة ولكنه يكشف الهيكل الداخلي للكائن للمستمعين الخارجيين - حيث يؤثر كل تغيير في الحقل على المستهلك. يُفضل استخدام Platform Event مخصص عند الرغبة في نشر نية تجارية ('تم تأكيد الطلب') بدلاً من تغيير فني في سطر.

**هل تضمن Platform Events وصول الرسالة مرة واحدة فقط؟**
لا. تضمن المنصة توصيل 'مرة واحدة على الأقل' (At-Least-Once)، مما يعني أنها قد تصل مرتين في نفس سيناريو فشل الشبكة أو الإعادة (Replay). من الضروري تصميم المستهلك ليكون متكررًا (Idempotent) - للتحقق من معرف المعاملة الفريد قبل تنفيذ الإجراء - وإلا فإن التحديث المزدوج أو إنشاء سجل مكرر أو الفوترة المزدوجة هي نتيجة متوقعة وليست خللًا استثنائيًا.

**ماذا يحدث عندما يكون مستهلك الأحداث غير متاح لبضع ساعات؟**
يتم تخزين Platform Events في Event Bus وفقًا لنافذة الاحتفاظ (Retention) المحددة للترخيص (عادة 24 ساعة إلى 3 أيام)، ويمكن تشغيل الإعادة (Replay) من آخر Replay ID تم التقاطه بنجاح. يجب حفظ الـ Replay ID في جانب المستهلك وعدم الاعتماد على 'لقد تلقينا كل شيء' - إذا انقضت النافذة دون إعادة، فستفقد الأحداث بشكل دائم.

**كيف يتم الحفاظ على ترتيب التحديثات عندما تتعلق عدة أحداث بنفس السجل؟**
لا تضمن Platform Events الترتيب بين القنوات المختلفة، وأحيانًا حتى داخل نفس القناة عند التحميل الزائد. الحل الشائع هو إضافة ختم إصدار أو رقم تسلسلي لكل حدث، والسماح للمستهلك برفض تحديث وصل بإصدار أقدم من الذي تمت معالجته بالفعل، بدلاً من الاعتماد على ترتيب الوصول.

**كم عدد Platform Events التي يمكن نشرها دون التأثير على الأداء؟**
يتم قياس القيد وفقًا لعدد الأحداث في اليوم وعدد عمليات التسليم في اليوم، اعتمادًا على الإصدار والترخيص، ويتم احتسابه أيضًا على الأحداث التي فشلت في الإرسال. المشروع الذي ينشر حدثًا لكل تغيير حقل في جدول مزدحم يصل إلى الحد الأقصى بسرعة؛ لذلك، يتم نشر أحداث المجال على مستوى الأهمية التجارية وليس حدثًا تقنيًا لكل DML.

---

## SSO، MFA وإدارة الهوية في Salesforce: مبادئ التصميم المؤسسي الفعال
URL: https://hpi.pro/ar/insights/salesforce-sso-identity-architecture
يحدد كل خيار في بنية الهوية لـ Salesforce، سواء كان SAML أو OIDC، أو IdP-initiated أو SP-initiated، أو JIT أو SCIM لإدارة دورة الحياة، من يمكنه الوصول إلى النظام، وما هي صلاحياته، وماذا يحدث عند مغادرته. يقدم هذا المقال إطار عمل واضح لاتخاذ القرار، بما في ذلك سيناريو Offboarding فاشل وكيفية معالجته.

## الإجابة المختصرة

إن هندسة الهوية في Salesforce ليست مشروعًا تقنيًا لمرة واحدة، بل هي طبقة تحكم مستمرة يوميًا: من يصل، بأي هوية، بأي صلاحيات، وماذا يحدث عندما لا يُسمح له بالوصول. يبدو الاختيار بين SAML وOIDC، بين JIT وSCIM، وبين سياسة المصادقة متعددة العوامل (MFA) على مستوى موفر الهوية (IdP) أو فرضها داخليًا في Salesforce – كل ذلك يبدو تفاصيل إعدادات. لكن في الواقع، هذه القرارات تحدد المدة الزمنية المستغرقة لحجب وصول موظف مفصول، وأي جزء من هذه الحوادث سيكتشف فقط أثناء التدقيق.

النهج الصحيح لا يبدأ بالبروتوكول، بل بسؤالين: من هو مصدر الحقيقة لهوية المستخدم، وما هو الحد الأقصى للوقت المسموح به بين حدث إنهاء الخدمة (Offboarding) وحجب الوصول الفعلي. ومن هنا تُستمد جميع القرارات الأخرى – نوع الاتحاد (Federation)، طريقة توفير الحسابات (Provisioning)، سياسة الجلسات (Session Policy)، وعملية الوصول الطارئ (Break Glass).

المنظمات التي تتساءل أيضًا عن الصلاحيات نفسها وليس فقط المصادقة، ستجد المزيد في [نموذج صلاحيات Salesforce](/ar/insights/salesforce-permission-model).

## خارطة قرارات Identity في Salesforce: أربع طبقات

| الطبقة | السؤال الذي يجب حسمه | الخيارات الرئيسية | العواقب في حال اتخاذ قرار خاطئ |
| --- | --- | --- | --- |
| الاتحاد والمصادقة | من هو موفر الهوية (IdP) وكيف يثق به Salesforce | SAML 2.0, OIDC, المصادقة المفوّضة (Delegated Authentication) | تسجيل دخول مزدوج، عدم تطابق السمات (Attributes)، اختراق الثقة |
| توفير الحسابات ودورة حياتها | كيف يُنشأ المستخدم ويُحدّث ويُلغى | توفير الحسابات في الوقت المناسب (JIT Provisioning), SCIM, الإنشاء اليدوي | حسابات يتيمة، استمرار الوصول بعد المغادرة |
| الجلسة والمصادقة متعددة العوامل (MFA) | أين يتم تطبيق مستوى المصادقة ومدة الجلسة | MFA في IdP, MFA داخلي في Salesforce, سياسات الجلسة | تجاوز MFA عبر مسار بديل، جلسة لا تنتهي أبدًا |
| الوصول الطارئ (Break Glass) والتدقيق | ماذا يحدث عند تعطل الدخول الموحد (SSO) ومن يدقق في الاستثناءات | مستخدم طوارئ محكوم، سجلات الدخول (Login History), مراقبة الأحداث (Event Monitoring) | اعتماد كلي على IdP، عدم القدرة على التحقيق بأثر رجعي |

## SAML مقابل OIDC: ليس سؤالًا عن "الأحدث"

لا ينبغي أن يستند الاختيار بين البروتوكولين إلى الاتجاهات، بل إلى البنية التحتية الحالية. يعمل SAML مع XML والتأكيدات الموقعة (Signed Assertions)، وهو شائع في المنظمات التي تستخدم خدمات اتحاد Active Directory (Active Directory Federation Services) أو لديها موفر هوية (IdP) قديم يُستخدم بالفعل لعشرات الأنظمة الأخرى. OIDC مبني على OAuth 2.0، وهو أخف وزنًا في الصيانة، ومريح بشكل خاص عندما يحتاج نفس موفر الهوية إلى خدمة مستهلكي واجهة برمجة التطبيقات (API) الحديثة بالإضافة إلى دخول المستخدمين.

الخطأ الشائع هو الاختيار بناءً على ما يبدو "متقدمًا" دون التحقق من السمات (Attributes) التي يرسلها موفر الهوية (IdP) الحالي بالفعل، وكيف يتم ربطها بـ Salesforce (اسم المستخدم، معرف الاتحاد Federation ID، الملف الشخصي Profile، مجموعة الصلاحيات Permission Set Group). يؤدي ربط السمات الخاطئ في مرحلة الإعداد غالبًا إلى تصحيح يدوي لعشرات المستخدمين في بيئة الإنتاج، وليس مجرد تغيير إعداد.

نقطة غالبًا ما تُنسى: حتى عند اختيار OIDC أو SAML، من الجيد التخطيط لتسجيل الدخول الذي يبدأ من موفر الهوية (IdP-Initiated) مقابل تسجيل الدخول الذي يبدأ من مزود الخدمة (SP-Initiated) بشكل منفصل – تنشأ بعض حوادث الأمان الشائعة من بقاء تسجيل الدخول الذي يبدأ من مزود الخدمة مفتوحًا على الرغم من أن عملية تسجيل الدخول بأكملها قد تم تصميمها ليتمها فقط عبر بوابة موفر الهوية.

## JIT Provisioning مقابل SCIM: متى لا يكون "في لحظة الدخول" كافيًا

تقوم آلية التوفير في الوقت المناسب (JIT Provisioning) بإنشاء أو تحديث المستخدم في Salesforce عند أول تسجيل دخول، وفقًا للبيانات الواردة من موفر الهوية (IdP) في تأكيد SAML (SAML Assertion) أو رمز OIDC (OIDC Token). هذا مريح، ومنخفض التكلفة في التنفيذ، ويكفي لمعظم المنظمات التي يتصل فيها المستخدمون بانتظام.

المشكلة: JIT لا يحل مشكلة إلغاء توفير الحسابات (Deprovisioning). إذا تمت إزالة موظف من موفر الهوية (IdP) ولكنه لا يقوم بتسجيل الدخول بعد ذلك، يظل حسابه نشطًا في Salesforce إلى أجل غير مسمى، لأنه لا يوجد حدث يؤدي إلى التحديث. هنا يأتي دور SCIM (System for Cross-domain Identity Management) – فهو يسمح بالمزامنة الاستباقية من موفر الهوية (IdP) إلى Salesforce، بما في ذلك إلغاء التنشيط الفوري عند إزالة المستخدم من المصدر.

القاعدة العملية: إذا كان لدى المنظمة متطلب إنهاء خدمة (Offboarding) خلال ساعات وليس أيام – مثل المقاولين، الموظفين المؤقتين، الوصول إلى البيانات الحساسة – فإن SCIM ليس "ميزة إضافية مرغوبة" بل هو متطلب امتثال. إذا كانت وتيرة تغيير الموظفين بطيئة وتشمل حوكمة البيانات بالفعل مراجعة ربع سنوية للوصول، فإن JIT وحده قد يكون كافيًا بشرط أن يكون مصحوبًا بعملية يدوية موثقة للحجب الفوري.

يجب دائمًا تقييم تخطيط توفير الحسابات (Provisioning) بناءً على تعقيد الأتمتة المحيطة به – على سبيل المثال عندما تتضمن Flow منطقًا لتعيين الصلاحيات أثناء إنشاء المستخدم، حيث تكون المقارنة في [Flow مقابل Apex](/ar/insights/salesforce-flow-vs-apex) ذات صلة بشأن تحديد موضع الكود المخصص.

## MFA وسياسة الجلسات: طبقتان، لا طبقة واحدة

من الأخطاء الشائعة الاكتفاء بالمصادقة متعددة العوامل (MFA) المطبقة في موفر الهوية (Identity Provider) وافتراض أنها تغطي جميع مسارات الوصول إلى Salesforce. في الواقع، طالما كان هناك مستخدم يمكنه الاتصال مباشرة عبر login.salesforce.com – على سبيل المثال، تكامل، مستخدم واجهة برمجة التطبيقات (API User)، أو مدير يمتلك صلاحية وصول احتياطية – فإن سياسة MFA منفصلة مطلوبة ومحددة داخل Salesforce نفسها (التحقق من الهوية Identity Verification، مستويات أمان الجلسة Session Security Levels).

إلى جانب ذلك، تحدد سياسة الجلسة أمورًا يسهل إهمالها: مهلة الجلسة (Session Timeout)، "فرض تسجيل الخروج عند انتهاء مهلة الجلسة" ("Force logout on session timeout")، نطاقات عناوين IP لتسجيل الدخول (Login IP Ranges)، وجلسة عالية الضمان (High Assurance Session) الإلزامية للعمليات الحساسة (مثل تغيير الصلاحيات أو تصدير كميات كبيرة من البيانات). المنظمة التي تُفعل MFA قويًا ولكنها تترك مهلة الجلسة على الإعداد الافتراضي وهو ساعتان، تفتح نافذة زمنية يحتفظ فيها جهاز كمبيوتر مسروق بوصول نشط لفترة تتجاوز المعقول بكثير.

## Break Glass والتدقيق: عندما يتعطل الدخول الموحد، من يدخل؟

الاعتماد الكامل على موفر هوية (IdP) خارجي يخلق نقطة فشل واحدة: إذا تعطل موفر الهوية أو كان هناك خطأ في إعداد الاتحاد (Federation)، لا يمكن لأحد تسجيل الدخول، بما في ذلك من يجب أن يقوم بإصلاح المشكلة. الحل الشائع هو مستخدم "Break Glass" – وهو حساب مسؤول فائق بصلاحيات إدارية عليا مع مصادقة مستقلة (لا تعتمد على الدخول الموحد SSO)، كلمة مرور تُدار في خزنة (Vault) وليس في ذاكرة شخص، ومصادقة متعددة العوامل (MFA) منفصلة.

من المهم التمييز: "Break Glass" ليس "بابًا خلفيًا مريحًا" – بل هو آلية طوارئ محكومة. يجب أن يؤدي استخدامه إلى تشغيل تنبيه تلقائي، ويجب مراجعته في غضون يوم عمل بواسطة طرف آخر غير من استخدمه. العديد من المنظمات تنشئ هذا المستخدم بشكل صحيح ولكنها تنسى التحكم المستمر – كلمة المرور ليست متاحة دائمًا، وصلاحياته واسعة جدًا افتراضيًا.

## سيناريو تنظيمي: فشل عملية إنهاء الخدمة في شركة تأمين متوسطة الحجم

لنفترض شركة تأمين تضم ستمائة موظف، تستخدم Okta كموفر للهوية (Identity Provider) وإعداد SAML مع Salesforce تم إنشاؤه قبل حوالي ثلاث سنوات. يعتمد توفير الحسابات (Provisioning) بالكامل على JIT: عندما يقوم موظف جديد بتسجيل الدخول للمرة الأولى، يتم إنشاء مستخدم له بملف تعريف (Profile) ومجموعة صلاحيات (Permission Set Group) وفقًا للمجموعة التي ينتمي إليها في Okta.

في إحدى الحالات، تم فصل ممثل خدمة عملاء بعد ظهر يوم جمعة. قام فريق تكنولوجيا المعلومات بتعطيله في Okta على الفور. ولكن في الواقع، نظرًا لعدم وجود آلية SCIM أو Webhook لمزامنة إلغاء التنشيط مع Salesforce، ظل حساب المستخدم نشطًا هناك – ونظرًا لأن جلسته كانت نشطة بالفعل منذ الصباح ولم يتم إعداد "Force logout on session timeout"، استمر في الوصول إلى النظام حتى بعد الفصل، إلى أن لاحظ شخص ما الأمر في مراجعة الوصول الأسبوعية يوم الاثنين.

الحل الذي تم تطبيقه لم يكن انتقالًا كاملاً إلى SCIM (الذي كان سيتطلب مشروعًا منفصلًا وميزانية تكامل)، بل دمجًا فوريًا لثلاثة إجراءات: تفعيل "Force logout on session timeout" لجميع الملفات الشخصية الحساسة، وتقصير مهلة الجلسة (Session Timeout) من 120 دقيقة إلى 30 دقيقة للمناصب التي تتعامل مع العملاء، وإضافة خطوة تلقائية في عملية إنهاء الخدمة التنظيمية تُنفذ إلغاء تنشيط مباشر في Salesforce كإجراء مستقل وليس فقط نتيجة غير مباشرة لتعطيل الحساب في Okta. ظل SCIM هدفًا للربع التالي، مصحوبًا بالفعل بميزانية وموافقة، ولكن الثغرة الخطيرة تم إغلاقها في غضون أسبوع.

## المخاطر الشائعة والإجراءات الوقائية

| الخطر | كيف يظهر عمليًا | الإجراء الوقائي |
| --- | --- | --- |
| الاعتماد الكلي على JIT دون إلغاء توفير الحسابات | بقاء المستخدمين الذين غادروا نشطين إلى أجل غير مسمى | إضافة خطوة إنهاء خدمة مستقلة في Salesforce، لا تعتمد على المزامنة |
| MFA في IdP فقط | المستخدمون المسؤولون عن التكامل والمسؤولون يتجاوزون MFA عبر تسجيل الدخول المباشر | سياسة MFA داخلية في Salesforce لجميع أنواع المستخدمين |
| مهلة جلسة طويلة جدًا | جهاز كمبيوتر مسروق أو جلسة منسية مفتوحة تحافظ على الوصول لساعات | تقصير المهلة (Timeout) وفرض تسجيل الخروج (Force Logout) للملفات الشخصية الحساسة |
| Break Glass بدون رقابة | استخدام حساب الطوارئ لا يُكتشف في الوقت المناسب | تنبيه تلقائي ومراجعة خلال يوم عمل لأي استخدام |
| ربط سمات (Attributes) خاطئ من IdP | يحصل المستخدم على ملف تعريف (Profile) أو دور (Role) غير صحيح عند تسجيل الدخول الأول | اختبار كامل لربط السمات في بيئة Sandbox قبل التغيير في الإنتاج |

## قائمة التحقق لإنشاء أو مراجعة هندسة الهوية (Identity Architecture)

- ☐ تحديد موفر هوية (Identity Provider) واحد كمصدر للحقيقة، ومعرفة ما يحدث عند تعطله.
- ☐ اختيار بروتوكول (SAML أو OIDC) بناءً على البنية التحتية الحالية وليس بناءً على توجهات.
- ☐ التحقق من ربط السمات (Attributes) بين موفر الهوية (IdP) والملف الشخصي (Profile)/مجموعة الصلاحيات (Permission Set Group) في Sandbox.
- ☐ تحديد سياسة واضحة: JIT فقط، أو JIT مع SCIM وفقًا لمتطلبات إنهاء الخدمة (Offboarding).
- ☐ فرض MFA داخل Salesforce أيضًا، وليس فقط في موفر الهوية (IdP).
- ☐ تحديد مهلة الجلسة (Session Timeout) وفرض تسجيل الخروج (Force Logout) وفقًا لحساسية الملف الشخصي (Profile).
- ☐ وجود مستخدم "Break Glass" محكوم، مع MFA منفصل وكلمة مرور محفوظة في خزنة.
- ☐ عملية إنهاء الخدمة (Offboarding) تتضمن خطوة مستقلة لإلغاء التنشيط في Salesforce.
- ☐ مراجعة سجلات الدخول (Login History) ومراقبة الأحداث (Event Monitoring) بانتظام.
- ☐ وجود خطة اختبار دورية (Access Review) لا تعتمد فقط على ذاكرة قسم تكنولوجيا المعلومات.

## كيف نقيس فعالية الهندسة المعمارية؟

المقياس الرئيسي ليس "هل SSO نشط" بل هو وقت الاستجابة بين حدث في مصدر الحقيقة وتغيير مماثل في Salesforce: كم من الوقت ينقضي بين إزالة مستخدم في موفر الهوية (IdP) وإلغاء تنشيطه الفعلي. مقياس تكميلي هو نسبة عمليات تسجيل الدخول التي تتم عبر مسار غير متوقع (تسجيل دخول مباشر Direct Login بدلاً من عبر موفر الهوية)، والتي يجب أن تقترب من الصفر باستثناء حالات "Break Glass" الموثقة. مقياس ثالث هو تكرار مراجعة الصلاحيات مقابل الوضع الفعلي – ليس كل تغيير تنظيمي يأتي عبر موفر الهوية (IdP)، وبالتالي فإن المراجعة ربع السنوية تظل ضرورية حتى مع التوفير التلقائي الكامل للحسابات.

لتنفيذ أو مراجعة هندسة الهوية في بيئة Salesforce قائمة، يمكن التقدم من خلال [خدمة هندسة إدارة علاقات العملاء (CRM Architecture)](/ar/crm-architecture). المنظمات التي تستكشف أيضًا الربط مع أنظمة تخطيط موارد المؤسسات (ERP) وأنظمة الرواتب كجزء من الصورة الشاملة للهوية ستجد معلومات إضافية في [ربط Salesforce بأنظمة تخطيط موارد المؤسسات (ERP)](/ar/insights/salesforce-erp-integration)، وصورة معمارية أوسع في [دليل هندسة إدارة علاقات العملاء (CRM Architecture Guide)](/ar/insights/crm-architecture-guide).

## الخلاصة

تُبنى هندسة الهوية في Salesforce مرة واحدة ولكن تُختبر يوميًا من خلال الحوادث الفردية – موظف يغادر، جلسة تنسى أن تُغلق، تكامل يتجاوز المصادقة متعددة العوامل (MFA). القرارات الرئيسية (SAML مقابل OIDC، JIT مقابل SCIM، MFA المزدوج، Break Glass المحكوم) لا يجب أن تُستمد من إعدادات IdP الافتراضية، بل من وقت الاستجابة المطلوب لحجب الوصول ومستوى حساسية المعلومات المكشوفة. المنظمات التي تخطط لهذه الطبقة مسبقًا، بدلاً من اكتشاف الثغرات في مراجعة أو بعد حادث أمني، توفر تكلفة الإصلاح وكذلك المخاطر المتعلقة بالسمعة والتنظيم.

### أسئلة وأجوبة
**ما هو الفرق العملي بين SAML وOIDC في سياق Salesforce؟**
كلاهما مدعوم كـ Single Sign-On Provider، ولكن OIDC يعتمد على REST/JSON ويتكامل بسهولة أكبر مع IdP الحديثة والمستهلكين الإضافيين لواجهة برمجة التطبيقات (API)، بينما ينتشر SAML بشكل أكبر في المؤسسات التي لديها بنية تحتية قديمة لإدارة الهوية والوصول (IAM) أو متطلبات تنظيمية مبنية حوله. يجب أن يعتمد الاختيار على IdP الحالي في المؤسسة وليس فقط على الاعتبارات التكنولوجية - الانتقال بين الاثنين بعد بناء تعيينات السمات (Attribute Mappings) ومجموعات الأذونات (Permission Sets) حولهما هو عمل غير تافه.

**متى يجب استخدام JIT Provisioning ومتى يجب استخدام SCIM؟**
JIT مناسب عندما يكون إنشاء المستخدم وتحديثه عند أول تسجيل دخول كافيًا، وعندما لا تكون هناك حاجة حقيقية لإلغاء التزويد الفوري خارج دورة حياة SSO. يلزم SCIM عندما يكون هناك مطلب تشغيلي لإلغاء الوصول خلال دقائق من إزالة المستخدم في IdP، أي في المؤسسات التي تتطلب Offboarding فوريًا، أو المتعاقدين المؤقتين، أو اللوائح التي تتطلب إثبات المزامنة بين المصادر.

**هل MFA المفروض في IdP كافٍ، أم أنه يلزم أيضًا MFA على مستوى Salesforce؟**
إذا كانت جميع عمليات تسجيل الدخول تمر عبر IdP ولا يوجد مسار دخول مباشر إلى Salesforce، فقد يكون MFA في IdP كافيًا لتسجيل الدخول العادي. ومع ذلك، هناك حاجة دائمًا إلى سياسة MFA داخلية في Salesforce لتغطية مستخدمي Break Glass، والتكاملات مع مستخدمي الخدمة، وأي مسار يتجاوز IdP - وإلا فسيتم إنشاء ثغرة أمنية في النقطة الأكثر حساسية.

**كيف يتم إنشاء مستخدم Break Glass لا يتحول إلى ثغرة أمنية دائمة؟**
يجب أن يكون لمستخدم Break Glass كلمة مرور مُدارة في خزنة، وMFA منفصل، وصلاحيات مقيدة لدور الطوارئ فقط وليس System Administrator شامل، وإشعار تلقائي عند أي استخدام. القاعدة الملزمة هي أن كل عملية تسجيل دخول به يتم مراجعتها في غضون يوم عمل واحد، وأن هناك عملية ربع سنوية تتأكد من تغيير كلمة المرور حتى لو لم يتم استخدامها.

**ماذا يحدث عندما يغادر موظف ولا يتم مزامنة IdP مع Salesforce في الوقت الفعلي؟**
بدون SCIM أو Webhook الذي يؤدي إلى إلغاء التنشيط الفوري، يظل المستخدم نشطًا في Salesforce حتى بعد إزالته في IdP، لأن الجلسة الحالية لا يتم فحصها مقابل IdP في كل طلب. الحل العملي هو مزيج من مهلة جلسة قصيرة (Session Timeout)، ونطاقات IP لتسجيل الدخول (Login IP Ranges)، وعملية Offboarding تنفذ إلغاء التنشيط المباشر في Salesforce كخطوة مستقلة وليس فقط اعتمادًا على المزامنة البطيئة مع IdP.

---

## المشاركة والرؤية في Salesforce: تخطيط الوصول إلى المعلومات المعقدة
URL: https://hpi.pro/ar/insights/salesforce-sharing-visibility-design
إن اعتماد إعدادات OWD مفتوحة 'لتجنب حظر أي شخص' وتنمية 'Role Hierarchy' بطريقة عشوائية هو أسرع طريق لتقرير يتيح للمدير الإقليمي رؤية جميع عملاء منافسه الداخلي. يقدم هذا المقال منهجية عمل عكسية: نبدأ بتحديد من يحتاج إلى رؤية ماذا ولماذا، ثم نختار بين OWD وRole Hierarchy وSharing Rules وTeams وApex Sharing.

## لماذا يُعد نموذج المشاركة المُعاد تصميمه لاحقًا أكثر صعوبة من نموذج تم بناؤه جيدًا منذ البداية

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

يُبنى نموذج الرؤية في Salesforce من طبقات تعمل معًا لا بشكل منفصل: تحدد الأذونات الافتراضية على مستوى المؤسسة (Organization-Wide Defaults) خط الأساس الأكثر تقييدًا، وتضيف التسلسل الهرمي للأدوار (Role Hierarchy) وصولًا عموديًا وفقًا للهيكل الإداري، وتفتح قواعد المشاركة (Sharing Rules) وصولًا أفقيًا بناءً على معيار عمل، بينما تُعالج فرق العمل (Teams) والمشاركة اليدوية (Manual Sharing) الحالات الفردية، ويُستخدم مشاركة Apex المدارة (Apex Managed Sharing) عندما يكون المنطق معقدًا بحيث لا يمكن التعبير عنه بقواعد ثابتة. هذا الترتيب مهم: فأي طبقة يتم اختيارها قبل الأوان تُنشئ دينًا يصعب تفكيكه، لأن الصلاحيات الممنوحة بالفعل تُعتبر حقًا قائمًا.

## خارطة الطريق للطبقات ومتى يكون اختيار كل منها صحيحًا

| الطبقة | ماذا تحل؟ | متى تختارها؟ | المخاطر عند الاختيار الخاطئ |
|---|---|---|---|
| OWD | خط الأساس: من لا يستطيع رؤية أي شيء افتراضيًا؟ | يتم تعريفها دائمًا، وعادة ما تكون "خاصة" (Private) للكائنات الحساسة. | إذا كانت OWD مفتوحة بشكل مفرط، فإنها تجعل أي طبقة أخرى غير ضرورية. |
| Role Hierarchy | وصول عمودي للمدير إلى معلومات مرؤوسيه. | عندما يعكس الهيكل الإداري الحاجة إلى الإشراف على البيانات. | تسلسل هرمي "سياسي" لا يتوافق مع الملكية الحقيقية للبيانات. |
| Sharing Rules | فتح وصول أفقي بناءً على معيار ثابت (دور، مجموعة، قيمة حقل). | عندما يحتاج فريق متعدد المستويات الإدارية إلى الوصول إلى نفس نوع السجل. | تراكم القواعد المتداخلة التي يصعب تحديد من فتح ماذا. |
| Public Groups | تجميع المستخدمين لأغراض المشاركة، بغض النظر عن التسلسل الهرمي. | عندما لا تتوافق مجموعة عمل مع دور تنظيمي واحد. | مجموعات لا يتم تحديثها عند تغيير الموظف لدوره. |
| Account/Case Teams | وصول متغير إلى سجل فردي بناءً على تكوين فريقه. | عندما يكون لكل عميل أو حالة فريق فريد متغير. | صيانة يدوية تُنسى عند تغيير الفريق. |
| Territory Management | تخصيص الوصول بناءً على قواعد ديناميكية ومتعددة الأبعاد. | تخصيص متغير بناءً على عدة خصائص في نفس الوقت، وصول متزامن لعدة ممثلين. | تعقيد في الصيانة لا يُبرر تحت عتبة تنظيمية معينة. |
| Apex Managed Sharing | مشاركة مستمدة من منطق ديناميكي لا يمكن التعبير عنه بقاعدة ثابتة. | معيار يعتمد على حساب، حدث خارجي، أو مجموعة حقول. | التعليمات البرمجية التي تستمر في العمل بدون مراقبة بعد تغيير المتطلبات التجارية. |

## OWD: القرار الذي يحدد كل شيء آخر

OWD ليس مجرد إعداد أمان تقني – إنه إعلان تنظيمي حول من هو المالك الأساسي للمعلومات. القاعدة العملية: يتم تعيين OWD بناءً على الحالة الأكثر تقييدًا المطلوبة بالفعل، ثم يتم التوسع في الوصول من خلال Sharing Rules وليس العكس. السبب في ذلك هو أن توسيع الوصول المستهدف سهل وموثّق، بينما يتطلب تقليص الوصول الموجود بالفعل تواصلًا تنظيميًا، حيث يرى المستخدمون فقدان الوصول كضرر حتى لو كان تصحيحًا لخطأ تاريخي.

نقطة لا تحظى دائمًا بالاهتمام الكافي: يتم تعيين OWD بشكل منفصل لكل كائن، والكائنات التابعة (Master-Detail) ترث الرؤية من الكائن الرئيسي. عند بناء نموذج بيانات جديد، يجب فحص سلسلة التبعية الكاملة قبل تحديد OWD – وإلا فإن كائنًا "ثانويًا" تم تعريفه على أنه عام (Public) عن طريق الخطأ سيكشف معلومات من الكائن الرئيسي من خلاله.

## التسلسل الهرمي للأدوار (Role Hierarchy) مقابل الهيكل الإداري الفعلي

أكثر الأخطاء شيوعًا هي تكرار المخطط التنظيمي في Role Hierarchy كما هو، دون التحقق مما إذا كان يعكس أيضًا تدفق ملكية البيانات. يحتاج المدير الإقليمي إلى رؤية فرص فريقه – وهذا دور إداري. لكن المدير المالي لا يحتاج إلى رؤية كل حالة خدمة تلقائيًا لمجرد أنه أعلى في التسلسل الهرمي العام؛ إذا كانت هناك حاجة من هذا القبيل، فسيتم حلها بواسطة Sharing Rule مستهدف وليس تسلسل هرمي واسع جدًا.

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

## مصفوفة اتخاذ القرار: ما الذي يُشغّل كل آلية مشاركة؟

- **الحاجة تتغير وفقًا لدور ثابت ويمكن التنبؤ بها مسبقًا** ← Role Hierarchy.
- **الحاجة مشتركة لمجموعة عمل متعددة المهام** ← Public Group + Sharing Rule.
- **الحاجة تتغير وفقًا لتكوين الفريق في سجل واحد** ← Account Team أو Case Team.
- **الحاجة تعتمد على مجموعة من الشروط الديناميكية (الجغرافيا، المنتج، حجم العميل)** ← Territory Management.
- **الحاجة مستمدة من حساب، حدث خارجي أو شرط لا يمكن التعبير عنه بقاعدة ثابتة** ← Apex Managed Sharing.
- **الحاجة هي استثناء نقطي ومؤقت لسجل واحد** ← Manual Sharing، مع المراقبة والتوثيق.

يجب كتابة هذه المصفوفة قبل العمل على الأدوات، وليس بالتوازي معها – وإلا فإننا سنختار آلية بناءً على ما هو مألوف لفريق التطوير وليس بناءً على ما يناسب الحاجة.

## سيناريو توضيحي: شركة مصنعة للمعدات الصناعية بثلاث قنوات بيع

لنفترض شركة تصنيع معدات صناعية افتراضية لديها حوالي 180 مستخدمًا لـ Salesforce، وتعمل بثلاث قنوات: البيع المباشر حسب المنطقة الجغرافية، والبيع عبر الموزعين، والبيع للحسابات الاستراتيجية العالمية التي يديرها عدة ممثلين في بلدان مختلفة في نفس الوقت.

فشلت المحاولة الأولية لاستخدام Role Hierarchy فقط: لم يكن حساب استراتيجي عالمي ينتمي إلى تسلسل هرمي إقليمي واحد، ولم ير ممثل في ألمانيا تحديثات زميله في البرازيل حول نفس الحساب. الحل المختار دمج ثلاث طبقات: تم تعيين OWD على Account وOpportunity كـ Private؛ استُخدم Role Hierarchy للوصول الإداري العادي داخل كل منطقة؛ وللحسابات الاستراتيجية، تم تعريف Account Team ديناميكي يتم تحديثه تلقائيًا باستخدام Flow عندما يتغير حقل "Strategic Account Owner Region". حصل الموزعون على وصول منفصل عبر Sharing Rule قائم على Public Group مخصص، حتى لا يتعرضوا لحسابات البيع المباشر.

النتيجة: ظل وقت إعادة حساب المشاركة (Sharing Recalculation) مستقرًا، لأن معظم الوصول مستمد من هيكل ثابت (Role, Public Group) ونسبة قليلة فقط من الحسابات – الاستراتيجية – تعتمد على التحديث الديناميكي. الدرس الرئيسي: ليس هناك آلية واحدة "صحيحة" للمؤسسة بأكملها؛ يجب تكييف الآلية مع نوع تبعية كل مجموعة فرعية من السجلات. يتوفر المزيد من التفاصيل حول اختيار أنماط التكامل ونموذج البيانات الداعم في [دليل هندسة إدارة علاقات العملاء (CRM)](/ar/insights/crm-architecture-guide).

## مخاطر خاصة بتخطيط الرؤية وإجراءات وقائية

| المخاطر | كيف تظهر عمليًا | إجراءات وقائية |
|---|---|---|
| OWD مفتوح "مؤقتًا" في مرحلة التجربة | يبقى الفتح حتى بعد انتقال النظام إلى الإنتاج الكامل. | تحديد تاريخ إغلاق مسبق وتوثيقه كعنصر Go-Live، وليس كتوصية. |
| كثرة قواعد المشاركة (Sharing Rules) المتداخلة | لا يمكن معرفة سبب رؤية المستخدم لسجل معين على وجه اليقين. | تسمية قياسية لكل قاعدة تتضمن السبب التجاري، ومراجعة دورية للقواعد غير المستخدمة. |
| مشاركة Apex بدون اختبارات الأداء تحت الضغط | تأخر في حساب المشاركة مع زيادة حجم البيانات. | إجراء اختبار تحميل على Sharing Recalculation قبل مضاعفة حجم السجلات في الإنتاج. |
| تسلسل هرمي للمشاركة منقول من تسلسل هرمي تنظيمي "سياسي" | يرى المديرون بيانات لا توجد لديهم حاجة تجارية إليها. | فصل التسلسل الهرمي للأدوار لأغراض المشاركة عن التسلسل الهرمي الرسمي للتقارير عندما لا يكونا متطابقين. |
| تراكم المشاركة اليدوية (Manual Sharing) بدون مالك | تبقى الأذونات الاستثنائية بعد أن يصبح سبب المشاركة غير ذي صلة. | عملية انتهاء الصلاحية أو مراجعة ربع سنوية للمشاركات اليدوية. |
| تغيير دور المستخدم دون تحديث المجموعات العامة | يبقى الوصول القديم مفتوحًا ويُفقد الوصول الجديد. | دمج تحديث المجموعات والأدوار كخطوة واحدة في عملية تغيير حالة الموظف. |

## قائمة التحقق قبل إغلاق نموذج المشاركة

- ☐ تم إعداد OWD وفقًا للوضع الأكثر تقييدًا المطلوب، وليس للراحة في مرحلة التطوير.
- ☐ تم فحص سلسلة التبعية بين كائنات Master-Detail مقابل OWD للكائن الرئيسي.
- ☐ تم فحص Role Hierarchy مقابل الملكية الحقيقية للبيانات، وليس فقط مقابل المخطط التنظيمي.
- ☐ لكل Sharing Rule سبب تجاري موثق ومالك مسؤول عن صلاحيته.
- ☐ تم التحقق مما إذا كانت Territory Management مطلوبة بالفعل أم أنها تعقيد غير ضروري.
- ☐ تم اختبار رمز Apex Sharing تحت حجم بيانات واقعي، وليس فقط في بيئة Sandbox صغيرة.
- ☐ توجد عملية لتحديث المجموعات العامة والأذونات عند تغيير الدور أو إنهاء الخدمة.
- ☐ تم تحديد معدل مراجعة دورية لـ Manual Sharing و Sharing Rules غير النشطة.
- ☐ تم فحص تأثير نموذج المشاركة على أداء التقارير وتشغيل الدفعات الكبيرة.
- ☐ توجد خطة استجابة لحالة الكشف المفرط الذي تم اكتشافه في الإنتاج.

## كيف تعرف أن النموذج يتحمل الضغط؟

المقياس الأول هو وقت إعادة حساب المشاركة (Sharing Recalculation) بعد التغيير الهيكلي – فالزيادة المستمرة بمرور الوقت تشير إلى أن النموذج يقترب من تعقيد غير مخطط له. المقياس الثاني هو عدد طلبات الدعم من نوع "ليس لدي وصول" مقابل "لدي وصول غير ضروري" – نسبة تميل بشدة في اتجاه واحد تشير إلى أن OWD أو Sharing Rules ليست معايرة بشكل صحيح. المقياس الثالث، وهو مهم بشكل خاص في المؤسسات التي تحتوي على أنظمة متعددة، هو التوافق بين أذونات Salesforce والأذونات في الأنظمة المتزامنة معه – خاصة عندما يتعلق الأمر بهندسة التكامل القائمة على الأحداث، كما هو موضح في [دليل هندسة الحلول المعتمدة على الأحداث في Salesforce](/ar/insights/salesforce-event-driven-architecture).

في المؤسسات التي تُشغّل عدة بيئات (Orgs)، غالبًا ما تختلط قضية نموذج المشاركة مع السؤال عما إذا كان هناك حاجة لأكثر من بيئة إنتاج واحدة على الإطلاق – النقاش الكامل حول هذا موجود في [Salesforce Single Org مقابل Multi Org](/ar/insights/salesforce-single-org-vs-multi-org)، وفي اختيار نمط التكامل المتوافق في [دليل أنماط تكامل Salesforce](/ar/insights/salesforce-integration-patterns).

## الخلاصة

لا يُقاس نموذج المشاركة والرؤية الجيد في يوم الإطلاق – بل يُقاس عندما تنمو المؤسسة، وعندما ينتقل المستخدم إلى دور آخر، وعندما يسأل أحدهم "لماذا لا أرى هذا؟". الطريقة للوصول إلى ذلك ليست اختيار أداة واحدة وتطبيقها على كل شيء، بل رسم خرائط لكل مجموعة من السجلات حسب نوع اعتماديتها – ثابتة، أفقية، ديناميكية، أو استثنائية – واختيار الآلية المناسبة لكل منها. OWD مغلقة افتراضيًا، Role Hierarchy يعكس الملكية الحقيقية، Sharing Rules بوجود سبب موثق، و Apex Sharing فقط عندما يبرر المنطق ذلك – هذه هي المجموعة التي تصمد حتى عندما تتضاعف المؤسسة في الحجم والتعقيد.

### أسئلة وأجوبة
**هل يمكن البدء بإعدادات OWD مفتوحة وإغلاقها لاحقًا؟**
تقنياً نعم، ولكن عملياً ينتهي الأمر دائمًا بالعكس: بمجرد أن يعتاد المستخدمون ومقدمو التقارير على رؤية كل شيء، يُنظر إلى أي عمليات إغلاق لاحقة على أنها تقييد وتثير مقاومة. الاتجاه الصحيح هو العكس – البدء بإعدادات مغلقة وفتح الوصول بشكل انتقائي من خلال Sharing Rules عند ظهور حاجة حقيقية.

**متى يجب استخدام Sharing Rule ومتى Apex Managed Sharing؟**
تناسب Sharing Rule الحالات التي تُشتق فيها معايير المشاركة من حقل ثابت أو من عضوية في وظيفة/مجموعة عامة. بينما يتطلب Apex Sharing عندما تعتمد المعايير على منطق يتغير أثناء التشغيل – مثل المشاركة المستندة إلى مزيج من الحقول، أو نتيجة حساب، أو حدث في نظام خارجي.

**هل يستحق Territory Management تعقيده حتى في المؤسسات المتوسطة؟**
في الغالب لا، إلا إذا توفر أحد الشروط التالية على الأقل: يتغير تخصيص العملاء وفقًا لعدة خصائص متزامنة (الجغرافيا، الصناعة، الحجم)، أو تتطلب الحاجة وصولاً متزامنًا لعدة مندوبين إلى نفس السجل، أو لم تعد الهياكل التنظيمية وهياكل المشاركة متطابقة. دون هذا الحد، تُعد Role Hierarchy وSharing Rules كافية وأبسط في الصيانة.

**كيف يمكن تحديد أن نموذج المشاركة لم يعد مناسبًا للمؤسسة؟**
تتمثل العلامات العملية في: تزايد وقت Share Recalculation مع كل تشغيل، وتكرار طلبات الدعم من نوع 'لا أرى سجلاً من المفترض أن أراه'، والاعتماد المتزايد على Manual Sharing النقطي كحل بديل، والشكاوى بأن التقارير الإدارية تظهر أرقامًا مختلفة حسب من يقوم بتشغيلها.

**ماذا يحدث لنموذج المشاركة عند نقل مستخدم بين الأدوار أو الأقسام؟**
يؤدي أي تغيير في الدور إلى إعادة حساب Role Hierarchy Sharing، وإذا كانت هناك أيضًا Sharing Rules تعتمد على المجموعات العامة، فيجب التأكد من تحديث بيانات المستخدم هناك أيضًا – فالآليتان لا تتزامنان تلقائيًا. يجب على المؤسسات التي تُجري تغييرات هيكلية متكررة أن تتبنى عملية محددة، تشمل التحقق من إغلاق الوصول القديم وليس فقط فتح وصول جديد.

---

## معالجة أخطاء ومراقبة تكاملات Salesforce من البداية للنهاية
URL: https://hpi.pro/ar/insights/salesforce-integration-error-handling
غالباً ما تنجم معظم أعطال التكامل التي تصل إلى العملاء ليس عن فشل واجهة برمجة التطبيقات (API)، بل عن رسالة فشلت بصمت ولم يكتشفها أحد. يستعرض هذا المقال عملية معالجة الأخطاء عبر أربع طبقات: Idempotency، Retry، Dead Letter، و Reconciliation، ويوضح أين تنهار كل منها عملياً.

## لماذا تنجح عملية التكامل في بيئة العرض وتفشل بصمت في نظام الإنتاج؟

في اختبار القبول القياسي، تُرسل رسالة واحدة، ويُلاحظ وصولها، ثم تُعتمد. في نظام الإنتاج، تُعالج عملية التكامل نفسها آلاف الرسائل يوميًا، وبعضها سيفشل – بسبب انتهاء المهلة (Timeout)، أو قفل السجل (Row Lock)، أو انتهاء صلاحية التفويض (Authorization)، أو تغيير المخطط (Schema) في النظام الآخر. السؤال الذي يحدد جودة الحل ليس "هل يعمل التكامل"، بل "ماذا يحدث عندما لا يعمل، ومن يلاحظ ذلك".

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

## الطبقات الأربع التي تشكل المعالجة الصحيحة للأخطاء

| الطبقة | ماذا تحل | الفشل النموذجي بدونها |
|---|---|---|
| Idempotency | إعادة تشغيل نفس الرسالة لا يؤدي إلى إنشاء سجل مكرر | طلب مزدوج أو حركة مخزون مزدوجة بعد إعادة المحاولة |
| Retry مع Backoff | الفشل المؤقت (Timeout, Rate Limit) يُصحح تلقائيًا | الحمل اللحظي يتحول إلى عطل دائم |
| Dead Letter Queue | الفشل غير المؤقت يُعلَم به ولا يختفي بصمت | رسالة "تُبتلع" ويعتقد الطرفان أنها عُولجت |
| Reconciliation الأعمال | تُكتشف الفروقات في البيانات التي لم تستطع أن تفشل بوضوح | تقرير شهري يكشف فرقًا يصعب تتبع مصدره |

كل طبقة تعتمد على سابقتها. إعادة المحاولة (Retry) بدون تميز العملية (Idempotency) يؤدي إلى تكرار البيانات؛ قائمة الرسائل المتوفاة (Dead Letter) بدون تسوية الأعمال (Reconciliation) تخفي حقيقة أن الرسائل التي نجحت "تقنيًا" لم تعكس بالضرورة الوضع التجاري الصحيح.

## Idempotency: المفتاح الذي يمنع التكرار

أي عملية تكامل يمكنها استقبال نفس الرسالة أكثر من مرة – وكل عملية تكامل تقريبًا كذلك – تحتاج إلى مفتاح فريد خارجي (External ID) يحدد الحدث، وليس فقط السجل. في Salesforce، التنفيذ الشائع هو Upsert بناءً على حقل External ID مع قيد فريد (Unique Constraint)، بالإضافة إلى جدول سجل (Custom Object أو Platform Event Log) يسجل أي معرفات أحداث تم التعامل معها بالكامل.

الخطأ الشائع: الاكتفاء بـ Upsert على السجل التجاري نفسه (مثل Order External ID) دون توثيق الخطوات الوسيطة. إذا كانت العملية تتضمن أيضًا تحديث المخزون في نظام خارجي، فإن Upsert على الطلب لا يمنع استدعاءً مزدوجًا لتحديث المخزون – يجب أن يكون كل إجراء فرعي له تأثير جانبي خارجي (Side Effect) متميزًا بذاته (Idempotent)، وليس فقط السجل النهائي.

## Retry: سياسة التراجع وتصنيف الأخطاء

ليست كل الأخطاء تستحق إعادة المحاولة (Retry). يجب الفصل مسبقًا بين ثلاث فئات:

- **الأخطاء المؤقتة** (Timeout, 503, Rate Limit) - مرشحة لإعادة المحاولة مع التراجع الأسي (Exponential Backoff)، أي أن الفاصل الزمني بين المحاولات يزيد (على سبيل المثال 30 ثانية، دقيقتين، 10 دقائق) لتجنب تفاقم الحمل.
- **الأخطاء الهيكلية** (حقل إلزامي مفقود، انتهاك قاعدة التحقق، قيمة غير صالحة) - لن تُعاد محاولتها، لأنها ستفشل مرة أخرى بنفس الطريقة. يجب أن تنتقل مباشرة إلى قائمة الرسائل المتوفاة (Dead Letter).
- **أخطاء التفويض أو التكوين** (رمز مميز منتهي الصلاحية، تغيير إصدار الـ API) - تتطلب تنبيهًا فوريًا للفريق التقني، لأنها تحجب جميع الرسائل في قائمة الانتظار وليس رسالة واحدة فقط.

في Salesforce، يُنفذ Retry عادةً في طبقة Middleware أو في Apex Queueable/Batch مع عداد محاولات محفوظ على السجل نفسه. عدد المحاولات المعقول لمعظم الحالات هو 3-5 مع التراجع (Backoff)، وليسRetry  غير محدود – إعادة المحاولة غير المحدودة تحول عطلًا مؤقتًا إلى حمل مستمر على كلا النظامين.

## Dead Letter Queue: حيث "تعيش" الرسائل الفاشلة

قائمة الرسائل المتوفاة (Dead Letter) ليست مجرد مكان تخزين – إنها عقد. يجب أن تحتوي كل رسالة تصل إليها على: معرف حدث أصلي، حمولة كاملة (Payload)، سبب فشل مصنّف، عدد المحاولات التي تمت، ووقت الدخول إلى قائمة الانتظار. بدون هذه المعلومات، يصبح "التعامل" مع قائمة الرسائل المتوفاة مجرد تخمين.

نهجان شائعان للتنفيذ في Salesforce:

1. **كائن مخصص مخصص** (`Integration_Failed_Message__c`) مع حقول منظمة وعرض قائمة (List View) حسب نوع الخطأ – مناسب عندما تكون الشفافية مطلوبة للفريق التجاري داخل Salesforce نفسه.
2. **قائمة انتظار خارجية في طبقة Middleware** (مثل Dead Letter Exchange في MuleSoft/Boomi) – مناسب عندما يراقب الفريق التقني من خارج Salesforce ويريد تجنب الحمل على المنظمة (Org).

يعتمد الاختيار على من يجب أن يتخذ إجراءً بشأن الفشل: إذا كان مالك عملية تجارية، فعليه رؤية ذلك داخل Salesforce؛ إذا كان فريق تكامل تقني، فمن الأفضل في الطبقة الخارجية.

## التسوية التجارية (Business Reconciliation): الفحص الذي يكشف ما لم تلتقطه إعادة المحاولة

حتى مع Idempotency وRetry المثاليين، هناك حالات فشل "تنجح" من الناحية التقنية ولكنها تخلق فجوة تجارية – على سبيل المثال، رسالة تم استلامها ومعالجتها، ولكن بقيمة خاطئة تم الحصول عليها من مصدر بيانات غير محدث. التسوية التجارية هي عملية دورية (يومية، كل ساعة، حسب معدل الأحداث) تقارن عددًا أو مجموعًا تراكميًا بين النظامين – على سبيل المثال، عدد الطلبات التي تم إنشاؤها في ERP مقابل عدد الطلبات التي تم إنشاؤها في Salesforce لنفس اليوم – وتسلط الضوء على الفجوات قبل أن تتحول إلى مشكلة خدمة للعملاء.

لا تتطلب عملية تسوية جيدة فحص حقل تلو الآخر لكل سجل؛ يكفي مجموع تحققي (Checksum) أو عد تراكمي يشير إلى متى يجب الانتقال إلى التفاصيل. في معظم المنظمات، يكفي التكرار اليومي؛ في العمليات المالية أو الحرجة (الطلبات، الفواتير)، يتطلب الفحص في غضون بضع ساعات.

## إطار العمل لاتخاذ القرار: متى تكون كل طبقة إلزامية ومتى يمكن الاستغناء عنها

| المعيار | Idempotency إلزامي | Retry تلقائي إلزامي | Dead Letter منفصل إلزامي | Reconciliation يومي إلزامي |
|---|---|---|---|---|
| يؤدي الحدث إلى حركة مالية أو مخزون | نعم | نعم | نعم | نعم |
| الحدث أحادي الاتجاه، للقراءة فقط (Read) | غير حاسم | نعم | لا | لا |
| حجم رسائل يتجاوز 500 رسالة يوميًا | نعم | نعم | نعم | موصى به |
| شريك خارجي بدون اتفاقية مستوى خدمة (SLA) عالية التوفر | نعم | نعم، مع Backoff طويل | نعم | موصى به |
| تكامل بين كائنين غير ماليين بحجم منخفض | موصى به | موصى به | غير ضروري | لا |

القاعدة التي توجه هذا الجدول: كلما كان للفشل تأثير مالي أو غير قابل للإلغاء (شحن، فوترة، تحديث مخزون)، تنتقل الطبقات الأربع جميعها من "مرغوبة" إلى "إلزامية" – بغض النظر عن الحجم.

## سيناريو مثال: بائع تجزئة مع مزامنة طلبات ثنائية الاتجاه

تُدير شركة بيع بالتجزئة لديها 40 فرعًا Salesforce لإدارة طلبات B2B ونظام ERP خارجي للمخزون والفواتير. تم بناء التكامل في الأصل باستدعاء REST بسيط: عندما يُنشأ طلب في Salesforce، يقوم استدعاء متزامن بإنشائه في ERP. بدون Retry، بدون Dead Letter.

خلال فترة الذروة (الجمعة السوداء)، بدأ نظام ERP بإرجاع مهلة (Timeout) في حوالي 3% من الاستدعاءات. بدون آلية Retry، اختفت هذه الـ 3% ببساطة – ظل الطلب في Salesforce في حالة "تم الإرسال" دون أن يعرف نظام ERP عنه. في غضون يومين، تراكم حوالي 140 طلبًا لم تصل إلى عملية التعبئة، وتم اكتشافها فقط عندما اتصل العملاء للاستفسار عن بضاعتهم.

الحل الذي تم بناؤه بعد ذلك: طبقة Queueable في Apex تُعيد المحاولة حتى 5 مرات مع تأخير زمني (Backoff) قدره 1/5/15/30/60 دقيقة؛ حقل `ERP_Sync_Status__c` بقيم Pending/Synced/Failed؛ كائن مخصص (`Integration_Failed_Message__c`) يجمع الإخفاقات النهائية مع زر "أعد المعالجة" لفريق العمليات؛ وتقرير تسوية يومي يقارن عدد الطلبات بين الأنظمة ويرسل تنبيهًا (Slack Alert) عندما يتجاوز الفرق الصفر. انخفض وقت الكشف عن مشكلة مماثلة من يومين إلى أقل من ساعة.

## المخاطر الشائعة والإجراءات الوقائية

| الخطر | كيف يبدو في الواقع | إجراء وقائي |
|---|---|---|
| Retry غير محدود في خطأ هيكلي | نفس الرسالة تفشل مرارًا وتكرارًا وتولد حملًا | تصنيف الأخطاء مسبقًا وإرسال الأخطاء الهيكلية مباشرة إلى Dead Letter |
| غياب مفتاح فريد للحدث | Retry أو استدعاء مزدوج يؤدي إلى إنشاء سجل مكرر | External ID على الحدث، وليس فقط على السجل النهائي |
| Dead Letter بدون مالك (Owner) | تتراكم الرسائل ولا يقوم أحد بإغلاقها | تحديد مالك و SLA للمعالجة حسب نوع الحدث، وليس حسب النظام |
| مراقبة تقنية فقط (حالة API) | التكامل "أخضر" لكن معلومات العمل غير متطابقة | إضافة Reconciliation يقارن النتائج التجارية، وليس فقط كود الاستجابة |
| Backoff ثابت وقصير جدًا | المحاولات المتكررة تزيد الحمل أثناء عطل واسع النطاق | Exponential Backoff مع سقف محدد لعدد المحاولات |

## قائمة التحقق قبل اعتماد تصميم معالجة الأخطاء

- ☐ لكل حدث مفتاح فريد (External ID) يمنع التكرار عند إعادة التشغيل.
- ☐ تُصنف الأخطاء مسبقًا إلى مؤقتة / هيكلية / تفويض، مع معالجة مختلفة لكل نوع.
- ☐ توجد سياسة Backoff محددة مع أقصى عدد للمحاولات.
- ☐ توجد قائمة رسائل متوفاة (Dead Letter) سهلة الوصول تحتوي على حمولة كاملة (Payload) وسبب الفشل.
- ☐ يوجد مالك (Owner) واتفاقية مستوى خدمة (SLA) محددة لكل نوع من أنواع الفشل.
- ☐ توجد عملية تسوية (Reconciliation) دورية تقارن النتائج التجارية بين الأنظمة.
- ☐ تصل التنبيهات إلى قناة يتم قراءتها بالفعل (وليس فقط إلى السجلات).
- ☐ يتضمن سيناريو الاختبار توقف خدمة النظام الآخر، وليس فقط المسار السعيد (Happy Path).

## كيف يترابط هذا مع باقي البنية الأساسية

لا يقف تصميم معالجة الأخطاء بمفرده – فهو يعتمد على طبقة البيانات والأذونات المحددة في [دليل بنية CRM](/ar/insights/crm-architecture-guide)، وعلى قرار ما إذا كان المنطق ينفذ في Flow أو Apex وفقًا لـ [Salesforce Flow أو Apex](/ar/insights/salesforce-flow-vs-apex). يجب مراجعة نموذج الأذونات الذي تكتب مكونات التكامل من خلاله إلى البيانات مقابل [نموذج أذونات Salesforce](/ar/insights/salesforce-permission-model)، لضمان عدم حصول المستخدم التقني للتكامل على وصول واسع النطاق للغاية. وعندما يزداد حجم الرسائل، تتلاقى مسألة إعادة المحاولة (Retry) مباشرة مع قيود API المفصلة في [حدود Salesforce API](/ar/insights/salesforce-api-limits-resilience).

## الملخص

معالجة أخطاء التكامل ليست ميزة تُضاف في النهاية – إنها الفرق بين نظام يُكتشف أنه معطل بعد شكوى من العميل، ونظام ينبه بنفسه قبل تراكم الضرر. الطبقات الأربع – Idempotency، Retry المصنفة، Dead Letter مع مالك، والتسوية التجارية – لا تتطلب مشروعًا منفصلاً، لكنها تتطلب قرارًا صريحًا في مرحلة التصميم، قبل أن يتم نشر أول عملية تكامل في نظام الإنتاج. المنظمة التي تحذر نفسها عند فشل 3% من الرسائل في غضون ساعة تختلف جوهريًا عن المنظمة التي تكتشف ذلك من عميل غاضب.

### أسئلة وأجوبة
**ما الفرق بين المحاولة التلقائية (Automatic Retry) وقائمة الرسائل المعطلة (Dead Letter Queue)؟**
Retry يحاول إعادة تنفيذ استدعاء فاشل بسبب مشكلة مؤقتة – مثل Timeout، أو قفل صف، أو تحديد معدل الطلبات – بناءً على سياسة Backoff محددة. عندما تنفد محاولات إعادة التنفيذ أو يتم تصنيف الخطأ على أنه غير قابل للإصلاح (على سبيل المثال، حقل إلزامي مفقود)، تنتقل الرسالة إلى Dead Letter Queue: وهو مكان تنتظر فيه معالجة يدوية أو تلقائية منفصلة، دون إعاقة باقي قائمة الانتظار.

**كيف نحافظ على Idempotency عندما يرسل نظام خارجي نفس الرسالة مرتين؟**
يجب أن يكون هناك مفتاح خارجي فريد (External ID) يحدد الحدث وليس فقط السجل، بالإضافة إلى التحقق من الوجود قبل الإنشاء (Upsert) باستخدام نفس المفتاح. إذا كان الحدث يتضمن أيضاً عملية مالية أو تغيير في المخزون، فستكون هناك حاجة إلى جدول سجل منفصل يسجل معرّفات الأحداث التي تم التعامل معها بالفعل، حتى لا يؤدي التشغيل المزدوج إلى حركة مزدوجة.

**ما المدة المسموح بها لترك رسالة عالقة في Dead Letter قبل أن تصبح مشكلة تجارية؟**
لا توجد إجابة شاملة – هذا يعتمد على العملية. قد يؤدي عدم تزامن طلب ما خلال ساعة إلى تسليم مزدوج؛ في حين يمكن لتحديث تفاصيل الاتصال أن ينتظر يوماً. القاعدة العملية هي تحديد اتفاقية مستوى الخدمة (SLA) للمعالجة بناءً على نوع الحدث وليس نوع النظام، والتأكد من ترجمة هذا الـ SLA إلى تنبيه حقيقي وليس مجرد سطر في السجل.

**من المسؤول عن رسالة عالقة – فريق Salesforce أم فريق النظام الآخر؟**
يجب أن تكون المسؤولية التشغيلية على عاتق من يمتلك طبقة التكامل، وليس على أحد النظامين بشكل منفصل. إذا لم تكن هناك طبقة تكامل وتنتقل الرسالة من نقطة إلى نقطة، فيجب تحديد جدول تصعيد مسبقاً: أي نوع من الأخطاء يذهب إلى فريق Salesforce، وأي نوع إلى مالك الـ API الخارجي، ومن يقرر خلال كم من الوقت عندما يكون الأمر غير واضح.

**هل يحل Middleware تلقائياً مسألة معالجة الأخطاء؟**
لا. أدوات Middleware (مثل MuleSoft، Boomi، أو أي منصة iPaaS أخرى) توفر البنية التحتية لـ Retry، Queue، والمراقبة، ولكن سياسة Backoff، وتصنيف الأخطاء، والتسوية التجارية لا يزال يجب تعريفها من قبل المنظمة. الأداة بدون سياسة تنتج سجلاً مفصلاً للفشل لا يقوم أحد بإغلاقه.

---

## الديون التقنية في Flows وApex: كيفية تحديدها وتقليصها دون إعاقة عملية التطوير
URL: https://hpi.pro/ar/insights/salesforce-flow-apex-technical-debt
لا تنشأ الديون التقنية في أتمتة Salesforce من اختيار خاطئ بين Flow وApex، بل من مئات القرارات الصغيرة التي تُتَّخذ دون سياسة واضحة أو رؤية تراكمية. يوضح هذا المقال كيفية تحديد هذه الديون عمليًا — عبر الأرقام، وليس مجرد الشعور — وكيفية بناء خطة لتقليصها دون إبطاء وتيرة التطوير.

## لماذا يختلف الدين التقني في الأتمتة عن الدين التقني الاعتيادي

في Salesforce، تتراكم الديون التقنية بسهولة أكبر مما هي عليه في بيئة تطوير نموذجية؛ وذلك لأن الأداة تمكّن أي شخص من إضافة الأتمتة دون المرور بعملية برمجية منظمة. كل مسؤول نظام يضيف Flow Before Save لحل مشكلة محددة، وكل Trigger أضيف منذ عامين ولا يتذكر أحد الغرض منه، وكل حقل صيغة يعتمد على حقل آخر لم يعد موجودًا – كل هذه الأمور تتراكم لتشكّل طبقة لا يمكن رؤيتها بشكل كامل.

يكمن الاختلاف الجوهري بين الدين التقني الاعتيادي والدين التقني في أتمتة Salesforce في أن الأخير يكاد يكون دائمًا خاليًا من التوثيق المركزي. فالتعليمات البرمجية موجودة في المستودع (Repository) مع سجل التزامات (Commits history)، بينما يوجد Flow في Setup بدون شرح لسبب إنشائه. هذا يجعل مرحلة التحديد صعبة للغاية – ليس لأن المشكلة معقدة تقنيًا، بل لأنه لا يوجد من يمكن سؤاله.

تتناول هذه المقالة تحديد وقياس وتقليل هذا الدين. وهي لا تناقش متى يجب اختيار Flow ومتى يجب اختيار Apex من الأساس – لذلك خُصص مقال [Flow مقابل Apex: كيف تختار](/ar/insights/salesforce-flow-vs-apex).

## ثلاثة أنواع من الديون تتصرف بشكل مختلف

ليس كل دين تقني متماثلًا، ومعالجة جميعها على أنها نفس المشكلة يؤدي إلى إهدار الجهد. من الأفضل تقسيمها إلى ثلاث فئات:

| نوع الدين | مثال نموذجي | ماذا يحدث إذا تم تجاهله | أولوية المعالجة |
|---|---|---|---|
| دين هيكلي | عدة Triggers على نفس الكائن بدون إطار عمل موحّد | ترتيب تنفيذ غير متوقع، فشل صامت | عالية |
| دين منطقي | Flow بعشرات من فروع اتخاذ القرار يمثل قاعدة عمل تغيرت بالفعل | قرارات خاطئة تعمل بصمت | عالية |
| دين صيانة | حقول، Flows، ومتغيرات ثابتة بدون توثيق أو استخدام | إطالة وقت التطوير، خوف من التعديل | متوسطة |

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

## كيف يتم تحديد الديون قبل أن تنفجر في بيئة الإنتاج

لا ينبغي أن يبدأ التحديد بمراجعة يدوية شاملة للتعليمات البرمجية – فهذا مكلف جدًا وغير مستدام. يبدأ الأمر ببعض المقاييس الكمية التي يمكن استخراجها في غضون ساعة:

- **عدد الـFlows النشطة على كل كائن أساسي** (مثل Lead, Opportunity, Case). تجاوز خمسة أو ستة Flows نشطة على نفس الكائن يجعل ترتيب التنفيذ صعب التنبؤ.
- **عدد الـTriggers غير الموحدة تحت إطار عمل واحد** لكل كائن. أكثر من Trigger واحد لكائن هو بالفعل علامة تحذير، ما لم توجد طبقة توجيه (Routing layer) صريحة.
- **كثافة استعلامات SOQL داخل الحلقات** التي تظهر في السجلات كـGovernor Limit يقترب من الحد الأقصى، حتى لو لم يتم تجاوزها بالفعل.
- **وقت تشغيل غير طبيعي لـFlow أو Apex Batch** يزداد بمرور الوقت دون أن ينمو حجم العمل بنفس النسبة.
- **الحقول والمتغيرات التي ليس لها استخدام محدد** في تقرير Field Usage، والتي تبقى "للحالة التي قد يحتاجها شخص ما".

هذه المقاييس لا تثبت مشكلة لا لبس فيها، لكنها توفر قائمة مركزة من المشتبه بهم. الجمع بين هذه المقاييس وعمق فهم التكاملات التي تعتمد عليها الأتمتة مفصل في [أنماط التكامل في Salesforce](/ar/insights/salesforce-integration-patterns).

## إطار عمل صنع القرار: ما الذي يتم معالجته أولًا

ليس كل اكتشاف في قائمة المشتبه بهم يستحق نفس الاستثمار. يوجد إطار عمل بسيط لتحديد الأولويات يعتمد على محورين – التأثير التجاري واحتمالية الفشل:

| الحالة | التأثير التجاري في حال الفشل | احتمالية الفشل على المدى القريب | الإجراء |
|---|---|---|---|
| أتمتة على عملية طلب/فوترة مع Triggers متعددة وغير موثقة | عالية | عالية | إعادة هيكلة فورية (Refactor)، خارج قائمة الانتظار العادية |
| Flow معقد على تحديث حالة داخلية بدون تأثير خارجي | منخفضة | عالية | توثيق وتبسيط بالسرعة العادية |
| Trigger قديم يعمل بثبات ولكن ليس واضحًا سبب وجوده | عالية محتملة | منخفضة | توثيق أولاً، لا تعديل فوري |
| حقول غير مستخدمة ومتغيرات ثابتة يتيمة | منخفضة | منخفضة | تنظيف دوري على مستوى الإصدار (Release) |

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

## سيناريو مؤسسي: شركة تأمين لديها 14 Flow على Opportunity

لنفترض شركة تأمين متوسطة الحجم تدير مبيعات B2B عبر Salesforce منذ ست سنوات. على مر الوقت، تراكمت 14 Flow نشطًا على كائن Opportunity: سبعة Flows تتعامل مع تحديثات المراحل، ثلاثة ترسل إشعارات داخلية، اثنان يقومان بمزامنة البيانات مع أداة BI خارجية، واثنان آخران هما بقايا عملية قديمة تم استبدالها قبل عامين ولكن لم يتم تعطيلهما مطلقًا.

 triggered كان الخلل المحدد هو الذي أدى إلى تحديد المشكلة: انتقلت صفقة إلى مرحلة "Closed-Won"، ولكن لم يتم إرسال الإشعار إلى فريق الاكتتاب، لأن Flow آخر قام بتحديث نفس الحقل في نفس الوقت، مما أدى إلى توقيت تنفيذ غير متوقع. أمضى الفريق يومين في محاولة لفهم السبب – ليس لأن الخلل كان معقدًا، بل لأن أحدًا لم يكن يعرف ترتيب التنفيذ الكامل لـ14 مكونًا.

لم تكن المعالجة هي "إعادة كتابة كل شيء في Apex". قام الفريق أولاً برسم جميع الـ14 Flow وتصنيفها وفقًا للجدول أعلاه: تم تعطيل الـFlows القديمين بعد التحقق من عدم وجود تبعية نشطة، وتم دمج الإشعارات الثلاثة في Flow واحد مع منطق توجيه واضح، وتم دمج تحديثات المراحل السبعة تحت Record-Triggered Flow واحد بترتيب تنفيذ صريح. النتيجة: من 14 مكونًا إلى 6، مع توثيق ترتيب التنفيذ الذي يمكن لأي مطور جديد قراءته في غضون ربع ساعة.

## المخاطر في عملية تخفيض الدين نفسها

تقليل الدين التقني هو عملية تنطوي على مخاطر خاصة بها، ليست مجرد إصلاح لمخاطر موجودة:

| الخطر | كيف يظهر فعليًا | إجراء وقائي |
|---|---|---|
| تغيير ترتيب التنفيذ يكسر تبعية خفية | توقف عملية كانت تعمل بعد دمج الـFlows | رسم كامل للتبعيات واختبار الانحدار (Regression) قبل كل دمج |
| حذف مكون "ميت" لا يزال يعمل في سيناريو نادر | خلل يظهر فقط في نهاية الربع أو في سيناريو حافة (Edge case) موسمي | مراجعة سجلات التنفيذ على مدار عام كامل، وليس فقط الشهر الأخير |
| التحويل إلى Apex بدون مالك عملية يفهم القاعدة التجارية | الكود الجديد "صحيح تقنيًا" ولكنه يطبق قاعدة قديمة تغيرت بالفعل | التحقق من القاعدة التجارية مع صاحب العملية قبل كتابة الكود، لا فقط مع الكود الموجود |
| Refactor يتم في Sandbox واحد ولا يتم مزامنته | تعود المشكلة في بيئة الإنتاج بعد النشر (Deploy) التالي | إدارة التغيير من خلال عملية Release عادية وليس كإصلاح "خارج الدور" |

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

## مقاييس المراقبة المستمرة بعد التخفيض

للتأكد من أن الجهد يقلل الدين حقًا ولا يكتفي بتحريكه، ينبغي متابعة ما يلي:

- **عدد مكونات الأتمتة النشطة لكل كائن**, كمقياس اتجاه ربع سنوي وليس نقطة واحدة.
- **متوسط الوقت لتشخيص خلل الأتمتة**, من لحظة الإبلاغ وحتى تحديد المكون المسؤول.
- **النسبة المئوية للمكونات الموثقة** من إجمالي الأتمتة النشطة في المجموعة الأساسية.
- **عدد الأعطال المتكررة على نفس المكون** في مدى ثلاثة أشهر.

تستعين المؤسسات التي تواجه صعوبة في تحديد الأولويات بين Refactor والتطوير المستمر بـ[خدمة هندسة CRM](/ar/crm-architecture) لبناء خطة عمل ملزمة وقابلة للقياس.

## قائمة مراجعة تشغيلية قبل البدء في Refactor

- ☐ توجد خريطة كاملة لجميع الأتمتات النشطة على الكائن المعني
- ☐ معروف ترتيب التنفيذ الفعلي، وليس فقط حسب ترتيب الإنشاء
- ☐ تم فحص كل مكون مخصص للإزالة مقابل سجلات التنفيذ على مدار عام كامل
- ☐ وافق مالك العملية التجارية على القاعدة التي يتم تطبيقها من جديد
- ☐ توجد بيئة اختبار تحاكي حجم البيانات الحقيقي
- ☐ تم تحديد مقياس "قبل وبعد" لعدد المكونات ووقت التشخيص
- ☐ تمر عملية الـRefactor بعملية Release عادية، وليس Deploy استثنائي
- ☐ تم تخصيص سعة ثابتة في كل Sprint للمعالجة المستمرة، وليس مجرد حدث لمرة واحدة

## الخلاصة

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

### أسئلة وأجوبة
**كم عدد الـ Flows على نفس الكائن يُعتبر كثيرًا؟**
لا يوجد رقم سحري، ولكن هناك علامة واضحة: عندما لا يستطيع المطور التنبؤ بما سيحدث عند حفظ سجل دون فتح القائمة بأكملها وتتبع ترتيب التنفيذ، فهناك بالفعل مشكلة تشغيلية — حتى لو كان هناك ثلاثة Flows فقط. المشكلة ليست في الكمية بل في الافتقار إلى التنسيق والتوثيق لترتيب التنفيذ بينها.

**هل يمكن تقليص الديون التقنية دون إيقاف تطوير الميزات الجديدة؟**
نعم، وعادة ما يكون هذا هو النهج الصحيح. يتم تخصيص نسبة ثابتة من كل Sprint – على سبيل المثال عُشر القدرة – لتقليص الديون بناءً على قائمة أولويات، بدلاً من طلب 'Sprint تجميد' مخصص يتم تأجيله دائمًا تقريبًا عندما يحين دور الأولويات التجارية.

**متى يتم تحويل Flow إلى كود Apex بسبب الديون التقنية؟**
عندما يحتوي الـ Flow على منطق معقد يضم أكثر من بضعة فروع قرار، أو عندما يستدعي نفس الاستعلام عدة مرات بسبب بنية نمطية سيئة، أو عندما يحتاج إلى اختبارات آلية لا تدعمها الأدوات الرسومية بشكل كافٍ. التحويل بحد ذاته أداة تقنية؛ والقرار ينبع من قياس التعقيد الفعلي وليس من تفضيل أسلوبي.

**كيف يمكن قياس الديون التقنية دون الدفع مقابل أداة خارجية؟**
يمكن البدء بـ Salesforce Optimizer وتقارير الإعداد (Setup reports) الداخلية لحساب الـ Flows النشطة حسب الكائن، بالإضافة إلى استعلام Tooling API عن حدود Apex وسجلات Debug (Debug Logs) لأوقات التشغيل غير الطبيعية. هذا ليس بديلاً كاملاً لأداة تحليل ثابتة (Static Analysis) مخصصة، ولكنه كافٍ لبناء قائمة أولويات أولية.

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

---

## نموذج البيانات في Salesforce: الكائنات القياسية، الكائنات المخصصة، والقرارات المحورية
URL: https://hpi.pro/ar/insights/salesforce-data-model-design
يُعد نموذج البيانات أهم قرار يتسم بارتفاع تكلفة التعديل بعد مرحلة التشغيل. يستعرض هذا الدليل متى يجب الالتزام بالكائنات القياسية (Standard Objects)، ومتى يكون الكائن المخصص (Custom Object) مبررًا، وكيفية الاختيار بين Lookup و Master-Detail، وكيف يمكن لنموذج يبدو مثاليًا في ورشة العمل أن يولد قيودًا على التقارير والصلاحيات والأداء بعد سنوات.

## الإجابة المختصرة

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

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

## القاعدة الأولى: البدء بالكائنات القياسية

تحمل كائنات Account وContact وLead وOpportunity وCase وProduct في طياتها قدرات لا تتوفر مجاناً للكائنات المخصصة، مثل: عمليات البيع، التنبؤ (Forecasting)، الاستحقاقات (Entitlements)، القناة المتعددة (Omni-Channel)، تطبيقات الجوال، والتكامل المدمج مع منتجات أخرى في المنصة.

المنظمة التي تنشئ `Customer__c` بدلاً من Account تحصل في البداية على نموذج يبدو أنظف، لتكتشف لاحقاً أن كل ميزة جاهزة تتطلب بناءً مستقلاً. القاعدة هنا: الحيد عن المعيار يكون فقط لسبب يمكن صياغته في جملة واحدة.

## متى يتطلب الأمر كائناً مخصصاً

| الحالة | هل هو كائن مخصص؟ | التعليل |
|---|---|---|
| عقد/اشتراك بدورة حياة خاصة به | نعم | حالات، تجديد، ملكية، وتقارير منفصلة |
| أصل مثبت لدى العميل | نعم (أو الأصل القياسي) | كيان مستقل بتاريخ خدمة خاص به |
| "عميل محتمل" إضافي | لا | هذا هو Lead أو Account بنوع سجل (Record Type) |
| قسم ضمن المنظمة | لا | معلومة عن المستخدم، وليست كياناً مستقلاً |
| بنود تسعير معقدة | يعتمد على الحالة | يجب مراجعة Quote Line أو CPQ قبل البناء |

## التطبيع مقابل التسوية: القرار الذي يؤثر على التقارير

في قواعد البيانات التقليدية، يعتبر التطبيع ميزة. في Salesforce، يُبادَل التطبيع براحة التقارير: كل مستوى علاقة إضافي يصعب بناء التقرير بدون أداة خارجية، لأن التقارير القياسية محدودة في عمق العلاقات.

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

## الصلاحيات جزء من النموذج وليست خطوة لاحقة

يجب طرح السؤال "من يرى ماذا" أثناء تصميم الكائنات. النموذج الذي يضع بيانات حساسة على نفس الكائن الذي يحوي بيانات تشغيلية يجبر على استخدام حلول غير مباشرة لاحقاً، مثل كائن وهمي (Shadow Object)، أو حقول مشفرة، أو فتح رؤية واسعة جداً.

الاختبار العملي: لكل كائن جديد، تُكتب جملة واحدة تحدد: من المالك، من يمكنه القراءة، من يمكنه التعديل، وماذا يحدث في التسلسل الهرمي. إذا تطلبت الإجابة أكثر من أربعة أسطر، فمن المحتمل أن الهيكل يخلط بين كيانين.

توسيع حول موضوع مصادر المعلومات وصلاحية التحديث موجود في [المصدر الوحيد للحقيقة في المنظمة](/ar/insights/salesforce-source-of-truth)، وحول إدارة الكيانات الأساسية في [Master Data Management](/ar/insights/salesforce-master-data-management).

## سيناريو: شركة برمجيات بنت نموذجها حول الأقسام

بنت شركة SaaS متوسطة الحجم نموذجاً بأربعة كائنات مخصصة - واحدة لكل فريق مبيعات - لأن كل فريق كان لديه عملية مختلفة. بعد عام ونصف، تم دمج الفرق، مما تطلب لاحقاً: دمج التقارير، وأتمتة متوازية في أربعة أماكن، وترحيل داخلي لـ 60 ألف سجل بين الكائنات.

أعيد البناء بالاعتماد على كائن Opportunity واحد مع أنواع سجلات (Record Types) للعمليات المختلفة. تم الحفاظ على نفس التمييز التجاري – مسارات مبيعات مختلفة، حقول مختلفة، تخطيطات صفحات (Page Layouts) مختلفة – ولكن على مستوى التكوين وليس على مستوى الهيكل. سيتطلب التغيير التنظيمي التالي تعديل نوع السجل، وليس ترحيل البيانات.

القاعدة التي نتجت عن ذلك: الهيكل يمثل الكيانات؛ والتكوين يمثل المنظمة. ما يُتوقع أن يتغير كل سنتين لا ينبغي أن يكون ضمن الهيكل.

## الأداء والحجم - ما يهم حقاً

تنشأ مشاكل الأداء في نماذج البيانات بشكل أساسي من ثلاثة مصادر: انحراف البيانات (Data Skew)، أي وجود سجل أب واحد يحتوي على عشرات الآلاف من السجلات الفرعية (مثلاً، حساب "العملاء الأفراد")؛ الصيغ المتداخلة التي تُحسَب في الوقت الفعلي عبر العلاقات؛ والمشاركة المستندة إلى Apex Sharing التي تُنشأ بكميات كبيرة. يمكن اكتشاف كل هذه المشاكل في مرحلة التخطيط إذا تم تقدير عدد السجلات المتوقعة تحت كل كيان أب.

## المخاطر الشائعة والإجراءات الوقائية

| المخاطر | كيف تبدو في الممارسة العملية | الإجراء الوقائي |
|---|---|---|
| كائن مخصص غير ضروري | إعادة بناء القدرات الجاهزة يدوياً | فحص الكائنات القياسية قبل أي كائن جديد |
| علاقة رئيس-تفصيل (Master-Detail) مبكرة | حذف تسلسلي وهيكل لا يمكن تغييره | البدء بعلاقة بحث (Lookup) إذا لم يكن هناك حاجة لـ Roll-Up |
| نموذج يعكس الهيكل التنظيمي | كل تغيير تنظيمي يصبح عملية ترحيل | استخدام أنواع السجلات (Record Types) بدلاً من الكائنات |
| انحراف البيانات (Data Skew) | تأخيرات في التحديثات الجماعية والإغلاقات | توزيع كيانات الأب، تقدير الحجم عند التخطيط |
| الصلاحيات كتفكير لاحق | حلول غير مباشرة ورؤية واسعة جداً | مصفوفة وصول لكل كائن في مرحلة التخطيط |

## كيف نقيس النجاح

| المجال | ما الذي يتم قياسه | وتيرة الفحص |
|---|---|---|
| استخدام الحقول | معدل تعبئة كل حقل | ربع سنوي |
| التقارير | نسبة التقارير التي تتطلب دمجاً يدوياً | ربع سنوي |
| استقرار الهيكل | عدد تغييرات الهيكل في النصف | نصف سنوي |
| الأداء | أوقات التحديث الجماعي والإغلاقات | شهري |

يتم تصميم نموذج البيانات كجزء من هيكل معماري شامل ضمن [خدمة التكامل والبيانات](/ar/integrations-data).

## قائمة التحقق قبل تثبيت النموذج

- ☐ لكل كائن مخصص يوجد تعليل في جملة واحدة.
- ☐ تم فحص الكائنات القياسية البديلة لكل كيان.
- ☐ تم اختيار نوع العلاقة صراحة مع تعليل لـ Master-Detail.
- ☐ تم تقدير الحجم المتوقع لكل كائن أب (تحقق من Skew).
- ☐ مصفوفة الوصول: المالك، القارئ، المعدِّل، التسلسل الهرمي.
- ☐ تم التحقق من إمكانية بناء جميع التقارير الرئيسية ضمن النموذج.
- ☐ يتم تحديث الحقول المكررة تلقائياً فقط.
- ☐ يتم التعامل مع التغييرات التنظيمية المتوقعة ضمن التكوين.
- ☐ يوجد ERD محدث وموثق.
- ☐ تم تحديد من يوافق على تغيير الهيكل مستقبلاً.

## مصادر احترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكامل والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**متى يكون الكائن المخصص (Custom Object) مبررًا، ومتى يكون خطأ؟**
يكون مبررًا عندما يمتلك الكيان دورة حياته الخاصة – حالات، ومالكية، وصلاحيات، وتقارير مستقلة. ويكون خطأً عندما يتم إنشاؤه فقط لتجنب إضافة حقول إضافية إلى كائن موجود، أو ليعكس هيكلًا تنظيميًا. الهياكل التنظيمية تتغير؛ والكائنات لا تتحرك معها بسهولة.

**Lookup أم Master-Detail؟**
يوفر Master-Detail ملخصًا تراكميًا (Roll-Up Summary) وتوريثًا للصلاحيات، لكنه يتسم بالصلابة: حذف الكائن الأب يؤدي إلى حذف الكائنات الأبناء، ولا يمكن للسجل أن يوجد بدون أب. Lookup أكثر مرونة ويمكن تعديله لاحقًا. القاعدة العملية: Master-Detail يستخدم فقط عندما يكون الكائن الابن عديم المعنى حقًا بدون الأب وتكون هناك حاجة إلى تلخيص تلقائي.

**كم عدد الحقول يعتبر كثيرًا على كائن واحد؟**
العدد أقل أهمية من الاستخدام. كائن يحتوي على 200 حقل قيد الاستخدام في التقارير مقبول؛ بينما كائن به 60 حقلًا معظمها فارغ في 80% من السجلات يشير إلى كيانات تم ضغطها في مكان واحد. الاختبار الأفضل هو نسبة ملء كل حقل، وليس مجرد العدد.

**هل يجب عكس هيكل نظام تخطيط موارد المؤسسات (ERP) في Salesforce؟**
لا. يتم تصميم ERP حول المعاملات، بينما Salesforce حول العلاقات والعمليات. الانعكاس الكامل يولد عشرات الكائنات التي لا يستخدمها أحد. يتم نقل ما هو مطلوب فقط لعمليات المبيعات والخدمة إلى Salesforce، ويتم استخدام الوصول عن بعد أو رؤية شاملة للبيانات 360 (Data 360) للبقية.

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

---

## إدارة البيانات الرئيسية (MDM) مع Salesforce: الملكية، والسجل الذهبي، والمزامنة
URL: https://hpi.pro/ar/insights/salesforce-master-data-management
تفشل إدارة البيانات الرئيسية (MDM) عندما تُعرّف كمشروع تقني، وتنجح عندما تُحدّد كنظام ملكية. يشرح الدليل الكيانات التي تتطلب إدارة رئيسية فعليًا، وكيفية بناء سجل ذهبي (Golden Record) بين CRM و ERP دون تعطيل أي نظام، ومتى يتطلب الأمر أداة MDM مخصصة ومتى يكون Salesforce كافيًا، وكيفية قياس فعالية هذا النظام.

## الإجابة المختصرة

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

الخطأ الشائع يكمن في البدء باختيار الأداة. فالمنظمة التي لم تحسم تعريف "العميل" لديها ستحصل على أداة توحد هذا الغموض بالضبط، ولكن بشكل أسرع وبتكلفة أعلى.

## ما يدخل في البيانات الرئيسية وما لا يدخل

| نوع البيانات | مثال | هل تعتبر بيانات رئيسية؟ |
| --- | --- | --- |
| بيانات رئيسية (Master Data) | عميل، منتج، مورد، موقع | نعم |
| بيانات مرجعية (Reference Data) | دول، عملات، رموز صناعية | إدارة منفصلة وأبسط |
| بيانات المعاملات (Transactional Data) | طلب، فاتورة، حالة خدمة (Case) | لا |
| بيانات تحليلية (Analytical Data) | تجزئة، تصنيف، توقع | لا - فهي مشتقة |

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

## الأساليب الثلاثة للتنفيذ

**السجل (Registry)** - تتم فيه إدارة جدول معرفات فقط يربط بين السجلات في الأنظمة المختلفة. وهو حل منخفض التكلفة، سريع، لا يغير أي نظام قائم، ويوفر رؤية موحدة للقراءة. وهو مناسب كخطوة أولى في معظم الحالات.

**التوحيد (Consolidation)** - يتم إنشاء سجل ذهبي (Golden Record) لأغراض التقارير والتحليلات، دون إعادة تدفقه إلى الأنظمة المصدرية. وهو مناسب عندما يكون الألم الرئيسي هو ازدواجية التقارير.

**المركزية (Centralized)** - يصبح مصدر البيانات الرئيسية هو المصدر الموثوق به، وتستهلك الأنظمة الأخرى البيانات منه. يقدم هذا الأسلوب أعلى قيمة، ولكنه يتطلب أيضًا أعلى مستوى من الحوكمة وعمليات الموافقة. غالبًا ما تكتشف المنظمات التي تنتقل مباشرة إلى هذا الأسلوب أنها تفتقر إلى المسؤولين (Stewards) لتشغيل هذا النظام.

النهج العملي هو التدرج: البدء بأسلوب السجل (Registry) لكيان واحد، ثم التوسع – بناءً على قيمة مثبتة وليس وفقًا لخطة رئيسية.

## Survivorship: القواعد التي تحدد ما يبقى

جوهر السجل الذهبي (Golden Record) هو قواعد Survivorship على مستوى الحقل: لكل حقل مصدر مفضل، وقاعدة احتياطية في حال كان المصدر المفضل فارغًا. وإلى جانب ذلك، يتم دائمًا الاحتفاظ بالمعرفات من الأنظمة المصدرية لضمان إمكانية شرح كل قيمة.

مبدأ يوفر الكثير من الجدل: السجل الذهبي لا يحذف سجلات المصدر ولا يدعي حلاً بديلاً لها. إنه طبقة تشير إليها. هذا يعني أنه يمكن تعديل القاعدة وإعادة الحساب – وهي قدرة لا يمتلكها من قام بدمج كل شيء في مرحلة التحميل.

يمكن العثور على فهم أعمق لتحديد الملكية في مقال [Source of Truth في المنظمة](/ar/insights/salesforce-source-of-truth)، ولتنقية التكرارات التي تسبقه في مقال [تنقية تكرارات البيانات في Salesforce](/ar/insights/salesforce-data-deduplication).

## الاستمرارية (Stewardship): الدور الذي يحدد نجاح المشروع

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

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

## سيناريو: شركة تصنيع بثلاثة أنظمة وعميل واحد

كانت شركة تصنيع صناعية تحتفظ ببيانات عملائها في ثلاثة مواقع: نظام تخطيط موارد المؤسسات (ERP)، Salesforce، ونظام خدمة. ظهرت نفس المؤسسة ككيانات ثلاثية مختلفة، وكان تقرير "الإيرادات لكل عميل" يتم إعداده يدويًا في Excel كل ثلاثة أشهر.

بدلاً من مشروع MDM كامل، بدأت المنظمة بأسلوب السجل (Registry): تم بناء جدول معرفات في Data 360 يربط السجلات الثلاثة باستخدام رقم هوية الشركة ومفتاح ثانوي، وبعد ذلك تم بناء سجل ذهبي للقراءة. لم يغير Salesforce هيكله؛ بل تلقى حقل معرف عالمي وعرض "جميع الأنشطة للمجموعة".

النتيجة بعد ربع واحد: تم إلغاء التقرير اليدوي، ولأول مرة رأى فريق المبيعات مدى التعرض الائتماني للمجموعة ككل - مما أدى إلى قرار تسعير واحد استرد تكلفة المرحلة. تم النظر في التوسع إلى أسلوب المركزية (Centralized) فقط بعد أن ثبت وجود مسؤول (Steward) يقوم بإغلاق قائمة الانتظار فعليًا.

## المخاطر الشائعة والإجراءات الوقائية

| الخطر | كيف يظهر عمليًا | إجراء وقائي |
| --- | --- | --- |
| البدء بالأداة | مستودع موحد يعكس الغموض القائم | تعريفات الكيانات والملكية قبل اختيار الأداة |
| الكثير من الكيانات | مشروع طويل بدون قيمة واضحة | كيان واحد حتى الإنتاج، ثم التوسع |
| لا يوجد Steward | قائمة انتظار للتطابقات تتزايد ويتم إهمالها | دور بوقت مخصص واتفاقية مستوى الخدمة (SLA) |
| الدمج التدميري | عدم القدرة على شرح أو استعادة القيمة | الاحتفاظ بمعرفات المصدر وإعادة الحساب |
| المركزية المبكرة | جميع الأنظمة تعتمد على بنية تحتية غير ناضجة | البدء بأسلوب السجل (Registry) |

## كيف يتم قياس النجاح

| المجال | ما يتم قياسه | وتيرة المراجعة |
| --- | --- | --- |
| التغطية | نسبة السجلات المرتبطة بمعرف عالمي | شهري |
| الدقة | معدل الروابط التي تم إلغاؤها أو تصحيحها | شهري |
| قائمة انتظار Steward | العناصر المفتوحة ومتوسط وقت الإغلاق | أسبوعي |
| القيمة التجارية | التقارير اليدوية التي تم إلغاؤها، قرارات على مستوى المجموعة | ربع سنوي |

يتم بناء نظام إدارة البيانات الرئيسية التدريجي ضمن [خدمات التكامل والبيانات](/ar/integrations-data).

## قائمة تحقق قبل بدء MDM

- ☐ تم اختيار ما يصل إلى ثلاثة كيانات للمرحلة الأولى.
- ☐ لكل كيان تعريف أعمال مكتوب.
- ☐ تم اختيار أسلوب التنفيذ: Registry، Consolidation، أو Centralized.
- ☐ تم تحديد مفاتيح تعريف قوية لكل مصدر.
- ☐ تم كتابة قواعد Survivorship على مستوى الحقل.
- ☐ يتم الاحتفاظ بمعرفات المصدر وتسمح بإعادة الحساب.
- ☐ تم تعيين Steward بوقت مخصص واتفاقية مستوى الخدمة (SLA).
- ☐ تم تحديد عملية الموافقة لإنشاء كيان جديد.
- ☐ تم تحديد مقياس قيمة واحد للمرحلة الأولى.
- ☐ يوجد قرار بشأن متى يجب النظر في أداة مخصصة.

## مصادر احترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ما هي الكيانات التي تحتاج حقًا إلى إدارة رئيسية (Master Management)؟**
تلك الكيانات التي تظهر في أكثر من نظام واحد وتؤثر على الجوانب المالية، أو التنظيمية، أو تجربة العميل. في معظم المؤسسات، ينطبق هذا على ثلاثة إلى خمسة كيانات: العميل/المورد، المنتج، الهيكل التنظيمي-المبيعات، وفي بعض الأحيان الموقع أو الأصول. محاولة إدارة 20 كيانًا في وقت واحد هي أسرع طريقة للتعثر.

**هل أحتاج إلى أداة MDM مخصصة؟**
ليس دائمًا. لغاية ثلاثة أنظمة مصدر وتعقيد تكامل متوسط، يكفي Salesforce مع External IDs و Matching Rules والتكامل المدار. تصبح الأداة المخصصة مبررة عند وجود مصادر متعددة، أو متطلبات حوكمة رسمية، أو حفظ سجل التغييرات لأغراض تنظيمية، أو Survivorship معقد على مستوى الحقل.

**ما الفرق بين Registry و Consolidation و Centralized؟**
تحتفظ Registry فقط بتعيينات المعرفات وتترك البيانات في مصدرها الأصلي. تُنشئ Consolidation نسخة موحدة لأغراض إعداد التقارير فقط. تُحوّل Centralized المستودع إلى مصدر موثوق يعتمد عليه الجميع. كلما ارتفعنا في هذا التسلسل، زادت القيمة وكذلك تكلفة التنفيذ والحوكمة.

**هل يمكن لـ Salesforce أن يكون المصدر الرئيسي للعميل؟**
نعم، عندما يتم إنشاء العميل وإدارته ضمن عملية المبيعات. في معظم المؤسسات، الحل الوسط هو التقسيم: الهوية القانونية وشروط التجارة في ERP، والكيان التجاري وتفاصيل الاتصال في Salesforce، مع معرف مشترك يربط بين الاثنين.

**كم يستغرق تحقيق القيمة الأولية؟**
بالنسبة لكيان واحد مع مصدرين، يتراوح الأمر بين ستة واثني عشر أسبوعًا للوصول إلى سجل ذهبي (Golden Record) فعال في الإنتاج. غالبًا ما لا تصمد مشاريع MDM المخطط لها لسنتين لـ 'بنية تحتية كاملة' أمام تغييرات الإدارة - من الأفضل كيان واحد في الإنتاج على بنية كاملة في عرض تقديمي.

---

## Data 360 مقابل بيانات Salesforce CRM: أين يتم تخزين كل منها؟
URL: https://hpi.pro/ar/insights/data-360-vs-crm-data
ليس كل البيانات المتعلقة بالعملاء يجب أن تُخزّن في الـ CRM. يوضح هذا الدليل الفرق بين البيانات التشغيلية التي تدفع العمليات اليومية والبيانات السلوكية ذات الحجم الكبير والمصممة لتوحيد الملفات الشخصية والتجزئة والتنشيط، ويبين كيف يؤثر هذا القرار على الأداء والتكلفة والصلاحيات وما يمكن تحقيقه باستخدام الذكاء الاصطناعي.

## الإجابة المختصرة

إن القرار بين CRM وData 360 لا يتعلق بـ "المساحة المتاحة" بل بـ "من يستهلك البيانات وبأي وتيرة". نظام إدارة علاقات العملاء (CRM) مصمم حول سجل يقوم شخص ما بفتحه وتحريره ودفعه قدمًا ضمن عملية محددة. أما Data 360 فهو مصمم حول تدفق الأحداث الذي يتم توحيده في ملف تعريفي ويُستخدم للتجزئة والتحليل والتفعيل.

عند دمج الاثنين، نحصل على إحدى نتيجتين: إما نظام CRM مثقل بملايين السجلات التي لا يراجعها أحد، أو طبقة بيانات غنية لا يتخذ أحد إجراءً بناءً عليها لأنها لا تصل إلى سير العمل الفعلي.

## التقسيم العملي

| نوع المعلومات | المكان | المبرر |
| --- | --- | --- |
| العميل، جهة الاتصال، الفرصة، الحالة (Case) | CRM | يُدار يدويًا، ويدفع العمليات والصلاحيات |
| مرحلة المبيعات، المهام، الموافقات | CRM | الأتمتة والعمليات اليومية |
| النقرات، المشاهدات، استخدام المنتج | Data 360 | حجم كبير، لا يُدار يدويًا |
| سجل المعاملات من نظام تخطيط موارد المؤسسات (ERP) | Data 360 (أو وصول افتراضي) | الحجم، ومصدر الحقيقة الخارجي |
| الملف التعريفي الموحد والهوية عبر الأنظمة | Data 360 | وظيفته توحيد معرفات الهوية |
| التسجيل، التجزئة، التوصية | يُحسب في Data 360، ويُعرض في CRM | الحساب في بيئة عالية الحجم، الاستخدام في سير العمل |

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

## اختبار الأسئلة الأربعة

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

العكس صحيح أيضًا: البيانات المخزنة فقط في Data 360 ولكنها مطلوبة لاتخاذ قرار في الوقت الفعلي، يجب أن يكون لديها آلية إرجاع – مثل حقل ملخص، أو عرض، أو إجراء – وإلا فلن تؤثر على النتائج التجارية.

## الحجم والأداء والتكلفة

يتم تسعير وتصميم نظام CRM حول السجلات التجارية. إن إدخال أحداث السلوك إليه يغير ملف تعريف الحمل: التحديثات الجماعية تبطئ النظام، وإنشاء التقارير يصبح ثقيلاً، وتزداد أحجام النسخ الاحتياطية وبيئات الاختبار. نظام Data 360 مصمم لهذه الوتيرة ويتم تسعيره حسب الاستهلاك – مما يتطلب اهتمامًا مختلفًا: الاستعلامات الواسعة والتدفقات غير الضرورية تولد تكلفة مستمرة.

في كلتا الحالتين، تبقى النظافة واحدة: تمرير فقط ما له مستهلك، وتحديد سياسة الاحتفاظ (Retention) لكل تدفق. يتم تفصيل النقاش حول النسخ مقابل الوصول عن بعد في [Zero Copy وFederation](/ar/insights/data-360-zero-copy-federation).

## الصلاحيات: الثغرة التي يسهل إغفالها

نموذج الصلاحيات في CRM غني ودقيق على مستوى السجل والحقل. تعمل طبقة التوحيد بشكل مختلف – فهي مصممة للتحليل، وتتم إدارتها وفقًا لقواعد الوصول والأقنعة (masks). قد تؤدي المؤسسة التي تنقل بيانات حساسة إلى طبقة التوحيد دون تخطيط مسبق إلى إنشاء رؤية أوسع مما هو موجود في CRM.

القاعدة: يتلقى كل دفق يحتوي على معلومات حساسة قرارًا واضحًا بالكشف قبل التدفق، وليس بعده.

## سيناريو: بائع تجزئة قام بنقل كل شيء إلى CRM

قامت سلسلة متاجر تجزئة بنقل ثلاث سنوات من تاريخ الشراء – حوالي 40 مليون صف – إلى كائن مخصص في نظام CRM، رغبةً في أن "يكون لدى البائع صورة كاملة". وكانت النتيجة: أوقات تحميل طويلة في شاشة العميل، وتحديثات ليلية تجاوزت المدة المحددة، وتقارير تفشل بسبب انتهاء المهلة.

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

أصبحت شاشة العميل تُحمّل بسرعة، وحصل البائعون على ما كانوا يسألون عنه حقًا، وتحسن التجزئة التسويقية – لأنها كانت تعمل على بيانات كلها في مكان واحد وليست فقط على تلك التي تمكنت من الدخول إلى CRM.

## المخاطر الشائعة والإجراءات الوقائية

| المخاطر | كيف تظهر في الواقع | الإجراء الوقائي |
| --- | --- | --- |
| كل شيء في CRM | الأداء، التكلفة، وأوقات التحميل | قيم مشتقة بدلاً من السجل الخام |
| كل شيء في طبقة التوحيد | الرؤى التي لا تصل إلى سير العمل | آلية إرجاع: حقل، عرض، أو إجراء |
| لا توجد سياسة احتفاظ (Retention) | حجم متزايد بلا مالك | سياسة احتفاظ لكل تدفق |
| صلاحيات غير مخططة | الكشف عن معلومات حساسة في التحليل | قرار الكشف قبل التدفق |
| هوية غير موحدة | ملف تعريفي مجزأ لنفس العميل | قواعد Identity Resolution محددة |

## كيفية قياس النجاح

| المجال | ما يتم قياسه | وتيرة المراجعة |
| --- | --- | --- |
| الأداء | وقت تحميل شاشة العميل والتحديثات الجماعية | شهري |
| التوحيد | نسبة الملفات التعريفية الموحدة بنجاح | شهري |
| التفعيل | التجزئات والإجراءات الناتجة فعليًا عن البيانات | ربع سنوي |
| التكلفة | الاستهلاك مقابل الميزانية لكل تدفق | شهري |

يتم تخطيط التقسيم بين CRM وطبقة التوحيد ضمن [خدمات التكامل والبيانات](/ar/integrations-data).

## قائمة مراجعة لاتخاذ القرار

- ☐ تحديد تدفقات البيانات حسب الحجم وسرعة التحديث
- ☐ اختبار الأسئلة الأربعة لكل تدفق
- ☐ تحديد القيم المشتقة التي ستُعرض في CRM
- ☐ وجود آلية إرجاع من التوحيد إلى سير العمل
- ☐ كتابة قواعد Identity Resolution
- ☐ قرار الكشف عن كل تدفق يحتوي على معلومات حساسة
- ☐ سياسة الاحتفاظ لكل تدفق
- ☐ تقدير تكلفة الاستهلاك للمرحلة الأولية
- ☐ اختيار حالة استخدام (Use Case) واحدة لإثبات القيمة
- ☐ تحديد مالك لكل تدفق بيانات

## المصادر الاحترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ما هو السؤال الذي يحدد مكان تخزين البيانات؟**
السؤال هو: هل يقوم مستخدم أو آلية بأي إجراء على هذه البيانات ضمن سير العمل؟ إذا كانت الإجابة نعم، فمكانها في الـ CRM. أما إذا كانت مخصصة للتجزئة أو التحليل أو توحيد الملفات الشخصية أو تغذية نموذج، فمكانها في Data 360. البيانات التي لا يتم التعامل معها أو تحليلها من قبل أحد لا ينبغي أن تكون في أي من النظامين.

**هل يحل Data 360 محل مستودع البيانات (Data Warehouse)؟**
ليس بالضرورة. يتخصص Data 360 في توحيد ملفات تعريف العملاء وإعادة تنشيطها ضمن عمليات المبيعات والخدمة والتسويق. بينما يستمر مستودع البيانات المؤسسي (Enterprise Data Warehouse) في دعم إعداد التقارير المالية والتشغيلية الشاملة. في الواقع، يتواجد النظامان جنبًا إلى جنب، وأحيانًا يتم ربطهما عبر وصول افتراضي دون الحاجة إلى نسخ البيانات.

**هل يتطلب الذكاء الاصطناعي (AI) نظام Data 360؟**
ليس لكل الاستخدامات. لتلخيص المحادثات أو صياغة الردود، يكون السياق المتوفر في الـ CRM كافياً. أما للتوصيات أو التسجيل (Scoring) أو لـ Agent الذي يحتاج إلى سجل واسع من أنظمة متعددة، فإن طبقة التوحيد ضرورية، وهذا بالضبط هو دور Data 360.

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

**كيف نبدأ عندما يكون لدينا CRM محمل بالفعل؟**
من خلال تحديد ثلاث مجموعات من البيانات ذات الحجم الكبير والاستخدام التشغيلي المنخفض، ونقلها إلى طبقة التوحيد مع الاحتفاظ بحقل ملخص في CRM. هذا يحسن الأداء ويخلق أساسًا للتجزئة دون الحاجة إلى مشروع بنية تحتية كامل.

---

## مفهوم Zero Copy وData Federation في Data 360: متى يكون الاستغناء عن نسخ البيانات هو الخيار الأمثل؟
URL: https://hpi.pro/ar/insights/data-360-zero-copy-federation
تُشكّل كل عملية نسخ للبيانات التزامًا إضافيًا: خط نقل، تكلفة، فجوة محتملة، ومخاطرة. رغم أن Zero Copy يتيح لك الاستفادة من البيانات في موقعها الأصلي دون نسخ، إلا أنه ليس الحل الوحيد لكل السيناريوهات. يرشدك هذا الدليل إلى متى يكون النهج الافتراضي هو الأفضل، ومتى يكون Ingestion أكثر ملاءمة، وكيفية اتخاذ القرار بناءً على حداثة البيانات (Freshness)، الأداء، حوكمة البيانات، وتكلفة النقل.

## الإجابة المختصرة

كانت القاعدة القديمة تقول "لتحليل البيانات، يجب عليك أولاً نسخها". تلغي تقنية "Zero Copy" هذا الافتراض في العديد من الحالات: يمكن الاستعلام عن جدول موجود في مستودع بيانات خارجي دون الحاجة إلى نقله. هذه القدرة حقيقية، ولكنها تستبدل نوعًا واحدًا من التكاليف بنوع آخر؛ فبدلاً من تكلفة التخزين وخطوط النقل، نحصل على تكلفة المعالجة والاعتماد على توفر المصدر.

يكون القرار صحيحًا عندما يُعامل كأي قرار معماري آخر: بناءً على متطلبات الاستخدام، وليس بناءً على الموضة.

## المحددات الأربعة الحاسمة

| المعيار | يميل إلى Zero Copy | يميل إلى Ingestion |
|---|---|---|
| حداثة البيانات | الحاجة الدائمة لأحدث البيانات | تكفي الدورات الزمنية المجدولة |
| الأداء | تحليل وتجزئة، تحمل بضع ثوانٍ | تشغيل في الوقت الفعلي، زمن استجابة ثابت |
| الحجم والتكرار | حجم كبير، عدد قليل من الاستعلامات | حجم متوسط، العديد من الاستعلامات |
| الحوكمة | المصدر يفرض سياسات صارمة | تتطلب تحكمًا كاملاً في النسخة |

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

## ما يبقى ضمن مسؤولية الفريق حتى مع Zero Copy

الوصول الافتراضي يزيل خط النقل، لا العمل. لا يزال يتطلب: تخطيط المخطط للنموذج المشترك، تحديد مفاتيح التعريف لتوحيد الملفات الشخصية، معالجة تغييرات المخطط في المصدر، ومراقبة التوفر. تغيير اسم عمود في المستودع الخارجي سيكسر العرض الافتراضي تمامًا كما يكسر عملية ETL.

لذلك، فإن الاتفاق مع فريق البيانات الذي يمتلك المصدر هو جزء من التنفيذ: إشعار مسبق بتغييرات المخطط، نافذة صيانة معروفة، وميزانية متفق عليها للاستعلامات.

## الأنماط الهجينة الفعالة

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

**النافذة الساخنة والأرشيف البارد** – يتم نسخ آخر 12 إلى 24 شهرًا لضمان الأداء، ويتم الاحتفاظ بالسجل الأقدم للوصول الافتراضي.

**افتراضي أولاً، نسخ عند الحاجة** – البدء بالوصول الافتراضي، قياس تكرار الاستخدام الفعلي، ونسخ البيانات التي يثبت أنها مطلوبة بشكل متكرر فقط. هذه هي الطريقة الفعالة لتجنب نسخ البيانات التي لن يتم الاستعلام عنها أبدًا.

يُفصَّل الارتباط بين هذا القرار وتوزيع المسؤوليات بين الأنظمة في [Data 360 مقابل بيانات CRM](/ar/insights/data-360-vs-crm-data) وفي [مصدر الحقيقة في المؤسسة](/ar/insights/salesforce-source-of-truth).

## سيناريو: شركة مالية لديها 400 مليون صف

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

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

ما تم حسمه هنا لم يكن "افتراضي مقابل نسخ" بل كان على مستوى الدقة: السؤال الصحيح كان ما هي الدقة التي تحتاجها البيانات فعلاً. وعند الإجابة على هذا السؤال، أصبح سؤال النسخ ثانويًا.

## المخاطر الشائعة والإجراءات الوقائية

| المخاطرة | كيف تظهر في الواقع | إجراء وقائي |
|---|---|---|
| تكلفة حوسبة مفاجئة | استعلامات واسعة النطاق بتردد عالٍ | القياس في التجربة الأولية والاتفاق المسبق |
| الاعتماد على توفر المصدر | عطل في المستودع يعطل التجزئة | نظام بديل (Fallback) أو نافذة ساخنة منسوخة |
| تغييرات المخطط (Schema Changes) | تعطل العروض التقديمية دون إشعار | اتفاقية تغييرات ومراقبة المخطط |
| أذونات غير محددة | انكشاف أوسع مما هو موجود في المصدر | هوية الاستعلام وسياسة انكشاف مكتوبة |
| دقة خاطئة | نقل تفاصيل لا يستفيد منها أحد | تحديد الدقة قبل تحديد الطريقة |

## كيفية قياس النجاح

| المجال | ما الذي يتم قياسه | وتيرة الاختبار |
|---|---|---|
| الأداء | زمن الاستجابة للاستعلامات التجزئة الرئيسية | شهريًا |
| التكلفة | تكلفة الحوسبة وحركة البيانات لكل حالة استخدام | شهريًا |
| الاستقرار | فشل الاستعلامات وتوفر المصدر | أسبوعيًا |
| القيمة | عمليات التجزئة والإجراءات التي تم إنشاؤها فعليًا | ربع سنويًا |

يتم اختيار المزيج بين الوصول الافتراضي وتدفق البيانات كجزء من [خدمة التكامل والبيانات](/ar/integrations-data).

## قائمة التحقق لقرار Zero Copy

- ☐ تحديد حالات استخدام ملموسة بدلاً من "قدرة عامة"
- ☐ تحديد متطلبات حداثة البيانات (Freshness) لكل حالة استخدام
- ☐ فحص دقة البيانات المطلوبة فعليًا
- ☐ تقدير تكرار الاستعلام وحجم المسح
- ☐ وجود اتفاقية تغييرات المخطط مع مالك المصدر
- ☐ تحديد هوية الاستعلام وسياسة الانكشاف
- ☐ تقييم نمط هجين قبل اتخاذ قرار ثنائي
- ☐ وجود خطة بديلة (Fallback) في حال عطل المصدر
- ☐ إجراء تجربة أولية مدروسة قبل التوسع
- ☐ وجود مسؤول عن مراقبة التكلفة والمراجعة الدورية

## مصادر احترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكامل والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ما الذي يوفره Zero Copy حقًا؟**
يوفر Zero Copy عليك البنية التحتية ويزيل الازدواجية: لا توجد حاجة لصيانة عمليات ETL، ولا يوجد نسخ بيانات قديم، وتُحل مشكلة تحديد النسخة الصحيحة. لكن ما لا يوفره هو عملية الحساب نفسها؛ فالاستعلام ما زال يعمل، ولكنه يعمل لدى الجهة التي تحتفظ بالبيانات، وتُستهلك ميزانيتها في ذلك.

**متى يُفضل اللجوء إلى نسخ البيانات رغم ذلك؟**
عندما تتطلب العمليات التشغيلية وقت استجابة منخفض ومستقر، أو عندما يكون المصدر غير مستقر أو محدود في معدل الاستعلامات، أو عند الحاجة إلى سجل تاريخي يمكن استعادته لنقطة زمنية محددة، أو عندما يكون المصدر مهددًا بالاختفاء. في هذه الحالات، يعتبر Ingestion الخاضع للتحكم هو الخيار المسؤول.

**هل Zero Copy مناسب للعمليات في الوقت الفعلي؟**
أقل ملاءمة لذلك. الاستعلامات الافتراضية تناسب التجزئة والتحليل وإثراء السياق، لكن العمليات التشغيلية التي تنتظر استجابة في أجزاء من الثانية من الأفضل أن تعتمد على قيمة محسوبة مسبقًا ومحفوظة بالقرب من المستهلك.

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

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

---

## المطابقة (Reconciliation) وعملية التحويل (Cutover) في ترحيل Salesforce: خطة ليوم الانتقال
URL: https://hpi.pro/ar/insights/salesforce-migration-cutover-reconciliation
غالبًا ما يفشل يوم الانتقال ليس بسبب عملية التحميل نفسها، بل بسبب ما يحيط بها: بيانات Delta لم يتم استيعابها، تكامل بدأ تشغيله مبكرًا، أو عدم وجود من يتخذ القرارات في الثانية صباحًا. يقدم هذا الدليل خطة Cutover مفصلة بالساعة، وقواعد التجميد (Freeze)، ومنهجية المطابقة (Reconciliation) بأربعة مستويات، ومعايير واضحة للانتقال/عدم الانتقال (Go/No-Go).

## الإجابة المختصرة

تُعدّ عملية Cutover تمرينًا تشغيليًا، وليست مجرد مرحلة تقنية. يحدد ثلاثة عوامل رئيسية نجاحها: خطة تفصيلية بالساعة تحدد مسؤولاً لكل خطوة، ومطابقة (Reconciliation) تُثبت صحة البيانات لا مجرد وصولها، ومعايير Go/No-Go تُصاغ في لحظة هدوء الجميع.

يكمن الفرق بين المؤسسة التي انتقلت بسلاسة والمؤسسة التي عانت أسبوعين من الفوضى، تقريبًا بشكل دائم، في عدد مرات التشغيل التجريبي (rehearsals) – لا في جودة الأدوات.

يُشرح التخطيط الكامل لعملية Cutover في [دليل ترحيل البيانات إلى Salesforce](/ar/insights/salesforce-data-migration-guide).

## هيكل نافذة الترحيل: ثلاث موجات

| الموجة | التوقيت | ما يتم تحميله |
| --- | --- | --- |
| بيانات تاريخية (Historical) | 3-10 أيام قبل Cutover | بيانات الماضي المغلقة: صفقات مغلقة، حالات مغلقة (Closed Cases)، سجلات تاريخية |
| دلتا (Delta) | أثناء نافذة Cutover نفسها | كل ما تغير منذ الموجة الأولى |
| بعد التشغيل المباشر (Post-Go-Live) | 24-72 ساعة بعد Cutover | ملفات كبيرة، بيانات غير حرجة، عمليات استكمال |

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

## جدول زمني نموذجي – نافذة Cutover مدتها 12 ساعة

| الساعة | الإجراء | المسؤول |
| --- | --- | --- |
| T-2 | الموافقة على Go، التحقق من توفر الفريق وصاحب القرار | مدير المشروع |
| T0 | تجميد النظام المصدر، فصل التكاملات الصادرة | عمليات تكنولوجيا المعلومات (IT Ops) |
| T0+1 | استخلاص بيانات دلتا والتحقق من التعدادات في المصدر | قائد البيانات (Data Lead) |
| T0+2 | تحميل بيانات دلتا وفقًا لترتيب التبعيات | فريق الترحيل |
| T0+6 | مطابقة تلقائية: التعدادات، المجاميع، العلاقات | ضمان الجودة (QA) |
| T0+8 | أخذ عينات يدوية وموافقة مالكي العمليات | الأعمال (Business) |
| T0+9 | نقطة اللاعودة: قرار Go / Rollback | لجنة التوجيه (Steering) |
| T0+10 | تفعيل التكاملات، فتح صلاحيات المستخدمين | عمليات تكنولوجيا المعلومات (IT Ops) |
| T0+11 | اختبارات Smoke للعمليات الحرجة | ضمان الجودة (QA) + الأعمال (Business) |
| T0+12 | إعلان الافتتاح للمستخدمين، الانتقال إلى الدعم المكثف (Hyper-Care) | الاتصالات |

مبدآن في الجدول الزمني: لكل سطر اسم مسؤول، ولكل فحص عتبة رقمية. فسطر بلا مسؤول لن يُنفذ؛ وفحص بلا عتبة سينتهي بالنقاش.

## المطابقة (Reconciliation): أربعة مستويات لا يمكن تخطيها

**التعداد** - عدد السجلات في المصدر مقابل الهدف، لكل كيان ولكل نطاق تاريخي. يكشف عمليات التحميل الجزئية.

**المجموع** - مجاميع الحقول المالية والرقمية. يكشف التحويلات الخاطئة والقطع وإعادة التعيين الصامتة؛ فالتعداد الصحيح لن يكشفها.

**العلاقات** - عدد العلاقات الفرعية لكل علاقة رئيسية، وعدد السجلات اليتيمة. يكشف ترتيب التحميل الخاطئ وخراب مفاتيح الربط.

**العينات اليدوية** - من 20 إلى 50 سجلاً مختارًا مسبقًا، تشمل حالات الحافة: عميل بعلامات خاصة، صفقة بعملة أجنبية، سجل مر بعملية دمج. هذا هو المستوى الوحيد الذي يكشف الخطأ الدلالي – وهو بيانات تم تحميلها بنجاح إلى المكان الخطأ.

تُشرح العلاقة بين دقة التحويل وجودة ربط البيانات في [Data Mapping لترحيل البيانات](/ar/insights/salesforce-data-mapping).

## سيناريو: ترحيل توقف في الساعة الثامنة

خططت شركة توزيع لنافذة Cutover مدتها عشر ساعات في نهاية الأسبوع. تم التحميل بنجاح، وتطابقت التعدادات بدقة، واستعد الفريق لفتح النظام. ولكن أثناء أخذ العينات اليدوية، اكتُشف أن الفرص المفتوحة لستة من أصل 30 عميلًا تم التحقق منهم قد نُسبت إلى المالك الخطأ – نتيجة لجدول ربط مستخدمين لم يتم تحديثه بعد عمليتي مغادرة وتغيير في الدور الوظيفي.

كانت التعدادات صحيحة. كانت المجاميع صحيحة. العينات اليدوية هي الوحيدة التي كشفت المشكلة. لم يقم الفريق بعملية Rollback: فقد حدد وجود 1,400 سجل يمكن إصلاحها باستخدام استعلام، وأجرى إصلاحًا مستهدفًا ضمن نافذة Cutover، وتحقق مرة أخرى.

أصبح القرار ممكنًا لأن معيار No-Go كان قد حُدد مسبقًا بأنه "خطأ لا يمكن إصلاحه خلال ساعتين" وليس "أي خطأ". المعيار المصاغ جيدًا هو ما يسمح لفريق متعب باتخاذ قرار صحيح في الساعة الثالثة صباحًا.

## Hyper-Care (الدعم المكثف): الـ 14 يومًا التالية

نافذة Cutover تنتهي بافتتاح النظام للمستخدمين، لكن المخاطر تستمر. يتطلب الأمر فريقًا في حالة تأهب مع قناة اتصال واحدة، وتقرير يومي عن استثناءات التكامل، وتتبع مقاييس الجودة مقابل baseline. يتم تصنيف الأعطال بناءً على تأثيرها التجاري، وليس بناءً على من صرخ بصوت أعلى.

يُشرح القياس المستمر للجودة بعد الترحيل في [مقاييس جودة بيانات Salesforce](/ar/insights/salesforce-data-quality-metrics).

## المخاطر الشائعة والإجراءات الوقائية

| الخطر | كيف يظهر في الواقع | إجراء وقائي |
| --- | --- | --- |
| نافذة واحدة للحجم الكامل | يتجاوز التحميل الوقت ويُؤجل الترحيل | التقسيم إلى ثلاث موجات |
| تكامل تم تنشيطه | سجلات مكررة أو تحديثات متضاربة | فصل متحكم به وتفعيل منظم |
| مطابقة سطحية | أعداد صحيحة وبيانات خاطئة | أربعة مستويات تشمل العينات اليدوية |
| لا توجد معايير No-Go | الاستمرار قدمًا بدافع الزخم | عتبات مكتوبة قبل نافذة Cutover |
| ربط مستخدمين قديم | ملكية خاطئة للسجلات | تحديث جدول المستخدمين قبل يوم من Cutover |

## كيف يتم قياس النجاح

| المجال | ما يتم قياسه | وتيرة الفحص |
| --- | --- | --- |
| دقة الترحيل | فروق أعداد، مجاميع، وعلاقات | في كل موجة وأثناء Cutover |
| الالتزام بالجداول الزمنية | الانحراف عن الأوقات المحددة في الجدول | في كل تشغيل تجريبي (Rehearsal) |
| الاستقرار بعد الترحيل | فشل التكامل وأعطال P1 يوميًا | يوميًا في الأيام الـ 14 الأولى |
| التبني | تسجيلات الدخول والإجراءات مقابل Baseline | أسبوعيًا في الشهر الأول |

يتم تقديم الدعم في تخطيط وتنفيذ Cutover في إطار [خدمات التكامل والبيانات](/ar/integrations-data).

## قائمة التحقق لـ Go/No-Go

- ☐ تشغيلان تجريبيان (Rehearsal) كاملان بحجم بيانات الإنتاج
- ☐ جدول زمني بالساعات مع مسؤول لكل سطر
- ☐ خطة تجميد متفق عليها مع الأعمال
- ☐ قائمة بالتكاملات للفصل والتفعيل، بترتيب صحيح
- ☐ سيناريو مطابقة بأربعة مستويات، مؤتمت قدر الإمكان
- ☐ عينة يدوية محددة مسبقًا تشمل حالات الحافة
- ☐ تحديث جدول ربط المستخدمين والملكية
- ☐ معايير No-Go مكتوبة بعتبات رقمية
- ☐ نقطة لا رجوع فيها وخطة إصلاح للأمام (Fix-Forward)
- ☐ فريق دعم مكثف (Hyper-Care)، وقناة اتصال، وتقرير يومي

## مصادر احترافية

- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**كم عدد الجولات التجريبية (Rehearsal) اللازمة فعليًا؟**
اثنتان كاملتان على الأقل، على أن تكون الثانية بحجم الإنتاج وبنفس ظروف التوقيت. تكشف الجولة الأولى عن أخطاء المحتوى، بينما تكشف الثانية عن مشاكل التوقيت والتسلسل التي تتسبب في فشل نافذة Cutover. المنظمات ذات التكاملات العديدة تجري ثلاث جولات.

**كم من الوقت يجب تجميد النظام الأصلي؟**
أقل وقت ممكن، وبطريقة مقصودة. تؤدي نافذة التجميد (Freeze) الطويلة إلى مقاومة تجارية وعمل خارج النظام. النهج المعتاد: تحميل تاريخي كامل قبل أيام من الانتقال، وجزء Delta قصير فقط خلال النافذة نفسها – عادة ما بين أربع واثنتي عشرة ساعة.

**كيف تتم المطابقة (Reconciliation) بشكل صحيح؟**
على أربعة مستويات: عد السجلات حسب الكيان، مجاميع الحقول المالية والرقمية، سلامة علاقات الأب-الابن، وأخذ عينة يدوية من 20-50 سجلًا يتم اختيارها مسبقًا بما في ذلك حالات الحافة. المستويات الثلاثة الأولى تكون تلقائية؛ الرابع هو ما يلتقط الأخطاء الدلالية.

**متى يتم اتخاذ قرار No-Go (عدم الانتقال)؟**
وفقًا للمعايير التي تم وضعها قبل النافذة وليس حسب الشعور في الوقت الفعلي: تجاوز حد الاستثناءات، فشل في المطابقة المالية، عدم الالتزام بوقت وسيط محدد، أو عدم توفر صانع قرار. من لم يضع معايير No-Go مسبقًا سيستمر دائمًا تقريبًا في المضي قدمًا.

**هل التراجع (Rollback) ممكن حقًا؟**
فقط إذا تم التخطيط له. في معظم الحالات، يكون التراجع الكامل ممكنًا فقط في النافذة الأولى، قبل أن يقوم المستخدمون بإنشاء بيانات جديدة. لذلك، يتم تحديد 'نقطة اللاعودة' في ساعة معينة، وبعدها يتم الانتقال إلى خطة الإصلاح اللاحق (Fix-Forward) مع فريق محدد.

---

## تكلفة Agentforce: الاستهلاك، التراخيص، والتكلفة الإجمالية للملكية (TCO) للوكيل المؤسسي
URL: https://hpi.pro/ar/insights/agentforce-cost-tco
تُعد تكلفة الترخيص الجزء الأسهل للحساب، وغالبًا ما لا تكون العنصر الأكبر. يفكك هذا الدليل التكلفة الإجمالية للملكية (TCO) الحقيقية لخمسة مكونات أساسية: الترخيص، الاستهلاك، البناء، التشغيل، وصيانة المحتوى. كما يقدم صيغة لتكلفة المهمة تتيح مقارنة الوكيل بتكلفة المعالجة البشرية، بدلاً من الاعتماد على الوعود.

## الإجابة المختصرة

السؤال "كم تبلغ تكلفة Agentforce" يتم الإجابة عليه بشكل خاطئ عند ترجمته إلى سعر ترخيص. تتكون التكلفة الحقيقية من خمسة مكونات: الترخيص، الاستهلاك وقت التشغيل، البناء الأولي، التشغيل المستمر، وصيانة المحتوى. في معظم عمليات النشر التي رأيناها، تكون المكونات الثلاثة الأخيرة أكبر من مجموع المكونين الأولين في السنة الأولى.

المقياس الحاسم ليس التكلفة الشهرية، بل التكلفة لكل مهمة مكتملة بدون تصعيد. هذا هو المقياس الوحيد الذي يمكن مقارنته بتكلفة المعالجة الحالية، وهو أيضًا الذي يكشف ما إذا كانت المشكلة في السعر أو في عدد المحاولات المطلوبة للإنجاز.

## المكونات الخمسة للتكلفة الإجمالية للملكية (TCO)

| المكون | ما يتضمنه | السلوك على المدى الزمني | علامة التجاوز |
|---|---|---|---|
| الترخيص | تراخيص المنصة والمستخدمين | ثابت، يزداد مع التوسع | التراخيص التي تم شراؤها قبل اختيار حالة الاستخدام (Use Case) |
| الاستهلاك | العمليات وقت التشغيل وفقًا لنموذج التسعير | متغير حسب الحجم وطول المحادثة | الاستهلاك الذي يزداد دون زيادة في المهام المكتملة |
| البناء | الاكتشاف (Discovery)، الإجراءات (Actions)، التأسيس (Grounding)، الاختبارات | لمرة واحدة لكل حالة استخدام، يتناقص مع الخبرة | النطاق (Scope) الذي يتوسع دون قرار عملي |
| التشغيل | المراقبة، مراجعة الفشل، الإصلاحات، إدارة التغيير | ثابت طالما أن الوكيل نشط | لا يوجد مالك وبالتالي لا توجد تكلفة مسجلة - ثم لا توجد صيانة |
| صيانة المحتوى | تحديث قاعدة المعرفة (Knowledge)، الأرشفة، التحكم في الصلاحية | ثابت حسب عدد مجالات المعرفة | انخفاض تدريجي في دقة الإجابات |

## التكلفة لكل مهمة: الصيغة التي يجب بناؤها

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

تعريف "مكتملة" هو القرار الصعب ويتطلب تحديداً من مالك العملية. محادثة حصل فيها العميل على إجابة وعاود الاتصال في اليوم التالي حول نفس الموضوع ليست مهمة مكتملة. التعريف الفضفاض ينتج أرقامًا جيدة لا تصمد أمام التدقيق.

من المهم المقارنة مقابل خط أساس (Baseline) حقيقي. تكلفة المعالجة البشرية تشمل الأجور، الأنظمة، التدريب، ووقت الانتظار - ليس فقط دقائق المحادثة. المقارنة مقابل رقم جزئي هي السبب الشائع لانهيار المبرر الاقتصادي في المراجعات ربع السنوية.

## ما الذي يزيد التكلفة في الواقع

العامل الأول هو التأسيس (Grounding) الضعيف. عندما لا يجد الوكيل مصدرًا دقيقًا، فإنه يحاول أكثر، وتطول المحادثة ويزداد الاستهلاك - وفي النهاية يتم تصعيد المحادثة على أي حال. تحسين المحتوى غالبًا ما يكون إجراءً يوفر تكلفة أكبر من استبدال النموذج.

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

العامل الثالث هو النطاق (Scope) الواسع. الوكيل الذي من المفترض أن يجيب على كل شيء يستهلك أكثر في كل محادثة، لأنه يفحص المزيد من المصادر ويجري المزيد من الاعتبارات. الوكيل المحدد النطاق يكلف أقل ويكون أكثر دقة.

العلاقة بين جودة مصادر المعلومات والتكلفة مفصلة في [التأسيس (Grounding) وRAG في Agentforce](/ar/insights/agentforce-grounding-rag).

## ضوابط الميزانية التي يجب إعدادها مسبقًا

سقف شهري محدد لكل حالة استخدام، مع تنبيه قبل الوصول إليه. بدون سقف، يأتي اكتشاف التجاوز مع الفاتورة.

تفكيك التكلفة حسب حالة الاستخدام وليس فقط على مستوى المؤسسة. عندما يكون هناك ثلاثة وكلاء ورقم واحد فقط، لا يمكن معرفة أي منهم غير مربح لإغلاقه.

قياس أسبوعي للاستهلاك نسبة إلى المهام المكتملة. الزيادة في الاستهلاك بالتوازي مع استقرار المهام هي إشارة حمراء مبكرة - تشير إلى تدهور في جودة الإجابات قبل أن يشتكي المستخدمون.

كيفية إعداد المراقبة التي تغذي الضوابط مفصلة في [المراقبة (Observability) لوكلاء الذكاء الاصطناعي](/ar/insights/agentforce-observability).

## سيناريو: مشروع تجريبي بدا مكلفًا وتبيّن أنه رخيص

أجرت شركة برمجيات مشروعًا تجريبيًا لمدة ثمانية أسابيع وتلقت فاتورة استهلاك كانت أعلى من المتوقع. كان رد الفعل الأول هو التفكير في التوقف. أظهر التحليل صورة مختلفة: 62% من الاستهلاك جاء من فئة أسئلة واحدة، حيث لم يتمكن الوكيل من العثور على مصدر وبالتالي حاول مرارًا وتكرارًا قبل التصعيد.

العلاج لم يكن فنيًا. تمت كتابة أحد عشر مقالًا جديدًا لقاعدة المعرفة (Knowledge) لتلك الفئة، وتم تحديد آلية تراجع (Fallback) تقوم بالتصعيد بعد محاولتين بدلاً من المحاولة حتى النهاية. انخفض الاستهلاك الشهري بشكل كبير، وزاد عدد المهام المكتملة بالفعل.

تحسنت التكلفة لكل مهمة - المقياس الوحيد الذي تم فحصه لدى المدير المالي (CFO) - أضعافًا مضاعفة، وتمت الموافقة على توسيع المشروع. الخلاصة: الفاتورة المرتفعة غالبًا ما تكون عرضًا لفجوة في المحتوى وليست مشكلة في التسعير.

## متى يكون الوكيل غير مجديٍ ببساطة

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

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

## المخاطر والإجراءات الوقائية

| المخاطرة | كيف تظهر | الإجراء الوقائي |
|---|---|---|
| الترخيص قبل حالة الاستخدام | تراخيص غير مستخدمة وضغط لإظهار القيمة | فحص الجاهزية واختيار العملية قبل الشراء |
| لا توجد ميزانية للتشغيل | انخفاض الجودة بعد الربع الأول | ميزانية سنوية للمراقبة وصيانة المحتوى |
| القياس على مستوى المؤسسة فقط | عدم القدرة على تحديد وكيل غير مجدي | تفكيك التكلفة حسب حالة الاستخدام |
| تعريف فضفاض لـ "مكتمل" | أرقام جيدة تنهار عند التدقيق | تحديد النجاح بواسطة مالك العملية مسبقًا |
| محاولات متكررة بلا سقف | استهلاك مضاعف بلا قيمة | تحديد أقصى عدد من المحاولات والتصعيد المبكر |

## المقاييس الاقتصادية

| المقياس | التعريف | التردد |
|---|---|---|
| التكلفة لكل مهمة مكتملة | إجمالي التكلفة مقسومًا على المهام بدون تصعيد | شهري |
| الاستهلاك لكل مهمة | متوسط وحدات الاستهلاك لكل مهمة | أسبوعي |
| معدل الإنجاز | النسبة المئوية للحالات التي انتهت بالنتيجة المرجوة | أسبوعي |
| تكلفة التشغيل الثابتة | ساعات المراقبة، الإصلاحات، وصيانة المحتوى | شهري |
| النسبة إلى تكلفة خط الأساس | تكلفة الوكيل مقابل تكلفة المعالجة الحالية | ربع سنوي |

عندما يتطلب الأمر نموذجًا اقتصاديًا يصمد أمام التدقيق الداخلي قبل اتخاذ قرار الاستثمار، فإن [خدمة Agentforce والذكاء الاصطناعي](/ar/agentforce-ai) هي المسار العملي للمضي قدمًا.

## قائمة مراجعة لبناء نموذج التكلفة

- ☐ تم تسعير المكونات الخمسة للتكلفة الإجمالية للملكية (TCO) بشكل منفصل
- ☐ تم تعريف ما يعتبر "مهمة مكتملة" من قبل مالك العملية
- ☐ تم قياس خط الأساس (Baseline) لتكلفة المعالجة الحالية
- ☐ تم تحديد سقف استهلاك شهري لكل حالة استخدام (Use Case)
- ☐ يوجد تفكيك للتكلفة على مستوى حالة الاستخدام وليس فقط مستوى المؤسسة
- ☐ تم تخصيص ميزانية للمراقبة وصيانة المحتوى للسنة الأولى
- ☐ تم تحديد أقصى عدد من المحاولات قبل التصعيد
- ☐ تم تحديد حد اقتصادي يتم عنده تعليق الوكيل أو إغلاقه

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

**كيف يمكن مقارنة تكلفة الوكيل بتكلفة الممثل البشري؟**
يتم حساب التكلفة لكل مهمة مكتملة دون تصعيد، وليس التكلفة لكل محادثة. إذا كان الوكيل يتعامل مع ثمانين بالمائة من المحادثة ثم يقوم بالتصعيد، فإن التوفير يكون في الوقت الموفر وليس في المعالجة الكاملة. المقارنة العادلة تشمل أيضًا وقت الممثل المطلوب للإكمال بعد التصعيد.

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

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

**متى يكون القرار الصحيح هو عدم تشغيل وكيل؟**
عندما تكون تكلفة المهمة أعلى من القيمة التي تولدها حتى بعد التحسين، أو عندما يكون حجم العمل منخفضًا جدًا بحيث لا يبرر التشغيل المستمر. معالجة العمليات التي تتضمن بضع مئات من الحالات شهريًا تكون دائمًا تقريبًا أقل تكلفة للحل باستخدام الأتمتة الكلاسيكية أو بتحسين العملية.

---

## أمن Agentforce ونموذج المسؤولية المشتركة
URL: https://hpi.pro/ar/insights/agentforce-security-shared-responsibility
تؤمّن المنصة البنية التحتية، بينما تتحمل المؤسسة مسؤولية تحديد ما يُسمح للعميل (Agent) بالاطلاع عليه وتنفيذه. يحدد هذا الدليل الخط الفاصل العملي - البيانات، الصلاحيات، التعليمات، الإجراءات، والمراقبة - ويسلط الضوء على المخاطر الجديدة التي تنشأ مع استخدام العميل الذكي ولا يوجد لها مثيل في أنظمة CRM التقليدية.

## الإجابة المختصرة

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

الخطر الأكبر لا يكمن في اختراق المنصة، بل في عميل يتمتع بصلاحيات مفرطة ويكشف معلومات لجهة غير مصرح لها، أو يقوم بإجراء لم يكن ينبغي له القيام به - وهذان الفشلان ينبعان بالكامل من جانب المنظمة.

## توزيع المسؤوليات عملياً

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

## المخاطر الجديدة التي لم تكن موجودة في أنظمة CRM التقليدية

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

ثانياً، حقن الأوامر (Prompt Injection). قد يتضمن المحتوى الذي يقرأه العميل - مثل بريد إلكتروني من عميل، حقل وصف، أو مستند مرفق - تعليمات تحاول تغيير سلوكه. لا يمكن الدفاع عن هذا بمجرد الصياغة؛ بل يجب أن يكون الدفاع معماريًا.

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

رابعاً، التوسع الصامت في الصلاحيات: إضافة Action أو إذن لحل مشكلة محددة، دون المرور بمسار الموافقة اللازم.

## عناصر التحكم الخمسة التي تحمل معظم الثقل

الاسترجاع في سياق المستخدم. هذا هو التحكم الوحيد الذي إذا انكسر، فإن كل ما سواه لا ينفع.

إذن منفصل لكل Action، وفقًا لمبدأ الحد الأدنى من الصلاحيات. إذا حصل العميل على ملف تعريف واسع واحد، فإنه يمنع أي تحكم مستقبلي.

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

موافقة بشرية على إجراء لا رجعة فيه. هذا هو التحكم الذي يحول فشلاً محتملاً إلى حدث يتم وقفه في الوقت المناسب.

سجل تدقيق يربط المستخدم، الإجراء، المصدر، والموافق. بدونه لا توجد إجابة لسؤال التدقيق: "بناءً على ماذا قام العميل بهذا الإجراء؟".

يمكن العثور على المبادئ العامة لنموذج الأذونات في Salesforce في [نموذج الأذونات في Salesforce](/ar/insights/salesforce-permission-model).

## ما يجب التحقق منه قبل الإطلاق المباشر (Go Live)

اختبارات Persona: هي من عشرة إلى عشرين سؤالاً يتم تشغيلها بهويات مختلفة - ممثل، مدير، مستخدم محدود، عميل خارجي - ويتم مقارنة الإجابات. أي فرق لا يمكن تفسيره بالصلاحية يعتبر اكتشافًا.

اختبار Red Teaming المحتوى: محاولات متعمدة لاستخراج معلومات غير مصرح بها، تشغيل إجراءات محظورة، وتجاوز آليات التصعيد. يتم كتابة السيناريوهات مرة واحدة ويتم الاحتفاظ بها لتشغيلها بشكل متكرر مع كل إصدار.

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

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

يتم شرح كيفية دمج هذه الاختبارات في إطار اختبار أوسع في [اختبارات Agentforce](/ar/insights/agentforce-testing-scorers).

## سيناريو: اكتشاف تم رصده في اختبار Persona

قامت شركة رعاية صحية بإعداد عميل داخلي للإجابة على أسئلة الإجراءات. في اختبار Persona قبل الإطلاق المباشر، تبين أن مستخدمًا في دور إداري تلقى إجابة تعتمد على إجراء مصنف حصريًا للفريق الطبي.

لم يكن السبب وجود خطأ في العميل. فقد تم بناء الفهرس بواسطة حساب تكامل يتمتع بوصول واسع، ولم يقم الاسترجاع بالتقييد بناءً على أذونات المستخدم. كان هذا التعرض المحتمل موجودًا في أي سؤال يتعلق بهذا المجال.

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

## المخاطر والإجراءات الوقائية

| الخطر | كيف يُكتشف | إجراء وقائي |
| --- | --- | --- |
| استرجاع بصلاحيات واسعة | كشف مستند مصنف في إجابة غير مقصودة | الاسترجاع في سياق المستخدم واختبارات Persona |
| حقن الأوامر (Prompt Injection) | إجراء تم تفعيله نتيجة محتوى خارجي | صلاحيات مقيدة، تحقيق صلاحية داخل الإجراء، موافقة بشرية |
| خلط المحتوى الداخلي والخارجي | وصول صياغة داخلية إلى العميل | قائمة السماح (whitelist) في القناة الخارجية |
| توسيع الصلاحيات بصمت | العميل يفعل أكثر مما هو مصرح به | وسم التغييرات الجوهرية وإعادة الموافقة |
| عدم وجود سجل تدقيق (Audit trail) | عدم وجود إجابة للتدقيق | تسجيل المستخدم، الإجراء، المصدر، والموافق |

## مقاييس الأمن

| المقياس | ماذا يكشف | التكرار |
| --- | --- | --- |
| نتائج Persona | فجوات الأذونات في الاسترجاع | في كل إصدار |
| نتائج Red Teaming | المقاومة ضد محاولات التحايل | في كل إصدار |
| الإجراءات الحساسة بدون موافقة | الثغرات في مسار التحكم | شهريًا |
| التغييرات التي تجاوزت الموافقة | انضباط عملية التغيير | ربع سنوي |
| تغطية سجل التدقيق (Audit trail) | نسبة الإجراءات الحساسة الموثقة بالكامل | ربع سنوي |

يتم تفصيل إطار عمل الموافقات الذي يتم ضمنه تطبيق عناصر التحكم في [إدارة حوكمة الذكاء الاصطناعي لـ Agentforce](/ar/insights/agentforce-ai-governance).

عند الحاجة إلى المساعدة في تحديد نموذج المسؤولية والاختبارات قبل الإطلاق المباشر، تعتبر خدمات [Agentforce والذكاء الاصطناعي](/ar/agentforce-ai) المسار العملي للمتابعة.

## قائمة تحقق الأمان قبل الإطلاق المباشر (Go Live)

- ☐ تم كتابة واعتماد وثيقة تقسيم المسؤوليات.
- ☐ تم توثيق شروط استخدام البيانات مقابل النموذج كتابيًا.
- ☐ يتم تشغيل الاسترجاع ضمن سياق أذونات المستخدم.
- ☐ تم إجراء اختبارات Persona لكل مستوى من مستويات الأذونات.
- ☐ لكل Action إذن منفصل وتحقق داخلي.
- ☐ تتطلب الإجراءات التي لا رجعة فيها موافقة بشرية.
- ☐ على القناة الخارجية، تعمل قائمة سماح للمحتوى.
- ☐ تم كتابة وتنفيذ سيناريوهات Red Teaming للمحتوى.
- ☐ يربط سجل التدقيق (Audit trail) المستخدم، الإجراء، المصدر، والموافق.
- ☐ تم اعتماد سياسة الاحتفاظ بالسجلات ومحتوى المحادثات.

### أسئلة وأجوبة
**ماذا تغطي المنصة وماذا لا تغطي؟**
تغطي المنصة البنية التحتية، التشفير، عزل البيئات، والالتزامات المتعلقة باستخدام البيانات مع النموذج. لكنها لا تحدد من يُسمح له بالاطلاع على ماذا داخل المؤسسة، أو الإجراءات التي يُسمح للعميل (Agent) بتنفيذها، أو ما يدخل إلى قاعدة المعرفة، أو من يقوم بالمراقبة. هذه القرارات هي التي تخلق معظم المخاطر.

**ما هو "حقن الأوامر" (Prompt Injection) في سياق المؤسسات؟**
هو محتوى يقرأه العميل (Agent) - كرسالة بريد إلكتروني واردة، أو حقل وصف، أو مستند تم تحميله - ويحتوي على تعليمات تحاول تغيير سلوكه. الحماية لا تكمن في صياغة تعليمات أفضل، بل في الضوابط: صلاحيات محدودة للإجراءات، والتحقق داخل الإجراء نفسه، والموافقة البشرية قبل أي إجراء حساس.

**هل تُستخدم بيانات المؤسسة لتدريب النماذج؟**
تعتمد الإجابة على الاتفاقية والتكوين، ولذلك يجب توثيقها كتابيًا قبل الإطلاق (Go Live)، وعدم الاعتماد على الافتراضات. هذا أحد الأسئلة الأولى التي ستطرحها فرق التدقيق الداخلي، ومن الأفضل أن تكون الإجابة مدعومة بوثيقة بدلاً من ذاكرة من شارك في مكالمة المبيعات.

**هل يتطلب العميل (Agent) اختبار اختراق؟**
نعم، ولكن من نوع مختلف. بالإضافة إلى الاختبار التقني العادي، يتطلب الأمر اختبار Red Teaming للمحتوى: محاولات استخراج معلومات غير مصرح بها، والتسبب في إجراءات غير مسموح بها، وتجاوز قواعد التصعيد. تُكتب هذه الاختبارات كسيناريوهات وتُحفظ لإعادة تشغيلها مع كل إصدار.

**ما هو المطلوب لأغراض التدقيق والامتثال التنظيمي؟**
سجل تدقيق (Audit trail) يوضح لكل إجراء حساس: المستخدم، ما فعله العميل (Agent)، بناءً على أي مصدر، ومن وافق. بالإضافة إلى سجل محدّث بالعملاء (Agents) ووثيقة تحدد تقسيم المسؤوليات. هذه الثلاثة تغطي معظم أسئلة التدقيق.

---

## اختبارات Agentforce: مجموعات الاختبار، أنظمة التقييم، وسيناريوهات الاستخدام القصوى
URL: https://hpi.pro/ar/insights/agentforce-testing-scorers
لا يمكن اختبار وكيل الذكاء الاصطناعي بنفس طريقة اختبار العمليات التقليدية (Flow)، فالسؤال نفسه قد يحمل إجابتين صحيحتين. يستعرض هذا الدليل كيفية بناء مجموعة اختبار تمثل الواقع بدقة، الأبعاد التي يتم قياسها بشكل مستقل، متى تكون الأتمتة كافية ومتى يتطلب الأمر تقييمًا بشريًا، وما هو الحد الأدنى المقبول للانتقال إلى مرحلة الإنتاج.

## الخلاصة

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

الفصل بين الأبعاد هو ما يجعل الاختبار مفيدًا. "الإجابة ليست جيدة" ليست نتيجة؛ "تم تحديد الموضوع بشكل صحيح ولكن لم يتم استرداد المصدر ذي الصلة" هي نتيجة يمكن إصلاحها.

## أبعاد القياس الأربعة

| البعد | ما يتم اختباره | كيفية القياس | من يقوم بالإصلاح |
| --- | --- | --- | --- |
| تحديد الموضوع | هل فهم Agentforce فحوى السؤال | مقارنة بالموضوع المتوقع | من يكتب التعليمات وأوصاف الإجراءات (Actions) |
| الاسترداد | هل تم استرداد المصدر الصحيح | هل ظهر الجزء المتوقع في عملية الاسترداد | صاحب المحتوى وواضع العلامات (Tagging) |
| الإجابة | هل المحتوى صحيح وكامل | معايير القبول: واجب، محظور، اقتباس | المحتوى والتعليمات |
| العملية | هل تم تفعيل الإجراء الصحيح والحفاظ على التصعيد | اختبار تسلسل الإجراءات وقرار التوقف | الإجراءات (Actions) وقواعد التصعيد |

## بناء مجموعة اختبار تمثيلية

مصدر المواد هو الاستفسارات الحقيقية وليس السيناريوهات المكتوبة في اجتماع. تحتوي النصوص، رسائل البريد الإلكتروني، وأوصاف الحالات (Case descriptions) على ما تفتقر إليه السيناريوهات المخترعة: الأخطاء الإملائية، الصياغة الجزئية، سؤالين في جملة واحدة، والمعلومات الناقصة.

التكوين الموصى به: حوالي نصف الحالات شائعة، حوالي ربع حالات حافة (Edge cases) – استثناءات، شروط أهلية حدودية، أسئلة متعددة الأجزاء – وحوالي ربع حالات يُفترض أن تفشل عمدًا: طلبات خارج النطاق (Out of Scope)، محاولات لاستخراج معلومات غير مصرح بها، وعميل يطلب التحدث إلى شخص.

لكل حالة، يتم تحديد أربعة حقول: الاستفسار كما صيغ، الموضوع المتوقع، معيار القبول للإجابة، والسلوك الإجرائي المتوقع – بما في ذلك "يجب التصعيد" كنتيجة صحيحة وليست فشلًا.

## معيار القبول بدلًا من الإجابة الدقيقة

هذا هو المبدأ الذي يسمح بالتحقق على الإطلاق. بدلًا من كتابة الإجابة الصحيحة، تُكتب ثلاث قوائم قصيرة: حقائق يجب أن تظهر، تصريحات يحظر ظهورها، والمصدر الذي يجب اقتباسه.

المثال النموذجي: سؤال حول أهلية الاسترداد. يجب أن تظهر الفترة الزمنية وشروط حالة المنتج؛ يحظر أن يظهر تعهد باسترداد؛ يجب أن يكون المصدر هو إجراءات الاسترداد في نسختها السارية. صياغتان مختلفتان تمامًا يمكن أن تكونا مقبولتين.

هذه هي الصيغة التي تسمح أيضًا بالتقييم التلقائي الموثوق به – فحص وجود حقيقة معرّفة أدق بكثير من طلب نموذج لتقييم "الجودة".

## الأتمتة مقابل الحكم البشري

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

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

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

كيفية ربط نتائج الاختبارات بالمراقبة في الإنتاج مشروحة في [المراقبة والامتثال لـ Agentforce](/ar/insights/agentforce-observability).

## سيناريوهات الحافة التي يجب تضمينها دائمًا

سؤال بموضوعين في جملة واحدة. استفسار يفتقر إلى معلومات أساسية – هل يسأل Agentforce سؤال توضيح أم يخمن؟ عميل يصيغ بلهجة سلبية – هل يتم تفعيل التصعيد؟ طلب إجراء غير مسموح به لنفس المستخدم. سؤال عن منتج غير موجود – هل يعترف Agentforce أم يخترع؟ محتوى يتضمن تعليمات مموهة تحاول تغيير السلوك.

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

سيناريوهات التجاوز ترتبط باختبارات الأمان المفصلة في [أمان Agentforce والمسؤولية المشتركة](/ar/insights/agentforce-security-shared-responsibility).

## الحدود الدنيا للنشر

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

القاعدة الأهم من الرقم: صفر إخفاقات في الفئات الإلزامية. الكشف عن معلومات غير مصرح بها، إجراء غير قابل للإلغاء بدون موافقة، عدم التصعيد بطلب صريح لشخص – أي من هذه يمنع النشر بغض النظر عن النتيجة الإجمالية.

## سيناريو: مجموعة اختبار صغيرة منعت إطلاقًا سيئًا

خططت شركة سياحة لإطلاق Agentforce للعملاء بعد أن أظهر المشروع التجريبي الداخلي أداءً جيدًا. تضمنت مجموعة الاختبار التي تم بناؤها 90 حالة، منها 22 حالة حافة من استفسارات حقيقية.

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

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

## المخاطر والإجراءات الوقائية

| المخاطرة | كيف تكتشف | الإجراء الوقائي |
| --- | --- | --- |
| مجموعة اختبار مخترعة | كل شيء ينجح في الاختبار ويفشل في الإنتاج | حالات من استفسارات حقيقية |
| اختبار النتيجة الإجمالية فقط | لا يُعرف ما يجب إصلاحه | قياس منفصل للأبعاد الأربعة |
| الاعتماد على التقييم الآلي | إجابات مقنعة مع إغفال تتجاوز | عينة بشرية ثابتة في كل إصدار |
| لا توجد حالات يُفترض أن تفشل | Agentforce يجيب على ما لا يُسمح له به | ربع المجموعة: خارج النطاق وتجاوز |
| لا يوجد انحدار | إصلاح صغير يكسر سيناريو آخر | تشغيل المجموعة قبل كل رفع إصدار |

## مقاييس الاختبار

| المقياس | التعريف | الحد الأدنى المبدئي |
| --- | --- | --- |
| Topic accuracy | نسبة تحديد الموضوع الصحيح | مرتفع؛ الفشل هنا يكسر كل شيء آخر |
| Retrieval hit rate | نسبة الحالات التي تم فيها استرداد المصدر المتوقع | مرتفع في قناة العميل |
| Answer acceptance | نسبة الإجابات التي استوفت معايير القبول | مشتق من القناة والمخاطر |
| Process compliance | نسبة الحالات التي تم فيها تفعيل الإجراء أو التصعيد الصحيح | صفر تجاوزات في الفئات الإلزامية |
| Regression delta | التغير في النتائج مقارنة بالإصدار السابق | بدون انخفاض غير مبرر |

عند الحاجة إلى دعم في بناء مجموعة الاختبار وتحديد حدود النشر، فإن [خدمات Agentforce والذكاء الاصطناعي](/ar/agentforce-ai) هي المسار العملي الأنسب للمتابعة.

## قائمة تحقق للاختبارات

- ☐ تم بناء مجموعة الاختبار من استفسارات حقيقية
- ☐ يتضمن التكوين حالات شائعة، حالات حافة، وحالات يُفترض أن تفشل
- ☐ لكل حالة معيار قبول: واجب، محظور، مصدر
- ☐ يتم تقسيم القياس إلى الموضوع، الاسترداد، الإجابة، والعملية
- ☐ يتم تشغيل المقيمين الآليين (Scorers) على المجموعة بأكملها
- ☐ يتم فحص عينة بشرية ثابتة في كل إصدار
- ☐ تم تضمين سيناريوهات التجاوز والتعليمات المموهة
- ☐ تم تحديد فئات إلزامية مع عدم التسامح مطلقًا
- ☐ تُشغل المجموعة كاختبار انحدار قبل كل رفع إصدار
- ☐ يتم توثيق نتائج الاختبارات ومقارنتها بالإصدار السابق

### أسئلة وأجوبة
**كم عدد الحالات المطلوبة في مجموعة الاختبار؟**
يكفي ما بين 50 إلى 150 حالة للإصدار الأول، شريطة أن تكون تمثيلية. فمجموعة مكونة من 500 حالة جميعها بصياغة صحيحة أقل فائدة من مجموعة مكونة من 80 حالة تتضمن أخطاء إملائية، أسئلة غامضة، طلبات خارج النطاق (Out of Scope) ومحاولات التحايل.

**من أين يمكن الحصول على حالات اختبار واقعية؟**
من الاستفسارات التي تم استلامها بالفعل: نصوص المكالمات، رسائل البريد الإلكتروني، أوصاف الحالات (Case). الحالات التي يكتبها الفريق غالبًا ما تكون مصاغة بشكل جيد وبالتالي قد تكون مضللة. أسرع طريقة هي أخذ آخر مائتي استفسار وتصفية المتكرر منها.

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

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

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

---

## مراقبة Agentforce: استراتيجيات قياس وتحليل وتحسين أداء الوكيل
URL: https://hpi.pro/ar/insights/agentforce-observability
الوكيل دون مراقبة هو صندوق أسود لا يستطيع أحد الدفاع عنه في اجتماع الإدارة. يفصّل هذا الدليل طبقة المراقبة إلى ثلاثة مستويات - المحادثة الفردية، والتوجهات، والنتائج التجارية - ويوضح ما يجب تضمينه في الـ Trace، وكيفية تحويل المحادثات الفاشلة إلى قائمة مهام عمل أسبوعية بدلاً من أن تصبح تقريراً لا يقرأه أحد.

## الإجابة المختصرة

يختلف رصد الوكلاء عن رصد الأنظمة التقليدية: فالوكيل نادرًا ما "يتوقف عن العمل". إنه يستمر في الاستجابة، ولكن بكفاءة أقل. لذلك، فإن المقاييس التقليدية للتوافر والأخطاء ليست كافية، وتتطلب طبقة تقيس جودة القرار وليس فقط السلامة التقنية.

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

## مستويات الرصد الثلاثة

| المستوى | السؤال الذي يجيب عليه | الجمهور | التكرار |
| --- | --- | --- | --- |
| التتبع (Trace) | لماذا انتهت هذه المحادثة بهذا الشكل؟ | الفريق التقني والمحلل | عند الحاجة |
| الاتجاهات (Trend) | ما الذي يتغير سلبًا أو إيجابًا؟ | مالك العملية ومدير المنصة | أسبوعياً |
| النتيجة (Result) | هل يبرر الوكيل وجوده؟ | الإدارة والراعي (Sponsor) | شهرياً وربع سنوي |

## المستوى 1: ما يجب أن يتضمنه التتبع (Trace)

يتيح التتبع (Trace) المفيد استعادة القرار دون سؤال أي شخص. يتألف من سبعة مكونات: الاستفسار بصيغته الأصلية، الموضوع المحدد، المقاطع المسترجعة فعليًا، الإجراءات التي تم تفعيلها مع المعلمات، نتيجة كل إجراء، نقاط الموافقة وقراراتها، وسبب الانتهاء.

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

يجب أيضًا ربط التتبع (Trace) بالسجل التجاري: Case أو Order أو Opportunity. بدون هذا الربط، لا يمكن التحقق مما إذا كانت المحادثة قد أدت في النهاية إلى نتيجة أو إلى استفسار متكرر.

## المستوى 2: الاتجاهات التي تستحق المتابعة

تكفي خمسة مقاييس لمعظم عمليات النشر: معدل الإنجاز بدون تصعيد، معدل الاستفسار المتكرر خلال أسبوع، نسبة الإجابات ذات المصدر الصالح، معدل فشل الإجراءات، والاستهلاك بالنسبة للمهام المكتملة.

يتم تحليل القراءات في أزواج. الاحتواء (Containment) المرتفع مع معدل استفسار متكرر مرتفع لا يعد نجاحًا. الاستهلاك الذي يرتفع بينما المهام مستقرة يعني أن الوكيل يعمل بجد أكبر لتحقيق نفس النتيجة - وهي علامة مبكرة على تدهور المحتوى.

يتم تعيين التنبيهات التلقائية بناءً على التغيير النسبي وليس على القيمة المطلقة: قفزة في معدل التصعيد، انخفاض في نسبة المصادر الصالحة، ارتفاع في فشل الإجراءات مقابل نظام خارجي معين.

يرد تفصيل العلاقة بين هذه المقاييس والتكلفة في [تكلفة Agentforce و TCO](/ar/insights/agentforce-cost-tco).

## المستوى 3: النتيجة التجارية

هذا هو المستوى الذي يحسم الأمر في المراجعة الربع سنوية. رقمان: ما الذي تغير في مقياس العملية الذي اخترناه مسبقًا - وقت المعالجة، معدل الانسحاب، حجم الاستفسارات لكل مندوب - وما هي تكلفة المهمة المكتملة مقابل Baseline.

من المهم تثبيت التعريفات مسبقًا وعدم تغييرها بعد رؤية النتيجة. تغيير تعريف "النجاح" في منتصف الطريق هو أكثر ما يضر بثقة الإدارة في البيانات، حتى عندما يكون التغيير مبررًا.

## من التحليل إلى جدول التحسين

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

القاعدة التي تمنع التشتت: معالجة سبب جذري واحد في الأسبوع. المؤسسات التي تحاول إصلاح خمسة أسباب في وقت واحد لا تعرف في النهاية ما الذي حسن المقياس وما الذي أساء إليه.

تعتبر فجوات المحتوى المحددة هنا مدخلًا مباشرًا لقائمة الكتابة - العملية مفصلة في [إدارة المعرفة لـ Agentforce](/ar/insights/agentforce-knowledge-readiness).

## سيناريو: تدهور صامت تم اكتشافه في الوقت المناسب

قامت شركة خدمات مالية بتشغيل وكيل داخلي ظل مستقرًا لمدة أربعة أشهر. في الأسبوع الخامس عشر، ارتفع معدل التصعيد تدريجيًا دون أن يشكو أحد - كان المندوبون يكملون المعالجة بأنفسهم ببساطة.

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

استغرقت عملية الإصلاح يومين ولم تتطلب أي تدخل في الوكيل. بدون طبقة الرصد، كان الفارق سيكتشف فقط عندما يسأل المدير عن سبب ارتفاع متوسط وقت المعالجة - ربما بعد ربع سنة.

## المخاطر والإجراءات الوقائية

| الخطر | كيف يبدو | إجراء وقائي |
| --- | --- | --- |
| رصد تقني فقط | كل شيء أخضر والإجابات أقل جودة | مقاييس الجودة والتصعيد بجانب مقاييس التوافر |
| تتبع (Trace) بدون مقاطع استرجاع | أشهر من التخمين بين المحتوى والنموذج | تسجيل إلزامي للمقاطع المسترجعة |
| تقرير بدون قائمة عمل | يتم عرض البيانات ولا يغير شيئاً | أخذ عينة أسبوعية وبند عمل لسبب جذري واحد |
| تغيير التعريفات في المنتصف | فقدان الثقة في البيانات | تثبيت تعريفات النجاح مسبقاً |
| لا يوجد ربط بسجل تجاري | لا يمكن تحديد استفسار متكرر | ربط التتبع (Trace) بـ Case أو Order |

## لوحة مقاييس موصى بها

| المقياس | التعريف | حد التنبيه |
| --- | --- | --- |
| معدل الإنجاز | الانتهاء بدون تصعيد وبدون استفسار متكرر | انخفاض نسبي كبير أسبوعاً بعد أسبوع |
| معدل التصعيد | نسبة التحويل إلى عامل بشري | ارتفاع نسبي مستمر |
| مصدر صالح | نسبة الإجابات مع استشهاد موجود وصالح | انخفاض إلى ما دون العتبة المحددة |
| فشل الإجراءات | نسبة العمليات الفاشلة حسب النظام المستهدف | ارتفاع في الفشل مقابل هدف معين |
| الاستهلاك لكل مهمة | وحدات الاستهلاك لكل مهمة مكتملة | ارتفاع بدون نمو في المهام |

عند الحاجة إلى الدعم في إنشاء طبقة رصد وعملية تحسين أسبوعية، فإن [خدمة Agentforce و AI](/ar/agentforce-ai) هي المسار العملي للمضي قدمًا.

## قائمة مراجعة لإنشاء قابلية الملاحظة (Observability)

- ☐ يسجل التتبع (Trace) الاستفسار والموضوع والمقاطع المسترجعة والإجراءات والنتائج.
- ☐ يرتبط كل تتبع (Trace) بسجل تجاري.
- ☐ تفصل سياسة الاحتفاظ بين البيانات الوصفية (Meta-data) ومحتوى المحادثة.
- ☐ تم اختيار من خمسة إلى سبعة مقاييس اتجاه فقط.
- ☐ تم تحديد تنبيهات للتغيير النسبي وليس للقيمة المطلقة.
- ☐ يوجد روتين أسبوعي لأخذ عينات من المحادثات الفاشلة.
- ☐ تم تعريف تصنيف الأسباب الجذرية للفشل.
- ☐ يشارك مالك العملية التجارية في المراجعة الأسبوعية.
- ☐ تم تثبيت تعريفات النجاح قبل بدء القياس.

### أسئلة وأجوبة
**ما الذي يجب أن يتضمنه الـ Trace للمحادثة؟**
الاستفسار بصيغته الأصلية، الموضوع الذي تم تحديده، المقاطع المسترجعة فعليًا، الإجراءات التي تم تفعيلها ومعاييرها، نتيجة كل إجراء، نقاط الموافقة البشرية وقراراتها، والسبب وراء الإنهاء أو التصعيد. بدون المقاطع المسترجعة، لا يمكن التمييز بين مشكلة محتوى ومشكلة نموذج.

**ما هي المدة التي يتم فيها الاحتفاظ بالـ Traces؟**
لمدة كافية للتحقيق في التوجهات الربع سنوية، ولكن بما يتوافق مع سياسة حفظ البيانات واللوائح التنظيمية. عادةً ما يتم الاحتفاظ بمحتوى المحادثة مع بيانات العملاء لفترة أقصر من البيانات الوصفية (metadata)، لذلك يُفضل الفصل: المقاييس والبيانات الوصفية للمدى الطويل، والمحتوى الكامل للمدى القصير.

**هل هناك حاجة لأداة مراقبة خارجية؟**
ليس في البداية. لوحة تحكم داخلية بخمسة إلى سبعة مقاييس وقائمة بالمحادثات الفاشلة كافية للسنة الأولى. تصبح الأداة الخارجية مبررة عندما يكون هناك عدة وكلاء، وقنوات متعددة، وحاجة للربط مع أنظمة مراقبة أخرى داخل المؤسسة.

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

**من يجب أن يدقق في البيانات فعليًا؟**
صاحب العملية التجارية أسبوعيًا، بالتعاون مع مدير المنصة. المراقبة التي تظل حكرًا على الفريق التقني تحدد الأعطال ولكنها تفشل في تحديد الإجابات الصحيحة تقنيًا والضارة تجاريًا – وهذا هو النوع الأكثر شيوعًا من الفشل.

---

## ابنِ أو اشترِ في Agentforce: الإجراءات الجاهزة، Flow، Apex، وواجهات برمجة التطبيقات (APIs)
URL: https://hpi.pro/ar/insights/agentforce-build-vs-buy-actions
لكل إجراء يقوم به العميل، توجد أربع طرق للتنفيذ، والاختلاف بينها ليس تقنياً فحسب؛ بل يتعلق بمن سيقوم بالصيانة، وكيفية الاختبار، والوقت المستغرق للتغيير. يقدم هذا الدليل تسلسلاً واضحاً للاختيار، وتكلفة صيانة كل خيار، والحالات التي يكون فيها Apex هو الخيار الصحيح رغم التكلفة.

## الإجابة المختصرة

تُعد الإجراءات (Actions) هي النقطة التي يتوقف فيها الوكيل عن الكلام ويبدأ في العمل. ولذلك، تتركز فيها معظم المخاطر وتكلفة الصيانة. توجد أربع طرق للتنفيذ: **الإجراءات القياسية (Standard Actions)** و**Flow** و**Apex** و**الخدمات الخارجية (External Services)** عبر واجهة برمجة تطبيقات (API) خارجية. لا يُعد الاختيار بينها مسألة قدرة - فتقريباً كل إجراء ممكن في جميع هذه الطرق - بل هو مسألة تتعلق بمن سيقوم بالصيانة، ومدى سرعة التغيير الممكن، وكيفية الاختبار.

الترتيب الموصى به للاختيار هو من الأعلى إلى الأسفل: البدء بإجراء قياسي، الانتقال إلى Flow عند الحاجة إلى منطق عمل، إلى Apex عندما تكون التعقيدات حقيقية، وإلى الخدمات الخارجية (External Services) عندما يكون مصدر الحقيقة خارج Salesforce. كل نزول في هذا السلم يزيد من تكلفة الصيانة، ولذلك يتطلب مبرراً.

## جدول القرار

| التنفيذ | متى يكون مناسباً | من يقوم بالصيانة | تكلفة الخيار |
| --- | --- | --- | --- |
| Standard Action | الاستعراض، تحديث حقل، فتح حالة (Case)، تلخيص سجل | مدير المنصة | مرونة محدودة لقواعد العمل |
| Flow | قواعد عمل متغيرة، عدة مراحل، التحقق من الصحة (Validation) | المسؤول (Admin) أو مالك العملية | أداء عالٍ عند معالجة كميات كبيرة، معالجة محدودة للأخطاء |
| Apex | منطق معقد، معالجة مكثفة، التحكم بالأخطاء | المطور فقط | كل تغيير يتطلب دورة نشر واختبارات |
| External Services / API | مصدر الحقيقة خارج Salesforce | فريق التكامل | الاعتماد على توفر وجهوزية وإصدارات الطرف الثالث |

## القاعدة الأولى: الوصف قبل التنفيذ

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

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

يجب أن تكون المعلمات (Parameters) بحد أدنى ومن نوع محدد. معلّمة نص حر يتوقع من الوكيل ملء قيمة من قائمة مغلقة هي دعوة للأخطاء؛ قائمة قيم محددة تحل هذه المشكلة دون منطق إضافي.

## متى يتم استخدام Flow ومتى Apex

يُعد Flow هو الخيار الافتراضي لقواعد العمل لأنه مرئي ويسمح لمالك العملية بفهم ما يحدث. في سياق الوكلاء (Agents)، هناك ميزة إضافية وهي سرعة الإصلاح: عند اكتشاف أن الإجراء لا يتحقق من شروط الأهلية، يمكن إصلاحه في نفس اليوم.

يُبرر استخدام Apex في أربع حالات: منطق ذو تفرعات متعددة يجعل Flow غير قابل للقراءة، معالجة كميات كبيرة في استدعاء واحد، الحاجة إلى تحكم دقيق في معالجة الأخطاء والمعاملات، والتكامل الذي يتطلب معالجة استجابة معقدة. بخلاف هذه الحالات، يزيد Apex بشكل أساسي من تكلفة التغيير التالي.

يرتبط الاختيار أيضاً بالديون التقنية الموجودة. يجب على المؤسسة التي تعاني بالفعل من آلاف الأسطر من كود Apex بدون اختبارات أن تفكر مرتين قبل إضافة طبقة أخرى – تظهر الاعتبارات الكاملة في [Flow مقابل Apex](/ar/insights/salesforce-flow-vs-apex).

## الإجراءات مقابل الأنظمة الخارجية

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

**اللامُساواة (Idempotence)** هي المفهوم الحاسم. يمكن محاولة إجراء الاستدعاء بأمان مرة أخرى. أما الإجراء الذي يُنشئ سجلاً، أو يرسل رسالة، أو يخصم من بطاقة – فإن المحاولة المتكررة قد تُنشئ ازدواجية. الحل هو مفتاح فريد لكل طلب تتعرف عليه المنظومة المُستقبِلة، أو التخلي الواعي عن المحاولة الثانية.

**الكمون (Latency)** هو اعتبار يتعلق بتجربة المستخدم وليس فقط اعتباراً تقنياً. يُعد استدعاء يستغرق بضع ثوانٍ مقبولاً في قناة الدردشة (Chat) إذا قال الوكيل إنه يتحقق؛ أما الاستدعاء الذي يستغرق أكثر من ذلك فيتطلب مساراً غير متزامن – حيث يؤكد الوكيل الاستلام ويُحدِّث عندما تصل الإجابة.

تُفصل أنماط التعامل مع إخفاقات التكامل في [معالجة أخطاء التكامل في Salesforce](/ar/insights/salesforce-integration-error-handling).

## الصلاحيات على مستوى الإجراء

يجب أن يكون كل إجراء (Action) مقيداً بترخيص منفصل. الخطأ الشائع هو منح الوكيل ملف تعريف واسع (Profile) يغطي جميع الإجراءات، وحينها لا توجد طريقة لفتح إجراء واحد لمجموعة معينة دون فتح جميعها.

مبدأ العمل: حد أدنى من الصلاحيات لكل إجراء، التحقق من الصحة (Validation) داخل الإجراء وليس فقط في تعليمات الوكيل، والتحقق من أن الإجراء يحترم سياق المستخدم. لا يجوز الاعتماد على أن التعليمات (Instructions) ستمنع التشغيل – التعليمات هي إرشاد وليست تحكماً.

## متى يجب تقسيم الإجراء

الإجراء الذي يقوم بثلاثة أشياء هو إجراء يصعب اختباره ويصعب اعتماده. علامة التقسيم: عندما يتطلب جزء من الإجراء موافقة بشرية وجزء آخر لا يتطلبها، أو عندما تتطلب الأجزاء المختلفة صلاحيات مختلفة، أو عندما يترك الفشل في المنتصف العملية في حالة غير متسقة.

يؤدي التقسيم إلى زيادة تكلفة التنسيق قليلاً ولكنه مجدٍ: يتم اختبار كل جزء على حدة، ويمكن للوكيل التوقف بين الأجزاء، وتكون الصلاحيات دقيقة. القاعدة العملية - إجراء واحد، قرار واحد.

يتم تفصيل التخطيط لنقاط التوقف بين الأجزاء في [Human-in-the-Loop في Agentforce](/ar/insights/agentforce-human-in-the-loop).

## سيناريو: مؤسسة انتقلت من Apex إلى Flow

قامت شركة خدمات ببناء ستة إجراءات (Actions) في Apex ضمن مرحلة تجريبية (Pilot)، على افتراض أنها ستحصل بذلك على تحكم كامل. وخلال شهرين، اتضح أن أربعة من هذه الإجراءات قد غيرت منطقها ثلاث مرات لكل منها – ليس بسبب الأخطاء (Bugs)، بل لأن قواعد العمل اتضحت أثناء الاستخدام. كل تغيير تطلب فريق تطوير واختبارات ودورة نشر استغرقت عدة أيام.

في الجولة الثانية، بقيت الإجراءات التي تتضمن استدعاءات متعددة لأنظمة خارجية ومعالجة استجابات معقدة في Apex. تم نقل الأربعة الأخرى إلى Flow، وأصبح مدير المنصة مسؤولاً عنها. انخفض متوسط وقت الإصلاح من أيام إلى ساعات.

لم تكن العبرة هنا أن Apex سيء، بل أن في المرحلة التي لا تزال فيها القواعد تتشكل، تكون تكلفة التغيير أهم من تكلفة البناء الأولية.

## المخاطر والإجراءات الوقائية

| الخطر | كيف يُكتشف | إجراء وقائي |
| --- | --- | --- |
| وصف إجراء غامض | الوكيل يُشَغّل الإجراء الخاطئ | وصف يتضمن "متى نعم" و"متى لا" ومعلمات محددة |
| إعادة المحاولة بشكل أعمى | سجلات أو فواتير مكررة | مفتاح فريد لكل طلب أو التنازل عن إعادة المحاولة (Retry) |
| صلاحية واسعة للوكيل | إجراء حساس متاح لكل مستخدم | صلاحية منفصلة لكل إجراء وتحقق من الصحة (Validation) داخل الإجراء |
| كل المنطق في Apex | كل تغيير في العمل يصبح مشروع تطوير | Flow لقواعد العمل المتغيرة، Apex للتعقيدات الحقيقية |
| إجراء يقوم بثلاثة أشياء | الفشل في المنتصف يترك العملية في حالة غير متسقة | تقسيم بناءً على الاعتبار والصلاحية |

## مؤشرات الأداء للإجراءات (Actions)

| المؤشر | ما يكشف عنه | التكرار |
| --- | --- | --- |
| Action success rate | نسبة الإجراءات التي اكتملت بنجاح | أسبوعي |
| Wrong action rate | نسبة الحالات التي تم فيها اختيار إجراء خاطئ | مع كل إصدار |
| Latency المتوسط للإجراء | هل تبقى التجربة مقبولة | أسبوعي |
| نسبة فشل التكامل | استقرار الأنظمة المستهدفة | أسبوعي |
| متوسط وقت الإصلاح | هل التنفيذ المختار يسمح بالتغيير السريع | شهري |

عندما تتطلبون التوجيه في تخطيط طبقة الإجراءات (Actions) وتكييفها مع البنية الحالية، تُشكل [خدمة Agentforce وAI](/ar/agentforce-ai) المسار العملي للمتابعة.

## قائمة مراجعة لكل إجراء (Action)

- ☐ تم كتابة وصف يتضمن "ماذا"، "متى نعم"، و"متى لا"
- ☐ المعلمات بحد أدنى ومن نوع محدد
- ☐ تم اختيار التنفيذ الأعلى مستوى الذي يفي بالغرض
- ☐ تم تحديد صلاحية منفصلة للإجراء
- ☐ التحقق من الصحة (Validation) موجود داخل الإجراء وليس فقط في التعليمات
- ☐ تم تحديد ما إذا كان الإجراء لَامُسَاوِياً (Idempotent) وما هي سياسة إعادة المحاولة (Retry)
- ☐ تم تحديد الحد الأقصى لوقت الانتظار ورسالة الفشل للمستخدم
- ☐ تم تقسيم الإجراءات متعددة القرار
- ☐ يوجد سيناريو اختبار للفشل وليس فقط للنجاح

### أسئلة وأجوبة
**لماذا لا نبني كل شيء باستخدام Apex ببساطة وننهي الأمر؟**
لأن كل إجراء (Action) مبني باستخدام Apex يجعل أي تغيير مستقبلي يعتمد على المطور ودورة النشر. في الإجراءات التي تعتمد على قواعد عمل متغيرة، يتيح Flow لمالك العملية التحديث بنفسه. يُبرر استخدام Apex عندما تكون هناك منطق معقد، معالجة مكثفة، أو استدعاء يتطلب تحكماً دقيقاً في الأخطاء.

**هل الإجراءات القياسية (Standard Actions) كافية لمشروع تجريبي (Pilot)؟**
غالباً نعم، وهذا هو المقصود. يمكن بناء مشروع تجريبي يبدأ باسترجاع سجل، وتحديث حقل، وفتح حالة (Case) في أيام بدلاً من أسابيع، مما يسمح باختبار السؤال الأهم – هل يختار العميل بشكل صحيح متى يستخدم الإجراء – قبل الاستثمار في التطوير.

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

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

**متى يُنصح بتقسيم إجراء واحد إلى عدة إجراءات (Actions)؟**
عندما يقوم الإجراء بأكثر من عملية تقديرية واحدة، أو عندما يتطلب جزء منه موافقة بشرية وجزء آخر لا يتطلبها. يتيح التقسيم تعيين صلاحية مختلفة لكل جزء، واختبار كل جزء على حدة، والسماح للعميل بالتوقف في المنتصف دون ترك عملية غير مكتملة جزئياً.

---

## إدارة المعرفة لـ Agentforce: إعداد البيانات غير المهيكلة للذكاء الاصطناعي
URL: https://hpi.pro/ar/insights/agentforce-knowledge-readiness
مستودع المعرفة المصمم للبشر ليس جاهزاً لـ Agentforce: فهو يحتوي على نُسخ متضاربة، مستندات بلا مالك، ومحتوى داخلي مختلط بمحتوى العملاء. يقدم هذا الدليل عملية تدريب من خمس خطوات - تدقيق، أرشفة، هيكلة، وسم، وملكية - مع عتبات دخول للفهرس ونموذج صيانة مستدام.

## الإجابة المختصرة

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

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

يُشرح كيفية استهلاك طبقة الاسترجاع لهذا المحتوى في [Grounding و-RAG في Agentforce](/ar/insights/agentforce-grounding-rag).

## الخطوة 1: مراجعة مركزة

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

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

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

## الخطوة 2: الأرشفة قبل الكتابة

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

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

في حالة تضارب بين نسختين، يكون الحسم لمالك المحتوى وليس للفريق التقني. هذه نقطة تتطلب قرارًا تجاريًا، وتجاوزها يعيد المشكلة في مرحلة الاختبارات.

## الخطوة 3: هيكلة المقال

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

قاعدتان تؤثران بشكل مباشر على جودة الاسترجاع: شروط الأهلية والاستثناءات توضع في قسم منفصل ومميز، ولا تدمج في جملة؛ والجداول تبقى صغيرة ومستقلة، لأن الجدول الذي يُقطع في المنتصف ينتج إجابة جزئية.

ما يجب تجنبه: المقالات الطويلة التي تغطي خمسة مواضيع. يفضل تقسيمها إلى خمسة مقالات مركزة - الاسترجاع يكون أكثر دقة والصيانة أسهل.

المبادئ الأوسع لإدارة المعرفة في Service Cloud مفصلة في [إدارة المعرفة في Salesforce](/ar/insights/salesforce-knowledge-management).

## الخطوة 4: التصنيف وفصل الجمهور

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

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

المستند الذي يكون معظمه مسموحًا به ولكن به فقرة واحدة حساسة ليس حالة استثنائية - بل هو شائع. الحل هو تقسيم المستند بدلاً من تمييزه بالكامل على أنه داخلي.

## الخطوة 5: الملكية والصيانة

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

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

الميزانية: صيانة المحتوى هي بند ثابت وليست مشروعًا. المؤسسات التي تتعامل معها كمهمة لمرة واحدة تشهد انخفاضًا في الدقة في غضون ربعين.

## عتبات الإدراج في الفهرس

| المعيار | الحد الأدنى | السبب |
|---|---|---|
| الملكية | مالك باسم لكل مقال | بدون مالك، لا يوجد من يحدث |
| الصلاحية | ضمن فترة المراجعة المحددة للمجال | يمنع اقتباس سياسة ملغاة |
| التفرد | مصدر واحد لكل موضوع | يمنع الإجابات المتضاربة |
| الجمهور | مصنف كداخلي أو معتمد للعميل | يمنع كشف محتوى حساس |
| الهيكل | عنوان سؤال وإجابة قصيرة في المقدمة | يحسن دقة الاسترجاع |

## سيناريو: 1400 مستند تم تقليصها إلى 190

أرادت إحدى شركات تقديم خدمات تكنولوجيا المعلومات ربط عميل افتراضي بملف SharePoint يحتوي على 1400 مستند. أظهر الفحص الأولي أن حوالي 30% منها فقط تم تحديثها في السنوات الثلاث الماضية، وأن حوالي 200 منها كانت مسودات أو نسخ عمل.

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

بدأ المشروع التجريبي بـ 190 عنصرًا بدلاً من 1400، وكانت دقة الإجابات أعلى بكثير من المحاولة الأولى. بقيت بقية المستودع في الأرشيف، وتم إدخالها تدريجياً وفقًا لقائمة الفجوات التي تراكمت من التصعيدات الفعلية.

## المخاطر والإجراءات الوقائية

| المخاطر | كيف تتجلى | إجراء وقائي |
|---|---|---|
| إدخال المستودع بأكمله | دقة منخفضة وصعوبة تحديد السبب | الإدخال حسب السيناريوهات وليس حسب المستودع |
| مقالات بدون مالكين | تقادم صامت | الملكية كشرط للدخول إلى الفهرس |
| إصدارات متضاربة | إجابات مختلفة لنفس السؤال | حسم تجاري وأرشفة |
| خلط المحتوى الداخلي والخارجي | كشف معلومات حساسة للعميل | قائمة بيضاء في القناة الخارجية |
| الصيانة كمشروع لمرة واحدة | انخفاض الدقة في غضون ربعين | ميزانية ثابتة واتفاقية مستوى الخدمة (SLA) للتحديث |

## مؤشرات جاهزية المحتوى

| المؤشر | التعريف | التكرار |
|---|---|---|
| تغطية السيناريوهات | نسبة السيناريوهات ذات المقالات المعتمدة | شهري |
| الصلاحية | نسبة المقالات في الفهرس ضمن تاريخ الصلاحية | شهري |
| التكرار الموضوعي | عدد المواضيع التي تحتوي على أكثر من مصدر واحد | ربع سنوي |
| فجوات من التصعيدات | عدد المواضيع الجديدة المطلوبة وغير الموجودة | أسبوعي |
| متوسط وقت التحديث | كم يستغرق تصحيح مقال تبين أنه خاطئ | شهري |

عند الحاجة إلى المرافقة في إعداد المستودع وإنشاء نموذج الصيانة، فإن [خدمات Agentforce و-AI](/ar/agentforce-ai) هي المسار العملي للمتابعة.

## قائمة مراجعة لإعداد المعرفة

- ☐ تم بناء قائمة أسئلة حقيقية من طلبات فعلية
- ☐ تم تصنيف كل سؤال: صالح، قديم، متضارب أو مفقود
- ☐ المقالات بدون مالكين تم أرشفتها أو تم تعيين مالكين لها
- ☐ تم حسم التضاربات من قبل مالك المحتوى
- ☐ المقالات منظمة: عنوان سؤال، إجابة قصيرة، أقسام
- ☐ شروط الأهلية والاستثناءات في قسم منفصل
- ☐ يوجد تصنيف للمنتج، السوق، اللغة، الجمهور، والصلاحية
- ☐ تم فصل المحتوى الداخلي عن المحتوى المعتمد للعميل
- ☐ تم تحديد وتيرة المراجعة والإزالة التلقائية عند انتهاء الصلاحية
- ☐ تم إنشاء آلية تحول التصعيدات إلى قائمة كتابة

### أسئلة وأجوبة
**هل يجب إعادة كتابة جميع المقالات قبل البدء؟**
لا. نبدأ بالسيناريوهات التي سيتعامل معها Agentforce في الإصدار الأول - وعادة ما تكون من عشرين إلى أربعين مقالاً. إعادة الكتابة الشاملة لمستودع يضم مئات المقالات تستغرق أشهراً وغالباً ما تتوقف في المنتصف، بينما التدريب المستهدف يكفي للمرحلة التجريبية.

**ماذا نفعل بالمقالات التي لا يوجد لها مالك؟**
إما أن تقوم بتعيين مالك أو أن تقوم بأرشفتها. المقال الذي لا يملك مالك سيستمر في التقادم وسيستمر Agentforce في الاقتباس منه. هذا قرار غير مريح ولكنه أرخص بكثير من اكتشاف لاحقًا أن Agentforce قدم سياسة تم إلغاؤها قبل عامين.

**كيف نميز المقالات المتضاربة في مستودع كبير؟**
نجمع المقالات حسب الموضوع ونفحص يدويًا المجموعات التي تحتوي على أكثر من مقال واحد فقط. يمكن أيضًا طرح الأسئلة العشرين الأكثر شيوعًا على Agentforce نفسه والتحقق من المصادر التي تم استرجاعها - يتم الكشف عن التناقض فورًا عند ظهور مقالين بإجابات مختلفة.

**هل ملفات PDF ومستندات Word مناسبة كمصدر؟**
هي أقل جودة من المقالات المهيكلة، ولكنها ممكنة عندما يكون المستند مقسمًا إلى أقسام ذات عناوين واضحة. المستندات الممسوحة ضوئيًا، العروض التقديمية، أو الملفات ذات الجداول المعقدة هي مصادر إشكالية، ومن الأفضل استخلاص المحتوى ذي الصلة منها لمقال مخصص.

**ما هي الهيكلة الصحيحة للمقال الذي يستهدف Agentforce أيضًا؟**
سؤال أو سيناريو كعنوان، إجابة قصيرة في الفقرة الأولى، ثم تفاصيل في أقسام ذات عناوين فرعية. شروط الأهلية والاستثناءات في قسم منفصل وليس ضمن جملة. هذه الهيكلة تخدم القارئ البشري أيضًا، لذا لا يوجد هنا أي تنازل.

---

## حوكمة الذكاء الاصطناعي لـ Agentforce: نموذج للمسؤولية والمخاطر والضوابط
URL: https://hpi.pro/ar/insights/agentforce-ai-governance
تفشل حوكمة الذكاء الاصطناعي على طرفي نقيض: إما لجنة تعيق كل مبادرة، أو غياب للضوابط يتجلى في المراجعات. يقدم هذا الدليل نموذجًا متدرجًا حسب المخاطر - من يوافق على ماذا، ما هي الضوابط الإلزامية في كل مستوى، ما هي المستندات المطلوبة حقًا، وكيف نحافظ على السرعة دون التنازل عن المسؤولية.

## الإجابة المختصرة

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

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

## تصنيف المخاطر: أساس جميع القرارات الأخرى

| الدرجة | الخصائص | الموافقون | الضوابط الإلزامية |
| :---- | :---- | :---- | :-------------- |
| منخفضة | داخلية، قراءة فقط، لا تحتوي على بيانات عملاء حساسة | مالك العملية + مدير المنصة | ترسيخ معتمد، سجل المحادثات، مراجعة شهرية |
| متوسطة | داخلية مع كتابة قابلة للعكس، أو كشف معلومات للعملاء | + مهندس معماري + ممثل بيانات | مجموعة اختبار، اختبارات الشخصية، مراقبة أسبوعية |
| عالية | تفاعل مع العميل، معاملات مالية، أذونات، أو بيانات غير قابلة للعكس | + إدارة المخاطر، الشؤون القانونية، ومدير أمن المعلومات | موافقة بشرية، مسار تدقيق كامل، خطة استرجاع |
| ممنوعة | قرارات ذات تأثير قانوني أو تنظيمي مباشر دون تدخل بشري | - | يتم رفض حالة الاستخدام أو تقسيمها إلى مهمة فرعية ذات درجة أقل |

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

## الأدوار الثلاثة الواجب تعيينها

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

المالك التقني مسؤول عن التنفيذ، المراقبة، عملية التغيير، والتكلفة. يحتفظ بسجل الوكلاء وكتيب التشغيل (Runbook) للتعامل مع الأعطال.

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

يتم تفصيل نموذج المسؤولية المشتركة مع Salesforce ومزودي النماذج في [أمن Agentforce والمسؤولية المشتركة](/ar/insights/agentforce-security-shared-responsibility).

## سجل الوكلاء

هذه هي الوثيقة الوحيدة التي لا يمكن الاستغناء عنها. لا يجب أن تكون نظامًا - جدولًا مُحدّثًا يكفي - ولكن يجب أن تكون مُحدّثة. لكل وكيل نشط: هدف في جملة واحدة، مالك عملي وتقني، درجة مخاطر، قنوات نشطة، قائمة "الإجراءات" (Actions) وأذوناتها، مصادر "الترسيخ" (Grounding)، نقاط الموافقة البشرية، تاريخ آخر مراجعة، ومؤشرات الأداء الرئيسية الثلاثة.

يحل السجل مشكلة تظهر في السنة الثانية: انتشار الوكلاء. عندما يقوم كل فريق بإنشاء وكيل خاص به، تجد ثلاثة وكلاء يجيبون على نفس السؤال بثلاث طرق مختلفة، ولا أحد يعرف من وافق على الوكيل الثالث.

## عملية التغيير بعد الإطلاق

التمييز بين التغيير الروتيني والتغيير الجوهري هو ما يمنع الحوكمة من أن تصبح معوقة. التغيير الروتيني - صياغة، تصحيح صياغة في الإجابة، إضافة مقال معرفي موجود إلى الفهرس - يمر عبر عملية التغيير العادية للمنصة. التغيير الجوهري يتطلب موافقة جديدة بالدرجة المناسبة.

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

يتم تفصيل آليات المراقبة التي تغذي عملية التغيير في [قابلية الملاحظة لوكلاء الذكاء الاصطناعي](/ar/insights/agentforce-observability).

## ما الذي تراجعه الحوكمة فعليًا، ربع سنويًا

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

نتج عن المراجعة قائمة قرارات: توسيع، تقليص، تعليق، أو إغلاق وكيل. الحوكمة التي لا تستطيع إغلاق وكيل ليست حوكمة - إنها توثيق.

## سيناريو: تاجر تجزئة استعاد السيطرة دون إيقاف التطوير

اكتشفت سلسلة متاجر تجزئة سبع مبادرات للذكاء الاصطناعي بالتوازي في أربعة أقسام، دون تسجيل ودون علم قسم المخاطر. كان الرد الأول المقترح هو تجميد شامل حتى وضع السياسات - وهي خطوة كانت ستجمد أيضًا المبادرتين اللتين تحققان قيمة بالفعل.

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

بعد ستة أشهر، تزايد عدد المبادرات ولكن الإدارة عرفت لأول مرة ما هو موجود، ومن هو المسؤول، وما هي التكلفة. الخلاصة العملية: اكتسبت الحوكمة الشرعية بالتحديد لأنها لم تعق الدرجة المنخفضة.

## مخاطر الحوكمة والإجراءات الوقائية

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

## مؤشرات الحوكمة

| المؤشر                  | ما يكشف عنه                                    | التكرار    |
| :----------------------- | :--------------------------------------------- | :---------- |
| تغطية السجل              | نسبة الوكلاء النشطين الموثقين                  | شهري       |
| متوسط وقت الموافقة       | هل أصبح المسار عنق زجاجة                         | شهري       |
| نتائج أخذ العينات         | الفجوة بين التحكم المعلن والحالة الفعلية      | ربع سنوي   |
| التغييرات الجوهرية في المسار الصحيح | انضباط العملية                                  | ربع سنوي   |
| الوكلاء المعلقون أو المغلقون | هل الحوكمة قادرة على اتخاذ قرار بعدم الاستمرار | ربع سنوي   |

عند الحاجة إلى إرشاد في إنشاء نموذج حوكمة يتناسب مع حجم المؤسسة واللوائح المطبقة عليها، فإن [خدمة Agentforce والذكاء الاصطناعي](/ar/agentforce-ai) هي المسار العملي للمضي قدماً.

## قائمة مراجعة لإنشاء الحوكمة

- ☐ تمت الموافقة على نموذج تصنيف المخاطر المكون من ثلاثة أسئلة
- ☐ تم تحديد الموافقين لكل درجة، بما في ذلك مسار سريع للدرجات المنخفضة
- ☐ تم تعيين مالك عملي وتقني لكل وكيل موجود
- ☐ تم تعيين مدقق مستقل غير مشارك في عملية البناء
- ☐ تم إنشاء سجل الوكلاء مع جميع الحقول الإلزامية
- ☐ تم تحديد قائمة مغلقة من التغييرات الجوهرية
- ☐ تم تحديد روتين مراجعة ربع سنوية مع صلاحية إغلاق وكيل
- ☐ تم تحديد مؤشرات الحوكمة وتواتر إبلاغ الإدارة

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

**من هو مالك الوكيل: العمل أم قسم تكنولوجيا المعلومات؟**
مالك العملية التجارية هو مالك النتيجة والقرار بشأن ما هو مسموح للوكيل بفعله. قسم تكنولوجيا المعلومات هو مالك التنفيذ، المراقبة، والاستقرار. عندما تظل الملكية مقتصرة على قسم تكنولوجيا المعلومات، لا يتخذ أحد قرارات بشأن السلوك، ويتوقف الوكيل عند نسخته الأولى.

**هل يتطلب كل تغيير في التعليمات (Instructions) موافقة؟**
لا. قد يمر تغيير في صياغة وكيل منخفض المخاطر عبر عملية تغيير عادية. أما التغيير الذي يوسع صلاحية، يضيف إجراءً (Action)، يفتح قناة جديدة، أو يزيل نقطة موافقة بشرية - فهو تغيير جوهري يتطلب إعادة موافقة على المستوى المناسب.

**ماذا يجب أن يتضمن سجل الوكلاء؟**
لكل وكيل نشط: الهدف في جملة، المالك التجاري، تصنيف المخاطر، القنوات، قائمة بالإجراءات (Actions) وصلاحياتها، مصادر Grounding، نقاط الموافقة البشرية، تاريخ آخر مراجعة، ومقاييس الأداء. هذه هي الوثيقة الأولى التي سيطلبها أي مدقق.

**كيف نمنع الحوكمة من إبطاء التطوير؟**
يتم تحديد مسار سريع للمخاطر المنخفضة: وكيل للقراءة فقط في قناة داخلية يُوافق عليه من قبل مالك العملية ومدير المنصة، دون الحاجة إلى لجنة. كلما زادت المخاطر، تضاف الموافقات والضوابط. المسار الموحد لكل وكيل هو السبب الشائع لتجاوز الحوكمة.

---

## دورة التحوّل من العميل المحتمل إلى الإيرادات (Lead-to-Cash) في Sales Cloud: تصميم عملية المبيعات حتى إتمام الطلب
URL: https://hpi.pro/ar/insights/salesforce-lead-to-cash
غالبًا ما تواجه دورة Lead-to-Cash تحديات في ثلاث نقاط تحول رئيسية: من العميل المحتمل إلى الصفقة، ومن الصفقة إلى عرض سعر معتمد، ومن العرض إلى الطلب في نظام ERP. يوضح هذا الدليل ما يجب تحديده في كل مرحلة، وكيفية تحديد مكان إقامة التسعير، ولماذا غالبًا ما تكون الموافقات على الخصومات هي عنق الزجاجة الحقيقي.

## الإجابة المختصرة

إن عملية تحويل العميل المحتمل إلى نقد (Lead-to-Cash) هي عملية شاملة تمتد عبر أربعة أقسام: التسويق، المبيعات، المالية، والعمليات. وبالتالي، فإنها غالبًا ما تتعثر عند الحدود الفاصلة بين هذه الأقسام وليس في جوهرها. توجد ثلاث نقاط تحول حاسمة تحدد كل شيء: متى يصبح الاستفسار صفقة، متى تتحول تسعيرة إلى عرض معتمد، ومتى تصبح الصفقة المغلقة طلب شراء في النظام التشغيلي.

في كل نقطة من هذه النقاط، يجب أن تكون هناك ثلاث إجابات مكتوبة: من يتخذ القرار، ما المتطلبات اللازمة للانتقال، وماذا يحدث عندما يفشل الانتقال. إذا غاب أحد هذه العناصر، ينشأ جدول بديل (spreadsheet) يؤدي إلى معظم الفجوات بين ما تم بيعه وما تم فوترته.

## نقطة التحول 1: من عميل محتمل إلى صفقة

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

المطلوب: معايير مكتوبة للتحويل (جهة اتصال ذات صلاحية، حاجة واضحة، أفق زمني محدد)، مالك (Owner) محدد لكل جانب من جوانب هذا الحد، وقاعدة واحدة للتعامل مع العملاء المحتملين الذين لم يستوفوا المعايير – التغذية (Nurture) بدلاً من الحذف. يمكن العثور على مزيد من التفاصيل حول هذا الموضوع في [تنفيذ Sales Cloud](/ar/insights/sales-cloud-implementation).

## نقطة التحول 2: من عرض أسعار إلى عرض أسعار معتمد

تتركز معظم التأخيرات في هذه المرحلة من العملية هنا، ويكاد يكون السبب دائمًا هو عدم وجود هيكل صلاحيات واضح للموافقة، وليس بسبب الأداة المستخدمة.

| المكون | ما يجب تحديده | ماذا يحدث بدونه |
| --- | --- | --- |
| كتالوج وقائمة الأسعار | مصدر واحد للحقيقة للسعر | عروض أسعار بأسعار يدوية |
| عتبة الخصم | تسلسل هرمي حسب النسبة المئوية ونوع العميل | كل خصم يذهب إلى المدير التنفيذي أو لا يوجد خصم |
| وقت الاستجابة للموافقة | هدف محدد، على سبيل المثال يوم عمل | تجاوز هاتفي وتوثيق لاحق |
| الشروط غير السعرية | شروط الدفع، الضمان، SLA | التزامات لم تصل إلى الإدارة المالية |

غالبًا ما يتم إهمال السطر الأخير: فبينما تضع المؤسسات ضوابط دقيقة على الخصومات، فإنها تسمح لممثل المبيعات بالالتزام بشروط دفع مثل "صافي 90 يومًا" دون أي موافقة.

## نقطة التحول 3: من صفقة مغلقة إلى أمر شراء

هذه هي النقطة الأكثر تقنية والأغلى تكلفة على مستوى الأعطال. ثلاثة أسئلة تحدد الهيكلية:

1. **من يصدر أمر الشراء** - عادةً ما يكون نظام تخطيط موارد المؤسسات (ERP). يقوم Salesforce بإرسال طلب ويستلم معرفًا، ولا يدير المخزون أو الفوترة.
2. **ماذا يحدث عند الفشل** - يتطلب الأمر حالة (status) مرئية على الصفقة، إشعارًا لمالك العملية، وآلية إعادة إرسال ثاتة الأثر (idempotent) لمنع إنشاء أمر شراء مكرر.
3. **ما الذي يعود إلى النظام** - على الأقل، معرف أمر الشراء، حالة التسليم، وحالة الفوترة. بدون هذه البيانات المرتدة، يقوم ممثلو المبيعات بالاتصال بالقسم المالي للإجابة على استفسارات العميل.

يمكن العثور على مبادئ تصميم التكامل نفسه في [تكامل Salesforce و-ERP](/ar/insights/salesforce-erp-integration)، والتعامل مع الأخطاء في [التعامل مع الأخطاء في التكاملات](/ar/insights/salesforce-integration-error-handling).

## المشكلة الصامتة: تنسيق المنتجات بين الأنظمة

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

القاعدة: كتالوج المنتجات مملوك لجهة واحدة فقط – عادةً نظام ERP – ويتم مزامنته مع Salesforce بتردد محدد، بما في ذلك وضع علامة على المنتجات المتوقفة بدلاً من حذفها. الحذف يفسد المعاملات التاريخية ويشوه التحليلات.

## ما يجب قياسه

| المقياس | ما يكشف عنه |
| --- | --- |
| متوسط الوقت للموافقة على عرض الأسعار | أكثر عنق زجاجة شيوعًا |
| نسبة عروض الأسعار التي أعيد إنشاؤها | علامة على تسعير غير واضح أو كتالوج غير كامل |
| فشل إنشاء أوامر الشراء | استقرار التكامل |
| الفرق بين مبلغ الصفقة ومبلغ الفاتورة | جودة العملية الشاملة |
| صفقات مغلقة بدون أمر شراء خلال 48 ساعة | استفسارات ضاعت بين الأنظمة |

المقياس الأخير هو أبسط طريقة لاختبار سلامة العملية، ولكن عدد قليل من المؤسسات تراقبه بانتظام.

## ترتيب التنفيذ

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

## الخلاصة

إن عملية تحويل العميل المحتمل إلى نقد (Lead-to-Cash) ليست مشروعًا تقنيًا بل هي توافق بين أربعة أقسام حول ثلاث حدود فاصلة. من يوثق هذه الحدود كتابيًا – بما في ذلك مسارات الفشل – يحصل على عملية قابلة للقياس؛ أما من يبدأ بالأدوات، فيحصل على سلسلة تبدو فعالة في العروض التوضيحية ولكنها تعتمد على المكالمات الهاتفية في الواقع.

### أسئلة وأجوبة
**هل نظام CPQ ضروري لإدارة دورة Lead-to-Cash؟**
ليس بالضرورة. يعتبر دليل المنتجات وقوائم الأسعار القياسية كافية عندما يكون التسعير بسيطًا. يصبح CPQ ضروريًا عند وجود تكوينات معقدة، أو مستويات كمية محددة، أو تجديدات، أو تسعير قائم على الاشتراكات.

**أين يجب أن يقيم التسعير - في Salesforce أم في ERP؟**
يمكن أن يقيم سعر القائمة في كلا النظامين، ولكن يجب أن يكون أحدهما هو مصدر الحقيقة ويغذي الآخر. التسعير الذي يتم تحديده بشكل متوازٍ في نظامين مختلفين يخلق فجوات بين عرض السعر والفاتورة.

**ماذا نفعل عندما يفشل الطلب في نظام ERP؟**
يتطلب الأمر مسار فشل محدد: حالة واضحة للطلب، وتنبيه لصاحب العملية، وخيار إعادة الإرسال دون إنشاء تكرارات. بدون ذلك، تختفي الصفقات المغلقة بين الأنظمة.

**من يوافق على تجاوز الخصومات؟**
يتطلب الأمر تسلسلاً هرميًا للموافقات بناءً على العتبة ونوع التجاوز، مع تحديد وقت استجابة. الموافقة التي تستغرق أكثر من يوم عمل تؤدي إلى تجاوزات هاتفية وتفقد قيمة التحكم.

**هل نحتاج إلى كائن Order في Salesforce؟**
عندما يصدر نظام ERP الطلب، يكفي غالبًا عكس الحالة والمعرف. يعتبر كائن Order الكامل مبررًا عندما تكون هناك طلبات متعددة لصفقة واحدة، أو تسليمات جزئية، أو تجديدات يتم إدارتها من جانب CRM.

---

## إدارة Forecast وDashboards في Salesforce Sales Cloud: بناء توقعات يمكن الاعتماد عليها
URL: https://hpi.pro/ar/insights/salesforce-forecast-dashboards
عندما يقوم مدير المبيعات بإدارة التوقعات في جداول بيانات منفصلة، لا تكمن المشكلة في لوحة المعلومات (Dashboard). يعتمد التوقع الموثوق به على أربعة شروط مسبقة أساسية: هيكلية صحيحة، تواريخ إغلاق دقيقة، تصنيفات متفق عليها، ودورة مراجعة منتظمة. يشرح هذا الدليل كيفية بناء هذه الأسس وما يجب قياسه لتحديد ما إذا كانت التوقعات قد تحسنت بالفعل.

## الإجابة المختصرة

إن التنبؤ ليس نتاج لوحة معلومات فحسب، بل هو نتاج انضباط البيانات. إذا تم تحديث الصفقات مرة واحدة في الأسبوع في مساء يوم اجتماع Pipeline، فلن يؤدي أي تصميم تقرير إلى صورة موثوقة. لذلك، يبدأ العمل على Forecast بأربعة شروط تشغيلية ثم ينتقل إلى العرض.

العلامة الواضحة لعدم استيفاء الشروط سهلة التحديد: وجود جدول بيانات تنبؤ موازٍ. طالما وجد هذا الجدول، فإن المنظمة نفسها تصرح بأن النظام ليس هو مصدر الحقيقة.

## الشروط المسبقة الأربعة

| الشرط | المطلوب | ما يحدث بدونه |
| --- | --- | --- |
| تسلسل هرمي صحيح للمستخدمين | Role Hierarchy يعكس الهيكل الفعلي للمبيعات | تنبؤ غير سليم على مستوى المدير |
| تواريخ إغلاق نظيفة | قاعدة تحظر تاريخًا تجاوز أسبوعًا | تنبؤ يتضمن صفقات ميتة |
| فئات متفق عليها | تعريف مكتوب لـ Pipeline, Best Case, Commit | كل مدير يفسرها بشكل مختلف |
| دورة مراجعة منتظمة | اجتماع أسبوعي من داخل النظام | تحديث بأثر رجعي قبل الاجتماعات |

الشرط الرابع هو الذي ينتج الشروط الثلاثة الأولى. بمجرد أن يتم الاجتماع من الشاشة وليس من جدول بيانات، يقوم الممثلون بالتحديث، وإلا فلن تظهر صفقاتهم.

## فئات Forecast: أين يقع الحكم البشري

الخلط الشائع هو بين الاحتمالية والفئة. الاحتمالية مستمدة من المرحلة وتستخدم للحساب المرجح - إنها إحصائية. الفئة هي تصريح التزام من شخص.

يفصل التقسيم الصحيح كالتالي: تحدد المرحلة احتمالية تلقائية لا يُسمح لأحد بتجاوزها؛ يصنف مدير الحساب الصفقة على أنها Best Case أو Commit بناءً على معرفته بالعميل؛ ويُسمح لمدير الفريق بتغيير التصنيف في المراجعة، مع التوثيق. بهذه الطريقة نحصل على رقمين ذوي مغزى مختلف - توقع إحصائي والتزام إداري - بدلاً من رقم واحد غامض.

تفاصيل تعريف مراحل المبيعات نفسها، والتي تستمد منها الاحتمالية، موجودة في [تطبيق Sales Cloud](/ar/insights/sales-cloud-implementation).

## ثلاث لوحات معلومات، وليس ثلاثين

كثرة لوحات المعلومات هي عرض لعدم ثقة أي شخص في اللوحات الموجودة. الهيكل الفعال هو:

1.  **تنبؤ للإدارة العليا** - رقم واحد للربع مع تقسيم حسب الفئة، مقارنة بالهدف، واتجاه أسبوعي. بدون تفصيل الصفقات.
2.  **Pipeline لإدارة الفريق** - صفقات حسب المرحلة والعمر، مع إبراز الحالات الشاذة: الصفقات التي لم تتحرك، التواريخ الماضية، المبالغ المتغيرة.
3.  **قائمة عمل للممثل** - ما الذي يتطلب اتخاذ إجراء اليوم. ليست تقريرًا بل قائمة انتظار عمل.

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

## قياس دقة التنبؤ

هذا هو المقياس الذي لا تقيسه معظم المؤسسات، وبالتالي لا تعرف ما إذا كانت قد تحسنت:

*   **انحراف Commit** - الفرق بين مبلغ الـ Commit في بداية الربع والنتيجة الفعلية. انحراف يزيد عن 20% يشير إلى تعريف Commit فضفاض.
*   **استقرار التنبؤ** - كم تغير التنبؤ من أسبوع لآخر. التقلبات العالية تدل على تحديث متأخر، وليس على سوق ديناميكي.
*   **Slippage (الانزلاق)** - الصفقات التي تم تأجيلها للربع التالي. نسبة عالية تدل على معايير مرحلة ضعيفة.
*   **الدقة حسب الممثل** - يكشف من يبالغ بشكل منهجي ومن متحفظ، مما يسمح بتصحيح فردي بدلاً من عامل تصحيح شامل.

تظهر المقاييس التكميلية للاعتماد في [مقاييس اعتماد Salesforce](/ar/insights/salesforce-adoption-metrics).

## الخطأ المتكرر: بناء تقرير بدلاً من إصلاح العملية

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

التسلسل الصحيح: تصحيح جودة البيانات، تثبيت دورة المراجعة، قياس الدقة لمدة ربع، ثم فقط النظر في تقسيمات إضافية.

## الخلاصة

التنبؤ الموثوق هو نتاج روتين إداري مدعوم بالنظام، وليس أداة تنبؤ. ثلاثة أسئلة تحدد ما إذا كنت قد وصلت إلى هناك: هل يوجد جدول بيانات موازٍ، هل يتفق الجميع على ما يدخل في Commit، وهل يقوم أحد بقياس دقة التنبؤ بأثر رجعي. ثلاث إجابات جيدة تساوي أكثر من أي تحسين للوحة معلومات.

### أسئلة وأجوبة
**لماذا تختلف التوقعات في النظام عن توقعات مدير المبيعات؟**
غالبًا ما يكون السبب هو عدم الاتفاق على تعريف الـ 'Commit': يُدرج المدير الصفقات في التوقعات بناءً على معرفته بالعميل، بينما يحسب النظام بناءً على المرحلة. الحل هو تعريف مكتوب يحدد ما يجب إدراجه في الـ 'Commit' ومن يحق له إجراء التعديلات.

**هل يجب استخدام الاحتمالية التلقائية أم تقدير المندوب؟**
كلاهما، ولكن بشكل منفصل. تُستمد الاحتمالية من مرحلة الصفقة وتُستخدم للحساب المرجح؛ بينما ينعكس التقدير البشري في فئة التوقع. خلط الاثنين - قيام المندوب بتجاوز النسب يدويًا - يلغي فائدة كليهما.

**كم عدد لوحات المعلومات (Dashboards) المطلوبة؟**
عادةً ما تكون ثلاث لوحات: لوحة توقعات للإدارة، لوحة Pipeline لإدارة الفريق، وقائمة عمل للمندوب. يؤدي وجود عدد كبير من لوحات المعلومات إلى إصدارات متناقضة لنفس الرقم.

**ماذا نفعل بالصفقات التي تجاوز تاريخ إغلاقها؟**
قاعدة تشغيلية صارمة: الصفقة التي مر على تاريخ إغلاقها أكثر من أسبوع تتطلب تحديثًا أو نقلها إلى 'Closed Lost'. بدون ذلك، تعتمد جميع حسابات التوقع على بيانات غير صحيحة.

**في غضون كم من الوقت يمكن توقع تحسن في الدقة؟**
عادة بعد دورتين إلى ثلاث دورات مبيعات كاملة - هذا هو الحد الأدنى من الوقت الذي تتراكم فيه صفقات كافية تم إدارتها وفقًا للتعريفات الجديدة للمقارنة بين التوقع والنتائج الفعلية.

---

## Omni-Channel و SLA في Service Cloud: تخطيط التوجيه والقدرة
URL: https://hpi.pro/ar/insights/service-cloud-omnichannel-sla
غالبًا ما يفشل Omni-Channel ليس في إعدادات التوجيه، بل في نموذج القدرة. فعندما تُقاس الدردشة والبريد الإلكتروني والمكالمات الهاتفية بنفس وحدة الوزن، يواجه الوكلاء إما إرهاقًا أو فراغًا متقطعًا. يشرح هذا الدليل كيفية تحديد أوزان العمل، وربط الاستحقاقات (Entitlements) بالتوجيه (Routing)، وكيفية التحديد المبكر لأي قصور في النموذج تحت الضغط.

## الإجابة المختصرة

لا تُعدّ Omni-Channel آلية توزيع بحد ذاتها، بل هي نموذج سعة. يطرح هذا النموذج سؤالاً واحداً في كل لحظة زمنية: ما هو حجم العمل الذي يمكن لهذا المندوب إنجازه الآن؟ إذا كانت الإجابة على هذا السؤال خاطئة – على سبيل المثال، إذا مُنح كلٌّ من الدردشة والبريد الإلكتروني نفس الأهمية – فإن التوجيه سيعمل تمامًا كما هو مُعرّف ويؤثر سلبًا على جودة الخدمة.

لذلك، فإن ترتيب العمليات ينبغي أن يكون كالتالي: أولاً، نموذج السعة والأوزان؛ ثم المهارات؛ ثم Entitlements و Milestones؛ وأخيرًا، عمليات الأتمتة الخاصة بالتصعيد.

## نموذج السعة: النقطة الحاسمة

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

نقطة انطلاق معقولة للمعايرة:

| نوع العمل | الخاصية | الوزن النسبي الموصى به |
| --- | --- | --- |
| مكالمة هاتفية | متزامن بالكامل | يشغل كامل السعة |
| دردشة حية | متزامن مع فواصل قصيرة | مرتفع، عادةً 2-3 كحد أقصى بالتوازي |
| بريد إلكتروني / نموذج | غير متزامن | منخفض |
| حالة (Case) بانتظار العميل | غير نشط | صفر - يجب تحرير السعة |

السطر الأخير هو الأكثر شيوعًا في الأخطاء: الحالة (Case) التي تنتظر العميل وتستمر في شغل سعة تؤدي إلى ظهور المندوبين بمظهر المشغولين بينما لا يوجد لديهم عمل نشط.

## المهارات: الأقل هو الأكثر

يبدو توجيه المهام بناءً على المهارات (Skills-Based Routing) تحسينًا بديهيًا، ولكنه في الواقع المصدر الأكثر شيوعًا للمهام العالقة. فكلما زادت متطلبات المهارات، زادت احتمالية عدم وجود مندوب متاح يستوفيها جميعًا.

ثلاث قواعد لمنع ذلك: تحديد المهارات فقط عندما يكون عدم وجودها يمنع المعالجة فعليًا؛ تحديد مستوى Fallback لكل متطلب يتم تفعيله بعد وقت انتظار محدد؛ والتحقق شهريًا من عدد المهام التي تم تخصيصها عبر Fallback – نسبة مئوية عالية تشير إلى أن النموذج لا يتوافق مع مدى توفر الموارد في مركز الاتصال.

## Entitlements و Milestones: من التزام إلى آلية

إن اتفاقية مستوى الخدمة (SLA) التي تظهر في التقرير فقط هي مجرد تقرير بأثر رجعي. تُحوّل Entitlements و Milestones هذه الاتفاقية إلى آلية نشطة:

1.  **Entitlement** يحدد مستوى الخدمة المستحق لأي عميل – وعادةً ما يكون هناك إعداد افتراضي واحد وعدد قليل من الاستثناءات التعاقدية.
2.  **Milestone** يحدد النقاط الزمنية التي يتم قياسها: الاستجابة الأولى، التحديث الدوري، الحل.
3.  **Business Hours** تحدد متى يتم احتساب الوقت، ويجب تعريفها لكل منطقة زمنية ولكل قناة على حدة.
4.  **Stopped Time** يُجمّد العداد عند انتظار العميل – فبدون ذلك، ستعاقب المقاييس مركز الاتصال على سلوك العميل.
5.  **إجراءات Milestone** تُصدر تنبيهًا وتصعيدًا **قبل** تجاوز الحد، عادةً عند حوالي 75-80% من الوقت.

القاعدة الإرشادية: إذا وصل التنبيه الأول بعد التجاوز، فإن الآلية تقيس ولا تدير.

تُفصّل القرارات الأساسية حول تعريف الحالة (Case) ومؤقت SLA في [تنفيذ Service Cloud](/ar/insights/service-cloud-implementation).

## كيف تعرف أن النموذج لا يعمل

خمس علامات مبكرة، قبل أن تكشف المقاييس الشهرية عن مشكلة:

*   نسبة عالية من التخصيصات عبر Fallback – المهارات لا تتوافق مع توفر الموظفين.
*   مهام في قائمة انتظار التخصيص تتجاوز بضع دقائق – نقص في السعة أو قاعدة Overflow مفقودة.
*   مندوبون يبلغون عن عبء عمل بينما يُظهر تقرير السعة توفرهم – أوزان غير صحيحة.
*   تركيز غير عادي لتجاوزات SLA في ساعة معينة من اليوم – مشكلة في التوظيف، وليست مشكلة في التوجيه.
*   معدل عالٍ من المهام التي تم تخصيصها ثم التخلي عنها فورًا – يرفض المندوبون العمل الذي لا يناسبهم.

## القياس المستمر

| المقياس | ما يكشف عنه |
| --- | --- |
| وقت الانتظار في قائمة التخصيص | هل يجد النموذج مندوبًا في الوقت المناسب |
| متوسط استخدام السعة | هل الأوزان واقعية |
| التجاوزات حسب Milestone | أين بالضبط تم كسر اتفاقية مستوى الخدمة (SLA) |
| معدل التصعيدات التي تم تجنبها | هل يعمل التنبيه المبكر |
| فجوات التجاوز بين القنوات | هل يتم التمييز ضد قناة معينة في التوجيه |

## ترتيب التنفيذ

ابدأ بتفعيل قناة واحدة مع Entitlement واحد وبدون مهارات، ثم عاير الأوزان بناءً على بيانات حقيقية لمدة أسبوعين، وبعد ذلك فقط أضف قناة ثانية ومهارات. إن التفعيل الكامل في يوم واحد يمنع القدرة على تحديد أي مكون تسبب في الحمل الزائد، وعادة ما ينتهي بإيقاف التوجيه والعودة إلى قوائم الانتظار اليدوية.

## الخلاصة

Omni-Channel هو نموذج سعة وليس نموذج توزيع، و SLA هو آلية تنبيه وليس تقرير. يحددان هذان المبدآن ما إذا كان مركز الاتصال سيعمل وفقًا للنظام أو سيجد طرقًا لتجاوزه – ويظهر الفرق بالفعل في الأسبوع الأول من التشغيل.

### أسئلة وأجوبة
**كيف يتم تحديد وزن القدرة لكل قناة؟**
يتم قياس مقدار الوقت الفعلي الذي يتطلبه كل نوع عمل من الاهتمام المستمر. تستحوذ الدردشة المباشرة على الوكيل بشكل شبه كامل، في حين أن البريد الإلكتروني غير متزامن. غالبًا ما يتبين أن الوزن المحدد بناءً على التقدير وحده غير دقيق خلال أسبوعين، لذا يُنصح بتخطيط جولة معايرة.

**كم عدد Skills التي يُوصى بتحديدها؟**
قليل وواضح. تؤدي كثرة المهارات إلى سيناريوهات لا يلبي فيها أي وكيل جميع المتطلبات، مما يؤدي إلى تعليق الطلب دون تخصيص. يُفضل استخدام مهارة أساسية مع Fallback محدد.

**هل Entitlements مطلوبة لكل عميل؟**
لا. يتم تحديد افتراضي واحد لجميع العملاء، والاستثناءات تكون فقط للعملاء الذين لديهم عقد خدمة مختلف بالفعل. يؤدي تكرار Entitlement لكل حساب إلى عبء صيانة لا يمكن لأحد الالتزام به.

**ماذا يحدث لطلب لا يتوفر له أي وكيل؟**
يجب أن تكون هناك قاعدة Overflow مع حد أقصى لوقت الانتظار وقائمة انتظار احتياطية. بدون مثل هذه القاعدة، تظل الطلبات في قائمة التخصيص دون أن يراها أحد، ويتجاوز SLA بصمت.

**هل يمكن الاعتماد على Push Routing فقط؟**
عادةً نعم، وهذا هو التفضيل الصحيح. يسمح Pull للوكلاء باختيار الطلبات السهلة. الدمج المعقول هو Push لمعظم العمل وقائمة انتظار Pull محدودة للعمل غير المعتمد على الوقت.

---

## إدارة المعرفة في Service Cloud: كيف تبني قاعدة بيانات موثوقة لوكلائك والذكاء الاصطناعي
URL: https://hpi.pro/ar/insights/salesforce-knowledge-management
غالبًا ما تفشل قواعد المعرفة في عامها الثاني وليس عند إطلاقها؛ فالمقالات التي تُكتب مرة واحدة دون صيانة تُعيد الوكلاء إلى غرف الدردشة الداخلية. يصف هذا الدليل دورة حياة مستدامة تشمل التكلفة، ومحفزات الإنشاء، والمراجعة الدورية، وقياس الاستخدام، والتغيرات عند استخدام وكيل الذكاء الاصطناعي لنفس القاعدة.

## الإجابة المختصرة

قاعدة المعرفة ليست مشروع محتوى بل هي عملية تشغيلية. السؤال الذي يحدد استمراريتها ليس عدد المقالات التي كُتبت عند الإطلاق، بل ما الذي يحفز إنشاء مقال جديد وما الذي يدفع لمراجعة مقال قديم. بدون هاتين الآليتين، تتدهور أي قاعدة إلى مجرد مجلد ملفات لا يفتحه أحد.

الاختبار البسيط للوضع الحالي: عدد الحالات (Cases) التي أُغلقت هذا الشهر مع مقال مرتبط. أقل من 30% يعني أن القاعدة ليست جزءًا من سير العمل.

## دورة حياة المقال

| المرحلة | المسؤول | المحفز |
|---|---|---|
| الإنشاء | الموظف الذي حل الحالة | حالة متكررة بدون مقال مرتبط |
| الموافقة | محرر المعرفة أو خبير المجال | قائمة انتظار موافقات مع هدف زمني |
| النشر | المحرر | تحديد الرؤية: داخلي أو عام |
| المراجعة | المالك المحدد | تاريخ المراجعة أو بيانات الاستخدام |
| الإحالة للتقاعد | المالك | منتج توقف إنتاجه أو إجراء تغير |

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

## المحفز الذي ينمّي القاعدة بشكل صحيح

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

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

## هيكل المقال الذي يخدم البحث والذكاء الاصطناعي

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

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

## الرؤية: داخلي مقابل عام

الموضوع نفسه غالبًا ما يتطلب نسختين. النسخة الداخلية تشمل القيود المعروفة، الحلول البديلة، وإرشادات التصعيد؛ النسخة العامة تشمل فقط ما يمكن للعميل تنفيذه. تتم إدارة هذا الفصل على مستوى المقال، وليس على مستوى القاعدة، لتجنب إنشاء قاعدتين تنفصلان عن بعضهما.

قبل فتح بوابة الخدمة الذاتية (Self-Service)، يُنصح بالتحقق من أن النسخ العامة قائمة بذاتها. فالبوابة التي تحيل إلى مقالات جزئية لا تقلل من الحالات، بل تنقلها إلى قناة أخرى، عادةً عبر الهاتف. السياق التشغيلي مفصل في [تنفيذ Service Cloud](/ar/insights/service-cloud-implementation).

## ما يتغير عندما يقرأ وكيل الذكاء الاصطناعي من القاعدة

قاعدة المعرفة التي يتعامل معها الموظفون على الرغم من الثغرات، ليست بالضرورة جاهزة للاستخدام بواسطة وكيل الذكاء الاصطناعي. فالموظف المتمرس يعرف كيف يتجاهل المقال القديم؛ آلية الاسترجاع لا تفعل ذلك.

ثلاث متطلبات إضافية: لا يوجد مقالان نشطان يقدمان إجابات متضاربة للسؤال نفسه؛ لكل مقال صلاحية ومصدر واضحان؛ ويُحدد صراحة ما يُسمح بعرضه للعميل. فالوكيل الذي يقتبس مقالًا داخليًا أو يدمج مصدرين متضاربين يؤدي إلى ضرر في الثقة يصعب إصلاحه. يتوفر تعمق في الموضوع في [الترسيخ (Grounding) وRAG في Agentforce](/ar/insights/agentforce-grounding-rag) و[جاهزية المعرفة لـ Agentforce](/ar/insights/agentforce-knowledge-readiness).

## القياس

| المؤشر | ما يكشفه | الحد للمراجعة |
|---|---|---|
| Knowledge attach rate (معدل ربط المعرفة) | هل القاعدة جزء من سير العمل | أقل من 30% |
| عمليات البحث بدون نتائج | ثغرات محتوى حقيقية | قائمة أسبوعية لقائمة انتظار الكتابة |
| مقالات بدون مشاهدات خلال ستة أشهر | محتوى غير ضروري أو لا يُعثر عليه في البحث | أكثر من 25% من القاعدة |
| الوقت من الإنشاء إلى النشر | هل قائمة انتظار الموافقات مُعيقة | أكثر من أسبوعين |
| تصنيف "لم يساعد" | جودة المحتوى المحددة | تركيز على موضوع واحد |

تُعد قائمة عمليات البحث بدون نتائج المصدر الأرخص والأكثر دقة لتخطيط المحتوى، وهي غالبًا ما تكون غير مستخدمة.

## الخلاصة

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

### أسئلة وأجوبة
**كم عدد المقالات المطلوبة للبدء؟**
من عشرة إلى عشرين مقالاً تغطي الاستفسارات الشائعة. قاعدة بيانات كبيرة مكتوبة مسبقًا تتقادم قبل استخدامها؛ قاعدة بيانات صغيرة تُحدّث من Cases حقيقية تتطور بشكل صحيح.

**من يجب عليه كتابة المقالات؟**
الوكلاء الذين يتعاملون مع الاستفسارات، مع وجود محرر للموافقة والتوحيد. الكتابة من قبل طرف خارجي تنتج محتوى دقيقًا لا يتوافق مع اللغة التي يستخدمها الوكيل.

**هل يمكن لنفس المقال أن يخدم وكلاء و1عملاء؟**
غالبًا لا بشكل كامل. يتطلب الأمر مستويات رؤية مختلفة – جزء داخلي (قيود، حلول بديلة) وجزء عام. تُدير Data Categories وChannels ذلك على مستوى المقال.

**كيف تعرف أن المقال قديم؟**
من خلال دمج تاريخ المراجعة، وبيانات الاستخدام، وعلامات من الوكلاء. المقال الذي لم يُشاهد لمدة ستة أشهر أو تم وضع علامة عليه بأنه غير مفيد يدخل قائمة مراجعة تلقائية.

**ماذا يلزم قبل أن يقرأ وكيل الذكاء الاصطناعي من قاعدة البيانات؟**
تنظيف المقالات المتعارضة، وتحديد الصلاحية والمصدر، وتحديد ما يُسمح بكشفه للعميل. الوكيل الذي يستشهد بمقالتين متضاربتين يسبب ضررًا أكبر من عدم وجود استجابة.

---

## ربط مركز الاتصال بـService Cloud: CTI، Voice، وصورة العميل الشاملة
URL: https://hpi.pro/ar/insights/service-cloud-cti-integration
يُقاس ربط نظام الهاتف بـSalesforce بالثواني: كم من الوقت يستغرق الموظف ليرى من يتصل ولماذا. يتناول هذا الدليل القرارات الحاسمة التي تحدد النتيجة - تحديد هوية المتصل، وظيفة Screen Pop، ملكية التوجيه (Routing)، معالجة التحويلات والانقطاعات، والاختيار بين Service Cloud Voice ومتكيف CTI الحالي.

## الإجابة المختصرة

تُقاس جودة اتصال CTI بثلاث ثوانٍ: من لحظة رد الوكيل وحتى رؤيته هوية المتصل، وسجله التاريخي، وما هو مفتوح. إذا لم يعمل التحديد، يبدأ الوكيل كل مكالمة بسؤال "مع من أتحدث؟" – وتصبح كل الاستثمارات الأخرى في حلول الاتصال المدمجة عديمة الفائدة.

القرار المحوري ليس في اختيار أي محوّل، بل **أين يتم اتخاذ قرار التخصيص**: في المقسم (PBX) أو في Salesforce. هنا يكمن معظم المخاطر والتكلفة.

## القرار الأساسي: من يدير عملية التوجيه (Routing)

| الجانب | التوجيه في المقسم (محول CTI) | التوجيه في Omni-Channel (Voice) |
| --- | --- | --- |
| مصدر القرار | نظام الرد الصوتي التفاعلي (IVR) وقواعد المقسم | التوفر والمهارات في Salesforce |
| الموازنة بين القنوات | تدار المكالمات الهاتفية بشكل منفصل عن الدردشة والبريد الإلكتروني | سعة واحدة لجميع القنوات |
| تغيير القواعد | يعتمد على مزود خدمة الاتصالات | يتم في إعدادات Salesforce |
| تعقيد التنفيذ | منخفض نسبيًا | مرتفع، ويؤثر على العمليات التشغيلية للمركز |
| متى يكون مناسبًا | مركز اتصال تقليدي، مقسم ناضج | مركز متعدد القنوات مع أحمال عمل مختلطة |

الحالة الإشكالية هي التخصيص المزدوج: المقسم يقوم بالتخصيص، ثم يقوم النظام بإعادة التخصيص. والنتيجة هي أن الوكلاء يتلقون مكالمات بينما هم منشغلون بالدردشة، وتصبح مقاييس التوفر لا تعكس شيئًا. إذا تم اختيار Voice، يتم فك قواعد التخصيص من المقسم؛ وإذا تم الإبقاء على المقسم، فلا يتم تفعيل Omni-Channel على قناة الصوت.

## تحديد هوية المتصل: مشكلة بيانات قبل مشكلة تقنية

معظم أعطال Screen Pop ليست أعطال تكامل، بل هي نتيجة لعدم توحيد أرقام الهواتف. قد يظهر العميل ذاته بصيغ 050-1234567، ‎+972501234567، و-0501234567 في ثلاثة أنظمة مختلفة، ويفشل التطابق.

ما هو مطلوب قبل الاتصال:

1.  **صيغة موحدة**: E.164 كمعيار، مع تحويل عند الإدخال وليس أثناء البحث.
2.  **ترتيب بحث محدد**: أولاً Contact، ثم Account، ثم Case مفتوح حسب الرقم. يحدد الترتيب ما سيظهر عند وجود عدة مطابقات.
3.  **معالجة حالات التطابقات المتعددة**: شاشة اختيار قصيرة، لا تخمين. في مراكز المقسمات المؤسسية وأرقام المقسمات للعملاء التجاريين، هذا هو الوضع الطبيعي، وليس الاستثناء.
4.  **معالجة حالات عدم التحديد**: شاشة إنشاء سريعة، لضمان عدم انتهاء المكالمة دون توثيق.

يمكن الاطلاع على مبادئ تحديد الهوية وتوحيد السجلات في [Deduplication وتوحيد السجلات](/ar/insights/salesforce-data-deduplication).

## ماذا يحدث عندما لا تسير المكالمة بسلاسة

السيناريوهات الهامشية هي التي تحدد مدى ثقة المركز في النظام:

*   **التحويل بين الوكلاء**: هل يتم نقل الـCase مع المكالمة أم يتم إنشاء Case جديد؟ التحويل الذي يؤدي إلى إنشاء Case ثانٍ يعطل كلاً من مقياس FCR وتجربة العميل الذي يكرر القصة مرتين.
*   **الانقطاع في منتصف المكالمة**: تتطلب هذه الحالة قاعدة "إعادة الاتصال" مع نافذة زمنية، وإلا ستختفي الاستفسارات دون أثر.
*   **المكالمات الصادرة**: هل يتم عدها وربطها بالـCase؟ بدون هذا، تكون بيانات عبء العمل على الوكيل ناقصة بحوالي الثلث.
*   **قائمة الانتظار وحالات التخلي**: يجب أن تكون حالات التخلي متاحة في Salesforce، وليس فقط في تقارير المقسم، وإلا ستكون الصورة التشغيلية غير مكتملة.

يجب كتابة كل من هذه السيناريوهات الأربعة كسيناريو اختبار شامل (End-to-End Test) قبل البدء بالعمل. اختبار مكالمة عادية فقط لا يثبت شيئًا.

## التسجيل، التفريغ، والخصوصية

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

ما هو الأساس القانوني للتسجيل والمعالجة؛ وكم من الوقت يتم الاحتفاظ بالنسخ المفَرّغة ومن يمكنه البحث فيها؛ وهل يتم استخدام المحتوى لتدريب النماذج. التفريغ هو معلومات حساسة – يتضمن تفاصيل قدمها العميل شفهياً ولم يكن ليُدخلها في نموذج. تحديد الوصول على مستوى الحقل وسياسة الاحتفاظ المحددة هما جزء من التنفيذ، وليس مهمة بعده.

## القياس بعد التشغيل

| المقياس | لماذا هو مهم |
| --- | --- |
| نسبة التحديد التلقائي | المقياس المباشر لجودة البيانات والاتصال |
| الوقت حتى ظهور Screen Pop | يُعتبر أبطأ من ثانيتين بطيئًا |
| المكالمات بدون Case مرتبط | يكشف عن فجوات التوثيق |
| الحالات التي فُتحت مرتين عند التحويل | يكشف عن فشل في الاستمرارية |
| التخلي في قائمة الانتظار | مؤشر على فشل التخصيص أو نقص الموظفين |

## الخلاصة

لا تُقاس جودة اتصال CTI الناجح بتركيب المحول، بل بقدرة الوكيل على بدء المكالمة وهو على دراية بهوية المتصل وما هو مفتوح، وبتحديد مسبق لكل حالة غير قياسية – مثل التحويل، والقطع، والتطابقات المتعددة. إن تحديد موقع التوجيه (Routing) هو القرار الأول الذي يجب حسمه، لأنه يحدد النموذج التشغيلي والتكلفة.

### أسئلة وأجوبة
**ما الفرق بين Service Cloud Voice ومتكيف CTI التقليدي؟**
يقوم متكيف CTI بعرض خدمات الهاتف داخل Salesforce، لكن يتم التخصيص (Assignment) في السنترال. بينما ينقل Voice عملية التوجيه (Routing) نفسها إلى Omni-Channel ويقدم نصوصًا مسجلة وبيانات المكالمات كسجلات. الفرق الجوهري يكمن في مكان اتخاذ قرار التخصيص.

**لماذا لا تظهر نافذة Screen Pop في بعض الأحيان؟**
عادةً ما يحدث ذلك لأن رقم المتصل غير موحد (Non-normalized) - مثل وجود بادئة دولية، أصفار زائدة، أو تنسيق مختلف بين الأنظمة. هذه مشكلة بيانات وليست مشكلة تكامل.

**ماذا نفعل عندما يتم تحديد رقم واحد لعدة عملاء؟**
يجب تحديد شاشة اختيار قصيرة للموظف مسبقًا بدلاً من التخمين التلقائي. فالإعداد التلقائي الخاطئ أسوأ من عدم التحديد، لأنه ينشئ توثيقًا لعميل غير صحيح.

**هل التسجيل والتفريغ النصي لجميع المكالمات إلزامي؟**
لا، وفي معظم المؤسسات ليس ذلك هو الأسلوب الصحيح. فالتسجيل الشامل يتطلب سياسة احتفاظ واضحة، أساس قانوني، ورقابة على الوصول. من الأفضل البدء بفئات محددة.

**من المسؤول عندما تصل المكالمة ولكن لا يتم إنشاء السجل؟**
يجب أن يتم تحديد ذلك كتابيًا قبل البدء بالعمل. فبدون وجود مالك (Owner) واحد للمسار الشامل، يتحول أي عطل إلى جدال بين مزود خدمة الاتصال وفريق CRM.

---

## شبكة رواد Salesforce: كيف تبني محرك تبنّي داخلي؟
URL: https://hpi.pro/ar/insights/salesforce-champions-network
الرائد الذي هو مجرد لقب رمزي لا يُحدث فرقًا. كيف تختار ممثلين ميدانيين، وكم من الوقت تخصصه لهم، وماذا يشمل الدور بالضبط، وكيف تكافئهم، وكيف تمنع الشبكة من التلاشي بعد شهرين.

## الإجابة المختصرة

تُشكل شبكة الـ "Champions" البنية التحتية لنشر تبني الأنظمة داخل المؤسسة. يميل المستخدمون إلى سؤال الزملاء القريبين منهم قبل فتح طلب دعم، ويثقون بآرائهم أكثر من الرسائل القادمة من الإدارة. تستفيد الشبكة من هذه الديناميكية بدلاً من مقاومتها.

لكن لقب "Champion" دون تخصيص وقت، وتحديد دور، وتأثير حقيقي على الأولويات، هو مجرد لقب أجوف. هذه العناصر الثلاثة هي ما يحدد ما إذا كانت الشبكة ستستمر لعام كامل أم ستتلاشى خلال ربع واحد.

## من هو المؤهل – ومن ليس كذلك

| المعيار | الأهمية | علامة حمراء |
| --- | --- | --- |
| ثقة الزملاء | يحدد ما إذا كان الزملاء سيلجؤون إليه | من يتم تعيينه لمجرد توافره |
| الخبرة في العملية التجارية | يُمكنه من تقديم إجابات صحيحة وليست تقنية فقط | معرفة نظرية بالنظام دون فهم للعمل |
| الرغبة الحقيقية | الدور التطوعي يُعزز الالتزام | تعيين قسري من قبل المدير |
| دعم المدير المباشر | يحدد مدى توفر الوقت لهذا الدور | موافقة شفهية فقط |

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

## تحديد الدور كتابيًا

دون تعريف مكتوب، يُفسر الدور على أنه "الشخص الذي تُعرَض عليه المشكلات". يشمل التعريف أربع مسؤوليات:

1. **الدعم المحلي** — الاستجابة الأولية للاستفسارات داخل الفريق، وتوثيق المتكرر منها.
2. **جمع الملاحظات** — نقل العقبات والاحتياجات إلى المنتدى المركزي، بما في ذلك ما لا يتم الإبلاغ عنه رسميًا.
3. **الاختبارات الأولية** — المشاركة في UAT واختبار التغييرات قبل إطلاقها للفريق.
4. **توصيل التغييرات** — شرح شفهي لما تغير، بلغة الفريق.

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

## المنتدى المركزي هو القلب النابض

اجتماع نصف أسبوعي مدته 45 دقيقة بهيكل ثابت: ما ورد من الميدان، ما تم إصلاحه من الاجتماع السابق، ما سيتم إطلاقه قريبًا، وسؤال مفتوح واحد. البنود الأولى والثانية هي المحرك – الـ "Champion" الذي يرى أن طلبه قد تم تنفيذه والتواصل بشأنه باسمه سيجلب خمسة طلبات إضافية. الـ "Champion" الذي قدم ثلاثة طلبات اختفت سيتوقف عن تقديمها.

يعمل المنتدى أيضًا كقناة إنذار مبكر: الشكاوى المتكررة التي تُسمع هناك قد لا تصل إلى لوحة التحكم (Dashboard) إلا بعد شهرين. تفاصيل الربط بالقياسات متوفرة في [Salesforce Adoption Metrics](/ar/insights/salesforce-adoption-metrics).

## ما يُقدم في المقابل

الحوافز التي تعمل، حسب ترتيب فعاليتها المثبتة:

-   **التأثير** — مكان ثابت في تحديد أولويات الإطلاق القادم.
-   **الوصول المبكر** — رؤية التغييرات قبل الجميع، والسلطة لقول "ليس بعد".
-   **التعرض الإداري** — تقديم النتائج للإدارة مرة كل ربع.
-   **التطوير** — تمويل شهادة Salesforce أو المشاركة في مؤتمر.
-   **الاعتراف** — ذكر اسمي في تحديث حول كل إصلاح نابع منهم.

المكافآت المالية نادرة وغير أساسية. ما يقتل الشبكات هو غياب التأثير، وليس غياب المكافأة.

## دور الشبكة في الإطلاق والتشغيل المنتظم

في الأسبوعين التاليين للانطلاق (Go Live)، يعتبر الـ "Champions" خط الدعم الأول في الميدان، ولذلك يتلقون التدريب قبل الجميع بأسبوع. يُوصف الهيكل في [Salesforce Role-Based Training](/ar/insights/salesforce-role-based-training).

في التشغيل المنتظم، يتغير الدور: استيعاب المنضمين الجدد، تحديد نقاط الاحتكاك المتراكمة، واختبار التغييرات قبل الإطلاق. هنا تتحول الشبكة من آلية إطلاق إلى آلية صيانة تمنع التراجع، وتغذي الإصلاحات التي نُوقشت في [Salesforce UX Simplification](/ar/insights/salesforce-ux-simplification).

## علامات التراجع وما يجب فعله

| العلامة | السبب الشائع | الإصلاح |
| --- | --- | --- |
| انخفاض الحضور في المنتدى | الطلبات لا تُنفذ | إطلاق إصلاحين من قائمتهم فورًا |
| الـ "Champion" يطلب الاستقالة | ضغط الأهداف في الوظيفة الأساسية | تجديد التخصيص مع المدير |
| لا توجد طلبات جديدة | تحولت الشبكة إلى قناة إعلانات فقط | فتح نقاش حول العقبات، وليس التحديثات |
| جميع الطلبات من فريق واحد | تمثيل جزئي | إضافة "Champion" في المناطق المفقودة |

## القياس

ثلاثة مقاييس كافية: عدد المشكلات التي أثيرت عبر الشبكة ربع سنويًا، معدل تنفيذها، وفجوة التبني بين الفرق التي لديها "Champion" نشط والفرق التي لا تملك ذلك. هذه الفجوة هي المبرر المالي للخطة بأكملها. الشبكة نفسها هي مكون ضمن [Salesforce Change Management Plan](/ar/insights/salesforce-change-management-plan).

## الخلاصة

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

### أسئلة وأجوبة
**كم عدد الرواد (Champions) الذين نحتاجهم؟**
النسبة المقبولة هي رائد واحد لكل 15 إلى 25 مستخدمًا، وعلى الأقل واحد في كل فريق مستقل أو موقع جغرافي. أقل من ذلك يخلق عنق زجاجة، وأكثر من ذلك يجعل صيانة الشبكة صعبة.

**كم من الوقت الأسبوعي يجب تخصيصه للرائد (Champion)؟**
من أربع إلى ست ساعات أسبوعيًا خلال فترة الإطلاق، وساعتان بعدها. يجب أن يكون التخصيص متفقًا عليه مع المدير المباشر وأن يخصم من الأهداف الجارية، وإلا سيهمل الدور أولاً.

**هل يجب أن يكون الرائد (Champion) مستخدمًا متقدمًا تقنيًا؟**
لا. المعيار الأهم هو ثقة الزملاء والخبرة في العملية التجارية. يمكن تعليم المعرفة بالنظام؛ لا يمكن تعيين التأثير الاجتماعي في الفريق.

**كيف تكافئ الرواد (Champions) بدون ميزانية؟**
الظهور الإداري، التأثير الحقيقي على خارطة الطريق (Roadmap)، التدريب أو الشهادات على نفقة المؤسسة، والتقدير بالاسم في التحديثات. التأثير على الأولويات هو الحافز الأقوى فعليًا.

**ماذا نفعل عندما تتلاشى شبكة الرواد (Champions) بعد شهرين؟**
التحقق من ثلاثة أمور: هل يتم تطبيق طلباتهم حقًا، هل يدعم المدير المباشر تخصيص الوقت، وهل يوجد منتدى منتظم. التلاشي ينجم دائمًا تقريبًا عن توقف القناة عن التأثير.

---

## تحسين تجربة المستخدم في Salesforce: حقول أقل، نقرات أقل، واعتماد أكبر
URL: https://hpi.pro/ar/insights/salesforce-ux-simplification
كل حقل غير ضروري هو عبء يومي على كل مستخدم. نقدم لكم منهجية عملية لتبسيط الشاشات في Salesforce: تشمل مراجعة استخدام الحقول، واختبار الثلاث نقرات، وتخطيط (Layout) الشاشات حسب الدور الوظيفي، وقياس وقت إنجاز المهمة قبل وبعد التحسين.

## الإجابة المختصرة

خمس ثوانٍ إضافية لكل إدخال، مضروبة بثلاثين إدخالاً يوميًا، مضروبة بمئة مستخدم — يمثل ذلك يوم عمل كامل يضيع يوميًا بسبب واجهة مستخدم مزدحمة. عادةً ما يكون تبسيط تجربة المستخدم (UX) هو الإجراء ذو العائد الأعلى الذي يمكن القيام به في نظام قائم، ويكاد يكون دائمًا قائمًا على الحذف بدلاً من البناء.

تكفي ثلاث أدوات: مراجعة استخدام الحقول، واختبار النقرات الثلاث لكل مهمة رئيسية، وتكييف تخطيط الشاشة (Layout) حسب الدور والمرحلة.

## لماذا تتضخم الشاشات

لم يقم أحد بتصميم شاشة تحتوي على 80 حقلاً. لقد نشأت من سبع سنوات من الطلبات الفردية، وكان كل منها معقولاً في حد ذاته. ثلاث آليات متكررة:

- **طلب "حقل واحد فقط"** — تكلفة هامشية تبدو صفرية، وتكلفة تراكمية هائلة.
- **حقل يبقى بعد تغيير العملية** — لا يوجد مسؤول عن إزالته.
- **حقول "للأمان"** — "ربما نحتاجها لتقرير في المستقبل".

لذلك، التبسيط ليس مشروعًا لمرة واحدة ولكنه ممارسة مستمرة: كل طلب لحقل جديد يتطلب تحديد حقل سيتم إزالته، أو تبريرًا صريحًا.

## المرحلة الأولى — مراجعة استخدام الحقول

لكل كائن رئيسي، يتم إنشاء جدول بأربعة أعمدة: نسبة التعبئة في الأشهر الـ 12 الماضية، الاستخدام في التقارير، الاستخدام في الأتمتة والتكاملات، ومالك العملية المعلن.

| النتيجة | التفسير | القرار |
|---|---|---|
| تعبئة أقل من 10%، لا يوجد استخدام في التقرير | حقل مهجور | إزالة من تخطيط الشاشة (Layout) |
| تعبئة عالية، لا يوجد استخدام في التقرير | عمل لا يستخدمه أحد | استفسار مع مالك العملية |
| تعبئة منخفضة، حقل إلزامي | المستخدمون يملأون قيمة عشوائية | إلغاء الإلزام أو التغيير إلى قائمة اختيار (Picklist) |
| تعبئة عالية واستخدام في التقرير | حقل نشط | الإبقاء عليه، ربما نقله إلى الأمام |

السطر الثالث هو الأكثر خطورة: الحقل الإلزامي الذي يملأ بقيمة وهمية يلوث البيانات ويقلل من الثقة.

## المرحلة الثانية — اختبار النقرات الثلاث

لكل مهمة رئيسية — تحديث مرحلة، توثيق مكالمة، إغلاق حالة (Case) — يتم عد عدد النقرات والشاشات من بداية النية وحتى الاكتمال. أكثر من ثلاث نقرات لمهمة يومية يبرر التصحيح.

الأدوات المتاحة: الإجراءات السريعة (Quick Actions) بدلاً من فتح سجل كامل، التعديل من القائمة، مسار (Path) مع حقول إرشادية لكل مرحلة، ومكونات تظهر فقط في السياق ذي الصلة. السؤال الإرشادي دائمًا هو نفسه: ماذا يأتي المستخدم ليفعله هنا، وما الذي يعيق طريقه.

## المرحلة الثالثة — تخطيط الشاشة (Layout) حسب الدور وليس الكائن

شاشة واحدة لجميع الأدوار هي دمج لجميع الاحتياجات، وهذا يعني أنها سيئة للجميع. يحتاج مندوب المبيعات إلى ثمانية حقول؛ ويحتاج مدير العمليات إلى خمسة حقول أخرى؛ ويحتاج المكتب الخلفي (Back Office) إلى حقول موافقة لا مكان لها لدى الاثنين الأولين.

الفصل حسب نوع السجل (Record Type) والملف الشخصي (Profile)، بالاشتراك مع النماذج الديناميكية (Dynamic Forms) للعرض الشرطي حسب المرحلة، يقلل شاشة تحتوي على 60 حقلاً إلى شاشة تحتوي على 12 حقلاً ذات صلة. ملاحظة هامة: العرض الشرطي ليس بديلاً عن قرار العمل بشأن ما هو مطلوب على الإطلاق.

## المرحلة الرابعة — الصفحة الرئيسية كقائمة عمل

يجب أن تجيب الشاشة الأولى التي يراها المستخدم على سؤال "ماذا علي أن أفعل الآن"، بدلاً من عرض رسوم بيانية عامة. قائمة بمهام مصنفة حسب الأولوية، وعناصر معلقة، واستثناءات تتطلب الانتباه. هذا هو العائد اليومي الذي يبرر الإدخال، وهو العامل الرئيسي في استعادة التبني — راجع [تحسين تبني Salesforce](/ar/insights/recover-salesforce-user-adoption).

## القياس: قبل وبعد

قبل التصحيح، يتم قياس متوسط وقت الإنجاز لثلاث مهام أساسية، على خمسة مستخدمين حقيقيين، باستخدام ساعة توقيت. بعد التصحيح، يتم القياس مرة أخرى بنفس الطريقة. انخفاض بنسبة 30% أو أكثر في وقت المهمة هو نتيجة مقبولة في الموجة الأولى من التبسيط.

إلى جانب ذلك، يتم تتبع جودة البيانات ومعدل أداء العملية الأساسية، وفقًا لـ [مؤشرات تبني Salesforce](/ar/insights/salesforce-adoption-metrics). التبسيط الحقيقي يحسن كليهما؛ إذا انخفض الوقت ولكن تأثرت الجودة، فقد تم حذف حقل كان ضروريًا.

## الاعتراضات وكيفية الإجابة عليها

"لكننا نحتاج الحقل لتقرير" — من قام بإنشاء التقرير في العام الماضي. "المدير X طلب ذلك" — هل العملية التي بررت ذلك لا تزال موجودة. "ربما نحتاجه في المستقبل" — يمكن إعادته في غضون ساعة، والبيانات التاريخية محفوظة حتى بعد الإزالة من تخطيط الشاشة (Layout).

تتم إدارة هذه الاعتراضات ضمن عملية التغيير التنظيمي، وليس كـ نقاش فني — راجع [إدارة تغيير Salesforce](/ar/insights/salesforce-change-management-plan).

## الخلاصة

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

### أسئلة وأجوبة
**كيف يمكن تحديد الحقول التي يمكن إزالتها؟**
نقوم بتشغيل تقرير استخدام الحقول: يُظهر نسبة السجلات المعبأة خلال الاثني عشر شهرًا الماضية، ويُبين استخدامها في التقارير والأتمتة. أي حقل ذو نسبة تعبئة منخفضة ولا يظهر في أي تقرير أو أتمتة هو مرشح للإزالة.

**هل يجب حذف الحقول أم إخفاؤها فقط؟**
نبدأ بإزالتها من الـLayout، ثم نتركها لمدة ربع سنوي، وبعد ذلك فقط يتم حذفها نهائيًا. الإزالة من الـLayout توفر الفائدة الكاملة للمستخدم دون المخاطرة بفقدان البيانات التاريخية.

**ما هو العدد المقبول للحقول الإلزامية في شاشة واحدة؟**
ما يصل إلى خمسة حقول كحد أقصى على مدار العملية بأكملها، وبحد أقصى حقلين في كل مرحلة. أي حقل إلزامي إضافي يتطلب من صاحب العملية تبرير الحاجة إليه ومن المستفيد من البيانات.

**هل تعمل Dynamic Forms على حل المشكلة؟**
إنها أداة ممتازة للعرض المشروط بناءً على المرحلة أو الملف الشخصي، لكنها لا تحل محل القرار التجاري. فالشاشة المزدحمة التي تم إخفاء جزء منها لا تزال تخفي عملية غير مُتفق عليها.

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

---

## كيفية استعادة المستخدمين إلى Salesforce بعد عملية إطلاق فاشلة
URL: https://hpi.pro/ar/insights/recover-salesforce-user-adoption
الإطلاق الفاشل ليس مشكلة تدريب فحسب. دليل عملي لإعادة التأهيل: كيفية تشخيص سبب الهجر، ما الذي يجب إصلاحه خلال أول 30 يومًا، كيفية استعادة الثقة دون الإعلان عن 'إعادة إطلاق' – ومتى يكون تقليص النظام أفضل من توسيعه.

## الإجابة المختصرة

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

التسلسل العملي: أسبوعان للتشخيص، 30 يوماً لإجراء إصلاحات ملموسة، ثم دورة إدارية منتظمة تعتمد على البيانات. يأتي التدريب فقط بعد أن يصبح النظام يستحق الوقت المستثمر فيه.

## خمسة أسباب للتخلي – وكيفية التمييز بينها

| السبب | علامة مميزة على أرض الواقع | التصحيح الصحيح |
| --- | --- | --- |
| عبء الإدخال | نماذج طويلة، حقول إلزامية لا يوجد من يملأها | حذف الحقول، قيم افتراضية، أتمتة |
| عدم الثقة في البيانات | الجميع يحتفظ بملف Excel موازٍ | تنظيف البيانات + مصدر وحيد معلن للحقيقة |
| نقص القيمة المرتجعة | المستخدم يُدخل ولا يحصل على شيء في المقابل | قوائم العمل، العروض الشخصية، التنبيهات |
| الإدارة لا تعتمد على النظام | مراجعة أسبوعية من ملف خارجي | نقل المنتدى إلى لوحة المعلومات (Dashboard) |
| الأداء والواجهة | شاشات بطيئة، تنقل مربك | تحسين وتبسيط تخطيط الشاشة (Layout) |

يستغرق التشخيص نفسه أسبوعين: عشر محادثات مع مستخدمين حقيقيين (وليس ممثلي مستخدمين)، ساعة واحدة لمراقبة العمل الفعلي لثلاثة أدوار، واستخلاص بيانات الاستخدام الفعلي وفقاً للنهج الموضح في [مقاييس تبني Salesforce](/ar/insights/salesforce-adoption-metrics).

## قانون العائد: ما الذي يحصل عليه المستخدم في 30 ثانية

هذا هو الاختبار الأساسي. افتح الشاشة الرئيسية لدور يتخلى عن النظام واسأل: ما الذي يحصل عليه هنا ولم يكن ليحصل عليه بدون النظام؟ إذا كانت الإجابة هي "لا شيء، إنه يدخل البيانات فقط" - فإن التخلي منطقي تماماً.

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

## الموجة الأولى من الإصلاحات: 30 يوماً

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

1.  إزالة 30%-50% من الحقول في النموذج المركزي، مع إثبات عدم حاجة أي شخص إليها.
2.  حقلان إلزاميان على الأكثر في كل مرحلة من مراحل العملية.
3.  عرض "عملي لليوم" لكل دور رئيسي.
4.  إصلاح ثلاث مشاكل في جودة البيانات يستشهد بها المستخدمون كدليل على عدم إمكانية الوثوق بالنظام.
5.  أتمتة واحدة تلغي العمل اليدوي المتكرر.
6.  تحسين أبطأ شاشة.

ما لم يدخل هذه الموجة: الميزات الجديدة، الوحدات الإضافية، التكاملات الجديدة. التوسع وقت أزمة الثقة يزيد الضرر. الاتجاه الصحيح في هذه المرحلة هو التبسيط، كما هو موضح في [تبسيط تجربة المستخدم في Salesforce](/ar/insights/salesforce-ux-simplification).

## بناء الثقة من جديد

الثقة لا تعود من رسالة بريد إلكتروني. بل تعود من ثلاثة أنماط متكررة: الإصلاحات التي يتم تسليمها في الوقت الموعود، الشفافية بشأن ما لن يتم فعله، وتقدير من أثار المشكلة.

آلية بسيطة وفعالة: قائمة طلبات مفتوحة لجميع المؤسسة مع حالة، إصدار كل أسبوعين، ورسالة موجزة توضح ما تم إصلاحه وبفضل من. في غضون ستة أسابيع، سيغير هذا الحوار من "النظام لا يعمل" إلى "لقد قدمت طلباً".

الشبكة البشرية التي تحمل هذه الرسالة هي شبكة الأبطال (Champions)، ويتم تفصيل طريقة بنائها في [شبكة الأبطال في Salesforce](/ar/insights/salesforce-champions-network).

## الدورة الإدارية هي الأداة الأقوى

العامل الأكثر تأثيراً على التبني هو ما يراجعه المدير المباشر. ما دام يدير الفريق من ملف خارجي، فإن النظام اختياري. بمجرد أن تتم مراجعة مسار الفرص (Pipeline) أو تذاكر الخدمة (Cases) الأسبوعية من لوحة معلومات (Dashboard) حية – يصبح تحديث البيانات مصلحة شخصية للممثل.

هذا تغيير إداري يتطلب دعم راعٍ (Sponsor)، ولذلك فهو جزء من خطة إدارة التغيير وليس جزءاً من خطة العمل التقنية. انظر [إدارة تغيير Salesforce](/ar/insights/salesforce-change-management-plan).

## متى يتم التقليص بدلاً من التوسع

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

## مقاييس استعادة الثقة

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

## الملخص

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

### أسئلة وأجوبة
**كم يستغرق استعادة التبني بعد إطلاق فاشل؟**
التشخيص يستغرق أسبوعين، والموجة الأولى من الإصلاحات 30 يومًا، مع استقرار قابل للقياس خلال ربع واحد. تستغرق استعادة الثقة الإدارية وقتًا أطول – عادة ربعين تظهر فيهما الأرقام باستمرار.

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

**ماذا نفعل عندما يستمر المديرون في العمل على Excel بالتوازي؟**
تتم إزالة Excel كمصدر شرعي للمناقشة الإدارية. طالما أن مراجعة خط الأنابيب (Pipeline) تتم من ملف، فلا يوجد حافز حقيقي لتحديث النظام. هذا قرار إداري، وليس تقنيًا.

**هل استبدال النظام أفضل من إعادة التأهيل؟**
لا يكاد يكون أبدًا. في 80% من الحالات، يكون سبب الفشل هو العملية أو البيانات أو الواجهة – وكلها تنتقل معك إلى النظام التالي. يكون الاستبدال مبررًا فقط عندما يكون الخلل في القدرة الأساسية للمنتج.

**من يجب أن يقود عملية إعادة التأهيل؟**
مالك عملية تجارية رفيع المستوى لديه صلاحية لتغيير العملية، وليس مدير نظم معلومات فقط. معظم الإصلاحات المطلوبة هي قرارات تجارية: ما الذي يجب التوقف عن طلبه، ومن المسؤول عن أي بيانات، وما الذي يتم قياسه.

---

## هل يجب إصلاح Salesforce أم إعادة بنائه؟ إطار اتخاذ القرار لنظام موجود
URL: https://hpi.pro/ar/insights/salesforce-rebuild-vs-refactor
غالباً ما يُتخذ القرار بين الإصلاح الجزئي، إعادة الهيكلة (Refactor)، أو إعادة البناء (Rebuild) بناءً على الإحساس، وهذا هو السبب في تكرار المشكلة بعد عامين. يقدم هذا الدليل أربعة اختبارات موضوعية، ويوضح لماذا تكون إعادة البناء (Rebuild) دائماً تقريباً أغلى من التقديرات الأولية، ويصف المسار العملي للاستبدال التدريجي.

## الإجابة المختصرة

الخيارات الثلاثة ليست على نفس المحور. فـ **Repair** يعالج الأعراض، و**Refactor** يغير التنفيذ دون تغيير السلوك، بينما **Rebuild** يغير النموذج الأساسي. وتُحدد هذه الاختيارات بناءً على سؤال واحد: هل تكمن المشكلة في طريقة التنفيذ أم في ما تم تعريفه في البداية؟

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

## أربعة معايير حاسمة

| المعيار | يشير إلى Refactor | يشير إلى Rebuild |
| :------ | :----------------- | :---------------- |
| نموذج البيانات | سليم، يعاني من زيادة في الحقول | كائنات تخدم أغراضًا متضاربة |
| مصدر الصعوبة | الأداء، تكرار الأتمتة | استحالة إعداد التقارير أو التوسع |
| نطاق المستخدمين المتأثرين | جزئي، يمكن عزله | شامل عبر جميع العمليات |
| تكلفة إعادة الاختبار | يمكن اختبار منطقة واحدة | كل تغيير يتطلب اختبار تراجع كامل |

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

## لماذا يكون Rebuild أغلى من التقديرات

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

في الواقع، تمثل هذه البنود الأربعة غالبًا أكثر من نصف التكلفة الإجمالية. المؤسسة التي تفكر في Rebuild ولا تُسعّر هذه البنود تقارن بين تفاحة ونصف برتقالة.

## المسار العملي: الاستبدال التدريجي

حتى عندما يكون القرار هو Rebuild، فإن التنفيذ كمشروع "إيقاف واستبدال" يمثل بحد ذاته مخاطرة. المسار الفعال هو الاستبدال مجالًا تلو الآخر:

1.  **بناء النموذج الجديد بجانب القديم** - كائنات جديدة، دون المساس بالوضع الحالي.
2.  **نقل عملية كاملة واحدة** - مع مستخدميها وبياناتها وتقاريرها.
3.  **إيقاف النسخة القديمة الموازية** - هذه هي الخطوة التي تؤجلها معظم المؤسسات، وهذا ما يجعل المشروع مضاعفًا.
4.  **التكرار** حتى يصبح النظام القديم فارغًا بالكامل.

الخطوة الثالثة هي الاختبار الحقيقي. فالنظام الذي يعمل فيه كل من القديم والجديد بالتوازي لمدة عام كامل قد زادت تكلفته ولم ينخفض دينه التقني.

## ما يجب أن يتغير في كل الأحوال

يفشل كلا المسارين إذا ظلت آلية التغيير على حالها. إن الحوكمة الدنيا – من يوافق على تغيير في النموذج، ما هو الاختبار الإلزامي قبل الإطلاق، ومن هو مالك كل مجال – هي الشرط الذي يمنع العودة إلى نفس النقطة. تفاصيل تحديد أولويات الدين التقني موجودة في [تحديد أولويات الدين التقني في Salesforce](/ar/insights/salesforce-technical-debt-prioritization)، والعلامات التحذيرية المبكرة موضحة في [8 علامات تدل على الحاجة لترقية نظام Salesforce](/ar/insights/salesforce-system-upgrade-signs).

## الخلاصة

الخيار ليس بين "الإصلاح" و "البدء من جديد"، بل بين إصلاح التنفيذ وإصلاح التعريف. في معظم الحالات التي تبدو وكأنها Rebuild، يكمن نموذج بيانات سليم مدفون تحت عقد من الأتمتة - وهذا ما يتم تنظيفه على مراحل، وليس عن طريق الحذف الكامل.

### أسئلة وأجوبة
**متى يكون Rebuild هو الخيار الصحيح حقًا؟**
عندما يكون نموذج البيانات نفسه خاطئًا - على سبيل المثال، كائن واحد يخدم ثلاث عمليات مختلفة - وعندما يتطلب تصحيحه ترحيلاً (migration) على أي حال. إذا كان السبب الجذري هو فقط الأتمتة المعقدة، فإن Refactor أقل تكلفة بكثير.

**هل يحل Org جديد المشكلة؟**
فقط إذا كان سبب الفوضى هو غياب الحوكمة. بدون قواعد للتغيير والاختبار والملكية الواضحة، سيصل Org جديد إلى نفس الوضع في غضون عامين - هذه المرة مع نظامين متوازيين.

**كم يستغرق Refactor جاد؟**
بمدى متوسط، من ثلاثة إلى ستة أشهر على مراحل – ليس كمشروع واحد. يجب أن تقدم كل مرحلة تحسينًا قابلاً للقياس بحد ذاته، وإلا سيتوقف التمويل في المنتصف.

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

**كيف نقنع الإدارة بتمويل عملية تنظيف لا تضيف ميزات جديدة؟**
بترجمة الدين إلى تكلفة تشغيلية قابلة للقياس: ساعات الدعم، فشل التكامل، الوقت المتزايد لكل تغيير. الدين الذي يُعرض كـ'وقت' وليس كـ'جودة الكود' يحصل على التمويل.

---

## ترتيب أولويات التقني في Salesforce: ماذا نصلح أولاً ولماذا؟
URL: https://hpi.pro/ar/insights/salesforce-technical-debt-prioritization
قائمة الديون التقنية التي تمتد لمئة سطر ليست أداة عمل، بل مصدر إحباط. يقدم هذا الدليل نظام تسجيل بأربعة أبعاد يخلق ترتيبًا واضحًا، ويوضح نوع الدين الذي يجب أن يعالج أولاً بغض النظر عن الدرجة، وكيفية ترجمة الدين إلى لغة تحصل على ميزانية.

## الإجابة المختصرة

إن الدين التقني لا يُقاس بجودة الكود، بل بالتكلفة التي يفرضها على أي تغيير مستقبلي. لذلك، لا يتعلق تحديد الأولويات بـ "ما هو الأكثر قبحًا" بل **بما يزيد تكلفة العمل التالي**.

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

## التسجيل بأربعة أبعاد

| البعد | السؤال | الوزن |
| --- | --- | --- |
| التعرض التجاري | ماذا لو فشل هذا تحت ذروة الضغط؟ | مرتفع |
| التكرار | كم مرة في اليوم يتم التعامل مع هذا؟ | مرتفع |
| التبعية | كم مجال آخر معلق بسببه؟ | متوسط |
| الجهد | كم تكلفة الإصلاح في بيئة مُتحكم بها؟ | معكوس |

التسجيل ليس علمًا دقيقًا. قيمته الحقيقية تكمن في أنه يفرض حوارًا صريحًا بين الخبير بالمخاطر التقنية والخبير بالألم التجاري - وينشئ ترتيبًا يمكن الدفاع عنه أمام المديرين.

## ثلاثة أنواع من الديون التي تتجاوز الدور

بغض النظر عن التسجيل، هناك ثلاثة أنواع تأتي أولاً:

1.  **دين يعيق الاختبار** - عدم وجود بيئة Sandbox سليمة أو بيانات اختبار. كل إصلاح آخر يتم بدونه يتم في الظلام.
2.  **دين في الصلاحيات** - نموذج رؤية فقد منطقه هو تعرض تنظيمي نشط، وليس مجرد إزعاج.
3.  **دين يتركز في شخص واحد** - عندما يكون شخص واحد فقط يفهم مكونًا، فإن المخاطرة ليست تقنية بل تنظيمية.

## كيفية عرض الدين للحصول على ميزانية

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

من يقدم "ثلاثة طلبات تغيير في الربع، يتأخر كل منها أسبوعين بسبب نفس المكون" يحصل على الموافقة. من يقدم مخطط تبعيات - لا.

## حصة ثابتة، وليس عرضًا لمرة واحدة

النمط الفاشل: مشروع تنظيف كبير مرة كل سنتين. النمط الناجح: حصة ثابتة من 15%-20% من كل موجة مخصصة للدين، يتم تحديدها مسبقًا ولا تخضع للتفاوض في كل Sprint.

بالإضافة إلى الحصة، يلزم وجود قاعدة وقائية واحدة على الأقل - على سبيل المثال، حظر إضافة أتمتة جديدة إلى كائن يحتوي بالفعل على عدة أتمتات، قبل توحيدها. بدون وقاية، يتجاوز معدل تراكم الدين معدل التنظيف. تفاصيل العلاقة بالبنية التحتية للتطوير في [استراتيجية بيئات Sandboxes وعمليات DevOps](https://your_company.com/insights/salesforce-sandbox-devops-strategy).

## ملخص

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

### أسئلة وأجوبة
**ما هي نسبة القدرة التشغيلية المستمرة التي يجب تخصيصها للديون التقنية؟**
بين 15% و20% من كل دورة، كحد أقصى ثابت. التخصيص المتغير بناءً على الضغط يتلاشى خلال ربعين، لأن هناك دائمًا شيئًا أكثر إلحاحًا.

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

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

**ماذا نفعل عندما يتراكم الدين بشكل أسرع من عملية التنظيف؟**
هذه مشكلة إدارة وليست مشكلة سعة. بدون قاعدة تحظر إضافة أتمتة جديدة إلى الكائن قبل توحيد الموجود، فإن أي تنظيف هو مؤقت.

**هل نقص التوثيق يعتبر دينًا تقنيًا؟**
نعم، وبمستوى عالٍ من المخاطر عندما تكون المعرفة مركزة لدى شخص واحد. لا يظهر في التقارير، لكنه هو الذي يجعل أي تغيير يعتمد على توفر شخص معين.

---

## تحسين أداء Salesforce في المؤسسات الكبرى: التشخيص، التخطيط، والقياس
URL: https://hpi.pro/ar/insights/salesforce-performance-optimization
نادراً ما يكون بطء Salesforce مشكلة كبيرة واحدة، بل هو تراكم لعدة عوامل مثل الشاشات المكتظة، الاستعلامات غير الانتقائية، والأتمتة المزدوجة. يقدم هذا الدليل منهجية تشخيص متعددة الطبقات — المتصفح، الشاشة، الخادم، البيانات، التكامل — بالإضافة إلى مقاييس قابلة للقياس لإثبات التحسين.

## الإجابة المختصرة

إن ضعف الأداء في Salesforce هو عرض تراكمي: صفحة سجل (Record Page) تحتوي على 14 مكونًا، ثلاث عمليات أتمتة تعمل على نفس عملية الحفظ (Save)، استعلام (query) يمسح مليون سجل، وتكامل يسحب البيانات في ساعة الذروة. الطريقة الوحيدة للتحسين دون إهدار الميزانية هي القياس الطبقي، وتحديد الطبقة الأكثر هيمنة، ومعالجتها — ثم القياس مرة أخرى.

## الطبقات الخمس وما يُقاس في كل واحدة

| الطبقة | العرض النموذجي | أداة القياس | العلاج الشائع |
| --- | --- | --- | --- |
| المتصفح والشبكة | بطء لدى بعض المستخدمين فقط | Lightning Usage App لكل مستخدم | زمن الاستجابة (Latency) التنظيمي، إصدار المتصفح، VPN |
| الشاشة والمكونات | ارتفاع EPT في صفحة السجل الرئيسية | EPT per Page, Debug Mode | تقليل المكونات، التحميل التدريجي، علامات التبويب (Tabs) |
| الأتمتة | بطء عملية الحفظ، انتهاء المهلة (Timeout) في التحديثات الجماعية | Debug Logs, Flow Interviews | دمج التدفقات (Flows)، الانتقال إلى التنفيذ غير المتزامن (asynchronous) |
| البيانات والاستعلامات | تقارير تتعطل، عرض القائمة (List View) متوقف | Query Plan, Apex Jobs | التصفية الانتقائية، الفهرسة (Index)، الأرشفة |
| التكامل | ذروات تحميل منتظمة في أوقات محددة | Event Monitoring, API Usage | Bulk API، نوافذ التشغيل، تقييد النطاق الترددي (Throttling) |

## العمل مع أحجام البيانات الكبيرة

يتغير مسار العمل عند تجاوز مليون سجل في العنصر (Object). يؤدي انحراف البيانات (Data Skew) — على سبيل المثال، 200 ألف حساب (Accounts) مرتبطة بنفس المالك (Owner) أو الأصل (Parent) — إلى عمليات قفل الصفوف ويُباطئ أي تحديث جماعي. الحل يكمن في توزيع الملكية، لا في إضافة المزيد من الأجهزة، التي ليست تحت سيطرتكم على أي حال. في الوقت نفسه، يُنصح بالنظر في الأرشفة: السجلات المُغلقة منذ خمس سنوات والتي لا يقرأها أحد تزيد من تكلفة أي استعلام يقوم بعملية مسح.

## الشاشات: كلما قل العدد كانت أسرع

تتراكم المكونات في متوسط صفحة السجل (Record Page) داخل المؤسسات القديمة بمعدل اثنين أو ثلاثة سنويًا، لأن كل طرف ذي مصلحة يطلب "عنصر واجهة مستخدم إضافي". يُجري كل مكون Lightning استدعاءاته الخاصة. ينتج عن عمليتين أقصى فائدة: نقل المكونات الثانوية إلى علامات تبويب (Tabs) منفصلة تُحمّل فقط عند النقر، وتطبيق رؤية المكونات (Component Visibility) بناءً على نوع السجل (Record Type) أو الدور، بحيث يرى المستخدم فقط ما هو وثيق الصلة به. يؤدي الجمع بين العمليتين إلى خفض مؤشر EPT بنسبة عشرات بالمئة دون تغيير في الكود.

## ترتيب الإجراءات الناجح

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

المنطق وراء هذا الترتيب اقتصادي: الطبقات الأولى رخيصة وقابلة للعكس، بينما الطبقات الأخيرة باهظة الثمن وتتطلب اختبار الانحدار (regression testing). تظهر معلومات إضافية حول هذا الموضوع في [Salesforce Health Check](/ar/insights/salesforce-health-check-guide) وفي [علامات ترقية النظام](/ar/insights/salesforce-system-upgrade-signs).

## المخاطر الشائعة والإجراءات الوقائية

الخطر الأكبر هو التحسين بدون خط أساس (Baseline): يتم إجراء عشرة تغييرات، والمستخدمون ما زالوا يشتكون، ولا توجد طريقة لمعرفة ما الذي ساعد. القياس قبل وبعد كل تغيير مهم هو شرط أساسي، وليس رفاهية.

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

## كيفية قياس النجاح

تكفي أربعة مقاييس: متوسط EPT في الشاشات الخمس الرئيسية، وقت الحفظ (Save) في عملية الأعمال الرئيسية، عدد حالات فشل انتهاء المهلة (Timeout) وحدود الحاكم (Governor Limit) شهريًا، ونسبة الاستعلامات التي تستغرق أكثر من خمس ثوانٍ. المقياس الخامس — تكميلي وغير تقني — هو عدد شكاوى الأداء في مكتب الخدمة (Service Desk)، والذي من المتوقع أن ينخفض مع التحسين الفعلي.

### أسئلة وأجوبة
**من أين نبدأ عندما يشتكي المستخدمون من أن 'النظام بطيء'؟**
نبداً بالقياس، وليس بالتخمين. يظهر Lightning Usage App أي الشاشات بطيئة ولأي المستخدمين، ويشير EPT لكل Record Page إلى المكون المُسبب للمشكلة. الشكوى العامة بدون قياس تؤدي غالباً إلى إصلاح المكون الخاطئ.

**ما هو الاستعلام غير الانتقائي ولماذا هو حاسم؟**
هو استعلام لا تدعم خاصية التصفية فيه نظام الفهرسة، مما يجبره على مسح جدول كبير. عند تجاوز مليون سجل، يفشل هذا الاستعلام في Timeout أو يبطئ أي عملية تعتمد عليه. الحل يكمن في التصفية بناءً على حقول مفهرسة، وتجنب NULL وعلامة LIKE المفتوحة، وطلب Custom Index.

**متى تكون Skinny Table مبررة؟**
عندما يكون هناك تقرير رئيسي أو List View يستورد عدداً قليلاً من الحقول من Object يحتوي على ملايين السجلات، ويكون التصفية مُحسّنة بالفعل. هذا يتطلب طلباً لدعم Salesforce Support، وليس إعداداً ذاتياً، ويحل مشاكل القراءة — وليس الكتابة أو الأتمتة الثقيلة.

**هل استبدال Process Builder بـFlow يحسن الأداء؟**
غالباً ما يكون الجواب نعم، ولكن ليس بسبب الأداة بحد ذاتها ولكن بسبب التوحيد. يأتي المكسب الحقيقي من تقليل عدد الأتمتات التي تعمل على نفس الـObject ونقل العمل الثقيل إلى المعالجة غير المتزامنة، وليس مجرد الانتقال بحد ذاته.

**كم هو التحسين المتوقع بصفة معقولة؟**
في مشروع تشخيص وعلاج مركز، يعتبر خفض بنسبة 30%–50% في وقت تحميل الشاشات الأكثر ثقلاً خلال ستة إلى عشرة أسابيع هدفاً واقعياً. أي تحسين أكبر من ذلك يتطلب عادةً تغيير نموذج البيانات أو بنية التكامل.

---

## تطبيق Salesforce في المؤسسة: الدليل الشامل من مرحلة التوصيف حتى Go Live
URL: https://hpi.pro/ar/insights/salesforce-implementation-guide
معظم عمليات تطبيق Salesforce لا تفشل في التطوير بل بين المراحل: الانتقال المتسرع من الاكتشاف إلى البناء، والترحيل دون مراجعة شاملة، واختبار UAT يفتقر إلى المالك الحقيقي. يستعرض هذا الدليل المسار الكامل خطوة بخطوة، مع تحديد المخرجات والاعتمادات لكل منها.

## الإجابة المختصرة

إن السؤال المحوري عند تنفيذ Salesforce في مؤسسة لا يتعلق بـ "أي وحدة يجب تفعيلها أولاً"، بل بكيفية بناء مسار ينتج عنه كل مرحلة مخرجات قابلة للتصديق، بدلاً من مجرد اجتماع إضافي. يتبع هذا الدليل ثماني محطات: الاكتشاف (Discovery)، تصميم الحل (Solution Design)، البناء التدريجي (Gradual Building)، الترحيل (Migration)، اختبار قبول المستخدم (UAT)، التدريب (Training)، الانطلاق الفعلي (Go Live)، والرعاية الفائقة (Hypercare). في كل محطة، يوجد ناتج إلزامي، ومُعتمد مسؤول، ومخاطرة رئيسية يجب تحييدها قبل المتابعة.

الفكرة المركزية هي تسلسل غير قابل للتخطي: لا يمكن البناء بدون تصميم حل معتمد، ولا يمكن الانتقال إلى التشغيل الفعلي بدون اختبار قبول مستخدم (UAT) موقع عليه من قبل سلطة تجارية. عندما يتم تجاوز محطة، لا تختفي المشكلة، بل تنتقل فقط إلى مرحلة يكون إصلاحها فيها أكثر تكلفة. يمكن العثور على معلومات إضافية حول قرار استبدال نظام موجود من عدمه في [استبدال نظام CRM بـ Salesforce](/ar/insights/replace-crm-with-salesforce).

## خريطة المراحل الكاملة

| المرحلة | الناتج الإلزامي | من يوافق؟ | المخاطرة الرئيسية |
|---|---|---|---|
| الاكتشاف (Discovery) | وثيقة الوضع الراهن/الوضع المستهدف (As-Is/To-Be)، خط الأساس (Baseline)، ومؤشرات النجاح | الراعي التجاري وصاحب العملية | تعريف غامض للنجاح يكتشف فقط في UAT |
| تصميم الحل (Solution Design) | نموذج البيانات، الصلاحيات، قرارات التصميم المعماري (ADR)، ومخطط التكامل | مهندس Salesforce والمدير التنفيذي للمعلومات (CIO) | حل مبني حول طلب فردي وليس حول عملية |
| البناء التدريجي (Gradual Building) | جزء عمودي (Vertical Slice) فعال في كل سبرنت، مع عرض توضيحي | مالك المنتج (Product Owner) | تراكم متأخر للمهام "شبه المكتملة" بدون تعريف للانتهاء |
| الترحيل (Migration) | نتيجة تجربة ترحيل كاملة (Migration Rehearsal) مقابل معايير جودة | مالك البيانات (Data Owner) لكل كائن | بيانات مكررة أو مفقودة تكتشف فقط بعد التحميل للإنتاج |
| UAT | توقيع أصحاب العمليات على سيناريوهات شاملة (End-to-End Scenarios) | رؤساء فرق العمل التجاري | اختبار سطحي يغطي فقط المسار الإيجابي (Happy Path) |
| التدريب (Training) | خطة تمكين (Enablement Plan)، مواد تدريب، وقائمة الأبطال (Champions) | مدير CRM | مستخدمون يتعلمون "أثناء العمل" وينتجون بيانات سيئة |
| الانطلاق الفعلي (Go Live) | قائمة تحقق Go/No-Go موقعة وخطة استعادة (Rollback Plan) | إدارة المشروع | الانطلاق الفعلي بدون خطة تراجع في حالة الفشل |
| الرعاية الفائقة (Hypercare) | سجل مشاكل يومي ومعدل تبني مقابل خط الأساس | مدير CRM وفريق التنفيذ | إغلاق المشروع مبكراً جداً، قبل استقرار التبني |

## الاكتشاف (Discovery): قبل لمس الأداة

مرحلة الاكتشاف تحدد كل ما سيأتي بعدها، ومع ذلك هي المرحلة التي تختصرها معظم المؤسسات "للبدء بالبناء فورًا". الناتج المطلوب ليس عرضًا تقديميًا، بل وثيقة تتضمن عملية As-Is موثقة، وهدف To-Be، وقائمة صريحة بما لن يتم تضمينه في الإصدار الأول. بدون هذا التعريف، أي طلب جديد يأتي بعد شهرين سيعتبر جزءًا "بديهيًا" من المشروع.

الأداة الأكثر عملية في هذه المرحلة هي خط أساس قابل للقياس (measurable Baseline): وقت التعامل مع العميل المحتمل، النسبة المئوية للصفقات التي تغلق بدون إدخال مزدوج، معدل الحقول الفارغة في سجل العميل. بدون رقم قبل التغيير، لا يمكن إثبات التحسين بعد الإطلاق – فقط الشعور بوجوده. المؤسسات التي تتخطى هذه المرحلة تعود إليها على أي حال، عادةً في ذروة البناء، وهذا يكلف أكثر. تفاصيل إضافية حول عواقب التخطي المبكر مذكورة في [أخطاء في تنفيذ Salesforce](/ar/insights/crm-implementation-mistakes).

## تصميم الحل (Solution Design): حيث تتخذ معظم القرارات المكلفة

تصميم الحل هو المرحلة التي يتم فيها الاختيار بين عدة طرق تنفيذ محتملة وتوثيق سبب اختيار واحدة دون الأخرى. يجب أن يكون نموذج البيانات، وهيكل الصلاحيات (بما في ذلك المشاركة بين الأدوار والمناطق)، ومخطط التكامل مع أنظمة مثل ERP، ومعالجة الدفع، أو منصة التسويق - كل هذه الأمور مكتوبة قبل فتح بيئة تطوير أولية.

من الأخطاء الشائعة هو ترك فريق التطوير "يقرر أثناء العمل" كيف سيبدو نموذج المشاركة، لأنه يبدو تفصيلاً تقنيًا. في الواقع، تغيير نموذج المشاركة بعد وجود مئات السجلات في الإنتاج هو مشروع بحد ذاته. لذلك، عندما يتقاطع القرار مع عدة أقسام أو يؤثر على صلاحيات حساسة، ينصح بالتأكد من وضوح المسؤوليات والأدوار حول المشروع - انظر المزيد في [فريق مشروع Salesforce](/ar/insights/salesforce-project-team-roles).

### ما يجب أن يتضمنه تصميم الحل (Solution Design)

* نموذج الكائنات والحقول الرئيسية، بما في ذلك ما لم يتم بناؤه في الإصدار الأول.
* خريطة الصلاحيات حسب الدور، بما في ذلك الاستثناءات وحالات الوصول المؤقت.
* قائمة بالتكاملات مع اتجاه تدفق المعلومات وتكرار المزامنة.
* ثلاثة قرارات معمارية على الأقل مع بديل تم رفضه وسبب الرفض.

## البناء التدريجي (Gradual Building): شريحة عمودية وليس مجموعة شاشات

في مرحلة البناء، الفخ الشائع هو التقدم "بشكل عرضي" - إنشاء جميع الشاشات مرة واحدة دون أن تعمل أي عملية واحدة من البداية إلى النهاية. النهج الصحيح هو بناء شريحة عمودية (Vertical Slice) واحدة في كل دورة: عملية كاملة، ببيانات حقيقية وصلاحيات تمثيلية، يمكن عرضها لمالك العملية والحصول على تغذية راجعة فورية عنها.

يجب أن ينتهي كل سبرنت بعرض توضيحي (Demo)، ليس فقط "رموز تم تحميلها". عندما لا يكون هناك عرض توضيحي منتظم، تتراكم قائمة من المهام "شبه المكتملة" التي تكتشف أنها غير مكتملة إلا في مرحلة UAT، وهذا بالضبط ما يزيد تكلفة المشروع في الثلث الأخير منه.

## الترحيل (Migration): الجزء الذي يتم الاستهانة به أكثر من غيره

غالباً ما يكون ترحيل البيانات هو الخطر الأكبر في المشروع، وعادة ما يُخصص له أقل وقت في الجدول الزمني. من الضروري إجراء تجربة ترحيل كاملة (full Migration Rehearsal) – تحميل البيانات إلى بيئة اختبار بحجم كامل، بما في ذلك كميات حقيقية، واختبار النتائج مقابل معايير جودة محددة مسبقًا: التكرارات، الحقول الإلزامية المفقودة، تنسيق التواريخ والعملات، والتوافق بين الأنظمة.

جدول مفيد لإدارة هذه المخاطرة:

| اختبار الجودة | ماذا يتم اختباره | حد القبول الموصى به |
|---|---|---|
| اكتمال الحقول الإلزامية | نسبة السجلات التي تحتوي على حقل حرج فارغ | أقل من 2% |
| التكرارات | العملاء/العملاء المحتملون بنفس المعرف التجاري | أقل من 1% بعد إزالة التكرارات |
| توافق التنسيق | التواريخ، العملات، رموز الدول | 100% متوافق مع معيار الوجهة |
| ترابط السجلات | علاقات Parent-Child لم تنكسر أثناء الانتقال | 100% من العلاقات بالغة الأهمية |

## UAT: اختبار بملكية حقيقية، لا توقيع تقني

اختبار UAT الذي يُنفذ بشكل صحيح يتضمن قيام أصحاب العمليات بأنفسهم بتشغيل سيناريوهات شاملة (end-to-end scenarios)، وليس فريق المشروع الذي يعرضها لهم. يُنصح باختيار 8-12 سيناريو لا يغطي المسار الصحيح فحسب، بل يشمل أيضًا حالات استثنائية: عميل بدون عنوان بريد إلكتروني، صفقة تُغنى بعد الموافقة، مستخدم بصلاحيات جزئية. يجب أن يكون التوقيع على UAT صريحًا - الاسم، التاريخ، وقائمة الفجوات المتبقية للإصدار التالي، وليس مجرد "موافقة شفهية في اجتماع".

## التدريب: حيث ينجح المشروع أو يفشل بصمت

حتى الحل التقني الممتاز يفشل إذا لم يتبناه المستخدمون. تتضمن خطة التدريب الجيدة مواد مخصصة لكل دور (وليست عرضًا تقديميًا موحدًا للجميع)، وعروض توضيحية في بيئة Sandbox ببيانات مألوفة، وقائمة بالأبطال (Champions) - مستخدمين رئيسيين من كل فريق يمكنهم الإجابة على الأسئلة الروتينية دون فتح طلب دعم. المؤسسات التي تستثمر في التدريب قبل أسبوعين من الانطلاق الفعلي (Go Live) عادة ما تشهد عددًا أقل من أخطاء الإبلاغ الكاذبة ("النظام لا يعمل" بينما في الواقع هي خطأ إدخال).

## الانطلاق الفعلي (Go Live) والرعاية الفائقة (Hypercare): الانتقال إلى التشغيل هو البداية، وليس النهاية

يتطلب الانطلاق الفعلي (Go Live) قائمة تحقق موقعة تتضمن فحص الصلاحيات في بيئة الإنتاج، والتحقق من عمل التكاملات، وخطة استعادة (Rollback) واضحة في حالة اكتشاف عطل فادح. بعد الإطلاق، تبدأ فترة الرعاية الفائقة (Hypercare) – تتراوح عادةً بين أسبوعين وأربعة أسابيع، يراقب خلالها الفريق يوميًا سجل الأخطاء، ومعدل الاستخدام الفعلي، وشكاوى المستخدمين، ويقوم بالإصلاح بأولوية عالية في غضون يوم عمل واحد. إغلاق المشروع قبل استقرار التبني هو خطأ شائع: البيانات من الأسبوعين الأولين غالبًا ما تقدم صورة أسوأ مما ستكون عليه الحقيقة بعد استقرار العادات.

## ما الذي يتعطل فعلياً في المؤسسات متوسطة الحجم في إسرائيل

في ممارسة HPI Pro مع الشركات متوسطة الحجم في إسرائيل (بين 20 و 300 موظف)، لا تنجم معظم الأعطال عن اختيار منتج خاطئ، بل عن اختصارات إجرائية:

*   **الإدارة غير المتاحة للموافقة على النطاق** - يتقدم المشروع بناءً على تفسير مدير تكنولوجيا المعلومات، وعندما ترى الإدارة النتيجة أخيرًا، تطلب تغييرات تعيد العمل لأسابيع إلى الوراء.
*   **الاعتماد على مطور واحد أو مكتب صغير بدون دعم توثيقي** - عندما يغادر الشخص، لا يوجد من يفهم القرارات التي اتخذت في تصميم الحل.
*   **الترحيل من مصادر غير رسمية** - جداول Excel يديرها كل مندوب مبيعات على حدة، بدون مصدر حقيقة متفق عليه، مما يجعل مرحلة التنظيف مشروعًا فرعيًا.
*   **ضغط UAT في أسبوع واحد قبل الانطلاق الفعلي** - عندما يضيق الجدول الزمني، يكون UAT هو أول مرحلة يتم تقليصها، وهذا بالضبط هو المرحلة التي من الأفضل الحفاظ عليها.
*   **نقص التدريب المخصص للغة والدور** - مواد تدريبية عامة باللغة الإنجليزية لفريق مبيعات يعمل بالعبرية تؤدي إلى استخدام جزئي وتجاوز النظام فعليًا.

طريقة تقليل هذه المخاطر ليست "العمل بشكل أسرع" بل تخطيط طبقة DevOps للمشروع – بيئات اختبار منفصلة، وعملية إصدار محددة، وتتبع التغييرات – منذ البداية. مزيد من التفاصيل حول هذا الموضوع في [Salesforce DevOps Sandboxes](/ar/insights/salesforce-sandbox-devops-strategy).

## قائمة تحقق قبل الانتقال بين المراحل

*   ☐ يوجد ناتج مكتوب لكل مرحلة، وليس مجرد ملخص اجتماع.
*   ☐ تم قياس خط الأساس (Baseline) قبل بدء المشروع.
*   ☐ نموذج البيانات والصلاحيات معتمدان قبل بدء التطوير.
*   ☐ كل سبرنت ينتهي بعرض توضيحي لشريحة عمودية (Vertical Slice).
*   ☐ تم إجراء تجربة ترحيل كاملة (Migration Rehearsal) بحد جودة محدد.
*   ☐ تم توقيع UAT من قبل أصحاب العمليات مع قائمة الفجوات المفتوحة.
*   ☐ توجد خطة تدريب مخصصة للدور واللغة.
*   ☐ توجد قائمة تحقق Go/No-Go وخطة استعادة (Rollback Plan).
*   ☐ فترة الرعاية الفائقة (Hypercare) محددة بالوقت والمسؤولية.

## كيف يتم قياس نجاح المشروع فعلياً

| مجال القياس | ماذا يتم اختباره | وتيرة المتابعة الموصى بها |
|---|---|---|
| التبني | نسبة المستخدمين النشطين مقابل إجمالي حاملي التراخيص | أسبوعياً في الشهر الأول |
| جودة البيانات | الحقول الإلزامية المفقودة، التكرارات | قبل Go Live ومرة واحدة شهرياً |
| أداء العملية | وقت التعامل مع العميل المحتمل/الصفقة مقابل خط الأساس | شهرياً في الأشهر الثلاثة الأولى |
| الأعطال | عدد مكالمات الدعم ومعدل إعادة الفتح | يومياً خلال فترة Hypercare |

يمكن للمؤسسات التي تختار المرافقة المهنية طوال هذا المسار، من مرحلة الاكتشاف (Discovery) وحتى إغلاق فترة الرعاية الفائقة (Hypercare)، الاستفادة من [خدمة تنفيذ Salesforce](/ar/salesforce-implementation) لضمان حصول كل محطة على الناتج والموافقة ومراقبة المخاطر المناسبة قبل الانتقال إلى المرحلة التالية.

## مصادر احترافية

*   Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
*   HPI Pro – تنفيذ Salesforce — https://hpi.pro/salesforce-implementation
*   HPI Pro – منهجية العمل — https://hpi.pro/methodology

### أسئلة وأجوبة
**كم يستغرق التطبيق الكامل لـ Salesforce في شركة متوسطة الحجم؟**
بالنسبة لشركة تضم 30-80 مستخدمًا وعمليات مبيعات وخدمة أساسية، فإن المسار الكامل من مرحلة الاكتشاف (Discovery) حتى الإطلاق العملي (Go Live) يتراوح بين 10 إلى 16 أسبوعًا. أما المشاريع التي تتضمن عمليات تكامل معقدة مع أنظمة ERP أو الفوترة، فتمتد إلى 20-24 أسبوعًا، ويرجع ذلك بشكل أساسي إلى متطلبات الترحيل والاختبار.

**ما الفرق بين تصميم الحل (Solution Design) وتوثيق المتطلبات العادي؟**
تصميم الحل (Solution Design) يشمل نموذج البيانات، خريطة الصلاحيات، مخطط التكاملات، والقرارات المعمارية مع البدائل المستبعدة. توثيق المتطلبات العادي يصف ما يريده المستخدم؛ أما تصميم الحل فيصف كيف سيبنى النظام فعليًا وما هي تكلفة كل خيار.

**هل يمكن تخطي مرحلة اختبار قبول المستخدم (UAT) عند ضيق الوقت؟**
يمكن تقليص نطاقه ولكن لا يمكن الاستغناء عنه. يتضمن الحد الأدنى من UAT اختبار 5-8 سيناريوهات حرجة وشاملة من البداية إلى النهاية مع أصحاب العمليات الفعليين. إن التخطي الكامل للمرحلة غالبًا ما يؤدي إلى ظهور المشكلات في الأسابيع الأولى بعد الإطلاق العملي (Go Live)، حيث تكون تكلفة الإصلاح أعلى.

**من المسؤول عن جودة البيانات في عملية الترحيل من Excel أو نظام قديم؟**
تقع المسؤولية المهنية عن قواعد التحويل والتنقية على عاتق فريق التطبيق، ولكن المسؤولية عن صحة المحتوى التجاري تظل لدى مالك البيانات في المؤسسة. لذلك، يُنصح بتعيين مالك للبيانات (Data Owner) لكل كائن (Object) يقوم بالموافقة على نتيجة الترحيل قبل تحميلها إلى بيئة الإنتاج.

**ماذا يحدث فعلاً خلال فترة الدعم المكثف (Hypercare)؟**
عادةً ما تستمر هذه الفترة من أسبوعين إلى أربعة أسابيع، حيث يكون فريق التطبيق متاحًا للدعم الوثيق، ومراقبة سجل الأخطاء والاعتماد اليومي، وإصلاح المشكلات ذات الأولوية العالية خلال يوم عمل واحد. في نهاية هذه الفترة، يتم نقل المسؤولية بشكل منظم إلى فريق الصيانة الروتيني أو الدعم الداخلي.

---

## هندسة Salesforce للمؤسسات: كيف تُصمّم نظامًا قابلًا للتوسع؟
URL: https://hpi.pro/ar/insights/crm-architecture-guide
المؤسسة التي تضيف كائنات Custom Object، تدفقات Flow، وعمليات دمج Point-to-Point دون وجود طبقة معمارية موثقة، تُراكم دينًا تقنيًا لا يظهر إلا عند محاولة إضافة أعمال جديدة أو التوسع في دول جديدة. يقسم هذا المقال الهندسة المعمارية إلى ست طبقات عملية.

## الملخص التنفيذي

تُقاس جودة هندسة Salesforce ليس بكمية المكونات التي تم بناؤها، بل بقدرة المؤسسة على إضافة أعمال أو منتجات أو أسواق جديدة دون تعطيل ما هو قائم بالفعل. المشكلة الأكثر شيوعًا التي نراها ليست اختيارًا تقنيًا خاطئًا، بل نقص طبقة القرارات الموثقة: من هو المالك لكل كائن (Object)، ولماذا تم اختيار Flow بدلاً من Apex، ولماذا توجد خمسة عمليات تكامل منفصلة بدلاً من طبقة وسيطة (Middleware) واحدة.

تقسّم هذه المقالة الهندسة إلى ست طبقات يجب تخطيطها بشكل متكامل وليس بمعزل عن بعضها: نموذج البيانات والكائنات، المشاركة والصلاحيات، الأتمتة، عمليات التكامل، استراتيجية Org، وDevOps مع قابلية التوسع. يمكن الاطلاع على الخلفية الموسعة حول معالجة أخطاء التكامل في [مراقبة تكاملات Salesforce](/ar/insights/salesforce-integration-error-handling).

## نموذج البيانات والكائنات: الأساس الذي يقوم عليه كل شيء

خطأ يتكرر في العديد من المؤسسات: إنشاء كائن مخصص (Custom Object) جديد لكل متطلب جديد من العمل، دون التحقق مما إذا كان بالإمكان استخدام حقل إضافي على كائن موجود أو Record Type. النتيجة بعد سنتين أو ثلاث هي وجود Org يحتوي على 80-120 كائنًا مخصصًا، بعضها مكرر في المعنى، بدون توثيق لسبب إنشاء كل منها.

المبدأ التوجيهي هو السؤال قبل إنشاء أي كائن: من هو المالك التجاري، وما هو مصدر الحقيقة (Salesforce أو نظام خارجي)، وماذا يحدث عند حذف سجل (Record) أو تكراره. الشركات التي تدير كتالوجات منتجات معقدة، على سبيل المثال، تميل إلى إنشاء كائن منفصل لكل فئة بدلاً من استخدام Record Types على Product2 - وهذا يخلق عبئًا لا داعي له على الصيانة مع كل ترقية.

جدول مفيد لتقييم نضج نموذج البيانات:

| المكون | سؤال الاختبار | علامة تحذير |
|---|---|---|
| الكائنات المخصصة | هل يوجد كائن مشابه يمكن توسيعه؟ | كائنان لهما نفس الحقول أساسًا |
| الحقول | هل يُستخدم الحقل لأكثر من عملية واحدة؟ | أكثر من 800 حقل على كائن مركزي |
| العلاقات | هل تم اختيار Master-Detail أو Lookup عن قصد؟ | اختيار Master-Detail "افتراضيًا" |
| المعرف الخارجي (External ID) | هل لكل كائن متزامن مفتاح فريد؟ | المزامنة بالاسم أو التاريخ فقط |

## المشاركة والصلاحيات: الطبقة التي تتهاوى بصمت

لا يتم اكتشاف نموذج الصلاحيات المرن فورًا - بل يظهر عندما يرى شخص ما بيانات لا ينبغي له رؤيتها، أو عندما يعرض تقرير إداري عددًا أقل من الصفوف المتوقعة لأن قاعدة مشاركة (Sharing Rule) تمنع الوصول. يجب أن ينبثق الاختيار بين Role Hierarchy وOrganization-Wide Defaults وSharing Rules وPermission Sets من الهيكل التنظيمي الفعلي، وليس من الهيكل الهرمي الرسمي في المخطط التنظيمي.

نمط غير مرغوب فيه شائع: منح "View All" أو "Modify All" على مستوى الملف الشخصي (Profile) "لحل" مشكلة صلاحيات تحت ضغط الوقت، دون العودة لاحقًا وتقليلها. هذا يعمل على المدى القصير ويؤدي إلى انكشاف واسع للمعلومات على المدى الطويل - خاصة في البيئات التنظيمية مثل المالية أو الرعاية الصحية. تتيح Permission Set Groups بناء صلاحيات معيارية يمكن إضافتها وإزالتها دون لمس الملف الشخصي الأساسي، وهي الطريقة الأكثر أمانًا للتعامل مع مؤسسة متنامية.

تتطلب قواعد المشاركة القائمة على المعايير (Criteria-Based Sharing Rules) على الكائنات التي تحتوي على ملايين السجلات اختبار الحمل قبل الإنتاج - هناك حالات تتسبب فيها قاعدة مشاركة تبدو بسيطة في إعادة حساب تستغرق ساعات وتعطل العمليات الليلية.

## الأتمتة: Flow مقابل Apex

السؤال "Flow أم Apex" ليس مسألة تفضيل بل مسألة تعقيد وحجم وعمر. Flow أسهل في القراءة لفريق التشغيل، ويتم بناؤه وصيانته بسرعة، ومناسب للمنطق التجاري المتغير. Apex مطلوب عندما تكون هناك معالجة مجمعة (Bulk Processing) لآلاف السجلات في معاملة واحدة، عندما تكون هناك حاجة إلى تحكم دقيق في ترتيب التنفيذ مقابل المشغلات (Triggers) الأخرى، أو عندما يكون الاختبار الآلي (Test Coverage) ضروريًا لأغراض تنظيمية أو لإدارة التغيير الرسمية.

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

قاعدة عملية: إذا كان هناك أكثر من 5-6 شروط متفرعة في منطق عمل واحد، أو إذا كانت هناك حاجة إلى استدعاء خارجي داخل حلقة (Loop)، فمن الأفضل استخدام Apex. بخلاف ذلك، يُفضل Flow لأنه متاح للصيانة حتى عندما لا يكون المطور الأصلي موجودًا في الشركة.

## التكاملات: من Point-to-Point إلى طبقة مُدارة

المؤسسة التي تبدأ باتصالين خارجيين (ERP ونظام دفع، على سبيل المثال) عادة ما تبنيهما مباشرة، Point-to-Point، وهذا مقبول في هذه المرحلة. تبدأ المشكلة عندما ينضم اتصال ثالث ورابع وخامس - كل منها بمنطق إعادة المحاولة (Retry)، ومعالجة الأخطاء، وتعيين الحقول الخاص به، دون معيار مشترك. في هذه المرحلة، يؤدي أي تغيير في النظام المصدر إلى كسر اتصال واحد أو أكثر دون أن يعلم أحد مسبقًا.

الانتقال إلى طبقة وسيطة (Middleware) (MuleSoft، أو طبقة تكامل مخصصة) لا يجب أن يكون مشروعًا ضخمًا - يمكن البدء بالاتصال الأكثر هشاشة أو الأكثر تكلفة للصيانة والانتقال تدريجيًا. المبادئ التي يجب اعتمادها في كل تكامل جديد: الثبات (Idempotency) (لا تؤدي المكالمة المكررة إلى إنشاء سجل مكرر)، المعرف الخارجي (External ID) للتعريف المؤكد، والسجل (Log) الذي يسمح باستعادة ما حدث بالضبط في كل مكالمة. يمكن العثور على مزيد من التفاصيل حول أنماط التكامل في [ربط Salesforce بنظام ERP](/ar/insights/salesforce-erp-integration) و[أنماط تكامل Salesforce](/ar/insights/salesforce-integration-patterns).

## استراتيجية Org: Org واحد، Org متعدد، أو تقسيم الوحدات التجارية

هذا أحد أغلى القرارات التي يمكن تغييرها بأثر رجعي. يُعد Org واحد مع تقسيم الوحدات التجارية (استخدام Record Types، وSharing، وPermission Sets للفصل المنطقي) مناسبًا لمعظم المؤسسات، لأنه يحافظ على مصدر واحد للحقيقة ومقاييس تقارير موحدة. يصبح Multi-Org مناسبًا عندما تتطلب الوحدات التجارية نماذج صلاحيات متضاربة بشكل جوهري، أو عند وجود عملية دمج أو استحواذ تجلب Org موجودًا، أو عندما يؤثر حمل الصلاحيات الفعلي على الأداء.

الانتقال بين النماذج بعد بناء المؤسسة هو مشروع ثقيل - دمج البيانات، إعادة تعيين الصلاحيات، وأحيانًا فقدان التاريخ. يمكن العثور على التفاصيل الكاملة لاعتبارات القرار في [Salesforce Multi Org](/ar/insights/salesforce-single-org-vs-multi-org).

## DevOps وقابلية التوسع: كيفية الحفاظ على القدرة على التغيير

المؤسسة التي تقوم بالتطوير مباشرة في بيئة الإنتاج (Production)، دون Sandbox منظم ودون أدوات CI/CD (مثل Copado أو Gearset أو SFDX)، تصل بسرعة إلى حالة يكون فيها أي تغيير محفوفًا بالمخاطر. تتضمن عملية DevOps السليمة على الأقل Sandbox للتطوير، وSandbox للاختبار، والتحكم في الإصدارات (Version Control) للبيانات الوصفية (Metadata)، وعملية نشر (Deployment) تلقائية مع اختبار الانحدار (Regression Tests).

جدول القرارات المعمارية الرئيسية وتداعياتها على المدى الطويل:

| القرار | الميزة الفورية | التداعيات بعد 2-3 سنوات |
|---|---|---|
| كائن مخصص لكل متطلب | حل سريع لحاجة معينة | Org به عشرات الكائنات المكررة، يصعب صيانته |
| صلاحيات "View All" المؤقتة | يحل مشكلة في دقائق | انكشاف واسع للمعلومات يصعب تتبعه وإغلاقه |
| Flow يستدعي Flow | تطوير سريع بدون كود | سلاسل يصعب تتبعها واختبارها |
| تكامل Point-to-Point إضافي | اتصال سريع بين نظامين | شبكة اتصالات يؤدي أي تغيير فيها إلى كسر شيء آخر |
| التطوير المباشر في Production | يوفر وقت إعداد العملية | مخاطر عالية لأي تغيير، صعوبة في الاستعادة |
| Org واحد بدون فصل منطقي | تقارير موحدة من اليوم الأول | صعوبة في إضافة وحدة عمل باحتياجات مختلفة |

## سيناريو تنظيمي نموذجي

عملت شركة توزيع بثلاث وحدات تجارية لمدة أربع سنوات على Org واحد، حيث أضافت كل وحدة كائنات وFlows وتكاملات خاصة بها حسب الحاجة الفورية. عندما قررت الإدارة إضافة وحدة رابعة، تبين عدم وجود وثيقة واحدة تشرح من هو المالك لكل كائن، وثلاث عمليات تكامل مختلفة تقوم بمزامنة العملاء مع النظام المالي بمنطق متضارب.

أجرى فريق هندسة Salesforce مسحًا كاملاً: حدد 23 كائنًا بدون مالك واضح، وست سلاسل Flow متداخلة، وعمليتي تكامل أنشأتا سجلات مكررة بسبب عدم وجود معرف خارجي (External ID) متسق. لم يكن الحل إعادة البناء، بل التوثيق التدريجي، وتوحيد منطق المشاركة (Sharing) ضمن Permission Set Groups، ونقل التكاملات الحيوية إلى طبقة وسيطة (Middleware) واحدة. في غضون ربعين، انخفض وقت إضافة وحدة تجارية جديدة من عدة أشهر إلى حوالي ستة أسابيع.

## الأنماط غير المرغوب فيها الشائعة في المؤسسات المتنامية

- **كائن مخصص لكل طلب** - إنشاء كائن جديد دون التحقق مما إذا كان هناك كائن مشابه موجود بالفعل.
- **صلاحيات واسعة "مؤقتة"** - تُمنح تحت الضغط ولا يتم تقليصها أبدًا.
- **Flow-in-Flow بدون رسم تخطيطي** - سلاسل أتمتة ليس لها مخطط تشغيل مركزي.
- **Point-to-Point بدون حوكمة** - يتم بناء كل اتصال جديد بشكل منفصل بدون معيار مشترك.
- **التطوير في بيئة الإنتاج (Production)** - تغييرات مباشرة بدون Sandbox أو اختبارات أو التحكم في الإصدارات (Version Control).
- **عدم وجود معرف خارجي (External ID)** - المزامنة بالاسم أو البريد الإلكتروني التي تؤدي إلى إنشاء سجلات مكررة.

## قائمة مراجعة لتقييم نضج هندسة Salesforce

- ☐ لكل كائن مخصص مالك تجاري موثق.
- ☐ تم اختبار نموذج المشاركة (Sharing) تحت حمل بيانات واقعي.
- ☐ توجد خريطة مركزية لجميع سلاسل الأتمتة.
- ☐ لكل تكامل معرف خارجي (External ID)، ومنطق إعادة المحاولة (Retry)، وسجل أخطاء (Error Log).
- ☐ توجد عملية Sandbox-to-Production منظمة مع اختبارات الانحدار (Regression Tests).
- ☐ تم اتخاذ قرار صريح بين Org واحد وMulti-Org مع تبرير مكتوب.
- ☐ يتم فحص Governor Limits مقابل توقعات النمو لثلاث سنوات.

عندما تتطلب هندسة Salesforce إرشادًا مهنيًا وليس مجرد إطار عمل مستقل، فهذا هو مجال [خدمة هندسة CRM](/ar/crm-architecture).

## المصادر المهنية

- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – هندسة CRM — https://hpi.pro/crm-architecture
- HPI Pro – التكاملات والبيانات — https://hpi.pro/integrations-data

### أسئلة وأجوبة
**ما الفرق بين Flow و Apex عند اختيار طبقة الأتمتة؟**
تُعد Flow مناسبة للمنطق التجاري المتغير بشكل متكرر، وتوجيهها إلى فريق العمليات (Operations)، وعند وجود أقل من 5-6 شروط معقدة. بينما تُصبح Apex ضرورية عند وجود معاملات (transactions) معقدة، حلقات (loops) تتضمن استدعاءات خارجية (external calls)، معالجة مجمّعة (Bulk Processing) لآلاف السجلات، أو الحاجة إلى اختبارات تلقائية (Test Classes) للامتثال التنظيمي.

**متى يحين الوقت للانتقال من Single Org إلى عدة مؤسسات؟**
عندما تتطلب وحدات الأعمال المختلفة نماذج صلاحيات متعارضة، أو عندما يؤدي حمل الصلاحيات إلى تدهور الأداء، أو عندما يؤدي الاندماج/الاستحواذ إلى إضافة Org منفصلة. هذا الانتقال مكلف ومعقد - لذا يُنصح بالتحقق أولاً مما إذا كان تجزئة وحدات الأعمال (Business Unit Segmentation) أو العملات المتعددة (Multi-Currency) يحل المشكلة ضمن Org واحد.

**كيف تُبنى نموذج مشاركة (Sharing) لا ينهار تحت الضغط؟**
يجب أولاً رسم خريطة لهيكل المؤسسة ومجموعات المستخدمين، ثم الاختيار بين Role Hierarchy و Sharing Rules و Permission Sets بناءً على نطاق الاستثناءات. تتطلب قواعد المشاركة (Sharing Rules) القائمة على المعايير والتي تُنفّذ على ملايين السجلات اختبار الأداء قبل الإنتاج (Production)، وليس بعده.

**ماذا نفعل مع تكاملات Point-to-Point القديمة التي تراكمت على مر السنين؟**
يجب رسم خريطة لجميع الاتصالات الحالية، وتحديد تكرارات المنطق بين الأنظمة، وبناء خطة انتقال تدريجية إلى طبقة Middleware أو هندسة Event-Driven Architecture. لا يجب استبدال كل شيء دفعة واحدة - بل البدء بالتكامل الأكثر هشاشة أو الأكثر تكلفة للصيانة.

**كيف يمكن التأكد من أن الهندسة المعمارية ستبقى قوية لمدة ثلاث سنوات قادمة؟**
يجب التحقق من حدود المحافظ (Governor Limits) مقابل حجم النمو المتوقع، وعدد الكائنات المخصصة (Custom Objects)، وعمق سلاسل الأتمتة (Automation Chains)، وعدد التكاملات النشطة (active integrations). تُعد المؤسسة التي تحتوي على أكثر من 15 Trigger على كائن واحد أو سلاسل Flow التي تستدعي بعضها البعض علامة إنذار مبكر.

---

## تصميم CRM قبل Salesforce: المخرجات الأساسية قبل البدء بالتنفيذ
URL: https://hpi.pro/ar/insights/crm-discovery-guide
الـDiscovery الذي ينتهي بعرض تقديمي مصاغ ببراعة ليس Discovery حقيقيًا. في نهاية مرحلة التصميم، يجب أن تكون هناك سبعة مخرجات جاهزة ليمكن البناء عليها، بناءً على تقدير التكاليف، والتحقق منها. يشرح هذا الدليل محتوى كل مخرج، وكيفية التأكد من نضجه، والوقت المعقول الذي يجب تخصيصه له.

## ما يجب أن يكون جاهزاً بعد مرحلة التحليل والتصميم

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

يحدد هذا الدليل سبعة مخرجات. لكل مخرج معيار نضج: جملة واحدة يمكن الإجابة عليها بنعم أو لا. أي مشروع يجيب "تقريباً" على أكثر من اثنين من هذه المعايير، يدخل مرحلة البناء مع مخاطرة يمكن تقييمها بالفعل. تتوفر نظرة عامة على المراحل التالية للتحليل والتصميم في [دليل تنفيذ Salesforce](/ar/insights/salesforce-implementation-guide).

## المخرج 1: خارطة عمليات بمستوى اتخاذ القرار

لا تُعنى هذه النقطة بتدفق العمل لكل نقرة، بل برسم خرائط نقاط اتخاذ القرار: من يتخذ القرار، بناءً على أي معلومات، ماذا يحدث في كل فرع، وماذا يحدث عندما لا يتم اتخاذ قرار. تكمن معظم إخفاقات مشاريع CRM ليس في المسار الطبيعي ولكن في الفروع – صفقة معلقة، عميل يعود بعد عامين، استفسار تم فتحه من قبل العميل الخطأ.

معيار النضج: يمكن تتبع معاملة حقيقية من الشهر الماضي على الخريطة من البداية إلى النهاية دون مواجهة أي فجوات.

## المخرج 2: مسرد مصطلحات الأعمال

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

يجب أن يحتوي مسرد المصطلحات، لكل مصطلح، على: تعريف في جملة واحدة، الكيان في Salesforce الذي يمثله، الحقل الذي يحدد حالته، القسم الذي يملك هذا التعريف.

## المخرج 3: نموذج بيانات أساسي حاسم

في مرحلة التحليل والتصميم، لا يتم بناء مخطط علاقات الكيانات (ERD) بشكل كامل، ولكن يتم حسم أربع مسائل رئيسية سيكون تغييرها مكلفاً لاحقاً:

- هل تعتمد الأنشطة التجارية على Opportunity، على كائن مخصص، أم على مزيج منهما، وما هي العلاقة بينها.
- هل يمثل Account كياناً قانونياً، موقعاً مادياً، أم مجموعة شراء، وكيف يتم التعامل مع التسلسل الهرمي.
- ما هو المفتاح الفريد الذي يحدد العميل بين Salesforce والأنظمة الأساسية.
- ما هي البيانات التاريخية التي ستدخل النظام وما هي التي ستبقى في مصدرها الأصلي.

معيار النضج: يمكن رسم الكائنات الخمسة الرئيسية والعلاقات بينها على السبورة دون فتح أي ملف.

## المخرج 4: نموذج الصلاحيات والمشاركة

يُشتَق نموذج الصلاحيات من السؤال "من لا ينبغي له أن يرى ماذا"، وليس من السؤال "من يحتاج إلى رؤية ماذا". يبدو السؤالان متشابهين لكنهما يؤديان إلى هياكل معمارية متناقضة. يحدد التحليل والتصميم الجيد الافتراض الافتراضي للمؤسسة لكل كائن رئيسي، وآلية التوسيع، والحالات التي تتطلب مشاركة استثنائية.

| السؤال | ما يتم التحقق منه في التحليل والتصميم | لماذا يكون التغيير مكلفاً لاحقاً |
|---|---|---|
| الافتراضي للكائن | Private, Public Read أو Read/Write | يؤثر على كل آلية مشاركة فوقه |
| هيكل التسلسل الهرمي | هل يعكس التسلسل الهرمي للمهام الإدارة أم الجغرافيا | يتطلب التغيير إعادة حساب الوصول في جميع السجلات |
| المشاركة بين الوحدات | فرق مشتركة، مشاركة يدوية أو معيار | يحدد ما إذا كانت هناك حاجة لمنطق مخصص |
| البيانات الحساسة | ما هي الحقول المقيدة ولمن | يكشف التغيير اللاحق عن معلومات تم الاطلاع عليها بالفعل |

## المخرج 5: خارطة الأنظمة ومصادر الحقيقة

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

## المخرج 6: معايير القبول للعمليات الأساسية

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

## المخرج 7: مقاييس الأساس قبل التغيير

لا يمكن إثبات التحسين دون قياس تم إجراؤه مسبقاً. في مرحلة التحليل والتصميم، يتم اختيار ثلاثة إلى خمسة مقاييس وقياسها فعلياً في الوضع الحالي، حتى لو كان القياس يدوياً وخاماً. تفاصيل اختيار المقاييس وكيفية ربطها بفائدة تجارية متوفرة في [دليل عائد الاستثمار ومؤشرات الأداء الرئيسية](/ar/insights/salesforce-roi-kpis).

## مثال توضيحي: سلسلة عيادات خاصة

السيناريو التالي افتراضي ومخصص للتوضيح فقط. شبكة عيادات تضم ثمانية فروع شرعت في مشروع CRM لتركيز استفسارات المرضى. في مرحلة التحليل والتصميم، تبين أن فرعين يعرّفان "الاستفسار المتكرر" بشكل مختلف: أحدهما يحسب كل مكالمة، والآخر يحسب فقط الاستفسارات المتعلقة بموضوع جديد. بدا الاختلاف مجرد خلاف على المعنى، ولكنه حدد ما إذا كان النظام يحتاج إلى كائن Case واحد مع تسلسل هرمي، أم كائنين منفصلين، وحدد جميع تقارير العبء الإداري.

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

## علامات تحذيرية لتحليل وتصميم سطحي

- تصف الوثيقة الشاشات والحقول لكنها لا تصف ما يحدث عندما تفشل العملية.
- لا يوجد قرار موثق تم النظر في بدائل له.
- جميع المتطلبات ذات أولوية عالية.
- لا يوجد اسم شخص بجانب أي عملية، فقط اسم قسم.
- يتجاوز عدد الحقول المطلوبة في شاشة واحدة خمسة وعشرين دون أن يتحقق أحد من يقوم بملئها.

تم تفصيل العلاقة بين التحليل والتصميم السطحي وأنماط الفشل التي تظهر لاحقاً في المشروع في [دليل الأخطاء الشائعة في تنفيذ CRM](/ar/insights/crm-implementation-mistakes)، وتم شرح تأثيرها على الجدول الزمني في [دليل مدة مشروع Salesforce](/ar/insights/salesforce-project-timeline).

## عند استبدال نظام قائم

عندما يحل المشروع محل نظام CRM قديم، فإن مرحلة التحليل والتصميم تتضمن مهمة إضافية: تحديد ما لن ينتقل. نظام قديم يجمع حقولاً، وأتمتة، وتقارير لا يستخدمها أحد، ونقلها بشكل أعمى يعني نقل الدين القديم إلى منصة جديدة. تم تفصيل التسلسل الموصى به للإجراءات في مثل هذا الانتقال في [دليل استبدال CRM بـ Salesforce](/ar/insights/replace-crm-with-salesforce).

## كيف تعرف متى يمكنك البدء بالبناء

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

الخطوة الطبيعية التالية هي ترجمة المخرجات إلى خطة موجات، مع قرار واضح بشأن ما سيتم تضمينه في الموجة الأولى وما سيتم تأجيله بوعي.

### أسئلة وأجوبة
**كم يجب أن تستغرق مرحلة تصميم CRM قبل مشروع Salesforce؟**
لا يوجد رقم واحد ثابت، ولكن هناك نسبة معقولة: تميل مرحلة التصميم إلى استغراق ما بين عُشر وخُمس إجمالي وقت المشروع، وتعتمد بشكل أساسي على عدد العمليات التي تعبر الإدارات وعدد الأنظمة المصدرية. التصميم الذي يستغرق وقتًا أطول من ذلك لا يعاني عادةً من نقص الوقت، بل من غياب جهة مخولة لاتخاذ القرارات بين الآراء المختلفة.

**ما الفرق بين تصميم CRM ووثيقة المتطلبات؟**
وثيقة المتطلبات تصف ما طلبه المستخدمون. التصميم يصف العملية التجارية التي ستشتغل، وعلى أي نموذج بيانات، وبأي صلاحيات، ومع أي أنظمة، وكيف سيتم إثبات فعاليتها. نفس المتطلب يمكن تنفيذه بخمس طرق مختلفة في Salesforce، ودور التصميم هو الاختيار بينها وتبرير هذا الاختيار.

**هل يمكن إجراء التصميم مع المورد الذي سينفذ لاحقًا؟**
ممكن، وفي كثير من الحالات يكون فعالاً. يكمن الخطر في أن يميل التصميم نحو ما هو مريح للمورد للبناء. يمكن تقليل هذا الخطر من خلال تسليم المخرجات للمنظمة بصيغة غير احتكارية، وتبرير القرارات المعمارية مع البدائل التي تم النظر فيها، وفصل تسعير مرحلة التصميم عن تسعير التنفيذ.

**ماذا نفعل عندما يختلف أصحاب العملية حول تعريف العملية؟**
لا تغلق الخلاف بنص غامض. قم بتدوينه كقرار مفتوح مع تحديد المسؤول، وتاريخ الاستحقاق، وتأثيره على نطاق المشروع (Scope)، ورفعه إلى الجهة المخولة باتخاذ القرار. التصميم الذي يصوغ إجماعًا مزيفًا يؤدي لاحقًا إلى طلبات تغيير مكلفة في مرحلة يكون فيها الكود قد تم بناؤه.

**هل يجب تصميم جميع العمليات قبل البدء بالبناء؟**
لا. يجب تصميم العمليات التي ستدخل في المرحلة الأولى بعمق، ورسم خريطة للعمليات الأخرى على مستوى العناوين لتجنب عرقلة النموذج لاحقًا. الشيء الوحيد الذي يجب تحديده مسبقًا للصورة الكاملة هو نموذج البيانات الأساسي ونموذج الصلاحيات، لأن تغييرها لاحقًا مكلف أكثر بكثير من تغيير شاشة.

---

## 10 أخطاء شائعة في تطبيق Salesforce وأنظمة إدارة علاقات العملاء (CRM) وكيفية تجنبها
URL: https://hpi.pro/ar/insights/crm-implementation-mistakes
معظم الإخفاقات في مشاريع CRM ليست أعطالاً فنية، بل هي قرارات مؤجلة. نقدم هنا عشرة أخطاء متكررة في مشاريع Salesforce، مع العلامات المبكرة التي تكشف كل خطأ في وقته، والإجراء الوقائي قليل التكلفة عند تنفيذه مبكراً وشديد التكلفة عند تأخيره لما بعد مرحلة الانطلاق (Go Live).

## كيفية قراءة هذه القائمة

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

## 1. البدء بقائمة الميزات بدلاً من العملية

**العلامة:** وثيقة المتطلبات مصممة كجدول من القدرات المطلوبة، ولا يصف أي سطر فيها نتيجة عمل.

**ما يحدث فعليًا:** ينتج المشروع نظامًا يلبي القائمة ولا يغير طريقة العمل. بعد عام، تسأل الإدارة عما تغير، ولا توجد إجابة قابلة للقياس.

**الوقاية:** لكل متطلب، يتم ربطه بالعملية التي يخدمها والمقياس الذي يُتوقع أن يتأثر. أي متطلب لا يملك إجابة لهذين السؤالين يُنقل إلى قائمة الانتظار. سيتم تفصيل مجموعة المخرجات التي تمنع هذا النمط في [دليل اكتشاف CRM](/ar/insights/crm-discovery-guide).

## 2. عدم وجود مالك عملية واحد

**العلامة:** في الاجتماعات، يحضر أربعة أشخاص من نفس القسم، ولا يملك أي منهم صلاحية اتخاذ قرار نهائي بالقول "هكذا سيكون الأمر".

**ما يحدث فعليًا:** يتم إغلاق كل قرار بتسوية تحاول إرضاء الجميع، مما يعني بناء مسارين بدلاً من مسار واحد. يصبح النظام معقدًا بضعف ما هو مطلوب.

**الوقاية:** تسمية شخص واحد كمالك لكل عملية. تفصيل الأدوار الموصى بها في [دليل فريق مشروع Salesforce](/ar/insights/salesforce-project-team-roles).

## 3. تأجيل القرارات المعمارية إلى النهاية

**العلامة:** الفريق يتقدم في بناء الشاشات بينما لا يزال السؤال حول "ما هو مصدر الحقيقة للعميل" مفتوحًا.

**ما يحدث فعليًا:** عندما يتم اتخاذ القرار أخيرًا، فإنه يتعارض مع ما تم بناؤه. يتم التخلي عن جزء من العمل، ويصبح التقدير المبدئي للمشروع غير ذي صلة.

**الوقاية:** في البداية، يتم تحديد أهم ثلاثة إلى خمسة قرارات يكلف تغييرها الكثير – مثل نموذج البيانات الأساسي، مصدر الحقيقة، نموذج الصلاحيات – وتعيين تاريخ لقرارها قبل بدء البناء.

## 4. استيراد ديون النظام القديم

**العلامة:** مواصفات ترحيل البيانات تحتوي على جميع حقول النظام السابق، بما في ذلك تلك التي ينتهي اسمها بـ "_old_2".

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

**الوقاية:** يجب أن يكون لكل حقل يتم ترحيله مالك واستخدام مثبت في العام الأخير. يتم نقل الباقي إلى أرشيف قابل للقراءة وليس إلى النظام المباشر.

## 5. قياس التقدم بالقصص المكتملة

**العلامة:** يعرض التقرير الأسبوعي نسب إنجاز عالية، لكن لم يتمكن أحد بعد من تشغيل عملية كاملة من البداية إلى النهاية.

**ما يحدث فعليًا:** يظهر المشروع في الرسم البياني كنجاح حتى الأسبوع الذي يسبق الإطلاق، ثم يتضح أن جميع الأجزاء تعمل بشكل منفصل ولم يختبر أحد الاتصال.

**الوقاية:** تحديد معلم "أول عملية مباشرة من البداية إلى النهاية" في أقرب وقت ممكن، حتى لو كان يغطي سيناريو واحدًا فقط. حتى يتم تحقيق ذلك، لا تعتبر نسب الإنجاز معلومات ذات قيمة.

## 6. الحقول الإلزامية كبديل لانضباط البيانات

**العلامة:** تتضمن شاشة إنشاء سجل اثني عشر حقلًا إلزاميًا، ثلاثة منها لا يعرف أحد من المفترض أن يعرف قيمتها.

**ما يحدث فعليًا:** يختار المستخدمون القيمة الأولى في القائمة للمتابعة. تتلقى التقارير بيانات كاملة تمامًا وخاطئة تمامًا.

**الوقاية:** الإلزام لا يفرض إلا على حقل مطلوب لاتخاذ قرار في النقطة التي يُسأل فيها. الحقول المطلوبة في وقت لاحق من العملية يجب أن تكون إلزامية في تلك المرحلة.

## 7. بناء الأتمتة قبل استقرار العملية

**العلامة:** توجد ثلاث آليات أتمتة تعمل على نفس الكائن، ولا يعرف أحد ترتيب تشغيلها.

**ما يحدث فعليًا:** آثار جانبية غير متوقعة، حلقات تحديث، والأهم من ذلك، عدم القدرة على تغيير عملية دون القلق من ما سيتعطل.

**الوقاية:** تشغيل عملية يدوية أو شبه يدوية لعدة أسابيع قبل أتمتتها. الأتمتة تثبت قرارًا – من الأفضل أن يكون القرار صحيحًا.

## 8. اختبار UAT يتم إجراؤه بواسطة من قام بالبناء

**العلامة:** سيناريوهات الاختبار كتبها نفس الفريق الذي قام بالتطوير، وهي تغطي بشكل أساسي المسار الصحيح.

**ما يحدث فعليًا:** الأخطاء التي تصل إلى مرحلة الإنتاج هي الحالات الشاذة – الإلغاءات، الاعتمادات، العميل المكرر، المستخدم الذي غادر في منتصف العملية.

**الوقاية:** يتم تنفيذ الاختبارات من قبل أصحاب العملية، على بيانات شبيهة بالبيانات الحقيقية، وبمسؤولية محددة للموافقة أو الرفض.

## 9. التدريب كحدث لمرة واحدة

**العلامة:** تتضمن خطة التنفيذ ورشتي عمل في الأسبوع الذي يسبق الإطلاق، ولا يوجد شيء بعد ذلك.

**ما يحدث فعليًا:** يتعلم المستخدمون الشاشات وليس العملية، ينسون في غضون أسبوعين، ويلجأون إلى الزملاء أو إلى جدول Excel. ينخفض معدل الاستخدام تدريجيًا دون أن يلاحظ أحد.

**الوقاية:** تدريب حسب الدور، أقرب ما يمكن إلى الوقت الذي يقوم فيه الموظف بالعمل فعليًا، مع نقطة دعم متاحة في الأسابيع الأولى.

## 10. عدم وجود ملكية بعد الإطلاق (Go Live)

**العلامة:** لا يوجد في خطة المشروع بند يصف من يدير النظام في الشهر الثالث.

**ما يحدث فعليًا:** تتراكم طلبات التغيير دون استجابة، وتتحول الأخطاء الصغيرة إلى ممارسة عمل التفافية، ويتقادم النظام بسرعة.

**الوقاية:** تحديد ملكية تشغيلية، وآلية لاستقبال الطلبات، ومعدل إطلاق ثابت قبل الإطلاق وليس بعده. في المؤسسات الكبيرة، يتم ذلك عادة من خلال نموذج حوكمة منظم، كما هو موضح في [دليل تطبيق Salesforce في مؤسسة Enterprise](/ar/insights/enterprise-salesforce-implementation).

## تكلفة التصحيح حسب المرحلة

| الخطأ | التصحيح في التصميم | التصحيح في البناء | التصحيح بعد الإطلاق (Go Live) |
|---|---|---|---|
| نموذج بيانات خاطئ | تغيير في الرسم البياني | إعادة بناء الكائن | ترحيل داخلي واختبار كامل متكرر |
| عدم وجود مالك للعملية | تعيين | توقفات وقرارات متكررة | عملية مزدوجة يتم صيانتها إلى الأبد |
| دين من النظام القديم | تصفية قائمة الحقول | تنظيف قبل التحميل | تنظيف على نظام مباشر |
| حقول إلزامية غير ضرورية | قرار في تصميم الشاشة | تغيير التكوين | تنظيف البيانات الخاطئة المتراكمة |
| عدم وجود ملكية تشغيلية | التحديد في الخطة | التوظيف أو التدريب | استعادة ثقة المستخدمين |

## مثال للتوضيح: شركة تأمين متوسطة الحجم

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

لم يكن التصحيح تقنيًا. تم حذف ستة حقول إلزامية، وتم تعيين مالك عملية واحد من قسم العمليات، وتم تقسيم التدريب إلى أقسام قصيرة تم إرسالها في الأسبوع الذي بدأت فيه كل مجموعة العمل. كان التغيير المعماري الوحيد المطلوب هو تأجيل إلزامية حقلين إلى مرحلة لاحقة في العملية.

## ماذا تفعل بهذه القائمة

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

### أسئلة وأجوبة
**ما هو الخطأ الأكثر تكلفة في إصلاحه عند تطبيق Salesforce؟**
الخطأ في نموذج البيانات الأساسي. يتطلب تغيير الكائن الذي يحتفظ بالعملية التجارية بعد تحميل البيانات وبناء الأتمتة والتقارير ترحيلاً داخلياً، وإعادة كتابة المنطق، وإعادة فحص الصلاحيات. في المقابل، تُصلح أخطاء واجهة المستخدم عادة في غضون أيام.

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

**متى يتم اكتشاف فشل التطبيق عادةً؟**
عادة بين الشهر الثاني والرابع بعد مرحلة الانطلاق (Go Live)، عندما ينتهي الدعم المكثف. حتى ذلك الحين، يستفيد المستخدمون من التوجيه الوثيق وترى الإدارة نشاطًا. العلامة الحقيقية هي الانخفاض المستمر في تحديث السجلات بالتوازي مع زيادة استخدام ملفات Excel الخارجية.

**هل يمكن إصلاح مشروع Salesforce تم إطلاقه بالفعل وبه عيوب؟**
في معظم الأحيان نعم، لكن ترتيب الإجراءات يختلف عن المشروع الجديد. أولاً، يتم تثبيت ما يعطل العمل اليومي، ثم تُنظف البيانات، وفقط في النهاية نعود لإعادة تخطيط العمليات. محاولة إصلاح كل شيء بالتوازي بينما النظام قيد الاستخدام عادة ما يطيل الأزمة.

**من المسؤول عن منع هذه الأخطاء — المنظمة أم المورد؟**
معظمها يمكن تجنبها فقط بالتعاون. يمكن للمورد الإشارة إلى مخاطر معمارية، لكنه لا يستطيع تحديد من هو مالك العملية في المنظمة، أو ما هي المعلومات التي تعتبر موثوقة، أو من هو المخول بالتنازل عن متطلب. المشاريع التي تفشل عادة ما تعاني من غياب جهة تنظيمية ذات سلطة اتخاذ القرار، وليس من نقص المعرفة التقنية.

---

## خدمات Salesforce: كيف تختار بين التوصيف، التنفيذ، الفحص الشامل (Health Check) والدعم المستمر
URL: https://hpi.pro/ar/insights/salesforce-services-guide
تتجه معظم المؤسسات إلى المزودين طالبةً "تنفيذًا"، حتى عندما يكون ما يلزمها هو تشخيص أو دعم. اختيار نوع الخدمة الخاطئ هو السبب الشائع لمشاريع تنتهي بنتيجة لم يطلبها أحد. هنا تجدون خريطة مبنية على الأعراض: ماذا تطلب في كل حالة، ما هي النتيجة المتوقعة، وما هي علامات التحذير.

## المشكلة تبدأ بالطلب، لا بالتنفيذ

عندما يتواصل أي كيان تجاري مع مورد لخدمات Salesforce، غالبًا ما يكون الطلب الأولي هو "عرض أسعار للتنفيذ". في العديد من الحالات، لا يكون هذا هو الطلب الصحيح. فبعض الكيانات التجارية لديها أنظمة قائمة وتفتقر إلى التشخيص المناسب؛ بينما لا يعرف البعض الآخر العمليات التي يرغبون في تطبيقها؛ وهناك كيانات أخرى تعمل أنظمتها بشكلٍ معقول لكنهم يفتقرون إلى الملكية المستمرة.

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

## تحديد سريع حسب العرض

| ما تقولونه | ما هو المطلوب على الأرجح | المنتج الرئيسي |
| --- | --- | --- |
| "نحن نعمل باستخدام Excel ونرغب في التنظيم" | التحليل ثم التنفيذ على مراحل | خرائط العمليات، نموذج البيانات، المرحلة الأولى في الإنتاج |
| "لدينا Salesforce ولكن لا أحد يستخدمه" | فحص سلامة النظام وخطة التبني | تقرير منظم للمشكلات وتحديد أولوياتها وخطة إصلاح |
| "النظام بطيء ومعطل بعد سنوات" | التشخيص التقني وخطة معالجة الديون التقنية | تحديد الديون التقنية، توصية إعادة الهيكلة أو إعادة البناء |
| "المشروع متوقف منذ ستة أشهر" | إنقاذ المشروع | تقييم الوضع، قرار المتابعة، خطة الاستقرار |
| "نحتاج إلى شخص للعناية المستمرة بالنظام" | خدمات المتابعة أو الخدمات المدارة | اتفاقية مستوى الخدمة (SLA)، وتيرة الإصدارات، نقطة استقبال الطلبات |
| "يريد الرئيس التنفيذي معرفة ما إذا كانت Salesforce مناسبة" | استشارة قصيرة، وليست مشروعًا | تقييم وتوصية بالملاءمة |

تغطي هذه الطاولة معظم الحالات. يوضح بقية المقال ما يجب طلبه بالضبط في كل خدمة.

## الخدمة 1: الاستشارات والتحليل

متى تطلب هذه الخدمة: عندما لا يكون من الواضح بعد ما هي العملية، وما هو مصدر الحقيقة، وما هي حدود المشروع؛ أو عندما يكون هناك نزاع داخلي بين الأقسام.

ما يجب أن يتضمنه المنتج: خريطة عملية على مستوى القرار، نموذج بيانات أساسي، نموذج صلاحيات، خريطة أنظمة، معايير قبول ومؤشرات أساسية. المنتج الذي لا يشمل النقاط الخمس الأولى ليس تحليلًا بل ملخص اجتماعات.

نطاق العمل النموذجي: ما بين أسبوعين وثمانية أسابيع، اعتمادًا على عدد العمليات المتعددة الأقسام. ما يجب الحصول عليه بالضبط وكيفية التعرف على استشاري جيد مفصل في [دليل استشارات Salesforce](/ar/insights/salesforce-consulting-guide).

## الخدمة 2: التنفيذ والتطبيق

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

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

علامة تحذير: عرض يفصل عدد ساعات التطوير ولكنه لا يفصل ما يعتبر "مكتملًا".

## الخدمة 3: فحص السلامة (Health Check) والتشخيص

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

ما يجب أن يتضمنه المنتج: قائمة بالنتائج مع تحديد درجة الخطورة، والتأثير التجاري، وجهد الإصلاح، والترتيب الموصى به. إن التقرير الذي يعدد خمسين نتيجة دون تحديد أولويات ليس ذا فائدة؛ بينما التقرير الذي يقول "ابدأ بإصلاح هذه الثلاثة ولا تلمس البقية بعد" هو منتج ذو قيمة.

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

## الخدمة 4: المتابعة، الدعم، والخدمات المدارة

متى تطلب هذه الخدمة: عندما يكون النظام قيد الإنتاج ولا يوجد فريق داخلي يمكنه تحمل الملكية المستمرة.

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

بالإضافة إلى ذلك: أوقات الاستجابة وفقًا لدرجة الخطورة، وتيرة إصدارات ثابتة، وملكية الوثائق.

## الدمج الصحيح بين الخدمات

لا تستخدم معظم الكيانات التجارية خدمة واحدة فقط، بل تسلسلًا من الخدمات. يبدو التسلسل الصحي على النحو التالي:

1. استشارة قصيرة لاتخاذ قرار المواءمة – أيام، لا أسابيع.
2. تحليل مركز على المرحلة الأولى.
3. تنفيذ على مراحل.
4. فترة استقرار محددة بعد التشغيل.
5. متابعة مستمرة.
6. فحص دوري للسلامة، ويفضل ألا يتم من قبل الطرف الذي قام بالبناء.

النقطة السادسة هي الأكثر تجاهلًا، وهي الأقل تكلفة.

## مثال توضيحي: سلسلة فنادق بوتيك

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

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

## علامات التحذير عند طلب الخدمة

- العرض يسعر الساعات ولكنه لا يحدد المنتج النهائي.
- يتضمن العرض نفسه التحليل والتنفيذ بمبلغ واحد دون وجود معلم يسمح بالتوقف.
- لا توجد فترة ضمان محددة بعد التسليم.
- لا يوجد بند لنقل المعرفة والوثائق تحت ملكية الكيان التجاري.
- يرفض المورد تقديم رأي معماري قبل التوقيع.

تتوفر الأدوات اللازمة لفحص المورد نفسه—وليس فقط الخدمة—في [دليل اختيار شركة تنفيذ Salesforce](/ar/insights/choose-salesforce-implementation-company).

## من الطلب إلى المستند

بعد تحديد الخدمة المطلوبة، تتمثل الخطوة التالية في صياغتها بحيث تكون العروض المستلمة قابلة للمقارنة. يتوفر هيكل وثيقة الطلب وقائمة الأسئلة التي يجب تضمينها في [دليل طلب العروض (RFP) لتنفيذ Salesforce](/ar/insights/salesforce-rfp-guide)، وتفاصيل البنود التي يجب أن تدرج في العقد نفسه متوفرة في [دليل العقد وبيان العمل (SOW)](/ar/insights/salesforce-sow-contract-clauses).

## الخطوة التالية

قبل طلب عرض أسعار، اكتب في جملة واحدة العرض—وليس الحل. فجملة "ليس لدينا رؤية موحدة للعملاء بين المبيعات والخدمة" تؤدي إلى طلب يختلف عن "نريد Salesforce". هذه الجملة تساوي أكثر من أي وثيقة متطلبات ستُكتب بعدها.

### أسئلة وأجوبة
**ما الفرق بين التوصيف (Specification) و Discovery في عروض مزودي Salesforce؟**
لدى معظم المزودين في المنطقة، تُستخدم المصطلحات بالتبادل، ولذلك من المهم فحص المخرجات وليس العناوين. ينتهي Discovery الاحترافي بنموذج بيانات أساسي، ونموذج صلاحيات، وخريطة للأنظمة، ومعايير قبول. إذا كان العرض يعد بـ "ورش عمل توصيف" دون تفصيل لنتائج قابلة للقياس، فأنت تشتري ساعات عمل وليس مستندًا.

**هل يمكن طلب 'Health Check' فقط دون الالتزام بالمتابعة؟**
نعم، وهذا هو الوضع المثالي. 'Health Check' هي خدمة مستقلة تُخرِّج تقرير نتائج مرتبة حسب الأولوية. إذا كان المزود يشترط الالتزام بالتنفيذ لإجراء الفحص، ينشأ تضارب مصالح: نفس الجهة تشخّص وتبيع العلاج. من الأفضل فصل الفحص عن الإصلاح، على الأقل تجاريًا.

**مؤسسة صغيرة — هل تحتاج إلى خدمة خارجية على الإطلاق أم يكفي وجود Admin؟**
يكفي وجود Admin داخلي للصيانة، وتغييرات التهيئة، والدعم. ولكنه عادةً لا يكفي للقرارات التي تحدد البنية المعمارية: نموذج البيانات الأساسي، نموذج الكشف، الحدود بين الأنظمة. القاعدة العملية هي الاستعانة بدعم خارجي للقرارات التي يكون تغييرها مكلفًا لاحقًا، وترك البقية داخل المؤسسة.

**ما هي 'Managed Services' لبيئة Salesforce في الواقع؟**
نموذج يكون فيه مزود خارجي مسؤولاً عن الصيانة الدورية، واستقبال طلبات التغيير، والإصدارات الدورية، والمراقبة، ضمن نطاق ساعات متفق عليه. يناسب هذا النموذج المؤسسات التي لا تملك فريقًا داخليًا، ولكنه يتطلب تعريفًا دقيقًا للمشمول: إصلاح الأعطال والتطويرات الصغيرة هما أمران مختلفان تمامًا من حيث التكلفة.

**هل يمكن طلب جميع الخدمات من مزود واحد؟**
ممكن وشائع، ولكن يُنصح بفصل مرحلة التوصيف أو الفحص الدوري على الأقل. السبب ليس الشك وإنما التحيز الكامن: المزود الذي نفذ نظامًا يجد صعوبة في تشخيص أن القرار المعماري الذي اتخذه كان خاطئًا. الحصول على رأي ثانٍ في نقاط التحول أرخص مقارنة بتكلفة الإصلاح المتأخر.

---

## استشارات Salesforce: متى تحتاج إلى مستشار وما الذي يجب أن تحصل عليه من العملية
URL: https://hpi.pro/ar/insights/salesforce-consulting-guide
تُطلب استشارة Salesforce بشكل أساسي في النقاط التي يكون فيها الخطأ باهظ التكلفة عند التصحيح، وليس لكل سؤال تقني. تحدد المقالة خمسة محفزات تبرر الاستشارة الخارجية، وتميز بين المستشار، والمهندس المعماري، والمسؤول، وتفصل المخرجات التي بدونها تكون قد دفعت مقابل الاجتماعات وليس مقابل القرارات.

## متى تكون الاستشارات الخارجية ذات قيمة ومتى تكون إهدارًا للموارد

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

خمسة محفزات تبرر الاستعانة باستشارات خارجية:

1.  **قرار المنصة** — هل Salesforce مناسبة من الأساس، وما هي البدائل المتاحة؟
2.  **قرار معماري يصعب الرجوع عنه** — نموذج البيانات الأساسي، استخدام منظمة واحدة (Org) مقابل عدة منظمات، مصدر الحقيقة (Source of Truth).
3.  **خلاف داخلي بين الوحدات** لا يوجد له حَكَم طبيعي.
4.  **مشروع متعثر** يتطلب طرفًا غير منخرط سياسيًا لتحديد الأسباب.
5.  **وضع يسبق التزامًا تجاريًا كبيرًا** — قبل توقيع عرض بملايين الشيكلات (ملايين الشواقل)، يعتبر رأي مستقل استثمارًا غير مكلف نسبيًا.

ما لا يبرر الاستعانة بالاستشارات: إضافة حقول، بناء تقارير، أسئلة التشغيل اليومي. هذه مهام مسؤول النظام (Admin)، والاستشارات التي تنحرف نحو هذه المهام سرعان ما تتحول إلى تعزيز مكلف للقوى العاملة.

## ثلاثة أدوار غالبًا ما يتم الخلط بينها

| الدور       | السؤال الذي يجيب عليه                    | الأفق           | عند طلبه بشكل غير صحيح        |
| :---------- | :--------------------------------------- | :-------------- | :----------------------------- |
| استشاري     | ما هو الإجراء الصحيح وما ترتيبه          | من شهور إلى سنوات | تحصل على استراتيجية بدلاً من حل لمشكلة |
| مهندس معماري | كيف يتم التنفيذ دون تكبد ديون             | المشروع والنظام | تحصل على تصميم مفصل لمشكلة غير محددة |
| مسؤول نظام | كيف يتم التشغيل والصيانة بشكل يومي       | أسابيع          | تحصل على حل جزئي يثبت قرارًا كبيرًا |

الخطأ الشائع يكمن في الصف الثالث: اتخاذ قرار معماري بواسطة مسؤول نظام (Admin) فعليًا، لأنه جاء كطلب صغير.

## ما يجب الحصول عليه من عملية الاستشارات

عملية الاستشارات التي تنتهي بتقرير ملخص هي عملية لا يمكن العمل بناءً عليها. النتائج التي ينبغي طلبها كتابةً، قبل التوقيع:

-   **وثيقة القرارات** — لكل قرار: السؤال، البدائل التي تم النظر فيها، التوصية، المبررات، والتداعيات إذا تم اتخاذ قرار مختلف.
-   **الافتراضات والتبعيات** — ما افترضه الاستشاري دون التحقق، وماذا سيحدث إذا كان الافتراض خاطئًا.
-   **خريطة مخاطر** مركزة على المنظمة، وليست قائمة عامة.
-   **توصيات بترتيب الإجراءات** مع تبعياتها، وليست قائمة أمنيات.
-   **ما لا يجب فعله** — التوصية السلبية غالبًا ما تكون الجزء الأعلى قيمة، وهي غالبًا ما تكون مفقودة.

الفقرة الأخيرة هي اختبار جودة جيد: الاستشاري القادر على قول "لا تبنوا هذا الآن" يبيع قرارًا، وليس ساعات عمل.

## كيفية تقييم استشاري قبل التعاقد

الأسئلة التي يجب طرحها لا تتعلق بالشهادات ولكن بمنهجية التفكير:

-   صف قرارًا معماريًا أوصيت به ثم ندمت عليه. ماذا تعلمت؟
-   في أي حالة توصي بعدم استخدام Salesforce؟
-   كيف تقرر بين التكوين (Configuration) والتطوير (Development)؟
-   ماذا تطلب من المنظمة لنجاح الاستشارات، وماذا يحدث إذا لم تحصل على ذلك؟
-   من يتولى صيانة المنتج لديكم بعد مغادرتك؟

تتوفر مجموعة أوسع من الأسئلة لتقييم المورد في [دليل الأسئلة قبل اختيار شركة تكامل Salesforce](/ar/insights/questions-before-choosing-salesforce-integrator).

## تضارب المصالح — ليس دائمًا سيئًا، ولكن يجب دائمًا معرفته

المورد الذي يقدم الاستشارات ثم يتولى التنفيذ ليس بالضرورة مشكلة؛ أحيانًا تكون هذه هي الطريقة الأكثر فعالية، لأن المعرفة لا تضيع أثناء النقل. تبدأ المشكلة عندما تؤثر التوصية على نطاق عمل نفس الجهة ولا توجد آلية توازن.

ثلاث آليات توازن بسيطة:

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

الآلية الثالثة هي الأكثر فعالية، وهي التي تولد أكثر المحادثات فائدة.

## مثال توضيحي: شركة بنية تحتية مملوكة للدولة

السيناريو افتراضي ولغرض التوضيح. كانت شركة بنية تحتية تدرس مشروع CRM كبير لإدارة استفسارات الجمهور واستفسارات الجهات الحكومية. قدم موردان هيكلاً معماريًا يتضمن منظمة Salesforce منفصلة لكل من الجمهورين، بحجة فصل المعلومات التنظيمية.

قامت الاستشارات الخارجية التي تم التعاقد معها بفحص المتطلب التنظيمي نفسه ووجدت أنه يتطلب فصل الوصول (Access Separation)، وليس فصل الأنظمة (System Separation). غيّر هذا الاستنتاج الصورة التجارية بالكامل: منظمة واحدة (Org) ذات نموذج تعرض دقيق بدلاً من بيئتين تتطلبان التزامن والصيانة المزدوجة.

لم يكن الناتج الأكثر قيمة في هذه العملية هو التوصية بما يجب بناؤه، بل إثبات أن الافتراض الأساسي لكلا العرضين لم يتم التحقق منه.

## كيف يرتبط هذا بالقرار التجاري

تغيّر استشارة جيدة ما تطلبونه من الموردين، ولذلك يجب أن تأتي قبل العروض وليس بعدها. من هنا ينتقل القرار إلى مستويين: اختيار نموذج التسعير المناسب لمستوى عدم اليقين المتبقي، كما هو مفصل في [دليل تسعير مشاريع Salesforce](/ar/insights/salesforce-project-pricing-models)، والمقارنة بين العروض التي سُتستلَم، كما هو مفصل في [دليل مقارنة العروض](/ar/insights/compare-salesforce-proposals).

تتركز معايير تقييم الشركة التي ستقوم بالعمل الفعلي في [دليل اختيار شركة التنفيذ](/ar/insights/choose-salesforce-implementation-company).

## اختبار سريع قبل طلب الاستشارات

أجب عن ثلاثة أسئلة: ما القرار الذي تحتاج إلى اتخاذه، من سيوافق عليه داخل المنظمة، وماذا سيحدث إذا اتخذته بشكل خاطئ؟ إذا كانت الإجابة على السؤال الثالث هي "سنقوم بالتصحيح لاحقًا بتكلفة منخفضة" — فمن المرجح أنك لا تحتاج إلى استشاري. إذا كانت الإجابة هي "سنعيد البناء من جديد" — فهذه هي النقطة التي تسترد فيها الاستشارات الخارجية تكلفتها تمامًا.

### أسئلة وأجوبة
**ما الفرق بين مستشار Salesforce ومهندس Salesforce المعماري؟**
يتعامل المستشار مع سؤال "ماذا يجب أن نفعل وبأي ترتيب؟"، بما في ذلك الاعتبارات التجارية والتنظيمية والتسويقية. أما المهندس المعماري فيتعامل مع سؤال "كيف ننفذ ذلك بشكل صحيح على المنصة؟" من حيث نموذج البيانات، العرض، حدود النظام، والسلامة التقنية. في المشاريع الصغيرة، يقوم نفس الشخص بالدورين، ولكن في القرارات الكبيرة، يُفضل وجود منظورين مختلفين.

**كم يجب أن تستغرق عملية استشارة Salesforce؟**
تُقاس الاستشارة لغرض اتخاذ قرار بشأن الملائمة عادةً ببضعة أيام. أما الاستشارة التي تصاحب التصميم فتُقاس بالأسابيع. الاستشارة التي تستمر لأشهر دون نتيجة قرار هي عادةً ليست استشارة بل تعزيز للقوى العاملة، ويجب تسعيرها وإدارتها على هذا الأساس.

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

**ماذا نفعل عندما يوصي المستشار بحل يعارضه الفريق الداخلي؟**
اطلب عرض التوصية مع البدائل التي تم النظر فيها ومع معيار اتخاذ القرار، وليس كاستنتاج نهائي. غالبًا ما تستند مقاومة الفريق الداخلي إلى معرفة سياقية لم يتعرض لها المستشار. إذا استمر الخلاف بعد عرض البدائل، فإن هذا قرار الجهة التي تتحمل المخاطر، وليس الجهة التي تكون "على صواب" مهنياً.

**كم تكلفة استشارة Salesforce في الشرق الأوسط؟**
يعتمد السعر على حجم الساعات، ومستوى الخبرة، والمسؤولية التي يتحملها المستشار عن النتائج، ويختلف بشكل كبير بين المزودين. ما يجب مقارنته ليس السعر بالساعة، بل التكلفة الإجمالية لاتخاذ القرار: استشارة أغلى بالساعة تُنجز في أسبوعين مع وثيقة قرارات قد تكون أرخص من استشارة منخفضة التكلفة تستمر شهرين.

---

## Agentforce Readiness: قائمة تحقق مؤسسية للبيانات، الصلاحيات، والعمليات
URL: https://hpi.pro/ar/insights/agentforce-salesforce-ai-guide
قبل الشروع في بناء وكيلك الأول، من الأجدى الإجابة على سؤال أقل تكلفة: هل المنظمة مستعدة بالفعل؟ يقدم هذا الدليل فحص جاهزية على خمسة محاور – العملية، البيانات، المعرفة، الصلاحيات، والتشغيل – مع درجة لكل محور، وعتبة دنيا للمشروع التجريبي، وكيفية التعامل مع الفجوات المكتشفة.

## الإجابة المختصرة

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

عملية التقييم ليست مجرد سؤال بنعم أو لا. إنها تُنشئ درجة لكل محور وتُظهِر خريطة للفجوات، مما يمكّن من اتخاذ قرار أكثر دقة: البدء، تقليص النطاق (Scope)، أو التأجيل وإغلاق فجوة معينة أولًا.

إطار قرار مدى ملاءمة حالة الاستخدام موضح في [Agentforce للمؤسسات](/ar/insights/agentforce-for-enterprises).

## المحاور الخمسة للجاهزية

| المحور         | السؤال الحاسم                             | علامة الضعف                                   | الحد الأدنى للمشروع التجريبي                 |
| :------------ | :---------------------------------------- | :-------------------------------------------- | :----------------------------------------- |
| العملية       | هل العملية محددة ولها مالك مسؤول؟          | كل فريق ينفذها بشكل مختلف ولا يوجد توثيق     | عملية واحدة موثقة بمالك وحجم معروف            |
| البيانات      | هل الحقول التي سيقرأها الوكيل موثوقة؟    | حقول فارغة أو مملوءة بنص حر                    | 90% اكتمال في الحقول الحاسمة للعملية       |
| المعرفة       | هل يوجد مصدر معتمد للإجابات؟             | مقالات قديمة أو متضاربة                       | 20 مقالًا مُحدَّثًا للسيناريوهات الشائعة |
| الصلاحيات     | هل من الواضح ما الذي يحق لكل مستخدم رؤيته وفعله؟ | صلاحيات واسعة وغير مراقبة                    | ربط ملفات التعريف ومجموعات الصلاحيات بالعملية |
| التشغيل       | من يراقب ويصحح ويوافق على التغييرات؟     | لا يوجد مالك بعد الإطلاق                       | مالك تشغيلي وروتين مراجعة أسبوعي             |

## المحور 1: العملية

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

التقييم العملي: اطلب وصفًا مكتوبًا للعملية من أربعة أشخاص يقومون بتنفيذها. إذا تلقيت أربعة إصدارات مختلفة بشكل جوهري، فإن العملية غير جاهزة لأتمتة الوكيل — إنها جاهزة للتوثيق والاتفاق أولًا.

يجب أن يكون هناك حجم أيضًا. عملية تحدث عشر مرات في الشهر لن تبرر تكلفة البناء والصيانة، حتى لو كانت مزعجة. المرشح الجيد هو عملية ذات حجم كبير، تكرارية عالية، وتنوع في صياغة الاستفسار — وهذا هو بالضبط المكان الذي تُكسر فيه القواعد الصارمة.

## المحور 2: البيانات

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

ثلاثة اختبارات تعطي إجابة سريعة: نسبة الحقول الحرجة المكتملة، عدد السجلات المكررة في الكائن المركزي، ونسبة الحالات التي تأتي فيها المعلومات المطلوبة من نظام خارجي وليس من Salesforce. الاختبار الثالث هو الأكثر مفاجأة – فهو يكشف عن الاعتماد على تكامل لم يتم تخصيص ميزانية له.

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

الترتيب الموصى به لمعالجة فجوات البيانات مفصل في [مقاييس جودة البيانات في Salesforce](/ar/insights/salesforce-data-quality-metrics).

## المحور 3: المعرفة

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

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

## المحور 4: الصلاحيات

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

لكل إجراء سيقوم به الوكيل، يجب تحديد ما إذا كان قابلًا للتراجع. العملية غير القابلة للتراجع – مثل استرداد أموال، إغلاق حالة، إرسال رسالة للعميل – تتطلب نقطة موافقة بشرية في المرحلة الأولى، وبالتالي تؤثر على تصميم العملية وليس فقط على الإعدادات.

تفصيل تخطيط نقاط الموافقة حسب المخاطر موضح في [Human-in-the-Loop في Agentforce](/ar/insights/agentforce-human-in-the-loop).

## المحور 5: التشغيل

الوكيل ليس مشروعًا له تاريخ انتهاء. إنه مكون يتطلب مراقبة المسارات (Traces)، ومعالجة الفشل، وتحديث المحتوى، والتحكم في التكلفة. المؤسسة التي لا يوجد لديها من يقوم بذلك – ولو بدوام جزئي – ستشهد تدهورًا تدريجيًا في الجودة خلال ربع سنة.

الحد الأدنى: وجود مالك تشغيلي مُسمى، وروتين مراجعة أسبوعي للمكالمات الفاشلة، وعملية تغيير متفق عليها لتحديث التعليمات (Instructions)، وميزانية شهرية مراقبة. إذا لم يكن أي من هذه الأربعة موجودًا، فإن الفجوة في هذا المحور أكبر مما تبدو عليه في البداية.

## ترجمة التقييم إلى قرار

| الحالة                             | التفسير                                      | الإجراء الموصى به                                                    |
| :------------------------------- | :------------------------------------------- | :------------------------------------------------------------------- |
| جميع المحاور عند الحد الأدنى وما فوق | جاهزية كاملة                                 | مشروع تجريبي على عملية واحدة بمعايير Go/No-Go                      |
| ضعف في التشغيل فقط                 | يمكن التعويض بالدعم                            | مشروع تجريبي بدعم خارجي وبناء قدرة داخلية بالتوازي                     |
| ضعف في المعرفة فقط                 | فجوة محتوى محددة                             | أربعة إلى ستة أسابيع من تدريب المعرفة (Knowledge)، ثم مشروع تجريبي  |
| ضعف في البيانات أو الصلاحيات         | خطر جوهري                                    | عدم البدء بالوكيل؛ إغلاق الفجوة كمشروع منفصل                       |
| ضعف في ثلاثة محاور أو أكثر          | المؤسسة ليست ناضجة                            | اختيار عملية فرعية أضيق وإعادة التقييم                               |

## سيناريو: مؤسسة مالية اكتشفت أن العملية الخاطئة قد تم اختيارها

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

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

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

## قائمة تحقق الجاهزية

- ☐ تم اختيار عملية مرشحة واحدة بمالك مسؤول.
- ☐ تم قياس الحجم الشهري ومعدل التكرار.
- ☐ تم فحص اكتمال الحقول الحرجة للعملية.
- ☐ تم فحص التكرارات في الكائن المركزي.
- ☐ تم تحديد الاعتمادات على الأنظمة الخارجية.
- ☐ تم رسم خريطة تغطية المعرفة لأكثر عشرين استعلامًا شيوعًا.
- ☐ تم فصل المحتوى الداخلي عن المحتوى المسموح به للعملاء.
- ☐ تم رسم خريطة صلاحيات القراءة والكتابة للعملية.
- ☐ تم تصنيف الإجراءات القابلة للتراجع مقابل غير القابلة للتراجع.
- ☐ تم تحديد مالك تشغيلي وروتين مراجعة بعد الإطلاق.

عندما يتطلب الأمر جهة خارجية لإجراء التقييم وترجمته إلى خارطة طريق (Roadmap)، فإن [خدمة Agentforce وAI](/ar/agentforce-ai) هي المسار العملي للمتابعة.

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

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

**من يجب أن يقود فحص الجاهزية - قسم تكنولوجيا المعلومات أم إدارة الأعمال؟**
يجب أن يقود مالك العملية التجارية، لأنه هو من سيحتاج إلى تبرير النتيجة. يوفر قسم تكنولوجيا المعلومات وأمن المعلومات محاور البيانات والصلاحيات. الفحص الذي يقوده قسم تكنولوجيا المعلومات فقط يميل إلى فحص قدرات المنصة ولا يختبر ما إذا كانت العملية نفسها تستحق الأتمتة.

**ماذا نفعل عندما يكشف الفحص أن المؤسسة غير جاهزة؟**
نحول كل فجوة إلى بند في خارطة الطريق مع مسؤول وتاريخ، ونختار عملية مرشحة بديلة تتطلب تبعيات أقل. في معظم الحالات، توجد عملية فرعية ضيقة واحدة تستوفي العتبة، وتصبح هي المشروع التجريبي بينما يتم سد الفجوات الكبيرة بالتوازي.

**هل يجب شراء ترخيص Agentforce قبل الفحص؟**
لا. فحص الجاهزية يتعامل مع العملية، البيانات، والصلاحيات – وكل هذه الأمور موجودة بغض النظر عن الترخيص. الشراء قبل معرفة أي حالة استخدام ناضجة يؤدي إلى تراخيص غير مستخدمة والحاجة إلى إظهار النتائج بسرعة كبيرة.

---

## فحص Salesforce Health Check: ماذا نفحص، متى، وما النتائج المتوقعة؟
URL: https://hpi.pro/ar/insights/salesforce-health-check-guide
لا يُعدّ Health Check استبيانًا للآراء حول النظام، بل هو تشخيص قائم على الأدلة: البيانات الوصفية (Metadata)، السجلات (Logs)، بيانات الاستخدام، والمراقبة المباشرة للمستخدمين الفعليين. يستعرض هذا الدليل محاور الفحص السبعة، ومنهجية تصنيف الخطورة، وهيكل التقرير النهائي الذي يمكن الاستناد إليه في اتخاذ القرارات المتعلقة بالميزانية.

## الإجابة المختصرة

إن "فحص الصحة" (Health Check) هو تحليل تشخيصي يستند إلى الأدلة، ويستغرق من أسبوعين إلى ستة أسابيع، وينتهي بثلاثة مخرجات: قائمة بالنتائج مرتبة حسب الخطورة، وخطة "مكاسب سريعة" (Quick Wins) لمدة 30 يومًا، وخارطة طريق (Roadmap) للاستثمارات العميقة. ما يجعله مفيدًا ليس اتساع نطاق المسح، بل الأدلة المرفقة بكل نتيجة — سواء كانت رقمًا، أو سجلًا (Log)، أو تسجيلًا للشاشة — لأنه بدونها يعود النقاش ليصبح جدالًا حول الآراء.

## محاور الفحص السبعة

| المحور | ما يتم فحصه فعليًا | مصدر الدليل |
| --- | --- | --- |
| العملية والاعتماد | هل العملية الموثقة هي نفسها التي تُنفذ؟ | سجل الدخول (Login History)، استخدام الحقول، مراقبة المستخدمين |
| نموذج البيانات | الكائنات (Objects) الزائدة، الحقول غير المستخدمة، العلاقات المزدوجة | استخدام الحقول (Field Usage)، واجهة برمجة تطبيقات البيانات الوصفية (Metadata API)، استعلامات العينة |
| الأتمتة | التداخل بين التدفقات (Flows)، المشغلات (Triggers)، ومُنشئ العمليات القديم (Process Builder) | البيانات الوصفية (Metadata)، سجلات التصحيح (Debug Logs)، تحليل ترتيب التنفيذ |
| الصلاحيات والأمان | الملفات الشخصية (Profiles) المتضخمة، قواعد المشاركة (Sharing Rules) المتعارضة، الوصول الزائد | فحص سلامة الأمان (Security Health Check)، تعيينات مجموعات الصلاحيات (Permission Set Assignments) |
| التكاملات | حدود API، الإخفاقات المتكررة، معالجة الأخطاء | مراقبة الأحداث (Event Monitoring)، سجلات الوسيط (Middleware Logs) |
| الأداء | أوقات التحميل، الاستعلامات الثقيلة، العمليات الدفعية (Batch) المتوقفة | تطبيق استخدام Lightning (Lightning Usage App)، مهام Apex (Apex Jobs) |
| التكلفة والترخيص | التراخيص غير المستغلة (Licenses)، التخزين (Storage)، الخدمات المكررة | تقرير التراخيص، الفاتورة مقارنة بالاستخدام الفعلي |

## كيفية تصنيف الخطورة

إن التصنيف العشوائي يجعل التقرير عديم القيمة. الطريقة الفعالة هي: تحصل كل نتيجة على درجتين تتراوحان بين 1 و 5 — التأثير (ماذا يحدث للعمل إذا لم يتم التعامل معها) والتكرار (كم مرة تحدث في الشهر). حاصل الضرب يحدد الأولوية، وليس تقدير مدى "سوء" الكود. النتيجة التي تحصل على 20 نقطة أو أكثر تُعالج فورًا؛ 12-19 نقطة تُدرج في الربع القادم؛ أقل من 12 نقطة تُسجل ولا تُعالج، إلا إذا كانت تكلفتها منخفضة للإصلاح أثناء عمل آخر.

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

## ما الذي تحصل عليه في النهاية

المخرجات الجديرة بالاهتمام تشمل وثيقة نتائج مع دليل لكل بند، مصفوفة خطورة، خطة 30 يومًا يمكن تنفيذ كل بند فيها دون تغيير معماري، وخارطة طريق للربع أو الربعين القادمين مع تقديرات تقريبية للجهد. بالإضافة إلى ذلك، يتطلب الأمر "سجل قرارات" (Decision Log) يتضمن من ثلاث إلى خمسة قرارات يجب على المنظمة اتخاذها — على سبيل المثال، هل يتم دمج وحدتي عمل في مؤسسة واحدة (Org) — لأنه بدونها تظل خارطة الطريق معلقة.

للتوسع في القرار بعد التشخيص، يمكن الرجوع إلى [إعادة الهيكلة مقابل التحديث](/ar/insights/salesforce-rebuild-vs-refactor) و[تحديد أولويات الديون التقنية](/ar/insights/salesforce-technical-debt-prioritization).

## المخاطر الشائعة والإجراءات الوقائية

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

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

## كيف نقيس النجاح

يعتبر فحص الصحة ناجحًا إذا تم تنفيذ 70% على الأقل من بنود خطة الـ30 يومًا خلال 60 يومًا، وإذا اعتمدت الإدارة ميزانية لاستثمار عميق واحد على الأقل، وإذا تحسنت مؤشرتان تشغيليتان — مثل نسبة فشل التكامل (integration failure rate) أو وقت تحميل شاشة رئيسية — بشكل ملموس مقارنة بالخط الأساسي (Baseline) الذي تم تحديده في بداية التشخيص.

## الخطوة التالية

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

### أسئلة وأجوبة
**كم يستغرق فحص Health Check؟**
لمؤسسة متوسطة لديها بيئة Org واحدة: من أسبوعين إلى ثلاثة أسابيع، منها حوالي أسبوع لجمع الأدلة والمراقبة، وأسبوع للتحليل وكتابة التقرير. قد تتطلب بيئة Org متعددة الوحدات التجارية ذات العشرات من التكاملات (Integrations) من أربعة إلى ستة أسابيع. أبعد من ذلك، لن يكون تشخيصًا بل مشروعًا كاملاً.

**هل يجب منح وصول إداري كامل (Admin access) للجهة الخارجية؟**
ليس بالضرورة. في معظم الفحوصات، يكفي الوصول لمشاهدة الإعدادات والتكوين (View Setup and Configuration)، وعرض جميع البيانات (View All Data) بنطاق محدود، ووصول للقراءة فقط للسجلات (Logs). إذا كانت هناك بيانات حساسة، يتم العمل على بيئة Sandbox مُحدّثة، ويتم استكمال البيانات في بيئة الإنتاج (Production) فقط للمقاييس التي لا يمكن استنساخها.

**ما الفرق بين فحص Health Check والأداة المدمجة Security Health Check؟**
تقوم أداة Salesforce بفحص إعدادات الأمان مقابل خط الأساس (Baseline) وتقديم درجة تقييم. بينما يغطي التشخيص الشامل أيضًا العمليات، ونموذج البيانات، والأتمتة، والتكاملات، ومعدل التبني، والتكلفة — وتعتبر الأداة المدمجة مجرد أحد مدخلاته.

**ماذا نفعل مع مشكلة تتطلب إعادة هيكلة جذرية؟**
لا يتم إدراجها ضمن خطة المكاسب السريعة (Quick Wins). بل تُصنف كقرار استثماري منفصل مع تقدير للجهد المطلوب، ومخاطر التجاهل، وتاريخ مستهدف لإعادة التقييم، وتتم معالجتها بشكل منفصل عن التعامل مع المشاكل العاجلة.

**هل يبرر فحص Health Check نفسه عندما يكون النظام يعمل بشكل جيد؟**
نعم، في حالتين: قبل اتخاذ قرار استثماري كبير، لمعرفة الأساس الذي نبني عليه؛ وبعد سنتين أو ثلاث سنوات من التغييرات التراكمية، عندما لا يمتلك أي شخص رؤية كاملة للأتمتة والصلاحيات.

---

## Trademark Disclosure
Salesforce® and Agentforce® are trademarks of Salesforce, Inc. HPI Pro is an
independent consultancy and does not present itself as an official Salesforce
partner unless explicitly stated on the site.