ERP ڈیٹا کی منتقلی: بہترین طرز عمل اور عام نقصانات

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

اصطلاح "ڈیٹا منتقلی" تکنیکی اور آپریشنل لگتا ہے۔ عملی طور پر، یہ آپریشن کے سالوں کے جمع کردہ ڈیٹا کوالٹی قرض کا مقابلہ کرنے کے لیے ایک تنظیمی مشق ہے۔ ڈپلیکیٹ گاہک کے ریکارڈ، متضاد پروڈکٹ کوڈز، غیر مربوط انوینٹری شمار، گمشدہ سپلائر کی معلومات، اور میراثی ڈیٹا ڈھانچے جو جدید ERP ڈیٹا ماڈلز کے لیے صاف نقشہ نہیں بناتے — یہ مسائل ختم نہیں ہوتے کیونکہ ایک نیا نظام نصب کیا گیا ہے۔ وہ ہجرت کرتے ہیں، اور وہ نئے نظام میں مسائل پیدا کرتے ہیں جنہیں ٹھیک کرنا بعض اوقات پرانے نظام سے زیادہ مہنگا ہوتا ہے۔

یہ گائیڈ مکمل ڈیٹا مائیگریشن لائف سائیکل کا احاطہ کرتا ہے جس میں ہر ایک مرحلے کے لیے مخصوص، قابل عمل رہنمائی اور ان نقصانات کی ایماندارانہ وضاحت ہوتی ہے جن کا سامنا زیادہ تر ERP منتقلی کو ہوتا ہے۔

اہم ٹیک ویز

• ڈیٹا کی منتقلی عام طور پر ERP کے نفاذ کا سب سے کم تخمینہ مرحلہ ہے (بجٹ 3–5x ابتدائی تخمینہ)
• عمل درآمد شروع ہونے سے چھ سے بارہ ہفتے پہلے ڈیٹا کے معیار کی جانچ شروع کریں۔
• کبھی بھی خراب ڈیٹا کو منتقل نہ کریں - پہلے اسے صاف کریں، دوسرے صاف ڈیٹا کو منتقل کریں۔
• "صرف ہر چیز کو منتقل کریں اور اسے بعد میں صاف کریں" نقطہ نظر قابل اعتماد طور پر ناکام ہوجاتا ہے۔
• منتقلی سے پہلے ڈیٹا کی ملکیت قائم کریں: ہر ڈیٹا کے ادارے کے معیار کے لیے کون جوابدہ ہے؟
• منتقلی سے پہلے توثیق کے اصول بنائیں، اس کے دوران نہیں۔
• کٹ اوور ہجرت سے پہلے دو سے تین مائیگریشن ٹیسٹ کا منصوبہ بنایا جاتا ہے۔
• تاریخی ڈیٹا اور اوپننگ بیلنس مختلف حل کے ساتھ الگ الگ مسائل ہیں۔

---

ERP منتقلی میں ڈیٹا کی چار اقسام

ERP منتقلی میں تمام ڈیٹا برابر نہیں بنایا گیا ہے۔ چار اقسام اور ان کے الگ الگ ہجرت کے چیلنجوں کو سمجھنا کامیاب ہجرت کی منصوبہ بندی کرنے کا پہلا قدم ہے۔

ٹائپ 1: ماسٹر ڈیٹا

ماسٹر ڈیٹا ہر لین دین کی بنیاد ہے: کسٹمر ریکارڈ، سپلائر ریکارڈ، مصنوعات (آئٹمز)، کھاتوں کا چارٹ، ملازمین، اور گودام/مقام کے درجہ بندی۔ ماسٹر ڈیٹا کوالٹی براہ راست لین دین کے ڈیٹا کے معیار کا تعین کرتا ہے — اگر کسی صارف کے ریکارڈ کو ڈپلیکیٹ کیا جاتا ہے، تو اس صارف کے ساتھ منسلک ہر لین دین ڈپلیکیشن کے مسئلے کو پیچیدہ کر دے گا۔

ماسٹر ڈیٹا کی منتقلی عام طور پر سب سے زیادہ محنت کا مرحلہ ہوتا ہے کیونکہ اس کے لیے ڈیٹا کوالٹی کے ہر مسئلے کے بارے میں کاروباری فیصلوں کی ضرورت ہوتی ہے۔ کیا ڈپلیکیٹ گاہک کے ریکارڈ کو ضم کیا جانا چاہیے؟ اگر ایسا ہے تو، مستند ریکارڈ کون سا ہے؟ پیمائش کی متضاد اکائیوں والی مصنوعات کو کس طرح معیاری بنایا جانا چاہیے؟

