المشكلة تبدأ بالطلب، لا بالتنفيذ
عندما يتواصل أي كيان تجاري مع مورد لخدمات Salesforce، غالبًا ما يكون الطلب الأولي هو "عرض أسعار للتنفيذ". في العديد من الحالات، لا يكون هذا هو الطلب الصحيح. فبعض الكيانات التجارية لديها أنظمة قائمة وتفتقر إلى التشخيص المناسب؛ بينما لا يعرف البعض الآخر العمليات التي يرغبون في تطبيقها؛ وهناك كيانات أخرى تعمل أنظمتها بشكلٍ معقول لكنهم يفتقرون إلى الملكية المستمرة.
إن طلب نوع خدمة غير ملائم يؤدي إلى مشروع ينتهي بمنتج غير ذي صلة، وغالبًا ما يتضح ذلك بعد مرور أشهر. يوضح هذا الدليل الأنواع الأربعة للخدمات بناءً على العرض الذي يدفع أي كيان تجاري للبحث عن المساعدة.
تحديد سريع حسب العرض
| ما تقولونه | ما هو المطلوب على الأرجح | المنتج الرئيسي |
|---|---|---|
| "نحن نعمل باستخدام Excel ونرغب في التنظيم" | التحليل ثم التنفيذ على مراحل | خرائط العمليات، نموذج البيانات، المرحلة الأولى في الإنتاج |
| "لدينا Salesforce ولكن لا أحد يستخدمه" | فحص سلامة النظام وخطة التبني | تقرير منظم للمشكلات وتحديد أولوياتها وخطة إصلاح |
| "النظام بطيء ومعطل بعد سنوات" | التشخيص التقني وخطة معالجة الديون التقنية | تحديد الديون التقنية، توصية إعادة الهيكلة أو إعادة البناء |
| "المشروع متوقف منذ ستة أشهر" | إنقاذ المشروع | تقييم الوضع، قرار المتابعة، خطة الاستقرار |
| "نحتاج إلى شخص للعناية المستمرة بالنظام" | خدمات المتابعة أو الخدمات المدارة | اتفاقية مستوى الخدمة (SLA)، وتيرة الإصدارات، نقطة استقبال الطلبات |
| "يريد الرئيس التنفيذي معرفة ما إذا كانت Salesforce مناسبة" | استشارة قصيرة، وليست مشروعًا | تقييم وتوصية بالملاءمة |
تغطي هذه الطاولة معظم الحالات. يوضح بقية المقال ما يجب طلبه بالضبط في كل خدمة.
الخدمة 1: الاستشارات والتحليل
متى تطلب هذه الخدمة: عندما لا يكون من الواضح بعد ما هي العملية، وما هو مصدر الحقيقة، وما هي حدود المشروع؛ أو عندما يكون هناك نزاع داخلي بين الأقسام.
ما يجب أن يتضمنه المنتج: خريطة عملية على مستوى القرار، نموذج بيانات أساسي، نموذج صلاحيات، خريطة أنظمة، معايير قبول ومؤشرات أساسية. المنتج الذي لا يشمل النقاط الخمس الأولى ليس تحليلًا بل ملخص اجتماعات.
نطاق العمل النموذجي: ما بين أسبوعين وثمانية أسابيع، اعتمادًا على عدد العمليات المتعددة الأقسام. ما يجب الحصول عليه بالضبط وكيفية التعرف على استشاري جيد مفصل في دليل استشارات Salesforce.
الخدمة 2: التنفيذ والتطبيق
متى تطلب هذه الخدمة: عندما يكون التحليل موجودًا، وأصحاب العمليات معروفون، وقد تم تحديد ما سيتم إدراجه في المرحلة الأولى.
ما يجب أن يتضمنه الاتفاق: تحديد المراحل، معايير القبول لكل مرحلة، المسؤولية عن ترحيل البيانات، آلية طلبات التغيير، فترة الضمان، وخطة نقل المعرفة. يُعد غياب العنصرين الأخيرين السبب الأكثر شيوعًا للاعتماد طويل الأمد على المورد.
علامة تحذير: عرض يفصل عدد ساعات التطوير ولكنه لا يفصل ما يعتبر "مكتملًا".
الخدمة 3: فحص السلامة (Health Check) والتشخيص
متى تطلب هذه الخدمة: عندما يكون النظام قيد التشغيل ولكن هناك مشكلة ما—انخفاض في نسبة التبني، بيانات غير موثوقة، أداء ضعيف، أو عدم القدرة على إجراء تغييرات دون إحداث أعطال.
ما يجب أن يتضمنه المنتج: قائمة بالنتائج مع تحديد درجة الخطورة، والتأثير التجاري، وجهد الإصلاح، والترتيب الموصى به. إن التقرير الذي يعدد خمسين نتيجة دون تحديد أولويات ليس ذا فائدة؛ بينما التقرير الذي يقول "ابدأ بإصلاح هذه الثلاثة ولا تلمس البقية بعد" هو منتج ذو قيمة.
فارق مهم: فحص السلامة ليس مشروع إصلاح. إنه يهدف إلى تمكين اتخاذ قرار بشأن ما يجب إصلاحه وبأي ترتيب.
الخدمة 4: المتابعة، الدعم، والخدمات المدارة
متى تطلب هذه الخدمة: عندما يكون النظام قيد الإنتاج ولا يوجد فريق داخلي يمكنه تحمل الملكية المستمرة.
ما يجب تحديده: ما هو مشمول وما هو غير مشمول. التمييز الحاسم هو بين إصلاح عطل، وتغيير بسيط في الإعدادات، وتطوير قدرة جديدة. العقد الذي يجمع هذه الثلاثة ضمن "بنك ساعات" يميل إلى الانهيار في غضون ربع سنة، لأن تطوير قدرة جديدة يستهلك الساعات المخصصة للدعم.
بالإضافة إلى ذلك: أوقات الاستجابة وفقًا لدرجة الخطورة، وتيرة إصدارات ثابتة، وملكية الوثائق.
الدمج الصحيح بين الخدمات
لا تستخدم معظم الكيانات التجارية خدمة واحدة فقط، بل تسلسلًا من الخدمات. يبدو التسلسل الصحي على النحو التالي:
- استشارة قصيرة لاتخاذ قرار المواءمة – أيام، لا أسابيع.
- تحليل مركز على المرحلة الأولى.
- تنفيذ على مراحل.
- فترة استقرار محددة بعد التشغيل.
- متابعة مستمرة.
- فحص دوري للسلامة، ويفضل ألا يتم من قبل الطرف الذي قام بالبناء.
النقطة السادسة هي الأكثر تجاهلًا، وهي الأقل تكلفة.
مثال توضيحي: سلسلة فنادق بوتيك
السيناريو افتراضي ومخصص للتوضيح. تواصلت سلسلة تضم أربعة فنادق مع ثلاثة موردين تطلب منهم عرض أسعار لتنفيذ Salesforce لإدارة الفعاليات وطلبات الضيوف. كان العرضان الأولان لتنفيذ كامل يستغرق عدة أشهر.
طرح المورد الثالث سؤالًا واحدًا: من يحدد ما يُسمى "حدثًا"—مدير الفعاليات في كل فندق أم المقر الرئيسي. وكانت الإجابة أنه لا يوجد تعريف مشترك. في مثل هذه الحالة، كان التنفيذ الكامل سينتج عنه أربعة أنظمة مختلفة تحت اسم واحد. وبدلًا من ذلك، طلبت السلسلة تحليلًا قصيرًا، وحصلت على تعريف واحد متفق عليه ونموذج بيانات، ثم بدأت بعد ذلك في التنفيذ—بنطاق أصغر مما كان مقترحًا في الأصل.
علامات التحذير عند طلب الخدمة
- العرض يسعر الساعات ولكنه لا يحدد المنتج النهائي.
- يتضمن العرض نفسه التحليل والتنفيذ بمبلغ واحد دون وجود معلم يسمح بالتوقف.
- لا توجد فترة ضمان محددة بعد التسليم.
- لا يوجد بند لنقل المعرفة والوثائق تحت ملكية الكيان التجاري.
- يرفض المورد تقديم رأي معماري قبل التوقيع.
تتوفر الأدوات اللازمة لفحص المورد نفسه—وليس فقط الخدمة—في دليل اختيار شركة تنفيذ Salesforce.
من الطلب إلى المستند
بعد تحديد الخدمة المطلوبة، تتمثل الخطوة التالية في صياغتها بحيث تكون العروض المستلمة قابلة للمقارنة. يتوفر هيكل وثيقة الطلب وقائمة الأسئلة التي يجب تضمينها في دليل طلب العروض (RFP) لتنفيذ Salesforce، وتفاصيل البنود التي يجب أن تدرج في العقد نفسه متوفرة في دليل العقد وبيان العمل (SOW).
الخطوة التالية
قبل طلب عرض أسعار، اكتب في جملة واحدة العرض—وليس الحل. فجملة "ليس لدينا رؤية موحدة للعملاء بين المبيعات والخدمة" تؤدي إلى طلب يختلف عن "نريد Salesforce". هذه الجملة تساوي أكثر من أي وثيقة متطلبات ستُكتب بعدها.
