الإجابة المختصرة
إن التنبؤ ليس نتاج لوحة معلومات فحسب، بل هو نتاج انضباط البيانات. إذا تم تحديث الصفقات مرة واحدة في الأسبوع في مساء يوم اجتماع Pipeline، فلن يؤدي أي تصميم تقرير إلى صورة موثوقة. لذلك، يبدأ العمل على Forecast بأربعة شروط تشغيلية ثم ينتقل إلى العرض.
العلامة الواضحة لعدم استيفاء الشروط سهلة التحديد: وجود جدول بيانات تنبؤ موازٍ. طالما وجد هذا الجدول، فإن المنظمة نفسها تصرح بأن النظام ليس هو مصدر الحقيقة.
الشروط المسبقة الأربعة
| الشرط | المطلوب | ما يحدث بدونه |
|---|---|---|
| تسلسل هرمي صحيح للمستخدمين | Role Hierarchy يعكس الهيكل الفعلي للمبيعات | تنبؤ غير سليم على مستوى المدير |
| تواريخ إغلاق نظيفة | قاعدة تحظر تاريخًا تجاوز أسبوعًا | تنبؤ يتضمن صفقات ميتة |
| فئات متفق عليها | تعريف مكتوب لـ Pipeline, Best Case, Commit | كل مدير يفسرها بشكل مختلف |
| دورة مراجعة منتظمة | اجتماع أسبوعي من داخل النظام | تحديث بأثر رجعي قبل الاجتماعات |
الشرط الرابع هو الذي ينتج الشروط الثلاثة الأولى. بمجرد أن يتم الاجتماع من الشاشة وليس من جدول بيانات، يقوم الممثلون بالتحديث، وإلا فلن تظهر صفقاتهم.
فئات Forecast: أين يقع الحكم البشري
الخلط الشائع هو بين الاحتمالية والفئة. الاحتمالية مستمدة من المرحلة وتستخدم للحساب المرجح - إنها إحصائية. الفئة هي تصريح التزام من شخص.
يفصل التقسيم الصحيح كالتالي: تحدد المرحلة احتمالية تلقائية لا يُسمح لأحد بتجاوزها؛ يصنف مدير الحساب الصفقة على أنها Best Case أو Commit بناءً على معرفته بالعميل؛ ويُسمح لمدير الفريق بتغيير التصنيف في المراجعة، مع التوثيق. بهذه الطريقة نحصل على رقمين ذوي مغزى مختلف - توقع إحصائي والتزام إداري - بدلاً من رقم واحد غامض.
تفاصيل تعريف مراحل المبيعات نفسها، والتي تستمد منها الاحتمالية، موجودة في تطبيق Sales Cloud.
ثلاث لوحات معلومات، وليس ثلاثين
كثرة لوحات المعلومات هي عرض لعدم ثقة أي شخص في اللوحات الموجودة. الهيكل الفعال هو:
- تنبؤ للإدارة العليا - رقم واحد للربع مع تقسيم حسب الفئة، مقارنة بالهدف، واتجاه أسبوعي. بدون تفصيل الصفقات.
- Pipeline لإدارة الفريق - صفقات حسب المرحلة والعمر، مع إبراز الحالات الشاذة: الصفقات التي لم تتحرك، التواريخ الماضية، المبالغ المتغيرة.
- قائمة عمل للممثل - ما الذي يتطلب اتخاذ إجراء اليوم. ليست تقريرًا بل قائمة انتظار عمل.
الاختبار البسيط: إذا كانت لوحتا معلومات تعرضان نفس الرقم بقيم مختلفة، فواحدة منهما على الأقل زائدة أو خاطئة.
قياس دقة التنبؤ
هذا هو المقياس الذي لا تقيسه معظم المؤسسات، وبالتالي لا تعرف ما إذا كانت قد تحسنت:
- انحراف Commit - الفرق بين مبلغ الـ Commit في بداية الربع والنتيجة الفعلية. انحراف يزيد عن 20% يشير إلى تعريف Commit فضفاض.
- استقرار التنبؤ - كم تغير التنبؤ من أسبوع لآخر. التقلبات العالية تدل على تحديث متأخر، وليس على سوق ديناميكي.
- Slippage (الانزلاق) - الصفقات التي تم تأجيلها للربع التالي. نسبة عالية تدل على معايير مرحلة ضعيفة.
- الدقة حسب الممثل - يكشف من يبالغ بشكل منهجي ومن متحفظ، مما يسمح بتصحيح فردي بدلاً من عامل تصحيح شامل.
تظهر المقاييس التكميلية للاعتماد في مقاييس اعتماد Salesforce.
الخطأ المتكرر: بناء تقرير بدلاً من إصلاح العملية
عندما يكون التنبؤ غير دقيق، يكون الرد الشائع هو طلب المزيد من التقسيمات - حسب المنتج، حسب المنطقة، حسب المصدر. هذا يخلق عبئًا على إعداد التقارير ويخفي السبب. إذا كانت 30% من الصفقات بتاريخ قديم، فلن يساعد أي تقسيم.
التسلسل الصحيح: تصحيح جودة البيانات، تثبيت دورة المراجعة، قياس الدقة لمدة ربع، ثم فقط النظر في تقسيمات إضافية.
الخلاصة
التنبؤ الموثوق هو نتاج روتين إداري مدعوم بالنظام، وليس أداة تنبؤ. ثلاثة أسئلة تحدد ما إذا كنت قد وصلت إلى هناك: هل يوجد جدول بيانات موازٍ، هل يتفق الجميع على ما يدخل في Commit، وهل يقوم أحد بقياس دقة التنبؤ بأثر رجعي. ثلاث إجابات جيدة تساوي أكثر من أي تحسين للوحة معلومات.