ٹائپ 2: اوپننگ بیلنس

اوپننگ بیلنس گو لائیو کے مقام پر کاروبار کی مالی حالت کی نمائندگی کرتے ہیں: وصول کیے جانے والے اکاؤنٹس (جن پر آپ کے پیسے واجب الادا ہیں)، قابل ادائیگی اکاؤنٹس (جن کے آپ پر پیسے واجب الادا ہیں)، انوینٹری کی قدریں (آپ کے پاس کون سا اسٹاک ہے اور کس قیمت پر)، اور عام لیجر اکاؤنٹ بیلنس۔ اوپننگ بیلنس پینی کے لیے درست ہونا چاہیے — وصول کیے جانے والے اکاؤنٹس میں $0.01 کا فرق مہینوں تک مصالحت کے مسائل کا سبب بنے گا۔

اوپننگ بیلنس کی توثیق میراثی نظام کی بند ہونے والی حالت کے خلاف کی جاتی ہے اور گو لائیو آگے بڑھنے سے پہلے ٹھیک ٹھیک سمجھوتہ کرنا ضروری ہے۔ یہ توثیق اکثر میراثی نظام اور حقیقی کاروباری حالت کے درمیان تضادات کو ظاہر کرتی ہے (وہ رسیدیں جو ریکارڈ کی گئی تھیں لیکن کبھی نہیں بھیجی گئیں، انوینٹری جو استعمال کی گئی لیکن ریکارڈ نہیں ہوئی، ادائیگی موصول ہوئی لیکن لاگو نہیں ہوئی)۔

ٹائپ 3: لین دین کی تاریخ

لین دین کی سرگزشت اس کا ریکارڈ ہے کہ کیا ہوا ہے: خریداری کے آرڈرز، سیلز انوائسز، انوینٹری کی نقل و حرکت، HR ریکارڈز وغیرہ۔ اوپننگ بیلنس کے برعکس، لین دین کی سرگزشت کو آپریشنز کو فعال کرنے کے لیے بالکل درست ہونے کی ضرورت نہیں ہے — اسے رپورٹنگ، آڈیٹنگ، اور حوالہ کے مقاصد کے لیے کافی حد تک درست ہونے کی ضرورت ہے۔

زیادہ تر نفاذ کے لیے، پچھلے دو سے تین سالوں کی لین دین کی تاریخ کافی ہے۔ پرانی تاریخ کو عام طور پر نئے ERP میں منتقل کرنے کے بجائے حوالہ کے لیے میراثی نظام میں محفوظ کیا جا سکتا ہے۔

قسم 4: کنفیگریشن ڈیٹا

کنفیگریشن ڈیٹا کاروباری ڈیٹا نہیں ہے بلکہ وہ ترتیبات ہیں جو سسٹم کو صحیح طریقے سے برتاؤ کرتی ہیں: ادائیگی کی شرائط، ٹیکس کی شرحیں، قیمتوں کے اصول، ورک فلو کنفیگریشنز، صارف کے کردار وغیرہ۔ اگرچہ یہ تکنیکی طور پر "ہجرت" کا حصہ ہے، اسے زیادہ درست طریقے سے کنفیگریشن ریپلیکیشن کے طور پر بیان کیا گیا ہے - نئے ERP کے کنفیگریشن ماڈل میں میراثی نظام کے کاروباری اصولوں کو دوبارہ بنانا۔

---

مرحلہ 1: ڈیٹا کی دریافت اور تشخیص

ڈیٹا کی دریافت کا مرحلہ عمل درآمد شروع ہونے سے چھ سے بارہ ہفتے پہلے شروع ہونا چاہیے - عمل درآمد کے پہلے سے جاری ہونے کے بعد نہیں۔ عمل درآمد کے دوران ڈیٹا کوالٹی کے سنگین مسائل کو دریافت کرنا، اس سے پہلے کی بجائے، ERP ٹائم لائن اووررن کی سب سے عام وجہ ہے۔

ڈیٹا انوینٹری:

ہر ڈیٹا ہستی کو کیٹلاگ کریں جو میراثی نظام(سسٹم) میں موجود ہے:

