برنامج متابعة الطلبات: جاهز أم مخصص؟ كيف تختار

برنامج متابعة الطلبات هو نظام ينقل سجل طلب واحد عبر حالات مسمّاة مثل مستلَم، مؤكَّد، قيد التجهيز، مشحون، مسلَّم ومحصَّل، ويسجّل عند كل انتقال من غيّر ماذا ومتى. الجواب المختصر: إذا كان تدفق طلباتك قياسياً (طلبات متجر إلكتروني أو منصة تسوق، مستودع واحد، قائمة أسعار واحدة) فنظام متابعة الطلبات الجاهز يكفي؛ أما إذا كان لديك إنتاج أو بيع بالجملة أو تدفق B2B (تسليمات جزئية، أسعار خاصة بكل موزّع، ربط بأمر الإنتاج، تكامل مع حسابات العملاء، خطوات اعتماد) فالحل هو برنامج متابعة طلبات مخصص. أما اللحظة التي يتوقف فيها Excel عن الكفاية فليست «عندما نكبر»، بل أول يوم يحرّر فيه شخصان الملف نفسه ولا يستطيع أحد أن يقول من غيّر الحالة ومتى. تشرح هذه المقالة كيف نتخذ هذا القرار في مشاريع الحلول المؤسسية.

ماذا يفعل برنامج متابعة الطلبات بالضبط؟

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

• مستلَم: دخل الطلب إلى النظام؛ ثُبّت العميل والبنود والعنوان والسعر.
• مؤكَّد: اجتاز فحص المخزون أو السعر، واعتمده مسؤول المبيعات.
• قيد التجهيز أو قيد الإنتاج: المستودع يجمّع الطلب، أو فُتح أمر إنتاج.
• مشحون: صدر رقم التتبع وسُلّم الطرد إلى شركة الشحن.
• مسلَّم: استلم العميل الطلب وبدأت مهلة الإرجاع.
• محصَّل: وصل المبلغ إلى الحسابات وأُغلق الطلب.

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

أين يتعطل Excel بالضبط؟

Excel بداية معقولة لمنشأة طلباتها قليلة ويديرها شخص واحد؛ المشكلة ليست في الحجم بل في نقطتي كسر محددتين. الأولى: تحرير عدة أشخاص للملف نفسه في الوقت نفسه. تُدخل المبيعات طلباً بينما يغيّر المستودع حالة، فيمحو التعديلان بعضهما ولا يعرف أحد أي صف هو الصحيح. الثانية: غياب تاريخ الحالات. تقول الخلية اليوم «مشحون»، لكن ما كان مكتوباً أمس، ومن غيّره، وهل تم الاعتماد فعلاً، كله ضاع. وحين يتصل العميل ليسأل لماذا تأخر طلبه، تظهر الفجوتان في اللحظة نفسها.

وقت الانتقال إلى برنامج متابعة الطلبات ليس «عندما نكبر». في أول يوم يحرّر فيه شخصان الجدول نفسه ويسأل أحدهم من غيّر الحالة ومتى، يكون Excel قد بلغ حدّه.

نرى الاختناق نفسه في جانب المخزون؛ نقاط الكسر التي شرحناها في مقالة برنامج متابعة المخزون أم برنامج مخصص تتبع منطق متابعة الطلبات نفسه، لأن كليهما عملية يمر فيها سجل واحد بعدة أيدٍ.

نظام متابعة طلبات جاهز أم برنامج مخصص؟

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

أما برنامج متابعة الطلبات المخصص فهو الجواب لتدفقات الإنتاج والجملة وB2B. هناك لا يكون الطلب قطعة واحدة، وتظهر قواعد لا تفترضها الحزم الجاهزة:

• التسليمات الجزئية: يُشحن جزء من الطلب اليوم والباقي عند خروجه من الإنتاج؛ سندا تسليم لطلب واحد.
• قوائم أسعار خاصة بكل موزّع: يُباع المنتج نفسه لكل عميل بسعر مختلف وبشروط سداد مختلفة.
• الربط بأمر الإنتاج: تأكيد الطلب يفتح أمر إنتاج، وانتهاء الإنتاج يدفع الطلب إلى الأمام تلقائياً.
• التكامل مع حسابات العملاء: اعتماد الطلب يتحقق من رصيد العميل وحد الائتمان.
• خطوات الاعتماد: الطلبات التي تتجاوز مبلغاً معيناً أو تحمل خصماً تنتظر موافقة المدير.

