میں AI کے ذریعے اپنے پرانے سسٹم سے بزنس قواعد کیسے نکالوں؟

آپ اپنے پرانے سسٹم سے بزنس قواعد 3 مراحل میں نکالتے ہیں: AI کوڈ پڑھتا ہے اور ہر قاعدے کو ایک واضح جملے میں لکھتا ہے جو اس لائن سے جڑا ہوتا ہے جہاں سے وہ آیا؛ عمل کا مالک اسے دیکھ کر تصدیق یا درستی کرتا ہے؛ اور آپ اس کا موازنہ اصل انوائسز پر سسٹم کے اصل رویے سے کرتے ہیں۔ مین فریم کے لیے AWS Transform جیسا ٹول قواعد کو قابلِ جائزہ ضروریات کی صورت میں لکھتا ہے، اور 29 ستمبر 2026 کو Amazon کے ساتھ Thought Machine کے اعلان میں قواعد نکالنے کا عمل 4 مراحل سے گزرتا ہے جن کا آخری مرحلہ انسانی منظوری ہے۔ قواعد کی تصدیق سے پہلے کوئی نیا کوڈ نہ لکھیں۔

حصہ 3 میں آپ نے ہر سسٹم کی فہرست اور ایک عارضی فیصلہ تیار کیا تھا۔ جن سسٹمز کو آپ نے دوبارہ بنانے یا تبدیل کرنے کا فیصلہ کیا ہے، انہیں سب سے پہلے اس مرحلے کی ضرورت ہے۔

بزنس قواعد آپ کے پرانے سسٹم کی سب سے قیمتی چیز کیوں ہیں

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

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

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

AI کوڈ کیسے پڑھتا ہے اور قواعد کیسے لکھتا ہے

قواعد نکالنا پہلے ایک لمبا ہاتھ کا کام تھا: ایک پروگرامر کوڈ لائن بہ لائن پڑھتا اور جو سمجھتا وہ لکھ لیتا۔ آج کے ٹولز پورا کوڈ پڑھتے ہیں، ہر عدد کہاں سے آتا ہے اور کہاں جاتا ہے اس کا سراغ لگاتے ہیں، اور جو ملتا ہے اسے آسان زبان میں لکھتے ہیں۔ ایک مثال: Amazon مین فریم کے لیے AWS Transform کے صفحے پر کہتا ہے کہ یہ سروس سورس کوڈ سے ہر بزنس قاعدہ نکال کر اسے اس کے ماخذ سے جوڑتی ہے، پھر ترقی کے لیے تیار ایسی ضروریات بناتی ہے جن کا آپ کی ٹیم جائزہ لے سکے، اور ہر ضرورت کو اس کوڈ تک ٹریس کیا جا سکتا ہے جہاں سے وہ آئی۔ یہ Amazon کی اپنی سروس کے بارے میں وضاحت ہے، کوئی ضمانت شدہ نتیجہ نہیں۔

قاعدہ کس فارمیٹ میں لکھا جاتا ہے، یہ اہم ہے۔ ایک معروف فارمیٹ EARS ہے، یعنی Easy Approach to Requirements Syntax، جسے Alistair Mavin اور Rolls-Royce میں ان کے ساتھیوں نے تیار کیا اور پہلی بار 2009 میں شائع کیا۔ اس کا خیال یہ ہے کہ ہر قاعدہ ایک مقررہ ترتیب میں لکھا جائے: پہلے حالت، پھر محرک، پھر وہ جو سسٹم کو کرنا ہے۔ اس کے 5 بنیادی نمونے ہیں؛ یہاں کاروبار سے متعلق وضاحتی مثالیں ہیں:

اس فارمیٹ کی خوبی یہ ہے کہ عمل کا مالک پروگرامنگ جانے بغیر اسے پڑھ کر پرکھ سکتا ہے۔ ہر قاعدے کے لیے ایک جملہ، اور جواب ہاں، نہیں یا نامکمل۔

بینکاری سے ایک مثال: لائن بہ لائن ترجمہ نہیں، کاروباری ارادہ

