تصميم CRM قبل Salesforce: المخرجات الأساسية قبل البدء بالتنفيذ

ما يجب أن يكون جاهزاً بعد مرحلة التحليل والتصميم

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

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

المخرج 1: خارطة عمليات بمستوى اتخاذ القرار

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

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

المخرج 2: مسرد مصطلحات الأعمال

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

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

المخرج 3: نموذج بيانات أساسي حاسم

في مرحلة التحليل والتصميم، لا يتم بناء مخطط علاقات الكيانات (ERD) بشكل كامل، ولكن يتم حسم أربع مسائل رئيسية سيكون تغييرها مكلفاً لاحقاً:

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

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

المخرج 4: نموذج الصلاحيات والمشاركة

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

المخرج 5: خارطة الأنظمة ومصادر الحقيقة

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

المخرج 6: معايير القبول للعمليات الأساسية

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

المخرج 7: مقاييس الأساس قبل التغيير

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

مثال توضيحي: سلسلة عيادات خاصة

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

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

علامات تحذيرية لتحليل وتصميم سطحي

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

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

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

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

كيف تعرف متى يمكنك البدء بالبناء

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

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