• کون سے ادارے موجود ہیں (صارفین، سپلائرز، مصنوعات، ملازمین، وغیرہ)
• جہاں ہر ایک ہستی رہتی ہے (کون سا نظام یا نظام)
• ہر ادارے کے لیے کتنے ریکارڈ موجود ہیں۔
• ڈیٹا کس فارمیٹ میں ہے (ریلیشنل ڈیٹا بیس، فلیٹ فائلز، اسپریڈ شیٹس)
• کاروبار کا مالک کون ہے جو ہر ادارے کے معیار کا ذمہ دار ہے۔

ڈیٹا کے معیار کی تشخیص:

ہر ایک بڑی ہستی کے لیے، ایک مقداری معیار کی تشخیص کا احاطہ کریں:

• مکمل (ریکارڈ کا کتنا فیصد تمام مطلوبہ فیلڈز آباد ہیں؟) انفرادیت
• مستقل مزاجی (کیا ایک ہی اقدار کی نمائندگی تمام ریکارڈز اور سسٹمز میں مستقل طور پر ہوتی ہے؟)
• درستگی (زمینی سچائی کے خلاف ریکارڈز کا نمونہ اسپاٹ چیک کریں — فزیکل انوینٹری، سپلائی کرنے والے کی اصل رسیدیں، اصل گاہک کی خط و کتابت)

وسط مارکیٹ ERP منتقلی میں عام معیار کے نتائج:

• 8-20% کسٹمر ریکارڈز ڈپلیکیٹ یا قریب نقل ہیں۔
• 15-35% پروڈکٹ ریکارڈز میں پیمائش کی اکائی کا ڈیٹا غائب یا متضاد ہے
• 10-25% انوینٹری ریکارڈز میں ایسے بیلنس ہوتے ہیں جو حالیہ جسمانی گنتی سے میل نہیں کھاتے ہیں۔
• میراثی G/L اکاؤنٹس جو سالوں میں استعمال نہیں ہوئے ہیں اور انہیں ریٹائر ہونا چاہیے۔
• نام کے متضاد کنونشنز، گمشدہ فیلڈز، یا پرانی کردار کی معلومات کے ساتھ ملازم کا ریکارڈ

ہجرت کے خطرے کی تشخیص:

ڈیٹا کے معیار کی تشخیص کی بنیاد پر، ہر ڈیٹا ہستی کو منتقلی کے خطرے سے درجہ بندی کریں:

• کم خطرہ: صاف ڈیٹا، نئے ERP ڈھانچے میں واضح نقشہ سازی، معیاری شکل
• درمیانے درجے کا خطرہ: معیار کے کچھ مسائل، صفائی کی ضرورت ہے لیکن قابل انتظام
• زیادہ خطرہ: اہم معیار کے مسائل، مبہم ڈھانچہ، یا پیچیدہ نقشہ سازی کی ضروریات

اعلی خطرے والے اداروں کو توسیع شدہ ٹائم لائنز، وقف کاروباری مالکان کی شمولیت، اور ممکنہ طور پر ڈیٹا صاف کرنے والے خصوصی ٹولز یا اسکرپٹس کی ضرورت ہوتی ہے۔

---

فیز 2: ڈیٹا کی صفائی

ڈیٹا کی صفائی وہ جگہ ہے جہاں ڈیٹا کی منتقلی کا اصل کام — اور حقیقی قدر — ہوتی ہے۔ مقصد ہر ڈیٹا ہستی کو معیار کی سطح پر لانا ہے جو نئی ERP میں منتقلی کے لیے موزوں ہے۔

خراب ڈیٹا کو کبھی بھی منتقل نہ کریں۔ ڈیٹا کو ابھی منتقل کرنے اور اسے بعد میں صاف کرنے کا لالچ مضبوط ہے، خاص طور پر جب صفائی میں منصوبہ بندی سے زیادہ وقت لگ رہا ہو۔ اس کی مزاحمت کریں۔ نئے ERP میں خراب ڈیٹا میراثی نظام میں خراب ڈیٹا سے بدتر ہے کیونکہ:

• نئے ERP کے توثیق کے اصول ان غلطیوں کو نشان زد کریں گے جنہیں میراثی نظام نے نظر انداز کیا ہے، جس سے فوری آپریشنل مسائل پیدا ہوں گے۔
• نئے ERP میں ڈیٹا کوالٹی کے مسائل کا سامنا کرنے والے صارفین نئے سسٹم کو مورد الزام ٹھہراتے ہیں، نہ کہ بنیادی ڈیٹا کوالٹی کے مسائل
• منتقلی کے بعد ڈیٹا کو صاف کرنے کے لیے نئے ERP کے ڈیٹا ماڈل کو سمجھنے کی ضرورت ہوتی ہے، جو واقف میراثی ڈھانچے میں ڈیٹا کو صاف کرنے سے زیادہ مشکل ہے۔

