← تمام مضامین

9 مارچ 2026

پلاننگ کے لیے ERP انٹیگریشن: کون سا ڈیٹا کس کی ملکیت ہے؟

ERP کہتا ہے 320 باقی، پلانر کہتا ہے 308، شاپ فلور کہتا ہے "ہو گیا"۔ جانیے کہ جزوی کنفرمیشن کو کیسے ٹریس کیا جائے، آرڈر کی تین تاریخیں الگ کیسے رکھی جائیں، اور کیسے طے ہو کہ کون سا سسٹم کس ڈیٹا کا مالک ہے۔

اس کے لیے آئسومیٹرک مثال پلاننگ کے لیے ERP انٹیگریشن: کون سا ڈیٹا کس کی ملکیت ہے؟

سیلز ایک سیدھا سا سوال پوچھتی ہے: آرڈر 4711 میں سے کتنا بنانا باقی ہے؟ ERP کہتا ہے 320۔ پلانر کا شیڈول کہتا ہے 308۔ شاپ فلور کہتا ہے "ہو گیا"۔ تین سسٹم، تین جواب، اور ہر ایک اپنے اصولوں کے مطابق درست ہے۔ ERP انٹیگریشن کو یہی مسئلہ حل کرنا ہوتا ہے۔

پروڈکشن پلاننگ کے لیے ERP انٹیگریشن کا مطلب ہے اپنے ERP سسٹم (SAP، Oracle، Microsoft Dynamics 365 یا کوئی اور) کو اس ٹول سے جوڑنا جو پروڈکشن کی پلاننگ اور شیڈولنگ کرتا ہے، تاکہ آرڈرز، اسٹاک اور کنفرمیشنز کا مطلب دونوں جگہ ایک ہی ہو۔ مشکل حصہ شاذ و نادر ہی تکنیکی کنکشن ہوتا ہے۔ اصل مشکل یہ طے کرنا ہے کہ کون سا سسٹم کس ڈیٹا کا مالک ہے، اور ہر عدد کا مطلب کیا ہے۔

ایک آرڈر، تین جواب

آرڈر 4711 میں 500 درست یونٹس درکار ہیں۔ اب تک مشین 192 یونٹس پراسیس کر چکی ہے: 180 درست اور 12 اسکریپ۔

  • ERP درست یونٹس منہا کرتا ہے: 500 − 180 = 320 باقی۔
  • پلاننگ ٹول نے مشین سے گزرنے والی ہر چیز منہا کی: 500 − 192 = 308 باقی۔
  • شاپ فلور کو اس ہفتے کے 192 یونٹس کے رن کا جاب آرڈر ملا تھا۔ وہ رن مکمل ہو چکا، اس لیے ان کے لیے کام ہو گیا۔

کسی نے ٹائپنگ کی غلطی نہیں کی۔ سب "باقی" کی الگ الگ تعریف استعمال کر رہے ہیں۔ انٹیگریشن کا آغاز ان تعریفوں پر اتفاق سے ہوتا ہے، کسی ایک فیلڈ کی میپنگ سے بھی پہلے۔

ایک جزوی کنفرمیشن، دونوں سسٹمز میں

100 بریکٹس کے ایک پروڈکشن آرڈر میں تین آپریشن ہیں: 10 کٹنگ، 20 ویلڈنگ، 30 پینٹنگ۔ ویلڈر آپریشن 20 پر 60 درست پیس کنفرم کرتا ہے اور گھر چلا جاتا ہے۔

  • پلاننگ ٹول میں آپریشن 20 کے 40 پیس باقی ہیں، جو کل پر منتقل ہو گئے۔ اگر آپ کے ٹرانسفر رولز جزوی بیچ کی اجازت دیتے ہیں تو 60 پیس پر پینٹنگ شروع ہو سکتی ہے۔ جاب آرڈر جزوی طور پر مکمل دکھتا ہے، اور بدستور کسٹمر آرڈر سے جڑا ہوا ہے۔
  • ERP میں آرڈر کو آپریشن 20 پر 60 کی جزوی کنفرمیشن ملتی ہے۔ ابھی کوئی تیار مال وصول نہیں ہوا؛ یہ صرف پینٹنگ کے بعد ہوگا۔

اب دو چیزیں جو حقیقی زندگی میں غلط ہو جاتی ہیں۔

میسج دو بار چلا گیا۔ نیٹ ورک میں ذرا سی گڑبڑ، ایک ری ٹرائی، اور ERP دکھاتا ہے کہ 100 میں سے 120 ویلڈ ہو گئے۔ ہر کنفرمیشن کی ایک منفرد ID ہونی چاہیے تاکہ وصول کرنے والا سسٹم ڈپلیکیٹ پہچان کر اسے نظرانداز کر سکے۔

گنتی درست کی گئی۔ اگلی صبح انسپیکشن میں 60 میں سے 5 ویلڈ خراب نکلتے ہیں۔ کنفرمیشن اب 55 درست اور 5 اسکریپ بن جاتی ہے، یعنی 40 نہیں بلکہ 45 پیس ابھی درکار ہیں۔ کسی کو فیصلہ کرنا ہوگا کہ 5 اضافی پیس کاٹے جائیں یا کسٹمر 95 قبول کر لے۔ یہ فیصلہ کسی انسان کا ہے، انٹرفیس کا نہیں۔

مطلوبہ، حساب شدہ اور وعدہ شدہ تاریخ