اختبار القرار بسيط: افتح نموذج الطلب الذي تستخدمه اليوم وعدّ الحقول غير القياسية. رمز الموزّع، مدة السداد، موعد الإنتاج، مضاعف الكرتونة، الخصم الخاص، اسم المعتمِد: إن لم تكن موجودة في نموذج الحزمة، سيتحول كل منها إلى «حل مؤقت». إذا تجاوز العدد بضعة حقول فستُلوى الحزمة حتى تنكسر؛ وعند تلك النقطة يصبح البرنامج المخصص أرخص. شرحنا جانب الموزّعين في مقالة نظام طلبات الموزّعين B2B، وربط الإنتاج في مقالة برنامج متابعة الإنتاج (MRP).

الميزات الإلزامية في برنامج متابعة الطلبات

جاهزاً كان أم مخصصاً، لا تتخذ القرار قبل أن تطلب هذه الميزات الست:

• نموذج حالات بتاريخ كامل: يُحفظ كل انتقال مع من ومتى ومن أي حالة، ولا يمكن حذفه.
• إشعار العميل عند تغيّر الحالة: رسالة SMS أو واتساب أو بريد إلكتروني عند التأكيد والشحن والتسليم؛ التفاصيل في مقالة تكامل WhatsApp Business API.
• صلاحيات حسب الدور: المبيعات تُدخل وتؤكد، المستودع يجهّز ويشحن، الحسابات تغلق التحصيل؛ لا أحد يغيّر حالة خارج دوره.
• التكامل مع المحاسبة: يتحول الطلب إلى فاتورة وقيد في النظام المحاسبي مثل Logo أو Netsis أو Paraşüt في السوق التركي؛ طريقة الربط في مقالة التكامل مع برنامج المحاسبة.
• التكامل مع شركات الشحن: تُطبع البطاقة من النظام ويُكتب رقم التتبع في الطلب تلقائياً؛ انظر تكامل الشحن.
• تقرير الطلبات المتأخرة: الطلبات التي تجاوزت موعدها أو بقيت في حالة واحدة أطول من المتوقع تُدرج يومياً.

لمن يريد أن يرى شكل نموذج الحالات في الكود، في الأسفل مثال صغير بلغة TypeScript يحتفظ بالانتقالات المسموحة في جدول واحد. ولأن الجدول في مكان واحد، تعمل قواعد مثل «الطلب المشحون لا يمكن أن يعود إلى انتظار التأكيد» بالطريقة نفسها على كل شاشة:

type OrderStatus =
  | 'received'
  | 'confirmed'
  | 'preparing'
  | 'shipped'
  | 'delivered'
  | 'collected'
  | 'cancelled';

const transitions: Record<OrderStatus, OrderStatus[]> = {
  received: ['confirmed', 'cancelled'],
  confirmed: ['preparing', 'cancelled'],
  preparing: ['shipped'],
  shipped: ['delivered'],
  delivered: ['collected'],
  collected: [],
  cancelled: [],
};

function changeStatus(order: Order, next: OrderStatus, userId: string) {
  if (!transitions[order.status].includes(next)) {
    throw new Error(`${order.status} -> ${next} is not allowed`);
  }
  order.history.push({ from: order.status, to: next, userId, at: new Date() });
  order.status = next;
}

ما الذي يحدد تكلفة برنامج متابعة الطلبات؟

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

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

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

الخلاصة

عند اختيار برنامج متابعة الطلبات ليس السؤال «أي علامة تجارية؟» بل «هل تدفقي قياسي؟». إذا كنت تعمل بطلبات المتجر الإلكتروني أو منصة التسوق ومستودع واحد وقائمة أسعار واحدة فالحزمة الجاهزة تكفي؛ أما إذا كانت لديك تسليمات جزئية وأسعار موزّعين وأوامر إنتاج واعتماد على حسابات العملاء فستحمل أنت الحزمة بدل أن تحملك. ابدأ بعدّ الحقول غير القياسية في نموذج طلبك؛ إذا تجاوزت بضعة حقول فإن البرمجيات المخصصة هي الطريق الأصح. أرسل لنا نموذجك وتدفقك الحالي عبر نموذج طلب العرض، وفي أول اجتماع نرسم نموذج الحالات معاً.