ڈیٹا صاف کرنے کا عمل:

ہر ایک اعلی اور درمیانے خطرے والے ادارے کے لیے، ایک منظم صفائی کا عمل لاگو کریں:

1. ڈیٹا کو لیگیسی سسٹم سے اسٹیجنگ ماحول میں نکالیں۔
2. معیار کے تمام مسائل کی نشاندہی کرنے کے لیے خودکار توثیق کے اصول چلائیں۔
3. حجم اور اثر کے لحاظ سے مسائل کو ترجیح دیں (100 ڈپلیکیٹ کسٹمر ریکارڈز> 5 غائب سپلائر پوسٹل کوڈز)
4. کاروبار کے مالک کے ان پٹ کے ساتھ مسائل کو حل کریں (جب دو گاہک کے ریکارڈ میں تضاد ہوتا ہے تو مستند ریکارڈ کیا ہوتا ہے؟)
5. آڈٹ ٹریل کے لیے فیصلوں اور قراردادوں کو دستاویز کریں۔
6. تمام مسائل کے حل ہونے کی تصدیق کے لیے توثیق کے قواعد کو دوبارہ چلائیں۔
7. منتقلی سے پہلے کاروبار کے مالک کو صاف کیے گئے ڈیٹا پر سائن آف کریں۔

ڈیٹا صاف کرنے کے اوزار:

ECOSIRE کاروبار کے مالک کے جائزے اور انفرادی ریکارڈ کے فیصلوں کی منظوری کے لیے Excel یا Google Sheets کے ساتھ مل کر خودکار توثیق اور تبدیلی کے لیے Python اسکرپٹس کا استعمال کرتا ہے۔ بہت بڑے ڈیٹا سیٹس کے لیے، وقف شدہ ETL ٹولز (Pentaho، Talend، یا کلاؤڈ مقامی مساوی) بہتر کارکردگی اور آڈٹ لاگنگ فراہم کرتے ہیں۔

---

فیز 3: ڈیٹا میپنگ اور ٹرانسفارمیشن

ڈیٹا میپنگ اس بات کی وضاحت کرتی ہے کہ کس طرح میراثی نظام کے ڈھانچے سے ڈیٹا نئے ERP کے ڈیٹا ڈھانچے میں نقش ہوتا ہے۔ یہ ایک تکنیکی مشق ہے جس میں اہم کاروباری ان پٹ ضروریات ہیں۔

** ساختی نقشہ سازی کے چیلنجز**:

میراثی نظاموں میں اکثر ڈیٹا ڈھانچے ہوتے ہیں جو جدید ERP ڈھانچے کے ساتھ صاف نقشہ نہیں بناتے ہیں۔ عام چیلنجز:

• اکاؤنٹس کی تنظیم نو کا چارٹ: اکاؤنٹس کے لیگیسی چارٹ میں سینکڑوں اکاؤنٹس ہو سکتے ہیں جنہیں نئے ERP میں کلینر ڈھانچے میں یکجا کرنے کی ضرورت ہے۔ استحکام کے ہر فیصلے کے لیے فنانس ٹیم کے ان پٹ کی ضرورت ہوتی ہے۔
• مصنوعات کے درجہ بندی میں تبدیلیاں: میراثی پروڈکٹ کیٹلاگ میں اکثر ایڈہاک درجہ بندی ہوتی ہے جنہیں ERP کے زمرے/ ذیلی زمرہ کے ماڈل میں دوبارہ ترتیب دینے کی ضرورت ہوتی ہے۔ ہر پروڈکٹ کو اس کے نئے زمرے میں میپ کرنے کی ضرورت ہے۔
• ملٹی کرنسی ری کنفیگریشن: اگر میراثی نظام نافذ ہونے کے بعد سے کاروبار ایک سے زیادہ کرنسیوں میں کام کرنے کے لیے بڑھ گیا ہے، تو نئے ERP میں کرنسی کی ترتیب کو موجودہ حالت کی عکاسی کرنے کی ضرورت ہے، تاریخی کی نہیں۔

تبدیلی کے اصول:

ساختی نقشہ سازی کے علاوہ، ڈیٹا کو اکثر تبدیل کرنے کی ضرورت ہوتی ہے اس سے پہلے کہ یہ نئے سسٹم کی فارمیٹ کی ضروریات کو پورا کرے۔ ہجرت کے چلنے سے پہلے تبدیلی کے قوانین کو دستاویزی شکل دی جانی چاہیے اور کاروبار کے مالک کے ذریعے اس کا جائزہ لینا چاہیے۔ عام تبدیلیاں:

• نام کی معیاری کاری (پہلے آخری فارمیٹ میں تمام صارفین، رجسٹرڈ قانونی نام کے ساتھ تمام سپلائرز)
• فون نمبر فارمیٹ نارملائزیشن (تمام نمبر E.164 بین الاقوامی فارمیٹ میں)
• پتے کی توثیق اور معیاری کاری (پوسٹ کوڈ کی توثیق، ملک کے کوڈ کی معیاری کاری)
• پیمائش کی تبدیلی کی اکائی (وراثتی اکائیوں میں تاریخی ریکارڈ ERP معیاری اکائیوں میں تبدیل)
• اسٹیٹس کوڈ میپنگ (میراثی نظام کے اسٹیٹس کوڈز کو ERP اسٹیٹس ویلیوز میں میپ کیا گیا)

ڈیٹا میپنگ دستاویز:

ڈیٹا میپنگ کا ایک باضابطہ دستاویز تیار کریں جو ظاہر کرتا ہے کہ میراثی نظام کے ہر شعبے کے لیے، نئے ERP میں متعلقہ فیلڈ، لاگو ہونے والی کسی بھی تبدیلی، اور نقشہ سازی پر حکمرانی کرنے والے کاروباری اصول۔ یہ دستاویز اس کے لیے ضروری ہے:

• مطلوبہ رویے کے خلاف ہجرت کے اسکرپٹ کی توثیق کرنا
• جانچ کے دوران پائے جانے والے تضادات کو حل کرنا
• گو لائیو کے بعد آڈٹ کے سوالات کی حمایت کرنا

---

فیز 4: ہجرت کی ترقی اور جانچ

مکمل صفائی اور نقشہ سازی کے دستاویزی ہونے کے ساتھ، منتقلی کے اسکرپٹ کو تیار اور جانچا جا سکتا ہے۔

مائیگریشن اسکرپٹ ڈویلپمنٹ:

مائیگریشن اسکرپٹس سٹیجنگ ماحول سے صاف شدہ ڈیٹا نکالتی ہیں، میپنگ دستاویز کے مطابق تبدیلیاں لاگو کرتی ہیں، اور تبدیل شدہ ڈیٹا کو نئے ERP میں لوڈ کرتی ہیں۔ ECOSIRE لوڈنگ کے لیے Odoo XML-RPC API کا استعمال کرتے ہوئے Python میں مائیگریشن اسکرپٹ تیار کرتا ہے۔ اسکرپٹ میں شامل ہیں:

• منتقلی سے پہلے کی توثیق (تصدیق کریں کہ اسٹیجنگ ماحول میں ڈیٹا منظور شدہ کلین ڈیٹاسیٹ سے میل کھاتا ہے)
• خرابی لاگنگ کے ساتھ بیچ پروسیسنگ (دستی جائزہ کے لیے لوڈ ہونے میں ناکام ہونے والے کسی بھی ریکارڈ کو ریکارڈ کریں)
• نقل مکانی کے بعد کی توثیق (تصدیق کریں کہ لوڈ کردہ ڈیٹا متوقع شمار اور اقدار سے میل کھاتا ہے)
• رول بیک کی اہلیت (اگر ہجرت کا عمل غیر متوقع نتائج پیدا کرتا ہے، ERP کو اس کی منتقلی سے پہلے کی حالت میں دوبارہ ترتیب دینے کی صلاحیت)

ٹیسٹ مائیگریشن چلتا ہے:

کٹ اوور منتقلی سے پہلے دو سے تین ٹیسٹ ہجرت کا منصوبہ بنائیں:

• ٹیسٹ رن 1 (ہفتہ X): مائیگریشن اسکرپٹ کی بنیادی فعالیت کی توثیق کریں اور کسی بھی تبدیلی کی غلطیوں کی نشاندہی کریں
• ٹیسٹ رن 2 (ہفتہ X+2): زیادہ مکمل اور کلینر ڈیٹاسیٹ کے خلاف توثیق کریں؛ پہلی مکمل توثیق کی رپورٹ تیار کریں۔
• ٹیسٹ رن 3 / ڈریس ریہرسل (ہفتہ X+4): حتمی کلین شدہ ڈیٹاسیٹ کے خلاف مکمل اینڈ ٹو اینڈ مائیگریشن رن، وقت پر، کٹ اوور کے عمل کو بالکل اسی طرح انجام دیا گیا جیسا کہ یہ گو لائیو ڈے پر ہوگا۔