زیادہ تر آرڈرز پر تین تاریخیں ہوتی ہیں، اور انہیں ایک دوسرے کو اوور رائٹ نہیں کرنا چاہیے:

  • مطلوبہ تاریخ: جو کسٹمر نے مانگی، 10 مارچ۔ یہ صرف اسی وقت بدلتی ہے جب کسٹمر اسے بدلے۔
  • حساب شدہ تاریخ: جو پلاننگ ٹول کے مطابق ممکن ہے، 14 مارچ۔ یہ ہر شیڈول رن کے ساتھ بدل سکتی ہے۔
  • وعدہ شدہ تاریخ: جو سیلز نے حساب شدہ تاریخ دیکھ کر کنفرم کی، 15 مارچ۔ یہ صرف اسی وقت بدلتی ہے جب کوئی نیا وعدہ کرنے کا فیصلہ کرے۔

کلاسیکی غلطی یہ ہے کہ حساب شدہ تاریخ کو سیدھا وعدہ شدہ تاریخ میں لکھ دیا جائے۔ پھر ہر شیڈول رن خاموشی سے وہ بات بدل دیتا ہے جو کسٹمر کو بتائی گئی تھی۔ بہتر یہ ہے: اگر حساب شدہ تاریخ وعدہ شدہ تاریخ سے آگے نکل جائے تو سیلز کو الرٹ کیجیے۔ اوور رائٹ مت کیجیے۔ وعدہ پہلی بار کیسے جانچا جاتا ہے، یہ سیلز آرڈر سے پروڈکشن تک میں بیان کیا گیا ہے۔

ERP انٹیگریشن میں کون سا ڈیٹا کس کی ملکیت ہے

اصول یہ ہے: ہر فیلڈ کا صرف ایک مالک ہوتا ہے، یعنی وہ واحد سسٹم جسے اسے بدلنے کی اجازت ہے۔ دوسرا سسٹم اسے صرف پڑھتا ہے۔ ایک عام تقسیم:

ڈیٹاعموماً کس کی ملکیت
آئٹمز، BOM، روٹنگزERP (یا انجینئرنگ)
سیلز آرڈرز، مطلوبہ تاریخیںERP
وعدہ شدہ تاریخیںERP، جنہیں سیلز حساب شدہ تاریخ دیکھ کر طے کرتی ہے
آپریشنز کی تاریخیں، مشینیں، ترتیبپلاننگ ٹول
شاپ فلور کے لیے جاب آرڈرزپلاننگ ٹول
درست اور اسکریپ کی کنفرمیشنزجہاں شاپ فلور انہیں درج کرتا ہے
اسٹاک بیلنس، گڈز ریسیٹ، لاگتERP

آپ کی تقسیم مختلف ہو سکتی ہے۔ اہم یہ ہے کہ وہ لکھی ہوئی ہو۔

دو باورچیوں کا سوچیے جو ایک ہی سالن میں نمک ڈال رہے ہیں۔ ہر ایک چکھتا ہے، پھیکا پاتا ہے، اور نمک ڈال دیتا ہے۔ دونوں نے سمجھ داری سے کام کیا۔ سالن خراب ہو گیا۔ جس ڈیٹا کے دو مالک ہوں، اس کا بھی یہی حال ہوتا ہے۔

غلط فہمی: "اچھی انٹیگریشن ہر چیز کو دونوں طرف، ریئل ٹائم میں سنک کرتی ہے"

ہر فیلڈ کو دونوں طرف بھیجنے سے یہ یقینی ہو جاتا ہے کہ دونوں سسٹم ایک دوسرے کا ڈیٹا اوور رائٹ کریں گے۔ اچھی انٹیگریشن منتخب ہوتی ہے: وہی جو دوسری طرف کو چاہیے، جب چاہیے، اور ہر فیلڈ کے لیے ایک ہی سمت۔ کنفرمیشنز ہر چند منٹ بعد جا سکتی ہیں، آئٹم ڈیٹا دن میں ایک بار۔

SAP، Oracle، Dynamics: سوال وہی

ان میں سے کوئی بات برانڈ پر منحصر نہیں۔ SAP، Oracle یا Microsoft Dynamics 365، کسی کے ساتھ بھی آپ کو طے کرنا ہوگا کہ "باقی" کا مطلب کیا ہے، کون سی تاریخ کون سی ہے، اور ہر فیلڈ کا مالک کون ہے۔ فیلڈ میپنگ ہر سسٹم اور کنفیگریشن میں مختلف ہوتی ہے، اس لیے پہلے ملکیت طے کیجیے۔ الگ پلاننگ لیئر کی ضرورت ہی کیوں پڑتی ہے، یہ ERP کے خیال میں ہر آرڈر 10 دن کیوں لیتا ہے میں سمجھایا گیا ہے۔

factory.online کیسے مدد کرتا ہے

factory.online کی SAP اور Microsoft Dynamics 365 کے ساتھ انٹیگریشن موجود ہے۔ اگر آپ Oracle یا کوئی اور ERP چلاتے ہیں تو پوچھ لیجیے کہ آپ کے سیٹ اپ کے لیے کنکشن میں کیا کچھ شامل ہوگا۔ factory.online کے اندر پلانر ہر مینوفیکچرنگ آرڈر کو اس کے جاب آرڈرز اور ہر آپریشن کی درست اور اسکریپ کنفرمیشنز کے ساتھ دیکھتا ہے، اس لیے ویلڈ شدہ 60 بریکٹس اور باقی 40 دونوں نظر آتے ہیں، اور کسٹمر آرڈر سے جڑے رہتے ہیں۔ تیار ہونے والے بیچز اپنی ہسٹری بیچ ٹریس ایبلٹی کے لیے محفوظ رکھتے ہیں۔

اگر آپ کا ERP، آپ کا پلانر اور آپ کا شاپ فلور تین مختلف جواب دیتے ہیں، تو ڈیمو بک کیجیے، ہم مل کر ان میں سے کسی ایک آرڈر کو ٹریس کریں گے۔

آپ کی فیکٹری اسپریڈ شیٹس اور اندازے سے بہتر کی مستحق ہے۔