تم النشر في 18 مايو • نُشر في الأصل على موقع mustafaerbay.com.tr
عند تطوير نظام تخطيط موارد المؤسسات (ERP) للتصنيع، كان أكبر كابوس بالنسبة لي هو التأخير في التوأم الرقمي للحركة المادية. في اللحظة التي يقوم فيها المشغل بمسح الرمز الشريطي على أرضية المصنع، لا يكفي أن تتم كتابة هذه البيانات ببساطة في قاعدة البيانات؛ يجب تحديث المخزون، وحساب التكاليف، وإخطار قسم الشحن، وإذا كانت هناك وحدة تخطيط إنتاج قائمة على الذكاء الاصطناعي، فيجب إعادة حساب المسار. خلال 20 عامًا من خبرتي الميدانية، رأيت أن برامج سلسلة التوريد ليست مجرد "برنامج"؛ إنه التمثيل المقنن للتدفق التنظيمي.
في هذه المقالة، سنفحص رحلة البيانات في تخطيط موارد المؤسسات (ERP) للتصنيع، بدءًا من قبول المواد الخام وحتى إصدار الفواتير، والاختناقات الفنية التي واجهتها، والأساليب المعمارية التي استخدمتها للتغلب عليها. سأركز بشكل خاص على إدارة معاملات PostgreSQL، وتجزئة طبقة الشبكة، ومعالجة البيانات غير المتزامنة. إذا تلقى نظامك شكاوى مثل "لقد أرسلت البيانات، ولكنها لا تظهر في المخزون"، فمن المحتمل أنك تواجه تسربًا في مكان ما في هذا التدفق.
رحلة البيانات: من المواد الخام إلى المنتج – عمليات SQL
كل شيء في سلسلة التوريد يبدأ بـ INSERT أو UPDATE، لكن هذه العمليات يجب أن تكون ذرية. عند العمل في نظام تخطيط موارد المؤسسات (ERP) للتصنيع، إذا تعطل النظام أثناء تعيين 500 كجم من مادة البولي بروبيلين التي تغادر مستودع المواد الخام إلى أمر عمل، فإن ذلك يؤدي إلى مخزون "مفقود". في مثل هذه المواقف، أستخدم دائمًا نمط صندوق الصادر للمعاملات للحفاظ على الاتساق حتى في ظل التحميل الثقيل. أثناء كتابة البيانات إلى الجدول الرئيسي، أقوم أيضًا بتسجيل المهمة المعلقة في جدول "صندوق الصادر" ضمن نفس المعاملة.
اسمحوا لي أن أقدم لكم مثالاً واقعيًا: في أحد مشاريع عميلي، تم إدخال البيانات في وقت واحد من 40 شاشة مشغل مختلفة. عندما حاولنا القيام بالكثير من العمل ضمن كتل BEGIN وCOMMIT على PostgreSQL، زادت أوقات القفل، وواجهنا أخطاء حالة توقف تام. كان الحل الذي وجدته هو نقل الحسابات الثقيلة (مثل محاسبة التكاليف) خارج المعاملة الرئيسية وإدارتها بشكل غير متزامن عبر العامل. أدى هذا إلى تقليل زمن استجابة واجهة المستخدم من 800 مللي ثانية إلى 40 مللي ثانية.