ہر ٹیسٹ رن کو متوقع شماروں، اقدار، اور حوالہ جاتی سالمیت کی رکاوٹوں کے خلاف منتقل شدہ ڈیٹا کا موازنہ کرنے والی توثیق کی رپورٹ پیش کرنی چاہیے۔ اگلے ٹیسٹ چلانے سے پہلے تضادات کو حل کرنا ضروری ہے۔

---

فیز 5: اوپننگ بیلنس ریکنسیلیشن

اوپننگ بیلنس کا مفاہمت ماسٹر ڈیٹا اور ٹرانزیکشن ہسٹری کی منتقلی سے الگ ہے کیونکہ اس کے لیے صرف ڈیٹا کی تکمیل کی بجائے پوائنٹ ان ٹائم مالی درستگی کی ضرورت ہوتی ہے۔

مفاہمت کا عمل:

متفقہ کٹ اوور تاریخ پر، ہر مالیاتی ادارے کے لیے میراثی نظام سے اختتامی بیلنس نکالیں: اکاؤنٹس قابل وصول عمر، اکاؤنٹس قابل ادائیگی عمر، مقام کے لحاظ سے انوینٹری کی قدریں، G/L اکاؤنٹ بیلنس۔ یہ نئے ERP میں اوپننگ بیلنس بن جاتے ہیں۔

نکالے گئے بیلنس کو اس کے خلاف جوڑیں:

• تازہ ترین بینک اسٹیٹمنٹس (کیش اکاؤنٹس کے لیے)
• سب سے حالیہ اکاؤنٹس قابل وصول عمر رسیدہ رپورٹ کی تصدیق اے آر عملے سے ہوئی۔
• تازہ ترین اکاؤنٹس قابل ادائیگی عمر رسیدہ رپورٹ کی تصدیق اے پی کے عملے سے ہوئی۔
• سب سے حالیہ فزیکل انوینٹری کی گنتی گنتی کی تاریخ سے نقل و حرکت کے لیے ایڈجسٹ کی گئی۔

نکالے گئے بیلنس اور زمینی سچائی کے درمیان کسی بھی تضاد کو گو لائیو سے پہلے حل کیا جانا چاہیے۔ نئے نظام میں تضاد کو لے کر جائیں اور یہ مہینوں تک مفاہمت کے مسائل کا باعث بنے گا۔

"ہمیشہ کے لیے کھلا" انوائس کا مسئلہ:

زیادہ تر میراثی اکاؤنٹنگ سسٹمز میں، کئی ایسی رسیدیں موجود ہیں جو تکنیکی طور پر کھلی ہیں (مکمل طور پر ادا نہیں کی گئی ہیں) لیکن فعال طور پر مردہ ہیں - متنازعہ، ناقابل جمع، یا انتظامی طور پر ترک کر دی گئی ہیں۔ ان "ہمیشہ کے لیے کھلے" رسیدوں کو اوپن اے آر کے طور پر منتقل نہیں کیا جانا چاہیے۔ ہجرت سے پہلے ان کو لکھا جانا چاہیے یا ان کو ناقابل جمع کے طور پر نشان زد کیا جانا چاہیے۔ فنانس ٹیم کو ہر ایک کے بارے میں واضح فیصلے کرنے کی ضرورت ہے۔

---

فیز 6: کٹ اوور کی منصوبہ بندی اور عملدرآمد

کٹ اوور وہ لمحہ ہوتا ہے جب میراثی نظام رک جاتا ہے اور نیا ERP شروع ہوتا ہے۔ کٹ اوور کی ترتیب کو درست طریقے سے پلان کرنا گو لائیو ڈے پر افراتفری کو روکتا ہے۔

** کٹ اوور پلان **:

کٹ اوور کے عمل کے ہر مرحلے کو اس کے ساتھ دستاویز کریں:

• جو قدم انجام دیتا ہے
• قدم کی تخمینی مدت
• انحصار (یہ مرحلہ شروع ہونے سے پہلے کیا مکمل ہونا چاہیے)
• توثیق کی جانچ (آپ کیسے تصدیق کرتے ہیں کہ مرحلہ مکمل اور درست ہے)
• رول بیک ایکشن (اگر یہ مرحلہ ناکام ہو جائے تو کیا کریں)