سب سے واضح حالیہ مثال بینکاری سے ہے، جہاں سود، فیس اور ادائیگی کے قواعد دہائیوں سے مین فریم پر COBOL کوڈ میں موجود ہیں۔ COBOL ایک پرانی پروگرامنگ زبان ہے جو آج بھی بینکاری اور انشورنس کے بہت سے سسٹم چلاتی ہے۔ بینکاری ٹیکنالوجی کمپنی Thought Machine نے 29 ستمبر 2026 کے اپنے اعلان میں کہا کہ وہ Amazon کے ساتھ ایک ایسے عمل پر کام کر رہی ہے جو کوڈ کا لائن بہ لائن ترجمہ نہیں کرتا بلکہ خالص کاروباری ارادہ نکالتا ہے۔ اعلان کے مطابق یہ عمل 4 مراحل پر مشتمل ہے:

1. نکالنا: AWS Transform پرانی ایپلیکیشنز پڑھتا ہے اور کاروباری منطق کو EARS فارمیٹ میں لکھی گئی تفصیلات میں نکالتا ہے۔
2. یکجائی: ایک ہی پروڈکٹ کی سینکڑوں دہرائی گئی شکلوں کو مختصر اور جدید تفصیلات میں ملا دیا جاتا ہے۔
3. تیاری: AI ایجنٹس Python میں مالیاتی پروڈکٹس اور ان کے ٹیسٹ تیار کرتے ہیں۔
4. توثیق: انسانی جائزہ، جس میں بینک کی انجینئرنگ اور رسک ٹیموں کے پاس واضح منظوری کا اختیار ہوتا ہے۔

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

عمل کے مالک کو ہر قاعدے کی تصدیق کیوں کرنی چاہیے

AI یہ پڑھتا ہے کہ کوڈ کیا کرتا ہے، یہ نہیں کہ کمپنی کیا چاہتی ہے۔ ان دونوں کے درمیان کا فاصلہ ہی وہ جگہ ہے جہاں جدید کاری کی غلطیاں ہوتی ہیں:

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

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

Origami کا نقطۂ نظر

جب ہم کسی پرانے سسٹم کو جدید بناتے ہیں تو منتقل کرنے کے لیے سب سے اہم چیز ہم اس کے بزنس قواعد کو سمجھتے ہیں، اس کے کوڈ کو نہیں۔ ہم AI ٹولز سے کوڈ پڑھتے ہیں اور قواعد کو ایسی رفتار سے واضح جملوں میں لکھتے ہیں جو پہلے ممکن نہیں تھی، لیکن جب تک عمل کا مالک کسی قاعدے کو پڑھ کر دستخط نہ کر دے، ہم اسے حتمی نہیں مانتے۔

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

اس ہفتے کی مشق: ایک قاعدہ، تین انوائسز

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

1. عمل کے مالک سے کہیں کہ وہ قاعدے کو ایک جملے میں اس صورت میں لکھے: جب ...، سسٹم کو ... کرنا ہوگا
2. سسٹم سے 3 اصل انوائسز نکالیں جن پر یہ قاعدہ لاگو ہوا: ایک عام، ایک حد پر اور ایک استثنا والی۔
3. لکھے گئے جملے سے ہر انوائس کا ہاتھ سے حساب لگائیں اور نتیجے کا موازنہ سسٹم کے نتیجے سے کریں۔

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

اگلے حصے میں

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

ماخذ

• مین فریم کے لیے AWS Transform: سرکاری صفحہ — اصل کوڈ تک ٹریس ہونے والے بزنس قواعد، قابلِ جائزہ ضروریات اور مساوات کے ٹیسٹ۔
• Thought Machine اور AWS: 29 ستمبر 2026 کا اعلان — چار مراحل: EARS میں نکالنا، یکجائی، تیاری اور انسانی توثیق۔
• EARS: Alistair Mavin کی سرکاری گائیڈ — فارمیٹ، اس کے پانچ نمونے اور 2009 میں اس کی پہلی اشاعت۔
• SDAIA: ذاتی ڈیٹا کا تحفظ۔