اس مضمون میں
دوسرے حصے نے آپ کو ایک صفحے کی فہرست دی تھی: اہم فائلیں، ان کے ذمہ دار، ان پر کیا منحصر ہے، اور آیا ان کا بیک اپ موجود ہے۔ وہ فہرست بتاتی ہے کہ کیا منتقل کرنا ہے۔ یہ حصہ بتاتا ہے کہ کیا جوں کا توں منتقل نہیں ہونا چاہیے۔
عام خیال یہ ہے کہ منتقلی ایک تکنیکی قدم ہے: فائل ایکسپورٹ کریں، نئے سسٹم میں امپورٹ کریں، کام ختم۔ تکنیکی طور پر یہ درست ہے، اور عملی طور پر یہ ایک چھوٹے مسئلے کو مہنگے مسئلے میں بدلنے کا تیز ترین طریقہ ہے۔ اسپریڈشیٹ اپنی ساخت ہی سے درگزر کرنے والی ہوتی ہے: آپ کسی بھی سیل میں جو کچھ ٹائپ کریں وہ قبول کر لیتی ہے اور اس کی تشریح کا کام آپ پر چھوڑ دیتی ہے۔ سسٹم ایسا نہیں ہوتا: وہ توقع کرتا ہے کہ تاریخ تاریخ ہو، نمبر نمبر ہو، اور گاہک ایک ریکارڈ والا ایک ادارہ ہو۔ اس لیے جب غیر صاف ڈیٹا منتقل ہوتا ہے تو گڑبڑ غائب نہیں ہوتی؛ وہ ایسی رپورٹوں کی صورت میں سامنے آتی ہے جن کا حساب نہیں بیٹھتا، ایسی انوائسز جو اپنے گاہک سے نہیں جڑتیں، اور ایسے بیلنس جو میل نہیں کھاتے۔ پھر وہ جملہ آتا ہے جو بہت سے منصوبوں کو ختم کر دیتا ہے: نیا سسٹم کام نہیں کرتا۔
صفائی منتقلی سے پہلے کیوں ہونی چاہیے، بعد میں کیوں نہیں
اسے ٹالنا ایک معقول وجہ سے پرکشش لگتا ہے: صفائی ایک اکتا دینے والا کام ہے جو کسی پریزنٹیشن میں نظر نہیں آتا، جبکہ نئے سسٹم کی اسکرین نظر آتی ہے۔ چنانچہ ابھی منتقل کرنے اور بعد میں صاف کرنے کا فیصلہ ہوتا ہے۔ لیکن جیسے ہی ڈیٹا اندر پہنچتا ہے، حرکت میں آ جاتا ہے: دہرائے گئے گاہکوں کے نام پر انوائسز جاری ہوتی ہیں، آرڈر دہرائے گئے آئٹمز سے جڑتے ہیں، اور رپورٹیں نامکمل اعداد پر بنتی ہیں۔ ہر نیا لین دین غلطی کے اوپر ایک تہہ چڑھاتا ہے جو اسے درست کرنا زیادہ مشکل اور پرخطر بنا دیتی ہے، کیونکہ جس ریکارڈ پر مالی لین دین چل چکے ہوں اس میں ترمیم کرنا کسی فائل کے سیل میں ترمیم کرنے جیسا بالکل نہیں۔
غیر صاف ڈیٹا عمومی طور پر رکے ہوئے سسٹم منصوبوں کی ایک بار بار سامنے آنے والی وجہ ہے، اور ہم نے اسے دیگر وجوہات کے ساتھ ERP منصوبے کیوں ناکام ہوتے ہیں اور اپنے منصوبے کو کامیاب کیسے بنائیں میں بیان کیا ہے۔ عملی نتیجہ یہ ہے کہ صفائی اس وقت سب سے سستی ہوتی ہے جب ڈیٹا ایک جامد فائل میں پڑا ہو، اور اس وقت سب سے مہنگی جب وہ ایک چلتے ہوئے سسٹم میں رہنے لگے۔
تقریباً ہر شیٹ میں موجود پانچ خامیاں
یہ کوئی انوکھی غلطیاں نہیں؛ یہ ایک ایسے ٹول کا فطری نتیجہ ہیں جو ہر چیز کی اجازت دیتا ہے۔ ان میں سے زیادہ تر آپ کو اپنی ہی فائل میں ملیں گی:
- ایک فریق، کئی نام۔ ایک ہی گاہک تین بار نظر آتا ہے: ایک بار تجارتی نام سے، ایک بار مالک کے نام سے، اور ایک بار کسی جلد باز شخص کے ٹائپ کیے ہوئے مخفف کی صورت میں۔ فائل میں یہ ساتھ ساتھ کی قطاریں ہیں جنہیں ہر پڑھنے والا سمجھ لیتا ہے۔ سسٹم میں یہ تین الگ گاہک بن جاتے ہیں، ہر ایک کا اپنا بیلنس اور تاریخچہ، چنانچہ تعلق کا ریکارڈ بٹ جاتا ہے اور تینوں میں سے کوئی بھی آپ کو پوری تصویر نہیں دیتا۔ یہی خامی آئٹمز اور سپلائرز میں بھی ہوتی ہے۔
- ملے جلے تاریخ فارمیٹ۔ ایک ہی کالم میں ایک تاریخ دن/مہینہ کی صورت میں، دوسری مہینہ/دن کی صورت میں، اور تیسری ٹیکسٹ میں لکھی ہوتی ہے، جیسے چھٹیوں کے بعد یا مہینے کے آخر میں۔ جب تک اسے صرف انسان پڑھتے ہیں، کام چل جاتا ہے، لیکن اس کالم پر مبنی کوئی بھی ترتیب، مدت کا حساب یا وقت پر مبنی رپورٹ پورے اعتماد کے ساتھ غلط جواب دے گی، جو نظر آنے والی خرابی سے زیادہ خطرناک ہے۔
- ٹیکسٹ کے طور پر محفوظ نمبر۔ سیل کے اندر کرنسی کے نشان کے ساتھ ٹائپ کی گئی رقم، اسی خانے میں پیمائش کی اکائی کے ساتھ مقدار، یا کوئی عدد جو ایک فالتو اسپیس سے شروع ہوتا ہے۔ آنکھ کو یہ نمبر لگتا ہے لیکن مشین کے لیے نہیں، اس لیے یہ نہ جمع ہوتا ہے، نہ موازنہ ہوتا ہے اور نہ منتقل ہوتا ہے؛ اور عموماً آپ کو اس کا پتا منتقلی کے بعد کی پہلی مالی رپورٹ میں چلتا ہے۔
- ایسے کالم جن کی تعریف کوئی نہیں کر سکتا۔ نوٹس، اسٹیٹس یا عارضی نام کا کوئی کالم، جو برسوں پہلے کسی ایسے مقصد کے لیے شامل کیا گیا تھا جو اب ختم ہو چکا، کبھی بھرا ہوا اور کبھی خالی۔ یہ عموماً اس لیے ساتھ منتقل ہو جاتا ہے کہ کوئی اسے حذف کرنے کی ہمت نہیں کرتا، چنانچہ یہ بغیر تعریف اور بغیر ذمہ دار کے فیلڈ کے طور پر سسٹم میں داخل ہوتا ہے اور اسکرینوں پر نظر آتا رہتا ہے تاکہ آپ کے بعد آنے والے کو الجھائے۔
- مطلب رکھنے والے رنگین سیل۔ فہرست میں سب سے خطرناک۔ پیلے کا مطلب واجب الادا، سرخ کا مطلب روکا گیا، سبز کا مطلب وصول ہو گیا۔ یہ فارمیٹنگ نہیں، ڈیٹا ہے؛ لیکن ایسا ڈیٹا جو رنگ میں اور رنگ لگانے والے کی یادداشت میں محفوظ ہے۔ فائل ایکسپورٹ ہونے پر ٹیکسٹ منتقل ہو جاتا ہے اور رنگ رہ جاتا ہے، چنانچہ آپ وہ معلومات کھو دیتے ہیں جن کے سہارے آپ روزانہ کاروبار چلاتے تھے، اور کوئی انتباہ بھی جاری نہیں ہوتا۔
واحد اصول: سیل سے باہر ہر مطلب کو فیلڈ بننا چاہیے
اگر آپ اس حصے سے صرف ایک جملہ یاد رکھیں تو یہ رکھیں: رنگ میں، کسی قطار کی جگہ میں یا کسی کے ذہن میں موجود ہر مطلب کو منتقل ہونے سے پہلے ایک تحریری کالم بننا چاہیے۔ ٹیسٹ سادہ اور بے رحم ہے: فائل کو بغیر کسی فارمیٹنگ کے سادہ ٹیکسٹ میں ایکسپورٹ کریں اور پوچھیں کہ کون سی معلومات ضائع ہوئیں۔ اس ٹیسٹ میں جو کچھ غائب ہو جائے، ٹھیک وہی ہے جسے اب فیلڈ بننا ہے۔
یہ تبدیلی بذات خود تکنیکی کام نہیں؛ یہ تعریف متعین کرنے کی مشق ہے۔ صرف ایک اسٹیٹس کالم بنا دینا کافی نہیں: آپ کو اس کی اجازت یافتہ قدریں طے کرنی ہوں گی اور ایک دوسرے سے ٹکرانے والی قدروں کو سلجھانا ہوگا۔ روکا گیا اور منسوخ ایک حالت ہیں یا دو؟ کوئی ریکارڈ ٹھیک کس مقام پر واجب الادا بنتا ہے؟ یہ سوالات پروگرامنگ کے بارے میں نہیں بلکہ اس بارے میں ہیں کہ کمپنی کیسے کام کرتی ہے، اور یہی وہ سب سے قیمتی چیز ہے جو کوئی مالک صفائی کے مرحلے سے حاصل کرتا ہے، کیونکہ ان کا ایک بار واضح جواب دے دینے سے وہ بحثیں ختم ہو جاتی ہیں جو پہلے ہر بار زبانی طور پر نمٹائی جاتی تھیں۔
Origami کا نقطۂ نظر
ہم ایک ٹیکنالوجی کمپنی ہیں جو سعودی کاروباروں کے لیے سسٹم بناتی ہے، اور ہم صفائی کے مرحلے کو اس سے پہلے ہونے والے انتظامی کام کے بجائے سسٹم ڈیزائن کا حصہ سمجھتے ہیں۔ وجہ یہ ہے کہ ڈیٹا کی ہر خامی ایک غیر تحریری کاروباری اصول کو بے نقاب کرتی ہے: دہرایا گیا گاہک ظاہر کرتا ہے کہ کسی فریق کے لیے کوئی متفقہ شناخت کنندہ موجود نہیں، اور رنگین سیل ایک ایسی حقیقی عملی حالت ظاہر کرتا ہے جسے کسی نے کبھی باضابطہ طور پر تسلیم نہیں کیا۔ یہ دریافتیں درست ڈیزائن کا خام مال ہیں، اسی لیے ہم انہیں کسی امپورٹ ٹول میں ڈالنے کے بجائے گاہک کے ساتھ مل کر پڑھتے ہیں۔
ہم جس ترتیب کی سفارش کرتے ہیں وہ یہ ہے کہ پہلے تعریفوں کو یکساں کیا جائے: کون ایک گاہک شمار ہوگا، کیا ایک آئٹم شمار ہوگا، اور ہر فیصلہ کن فیلڈ میں کون سی قدریں جائز ہیں۔ اس کے بعد منتقلی ایک صاف عمل بن جاتی ہے جسے دہرایا اور جانچا جا سکتا ہے۔ سسٹم بنانے میں ہماری خدمات یہیں سے شروع ہوتی ہیں، اور یہ وہی منطق ہے جو ہم نے ایک حقیقی کیس میں دیکھی جسے ہم نے دکان سے سسٹم تک میں بیان کیا: منظم کارروائیوں کو عارضی بندوبست والی کارروائیوں سے انٹرفیس الگ نہیں کرتا بلکہ اس کے نیچے موجود ڈیٹا کا نظم و ضبط الگ کرتا ہے۔
صفائی کی ایک عملی ترتیب
ہر فائل کو مکمل طور پر صاف کرنا کبھی نہ ختم ہونے والا منصوبہ ہے۔ ایسی ترتیب سے کام کریں جو چند ہی دنوں میں آپ کو منتقلی کے قابل کچھ دے دے:
- لین دین سے نہیں، ماسٹر ڈیٹا سے شروع کریں۔ گاہک، آئٹمز اور سپلائرز مختصر فہرستیں ہیں جو بار بار استعمال ہوتی ہیں، اور انہیں صاف کرنے سے وہ ہزاروں قطاریں خود بخود درست ہو جاتی ہیں جو بعد میں ان سے جڑیں گی۔ انوائسز اور آرڈرز اس کے بعد آتے ہیں۔
- ہر ادارے کے لیے ایک شناخت کنندہ اپنائیں۔ ایک مستقل کوڈ یا نمبر جو کبھی نہ بدلے اور کبھی دوبارہ استعمال نہ ہو، پھر ہر پرانے نام اور مخفف کو اس سے جوڑیں۔ خاص طور پر گاہکوں کے لیے خریدار کی درست قانونی تفصیلات کوئی تکلف نہیں، کیونکہ زکوٰۃ، ٹیکس اور کسٹمز اتھارٹی (ZATCA) کی ای انوائسنگ کی شرائط طے کرتی ہیں کہ ٹیکس انوائس میں کیا ہونا چاہیے؛ اور ہم نے کسی نقل و حرکت اور اس کی انوائس کے درمیان تعلق فیکٹری اور گودام میں ای انوائسنگ میں بیان کیا ہے۔
- ہر مرکب سیل کو الگ کریں۔ مقدار ایک کالم میں اور پیمائش کی اکائی دوسرے میں، رقم ایک میں اور کرنسی دوسرے میں، نام ایک میں اور موبائل نمبر دوسرے میں۔ اصول یہ ہے: ایک خانے میں ایک معلومات۔
- کسی بھی امپورٹ سے پہلے فارمیٹ یکساں کریں۔ پوری فائل میں ایک تاریخ فارمیٹ، سیل کے اندر بغیر نشانات کے نمبر، اور موبائل نمبروں کے لیے ایک ہی فارمیٹ۔ کام دہرایا جانے والا اور اکتا دینے والا ہے، لیکن ایک ہی بار ہوتا ہے۔
- صفائی کے اپنے فیصلے ایک الگ شیٹ پر درج کریں۔ کس کو کس میں ضم کیا گیا، کیا حذف کیا گیا، اور کیا اب بھی مشکوک ہے۔ جب کوئی دو مہینے بعد پوچھے کہ فلاں گاہک کہاں گیا، تو وہ شیٹ ہی جواب ہے؛ اس کے بغیر ٹیم پوری منتقلی پر اعتماد کھو دیتی ہے۔
- اصل فائل حذف نہ کریں۔ صفائی سے پہلے والی فائل کو ایک بند، صرف پڑھنے کے قابل نقل کے طور پر رکھیں۔ صفائی میں فیصلے کرنے پڑتے ہیں، اور فیصلوں کو لوٹ کر دیکھنے کے لیے ایک حوالہ چاہیے۔
اور منتقلی کے لیے کامل ڈیٹا کا انتظار نہ کریں، کیونکہ وہ کبھی نہیں آتا۔ آپ کو جس صفائی کی ضرورت ہے وہ یہ ہے کہ اہم فیلڈز درست، یکساں اور متعین ہوں، اور جو کچھ نامکمل رہ جائے وہ بعد میں اچانک انکشاف کے بجائے معلوم اور درج ہو۔
آنے والے حصوں میں
ڈیٹا اب منتقلی کے قابل ہے، اور اب وہ سوال باقی ہے جو طے کرتا ہے کہ تبدیلی کے دوران کاروبار چلتا رہے گا یا رک جائے گا: پہلے کیا منتقل ہوگا؟ اگلا حصہ منتقلی کی ترتیب پر ہے، کہ ماسٹر ڈیٹا ہمیشہ لین دین سے پہلے کیوں آتا ہے، اور متوازی عمل کھلی نہیں بلکہ اعلان شدہ اختتامی تاریخ کے ساتھ کیسے چلتا ہے۔ اس کے بعد ہم اجازتوں اور کون کیا دیکھتا ہے کی طرف آئیں گے، پھر ان رپورٹوں کی طرف جو آپ ہاتھ سے بناتے تھے، اور سلسلے کو منتقلی کے بعد کے پہلے تیس دنوں کے ساتھ ختم کریں گے۔
ذرائع
- زکوٰۃ، ٹیکس اور کسٹمز اتھارٹی (ZATCA): ٹیکس انوائس کی شرائط، خریدار کی تفصیلات اور دستاویزات کی حفاظت۔
- سعودی ڈیٹا اور مصنوعی ذہانت اتھارٹی (SDAIA): ذاتی ڈیٹا کے تحفظ کا قانون (PDPL) اور افراد کے ڈیٹا سے نمٹنے کے قواعد۔
- وزارت انسانی وسائل و سماجی ترقی: ملازمین کے ریکارڈ اور ڈیٹا رکھنے کی شرائط۔
- وزارت تجارت: اداروں کے تجارتی کھاتوں اور ریکارڈ سے متعلق دفعات۔
- قومی سائبر سیکیورٹی اتھارٹی (NCA): ڈیٹا کے تحفظ اور بیک اپ سے متعلق کنٹرولز۔
عام سوالات
ڈیٹا کو جوں کا توں منتقل کر کے بعد میں سسٹم کے اندر کیوں نہ صاف کریں؟
کیونکہ سسٹم کے اندر ڈیٹا فوراً حرکت میں آ جاتا ہے: اس کی بنیاد پر انوائس جاری ہوتی ہیں، آرڈر اس سے جڑتے ہیں اور رپورٹیں اسی سے بنتی ہیں۔ جس ریکارڈ پر مالی لین دین چل چکے ہوں اسے درست کرنا کسی جامد فائل کے ایک سیل کو درست کرنے سے کہیں زیادہ مشکل اور پرخطر ہے۔ منتقلی سے پہلے صفائی ایک انتظامی کام رہتی ہے؛ منتقلی کے بعد یہ ایسی اصلاح بن جاتی ہے جس کے حسابی اور عملی نتائج ہوتے ہیں۔
اسپریڈشیٹ چھوڑتے وقت سب سے خطرناک ڈیٹا خامی کون سی ہے؟
غیر تحریری مطلب رکھنے والے رنگین سیل، جیسے واجب الادا کے لیے پیلا اور روکے گئے کے لیے سرخ۔ یہ حقیقی عملی ڈیٹا ہے، لیکن یہ ٹیکسٹ کے بجائے فارمیٹنگ میں محفوظ ہے، اس لیے ایکسپورٹ کرتے وقت بغیر کسی انتباہ کے ضائع ہو جاتا ہے۔ اس کے بعد مختلف ناموں سے دہرایا گیا ایک ہی فریق آتا ہے، کیونکہ وہ ایک تعلق کے ریکارڈ کو کئی نامکمل ریکارڈز میں بانٹ دیتا ہے۔
مجھے کیسے پتا چلے کہ میرا ڈیٹا منتقلی کے لیے تیار ہے؟
فائل کو بغیر کسی فارمیٹنگ کے سادہ ٹیکسٹ میں ایکسپورٹ کریں اور پوچھیں کہ کون سی معلومات ضائع ہوئیں۔ اس ٹیسٹ میں جو کچھ غائب ہو جائے وہ ڈیٹا سے باہر محفوظ مطلب ہے اور اسے تحریری فیلڈ بننا چاہیے۔ تیار ہونے کا مطلب کامل ہونا نہیں: اس کا مطلب ہے کہ اہم فیلڈز یکساں اور متعین ہوں، اور باقی رہ جانے والی کمیاں کسی اچانک انکشاف کے بجائے معلوم اور درج ہوں۔
سب سے پہلے کون سا ڈیٹا صاف کرنا چاہیے؟
ماسٹر ڈیٹا سے شروع کریں: گاہک، آئٹمز اور سپلائرز۔ یہ مختصر فہرستیں ہیں، لیکن ہزاروں لین دین کی قطاروں میں استعمال ہوتی ہیں، اس لیے انہیں صاف کرنے سے بعد میں ان سے جڑنے والی ہر چیز درست ہو جاتی ہے۔ ہر ادارے کو ایک مستقل شناخت کنندہ دیں اور ہر پرانے نام کو اس سے جوڑیں، پھر انوائس اور آرڈرز کی طرف بڑھیں۔
گوگل میں اوریگامی کو فالو کریں
اوریگامی کو پسندیدہ ذریعہ بنائیں، ہمارے مضامین گوگل سرچ اور اہم خبروں میں آپ کو سب سے پہلے نظر آئیں گے۔