100 افراد کی کمپنی کے لیے ایک عام کٹ اوور میں 8-16 گھنٹے لگتے ہیں۔ کاروباری خلل کو کم کرنے کے لیے کٹ اوور عام طور پر ہفتے کے آخر میں طے کیا جاتا ہے۔

کٹ اوور کی ترتیب:

1. میراثی نظام منجمد: کسی نئے لین دین کی اجازت نہیں ہے۔
2. میراثی نظام سے حتمی ڈیٹا نکالنا
3. حتمی ڈیٹا کی توثیق اور صفائی (آخری ٹیسٹ چلانے کے بعد سے دریافت ہونے والا کوئی بھی مسئلہ)
4. ماسٹر ڈیٹا کے لیے مائیگریشن اسکرپٹ پر عمل درآمد
5. اوپننگ بیلنس کی منتقلی اور توثیق
6. لین دین کی تاریخ کی منتقلی (اگر حالیہ تاریخ کی منتقلی ہو)
7. مکمل توثیق کی رپورٹ کا جائزہ اور فنانس کے ذریعے سائن آف
8. سسٹم کنفیگریشن کی توثیق (تمام ترتیبات درست)
9. کاروبار کے لیے نئی ERP کھولی گئی۔

---

عام نقصانات اور ان سے کیسے بچنا ہے۔

خطرہ 1: ہر چیز کو منتقل کرنا

تمام تاریخی ڈیٹا کو منتقل کرنے کا جذبہ قابل فہم ہے لیکن اکثر الٹا نتیجہ خیز ہے۔ میراثی نظام سے لین دین کی دس سال کی تاریخ کو منتقلی، توثیق کرنے اور لوڈ کرنے میں ہفتے لگتے ہیں — اور اس میں سے زیادہ تر کو کبھی نہیں پوچھا جائے گا۔ ہجرت کے افق کی وضاحت کریں (عام طور پر دو سے تین سال) اور پرانی تاریخ کو ہجرت کرنے کے بجائے میراثی نظام میں محفوظ کریں۔

خطرہ 2: فرض کریں کہ میراثی نظام کا ڈیٹا سچائی کا ذریعہ ہے

میراثی نظام کا ڈیٹا اکثر غلط ہوتا ہے۔ اگر آپ اسے مستند سمجھتے ہیں، تو آپ غلطیوں کو نئے نظام میں منتقل کر دیتے ہیں۔ جسمانی شمار، بینک اسٹیٹمنٹس، اور سپلائر کے بیانات میراثی نظام کی رپورٹس کے مقابلے میں اوپننگ بیلنس کے لیے سچائی کے بہتر ذرائع ہیں۔

خطرہ 3: کوئی ٹیسٹ ماحول نہیں

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

خطرہ 4: کاروبار کے مالک کی ناکافی شمولیت

ڈیٹا کی صفائی اور نقشہ سازی کے فیصلوں کے لیے کاروباری فیصلے کی ضرورت ہوتی ہے جو تکنیکی ٹیموں کے پاس نہیں ہے۔ کاروباری مالکان کی ناکافی شمولیت تکنیکی ٹیموں کو کاروباری فیصلے کرنے کا باعث بنتی ہے جو غلط ہیں، جس سے ڈیٹا کے معیار کے مسائل پیدا ہوتے ہیں جو لائیو کے بعد آپریشنل مسائل کے طور پر سامنے آتے ہیں۔

خطرہ 5: کوئی رول بیک پلان نہیں

ہر گو لائیو کا ایک واضح رول بیک پلان ہونا چاہیے: اگر نیا سسٹم پہلے 24-48 گھنٹوں میں صحیح طریقے سے کام کرنے میں ناکام ہو جاتا ہے، تو میراثی نظام پر واپس جانے کا کیا عمل ہے؟ اس منصوبے کے تیار ہونے سے بحران میں جلد بازی میں فیصلے کرنے کا دباؤ کم ہو جاتا ہے۔

---

اکثر پوچھے گئے سوالات

ہمیں ERP کے نفاذ میں ڈیٹا کی منتقلی کے لیے کب تک منصوبہ بندی کرنی چاہیے؟

