نقطة إعادة الطلب تساعدك على معرفة وقت مراجعة التعويض، لكنها لا تخبرك وحدها بعدد الوحدات التي ينبغي شراؤها. كما أن عدد القطع على الرف لا يصف كل ما في الطريق. سنحسب القرار في مثال مستودع افتراضي، ثم نغير كمية الوارد والمهلة وحجم العبوة لنرى أي رقم يتغير، وأي سؤال يبقى محتاجًا إلى جواب.
الخلاصة السريعة
ابدأ بتعريف رصيد المقارنة ومدة الانتظار، ثم طبق قاعدة الطلب وراجع مواعيد الشحنات. الأرقام الآتية تعليمية ولا تمثل توصية شراء لمشروع بعينه.
- في النموذج المبسط، نقطة الطلب تجمع الطلب المتوقع خلال المهلة ومخزون الأمان. [1]
- حدد ما تضيفه من وارد وما تخصمه من طلب قبل مقارنة الرصيد؛ تختلف تعريفات البرامج. [2]
- في مثالنا، نقطة الطلب مئة وسبعون وحدة، بينما الرصيد يصبح مئة وتسعين أو مئة وخمسين بحسب الوارد.
- نقطة الطلب تحدد بداية القرار، وسياسة الكمية تحدد الحجم مع قيود العبوات والمواعيد. [3]
- رفع الطلب اليومي أو إطالة المهلة يغير العتبة؛ اختبر كل عامل منفصلًا قبل جمع الأثرين.
- الرصيد الإجمالي لا يكفي للتحقق من تلبية طلب سابق لوصول الشحنة؛ راجع تسلسل الأيام.
ما المقصود بنقطة إعادة الطلب؟
تشرح وثائق أوراكل نقطة الطلب باعتبارها مخزون الأمان مضافًا إليه الطلب المتوقع خلال مهلة التعويض، وتفصل ذلك عن حجم أمر الشراء. وتضم المهلة في ذلك النظام مراحل قبل المعالجة وأثناءها وبعدها. الفكرة هنا أن الشحنة الجديدة لا تظهر فور اتخاذ القرار؛ لذلك نقارن الرصيد بحاجة تغطي فترة الانتظار ضمن سياسة معلومة، ولا ننتظر نفاد الرف بالضرورة. [1]
سنؤلف مستودعًا صغيرًا يبيع عبوات قياسية من صنف واحد، ونقيس جميع الكميات بالوحدة المفردة. نفترض طلبًا يوميًا قدره عشرون وحدة، ومهلة مقدارها ستة أيام عمل على التقويم نفسه، واحتياطيًا اختير للتوضيح مقداره خمسون وحدة. لا نستنتج من هذه الفروض أن خمسين كمية كافية فعلًا لأي نشاط؛ لم نقدم بيانات تذبذب أو احتمال نفاد أو مستوى خدمة مستهدفًا.
طلب فترة الانتظار في حالتنا هو عشرون مضروبة في ستة، أي مئة وعشرون وحدة. بإضافة الخمسين تصبح نقطة الطلب مئة وسبعين وحدة. اكتب بجوار النتيجة أنها عتبة بوحدة القطع، وبجوار المدخل الأول أنه وحدات لكل يوم عمل، وبجوار المهلة أنها أيام عمل؛ فالناتج مفهوم لأن وحدتي الزمن تتفقان، وليس لأن عملية الضرب تبدو مألوفة فقط.
ولكي يكون القرار قابلًا للفحص، سنفترض في بقية المثال أن المراجعة تحدث عند وصول حركة جديدة إلى السجل، وأن إصدار طلب جديد يُدرس عندما ينخفض رصيد المقارنة عن العتبة. عند المساواة نكتفي بالمراقبة وفق هذا الفرض. هذه قاعدة معلنة للمثال، وليست وصفًا موحدًا لجميع البرامج؛ تغيير شرط المقارنة إلى «أقل من أو يساوي» يغير حالة الحد نفسها.
أي رصيد تقارن بالعتبة؟
تعرض وثائق مايكروسوفت للتخطيط بالأولوية رصيد تدفق يجمع الموجود والوارد المتوقع، ثم يطرح الطلب المؤهل وفق نطاق التخطيط. لا يعني ذلك أن كل فاتورة مفتوحة تصلح للجمع، أو أن كل حجز يطرح بالطريقة نفسها في كل نظام. سنستخدم سجلًا يدويًا أبسط: موجود صالح، ووارد مؤكد مشمول، وطلبات متأخرة لم تخصم بعد، مع إعلان ما يدخل في كل خانة. [2]
الموجود الصالح في هذا السجل مئة وعشرون وحدة. الوارد المشمول ثمانون وحدة، والطلبات المتأخرة عشر وحدات. افترضنا أن العشر تخص التزامات سابقة مستقلة عن توقع العشرين اليومي، وأنها لم تخصم من الموجود ولم تحسب مرة ثانية في الطلب المتوقع. بهذا التعريف يكون الرصيد مئة وعشرين زائد ثمانين ناقص عشر، أي مئة وتسعين وحدة، وهو أعلى من العتبة بعشرين.
إذا نظر الموظف إلى الرف وحده فسيجد مئة وعشرين، أي أقل من مئة وسبعين بخمسين. وإذا نظر إلى سجلنا سيجد مئة وتسعين. لا نختار الرقم الأكبر لأنه يريحنا؛ كل رقم يجيب عن سؤال مختلف. الأول عد للموجود الآن، والثاني رصيد تعويض وفق الفروض المذكورة. أما إمكان تسليم كمية معينة اليوم فيحتاج التحقق من الموجود القابل للتخصيص اليوم تحديدًا.
قد يقدم تقرير آخر مئة وعشر وحدات بوصفها الموجود الصافي بعد خصم الطلبات العشر. إذا استعملنا ذلك التقرير، نجمع إليه الثمانين فنصل إلى مئة وتسعين أيضًا، ولا نطرح العشر مرة أخرى. هذا اختبار اتساق مفيد بين تقريرين: اسأل أين دخل الخصم قبل أن تصلح الفرق يدويًا، واحتفظ بتعريف الحقل إلى جانب العدد حتى لا يعود الخطأ في المراجعة التالية.
مثال تغير الوارد من ثمانين إلى أربعين
لننشئ فرعًا مستقلًا من المثال، لا حركة إضافية بعد الحالة السابقة: الموجود مئة وعشرون والطلبات المتأخرة عشر، لكن المورد أكد أربعين وحدة فقط ضمن الوارد المشمول. يصبح الرصيد مئة وخمسين وحدة. وهو أقل من نقطة الطلب مئة وسبعين بمقدار عشرين، فتتحقق قاعدة المراجعة التي وضعناها. السبب هنا تغير الوارد، ولم نفترض ارتفاع المبيعات أو تغير الاحتياطي.
الفارق البالغ عشرين يصف المسافة بين الرصيد والعتبة، ولا يثبت أن شراء عشرين سيحل كل حاجة لاحقة. وكذلك لا تعني العتبة أن نكتب مئة وسبعين في خانة كمية الشراء. قبل ملء الخانة نحتاج سياسة كمية منفصلة. ومن المفيد أن يضع الموظف عبارتين في المذكرة: «سبب فتح القرار: الرصيد أقل من العتبة»، و«أساس الكمية: السياسة المختارة».
نفترض الآن، لأغراض الحساب وحدها، أن صاحب المثال اعتمد هدف رصيد قدره ثلاثمئة وحدة عند إصدار الطلب. في هذه النسخة تكون الكمية الأولية ثلاثمئة ناقص مئة وخمسين، أي مئة وخمسين وحدة. لم نحسب تكلفة تخزين أو خصم مورد أو مساحة مستودع؛ لذلك لا نسمي هذا الحجم اقتصاديًا أو أمثل، ولا نستدل من سهولة حسابه على ملاءمته التجارية.
بعد تسجيل أمر جديد بهذه الكمية، يصبح الرصيد الحسابي ثلاثمئة إذا ظل كل شيء آخر ثابتًا. لكن الموجود الفعلي لا يقفز من مئة وعشرين إلى ثلاثمئة في اللحظة نفسها؛ أضفنا التزام توريد لا عملية استلام. حافظ على هذا الفرق أثناء عرض النتيجة على زميلك، وإلا تحول قرار تعويض صحيح على الورق إلى وعد تسليم لا تؤيده كمية الرف الحالية.
كيف تغير العبوة وموعد المراجعة القرار؟
توضح وثائق Business Central أن سياسة إعادة الطلب تحدد حجم التوريد، وقد تراعي حدود الكمية ومضاعفات الشراء والتقويم. كما تميز الرصيد المتوقع من المتاح، وتحذر من أثر الحجوزات في بعض سياسات نقطة الطلب. لذلك لا تنقل معادلة سجلنا إلى حقل في برنامجك دون مراجعة تعريفه؛ مثالنا ليس محاكاة لإعداداته أو توصية بتعطيل حجوزات موجودة. [3]
لنفترض أن المورد في الفرع السابق لا يبيع إلا عبوات كاملة، في كل منها أربع وعشرون وحدة، وأن المطلوب تغطية الكمية الأولية مئة وخمسين على الأقل. ست عبوات توفر مئة وأربعًا وأربعين، فتقل بست وحدات. سبع عبوات توفر مئة وثمانيًا وستين، فتزيد بثماني عشرة. إذن سبع هي أقل عدد صحيح يحقق شرطنا المعلن، دون افتراض قبول المورد كسر العبوة.
إضافة مئة وثمان وستين إلى رصيد مئة وخمسين تعطي ثلاثمئة وثماني عشرة. الزيادة على هدف الثلاثمئة ليست خطأ جمع؛ إنها نتيجة شرط العبوة. سجّلها منفصلة لتقرر قبولها أو مناقشة شرط التوريد. لم نعط حدًا نقديًا أو سعة تخزين، فلا يستطيع المثال حسم الموافقة. ما أثبته الحساب هو مقدار التجاوز وسببه، وليس أن التجاوز مناسب في كل الأحوال.
غيرنا أيضًا توقيت المراجعة في سيناريو مستقل: لا يفتح الموظف السجل إلا مرة كل أسبوع. عندها لا يعود فرض المراجعة بعد كل حركة صحيحًا، وقد يمر انخفاض الرصيد دون قرار فوري. لا نضيف رقمًا عشوائيًا إلى الخمسين لإخفاء الاختلاف؛ نكتب موعد المراجعة الفعلي ونختبر الأيام الواقعة بين مراجعتين. هذه مسألة مختلفة عن تقريب عدد العبوات، حتى لو ظهرتا في طلب الشراء نفسه.
اختبر أثر تغير الطلب والمهلة
نعود إلى أساس المثال: عشرون وحدة يوميًا وستة أيام وخمسون احتياطيًا. في اختبار أول نرفع الطلب إلى خمس وعشرين وحدة يوميًا ونثبت المدخلين الآخرين. يصبح طلب المهلة مئة وخمسين، وتصبح العتبة مئتين. مقدار التغير ثلاثون وحدة، وهو الزيادة اليومية البالغة خمس وحدات مكررة خلال الأيام الستة. هذه قراءة حسابية للفرض الجديد، وليست توقعًا لمبيعات الشهر المقبل.
وفي اختبار ثان مستقل، نبقي الطلب عشرين ونمد المهلة إلى ثمانية أيام، مع الاحتياطي نفسه. يصبح طلب المهلة مئة وستين، والعتبة مئتين وعشرًا. الزيادة أربعون لأننا أضفنا يومين، لكل منهما عشرون وحدة. إذا كان التأخير يخص ساعات عمل المورد أو وقت إتاحة الشحنة، فيجب وصفه بالمرحلة والتقويم المناسبين قبل إدخاله؛ لا تستبدل الأيام التقويمية بأيام العمل دون تفسير.
أما عندما نجمع التغيرين، فالطلب خمس وعشرون والمهلة ثمانية، وتصبح العتبة مئتين وخمسين. الزيادة على الأساس ثمانون، وليست سبعين ناتجة عن جمع الزيادتين المنفردتين فقط. الفرق عشر وحدات يمثل خمس وحدات إضافية في كل واحد من اليومين الإضافيين. إعادة الحساب من المدخلات الجديدة تمنع إغفال هذا التفاعل عندما يتغير أكثر من عامل في الوقت نفسه.
يمكنك إعداد ثلاث خانات إلى جانب الحساب الأساسي: طلب أعلى، مهلة أطول، واجتماع الاثنين. اكتب المدخلات قبل النتائج حتى يستطيع المراجع تكرار العملية، ثم افصل ما حدث فعلًا عما تختبر حدوثه. أبقينا الاحتياطي ثابتًا كي نعزل أثر المتغيرين؛ لا يعني ذلك أن قرار الاحتياطي الحقيقي يجب أن يظل ثابتًا عندما تتغير ظروف النشاط أو درجة عدم اليقين.
راجع الأيام قبل اعتماد أمر الشراء
لرؤية حدود الإجمالي، نؤلف حالة زمنية مستقلة فيها عشرون وحدة موجودة وأربعون ستصل في بداية اليوم الخامس، ولا شحنات أخرى. يوجد طلب لثلاثين وحدة في اليوم الثاني. مجموع الموجود والوارد ستون، لكنه لا يتيح تسليم الثلاثين في موعدها: المتاح قبل الشحنة عشرون فقط، والعجز عشر. لم نحتج إلى تغير أسعار أو خطأ مورد حتى يظهر الفرق بين الإجمالي والتوقيت.
إذا غيرنا موعد وصول الأربعين إلى بداية اليوم الثاني قبل تجهيز الطلب، يختفي العجز في هذا المثال، بشرط صلاحية الوحدات وعدم وجود التزامات أخرى. وإذا أبقينا الوصول في اليوم الخامس وغيرنا موعد طلب العميل إلى اليوم السادس، يختلف الاستنتاج أيضًا. لهذا ينبغي أن تصاحب الكمية ثلاثة تواريخ واضحة: موعد الحاجة، وموعد الوصول المتوقع، وموعد الإتاحة الفعلية إن كان مختلفًا.
قبل اعتماد المذكرة، اقرأها من دون الاطلاع على حسابك السابق. هل تعرف الصنف والموقع ووحدة العد؟ هل يمكن معرفة الطلبات الداخلة في الخصم، والوارد الداخل في الجمع، ووقت تحديث السجل؟ وهل يظهر سبب اختيار المهلة والاحتياطي والهدف؟ أي فراغ هنا سؤال يحتاج جوابًا من صاحب البيانات؛ لا تملأه من أرقام مثالنا ثم تعرض الناتج باعتباره قرارًا خاصًا بمستودعك.
احتفظ بالقرار في صورة قابلة للتتبع: الرصيد عند المراجعة، والعتبة، وسبب فتح طلب جديد، والكمية قبل التقريب وبعده، ومواعيد الوارد المشمول. إذا تغير التأكيد من المورد تستطيع معرفة أي فرض تبدل وإعادة الحساب منه. بهذه الطريقة يصبح الرقم بداية لمراجعة محددة، بدل أن يكون حكمًا نهائيًا بأن المخزون كاف أو أن كل انخفاض في الرف يستدعي طلبًا مكررًا.
المصادر ومتابعة القراءة
- أوراكل: التخطيط بنقطة إعادة الطلب (يفتح في نافذة جديدة)docs.oracle.com
- مايكروسوفت: التخطيط القائم على الأولوية (يفتح في نافذة جديدة)learn.microsoft.com
- مايكروسوفت: معالجة سياسات إعادة الطلب (يفتح في نافذة جديدة)learn.microsoft.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.
