10 أخطاء شائعة في تطبيق Salesforce وأنظمة إدارة علاقات العملاء (CRM) وكيفية تجنبها

كيفية قراءة هذه القائمة

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

1. البدء بقائمة الميزات بدلاً من العملية

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

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

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

2. عدم وجود مالك عملية واحد

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

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

الوقاية: تسمية شخص واحد كمالك لكل عملية. تفصيل الأدوار الموصى بها في دليل فريق مشروع Salesforce.

3. تأجيل القرارات المعمارية إلى النهاية

العلامة: الفريق يتقدم في بناء الشاشات بينما لا يزال السؤال حول "ما هو مصدر الحقيقة للعميل" مفتوحًا.

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

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

4. استيراد ديون النظام القديم

العلامة: مواصفات ترحيل البيانات تحتوي على جميع حقول النظام السابق، بما في ذلك تلك التي ينتهي اسمها بـ "_old_2".

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

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

5. قياس التقدم بالقصص المكتملة

العلامة: يعرض التقرير الأسبوعي نسب إنجاز عالية، لكن لم يتمكن أحد بعد من تشغيل عملية كاملة من البداية إلى النهاية.

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

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

6. الحقول الإلزامية كبديل لانضباط البيانات

العلامة: تتضمن شاشة إنشاء سجل اثني عشر حقلًا إلزاميًا، ثلاثة منها لا يعرف أحد من المفترض أن يعرف قيمتها.

ما يحدث فعليًا: يختار المستخدمون القيمة الأولى في القائمة للمتابعة. تتلقى التقارير بيانات كاملة تمامًا وخاطئة تمامًا.

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

7. بناء الأتمتة قبل استقرار العملية

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

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

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

8. اختبار UAT يتم إجراؤه بواسطة من قام بالبناء

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

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

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

9. التدريب كحدث لمرة واحدة

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

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

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

10. عدم وجود ملكية بعد الإطلاق (Go Live)

العلامة: لا يوجد في خطة المشروع بند يصف من يدير النظام في الشهر الثالث.

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

الوقاية: تحديد ملكية تشغيلية، وآلية لاستقبال الطلبات، ومعدل إطلاق ثابت قبل الإطلاق وليس بعده. في المؤسسات الكبيرة، يتم ذلك عادة من خلال نموذج حوكمة منظم، كما هو موضح في دليل تطبيق Salesforce في مؤسسة Enterprise.

تكلفة التصحيح حسب المرحلة

مثال للتوضيح: شركة تأمين متوسطة الحجم

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

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

ماذا تفعل بهذه القائمة

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