ما المشكلة الأساسية في البيع متعدّد القنوات؟
المشكلة الأساسية هي بيع المخزون نفسه في أكثر من مكان. فإذا كان موقعكم والأسواق الإلكترونية والمتجر الفعلي تُغذّى كلّها من المستودع نفسه، أمكن لطلبين يردان في وقت واحد من قناتين أن يبيعا منتجًا ليس في حوزتكم. والبيع الزائد ليس تكلفة إلغاء فحسب؛ بل يخفض أيضًا درجة أداء البائع في الأسواق الإلكترونية.
ثلاثة أساليب تمنع البيع الزائد
- التخصيص لكلّ قناة: يُفرَد جزء من المخزون لكلّ قناة. وهو الأسهل تنفيذًا؛ وعيبه أنّ المخزون غير المستخدَم في قناة لا ينتقل إلى أخرى.
- هامش الأمان: يُنشَر المخزون بعد خصم مقدار ثابت من المخزون المركزي. ويُطبَّق سريعًا لكنّه يُنتج خسارة بيع في المنتجات قليلة المخزون.
- الحجز المركزي: يُنشأ حجز على المخزون المركزي لحظة الطلب. وهو يعطي أدقّ نتيجة؛ ويتطلّب أن يعمل التكامل قريبًا من الزمن الفعلي.
والحلّ الشائع عمليًا هو استخدام الحجز في المنتجات سريعة الدوران وهامش الأمان في المنتجات بطيئة الدوران.
اقبلوا تأخّر المزامنة، ولا تُخفوه
لا يوجد تكامل فوري. والنهج الصحيح ليس محاولة تصفير التأخّر، بل قياسه وتحديده: ينبغي متابعة متوسّط تأخّر تحديث المخزون وأسوأ حالاته، وإنتاج تنبيه عند تجاوز العتبة. كما ينبغي زيادة دورية التحديث كلّما قلّ المخزون؛ فتأخّر عشر دقائق في منتج فيه 500 وحدة ليس مشكلة، لكنّه مشكلة في منتج فيه 3 وحدات.
مسار الطلب ← الفاتورة
تتألّف السلسلة بعد استلام الطلب من خطوات حجز المخزون، والتحقّق من الدفع، والشحن، والفوترة. وفي جانب الفوترة تدخل التزامات المستندات الإلكترونية، وتصير مطابقة رقم الفاتورة مع رقم الطلب إلزامية للإرجاع والمطابقة. وفي طلبات الأسواق الإلكترونية تختلف مسؤولية تحرير الفاتورة بحسب عقد القناة؛ ويجب أن يكون هذا إعدادًا على مستوى القناة في نموذج البيانات.
ويُستخدم مفتاح العملية كي لا تُنتج عمليات النقل المعادة طلبًا مكرّرًا؛ والتفصيل في دليل تكامل واجهات API.
مسار الإرجاع جزء من نموذج البيانات
الإرجاع ليس حذفًا للطلب؛ بل سجلّ مستقلّ له دورة حياته الخاصّة: طُلب ← اعتُمد ← استُلم من الشحن ← فُحص ← قُبل أو رُفض ← رُدّ المبلغ. ويجب نمذجة الإرجاع الجزئي على مستوى البند. كما يجب الفصل بحقل حالة يبيّن هل يعود المنتج المرتجَع إلى المخزون أم لا (تالف، مفتوح، غير قابل للبيع). فمن دون هذا الفصل تفسد دقّة المخزون مع كلّ إرجاع.
لا تُذيبوا فروق الأسواق الإلكترونية في نموذج واحد
لكلّ سوق إلكتروني شجرة فئات خاصّة به، ومجموعة خصائص إلزامية، وبنية عمولة، وقاعدة شحن. واختزال بيانات المنتج في حقلَي «عنوان + وصف» لا يلبّي الإلزامات على مستوى القناة. والبنية الصحيحة هي حفظ نموذج بيانات منتج غنيّ في المركز وتعريف مطابقة لكلّ قناة.
الأسئلة الشائعة
هل ينبغي حفظ المخزون في ERP المركزي؟
نعم. يجب أن يكون ERP مصدر الحقيقة الوحيد، وأن تُغذّى القنوات منه. أمّا إدارة القنوات لعدّادات مخزونها بشكل مستقلّ فتجعل المطابقة مستحيلة.
كيف يُدار تمييز الأسعار؟
يجب أن تُجرى قوائم الأسعار لكلّ قناة والحساب الشامل للعمولة في مكان واحد. وبما أنّ عمولة السوق الإلكتروني وتكلفة الشحن تغيّران ربحية القناة، يمكن تسعير المنتج نفسه بأسعار مختلفة في قنوات مختلفة؛ وينبغي أن يكون ذلك قرارًا واعيًا لا أثرًا جانبيًا لتحديث يدوي.
هل ينبغي فتح مخزون المتجر للبيع الإلكتروني؟
يمكن ذلك، لكنّ موثوقية جرد المتجر شرط مسبق. ففتح مخزون المتجر للنشر مع انخفاض دقّة الجرد أكثر أسباب البيع الزائد شيوعًا. ونتناول موضوع دقّة المخزون في جانب المتجر في دليل نقاط البيع بالتجزئة.