ایک وسط مارکیٹ کمپنی کے لیے (100–300 ملازمین، 2–5 ڈیٹا سورس سسٹمز)، ڈیٹا کی منتقلی کے لیے چھ سے دس ہفتوں کا منصوبہ ایک وقف شدہ مرحلے کے طور پر بنائیں، ترتیب کے مکمل ہونے کے بعد شروع کریں تاکہ ہدف ڈیٹا کا ڈھانچہ قائم ہو سکے۔ مزید برآں، ڈیٹا کے معیار کی جانچ اور ابتدائی صفائی کے لیے عمل درآمد شروع ہونے سے پہلے چار سے چھ ہفتے مختص کریں۔ ڈیٹا کی منتقلی کی کل سرمایہ کاری عام طور پر پہلی تشخیص سے کٹ اوور تک دس سے سولہ ہفتے ہوتی ہے۔

کیا ہمیں عمل درآمد سے پہلے یا اس کے دوران ڈیٹا صاف کرنا چاہیے؟

پہلے، ہمیشہ۔ ڈیٹا کی صفائی جو عمل درآمد کے متوازی طور پر ہوتی ہے وہی کاروباری مالک کے وسائل کا استعمال کرتی ہے جن کی نفاذ ٹیم کو کنفیگریشن کی توثیق اور جانچ کے لیے ضرورت ہوتی ہے۔ اس سے ہجرت کی ٹائم لائن میں بھی تاخیر ہوتی ہے کیونکہ صفائی کا انحصار کاروباری فیصلوں پر ہوتا ہے جنہیں جمع ہونے میں وقت لگتا ہے۔ عمل درآمد کِک آف سے چھ سے بارہ ہفتے پہلے ڈیٹا کی صفائی شروع کرنا سب سے مؤثر طریقہ ہے۔

کیا ECOSIRE کسی بھی لیگیسی ERP سے ڈیٹا کو منتقل کر سکتا ہے؟

ECOSIRE نے SAP Business One، QuickBooks (ڈیسک ٹاپ اور آن لائن)، Sage 50 اور Sage 100، Microsoft Dynamics (GP، NAV، BC)، اور متعدد صنعت کے مخصوص پلیٹ فارمز کے لیے مائیگریشن ٹولنگ بنائی ہے۔ دوسرے سسٹمز کے لیے، منتقلی کا طریقہ دستیاب برآمدی فارمیٹ — SQL ڈیٹا بیس، XML، CSV برآمدات، یا API رسائی کی بنیاد پر ڈیزائن کیا گیا ہے۔ کسی میراثی نظام کا سامنا نہیں کیا گیا ہے جسے منتقل نہیں کیا جا سکتا، حالانکہ یہ کوشش سورس سسٹم کے لحاظ سے نمایاں طور پر مختلف ہوتی ہے۔

ERP کے نفاذ میں ڈیٹا کی منتقلی کی عام لاگت کیا ہے؟

ECOSIRE کے نفاذ کے لیے، ڈیٹا کی منتقلی عام طور پر عمل درآمد کی کل لاگت کے 15-25% کی نمائندگی کرتی ہے۔ $150,000 کے نفاذ کے لیے، ڈیٹا کی منتقلی کی لاگت $22,000–$37,000 ہے۔ رینج بنیادی طور پر ڈیٹا کے معیار (کم معیار = زیادہ صفائی کی لاگت) اور حجم (زیادہ ریکارڈ = زیادہ اسکرپٹ کی ترقی اور توثیق کا وقت) پر منحصر ہے۔ منتقلی شروع ہونے کے بعد دریافت ہونے والے ڈیٹا کے معیار کے مسائل اس لاگت کو نمایاں طور پر بڑھا سکتے ہیں، یہی وجہ ہے کہ عمل درآمد سے پہلے کی تشخیص کی سرمایہ کاری بہت قیمتی ہے۔

---

اگلے اقدامات

اگر آپ ERP کے نفاذ کی منصوبہ بندی کر رہے ہیں اور ٹائم لائن اور بجٹ کے وعدے کرنے سے پہلے اپنے ڈیٹا کے معیار کا اندازہ لگانے میں مدد چاہتے ہیں، تو ECOSIRE ڈیٹا کی تیاری کا ایک جائزہ پیش کرتا ہے جو آپ کے ڈیٹا کے اہم اداروں کا جائزہ لیتا ہے، معیار کے مسائل کی نشاندہی کرتا ہے، اور منتقلی کے مرحلے کے لیے حقیقت پسندانہ تخمینہ فراہم کرتا ہے۔

ECOSIRE کے Odoo مائیگریشن پریکٹس کے بارے میں مزید جانیں /services/odoo/migration پر۔