کام کا مستقبل

AI کا ROI وقت بچنے سے ثابت نہیں، قابلِ قبول نتیجے کی لاگت ناپیں

|مصنف: QUASA ادارتی ٹیم|7 منٹ مطالعہ| 1
AI کا ROI وقت بچنے سے ثابت نہیں، قابلِ قبول نتیجے کی لاگت ناپیں

AI کی حقیقی پیداواری قدر ناپنے کے لیے prompts، logins یا اندازاً بچنے والے گھنٹوں کو مرکزی پیمانہ نہ بنائیں۔ پہلے طے کریں کہ کاروبار کے لیے قابلِ قبول نتیجہ کیا ہے، پھر AI سے پہلے اور بعد میں ایسے ہر نتیجے کی مکمل لاگت پاکستانی روپے میں نکالیں۔ فرق اسی وقت کاروباری فائدہ ہے جب معیار برقرار رہے، کام واقعی مکمل ہو اور بچنے والی صلاحیت کم overtime، کم outsourcing، اضافی کام یا آمدن میں استعمال ہو۔

ملازم سے صرف یہ پوچھنا کہ اس نے کتنا وقت بچایا، کافی ثبوت نہیں۔ برطانوی حکومت کی عملی رہنمائی کے مطابق وقت کی بچت کا خود لگایا گیا اندازہ ذہنی طور پر مشکل اور اکثر زیادہ ہو سکتا ہے، اس لیے سروے کے ساتھ تقابلی مشق اور معیاری تحقیق بھی درکار ہے۔ مزید یہ کہ National AI Centre کی ROI رہنمائی وقت کو تبھی قدر شمار کرتی ہے جب وہ مفید کام میں دوبارہ لگے، اور معیار، capacity، اطمینان اور فیصلہ سازی کو بھی نتیجے میں شامل کرتی ہے۔

قابلِ قبول نتیجے کی تعریف پہلے لکھیں

مقررہ معیار کے تحت AI نتائج قبول، درست، تبدیل یا مسترد کیے جا رہے ہیں

پیمائش کی اکائی ایسی چیز ہو جو workflow کے اگلے مرحلے تک جا سکے: منظور شدہ invoice، درست customer response، مکمل product description یا پالیسی کے مطابق بند support ticket۔ “AI نے جواب بنا دیا” صرف ایک attempt ہے۔ اگر انسان کو جواب نمایاں طور پر دوبارہ لکھنا، بنیادی فیصلہ بدلنا یا غلطی کے باعث روکنا پڑے تو اسے الگ درجہ دیں۔

Pilot سے پہلے مختصر quality rubric بنائیں اور ایک ہی نمونے پر reviewers کی درجہ بندی کا موازنہ کریں۔ ہر output کو صرف ایک حالت دیں:

  • قبول: معمول کے ہلکے جائزے کے بعد استعمال یا ترسیل کے قابل؛
  • درست شدہ: محدود correction کے بعد قابلِ استعمال؛
  • override: انسان نے AI کی بنیادی تجویز یا فیصلہ بدل دیا؛
  • مسترد: کام ابتدا سے دوبارہ کرنا پڑا یا استعمال نہ ہوا۔

معیار کی حد use case کے خطرے کے مطابق رکھیں۔ اندرونی خلاصے میں معمولی اسلوبی ترمیم قابلِ قبول ہو سکتی ہے، مگر مالی منظوری، صحت یا قانونی کام میں حقیقت، اختیار اور compliance کی سخت جانچ چاہیے۔ یوں denominator پیدا کیے گئے تمام جوابات نہیں بلکہ مقررہ معیار سے گزرنے والے نتائج ہوں گے۔

AI سے پہلے baseline محفوظ کریں

ایسا نمائندہ دورانیہ منتخب کریں جس میں اسی نوعیت کے کام کا حجم، قبول شدہ نتائج، انسانی execution، reviewer time، rework، غلطی کے واقعات اور outsourcing درج ہو سکیں۔ موسمی رش، نئی بھرتی یا پالیسی کی تبدیلی کو الگ نوٹ کریں؛ ورنہ بعد کا فرق AI سے منسوب کرنا مشکل ہوگا۔ برطانیہ کی AI impact-evaluation guidance بھی rollout سے پہلے baseline قائم کرنے، business-as-usual کو واضح کرنے اور comparison group کی نوعیت درج کرنے پر زور دیتی ہے۔

کم وسائل والی پاکستانی ٹیم کے لیے randomized trial ہی واحد راستہ نہیں۔ ملتے جلتے دو گروپ، باری باری AI اور non-AI ادوار، یا مرحلہ وار rollout قابلِ عمل متبادل ہو سکتے ہیں۔ دونوں طرف task mix، quality rubric اور costing method ایک رکھیں؛ پیچیدہ cases صرف pilot میں ڈال کر سادہ baseline سے موازنہ نتیجہ بگاڑ دے گا۔

بنیادی فارمولا یہ ہے: baseline cost per accepted output = baseline کی کل متعلقہ لاگت ÷ baseline کے قبول شدہ نتائج۔ تنخواہ کو وقت کی لاگت میں بدلتے ہوئے employer-paid benefits اور متعلقہ overhead شامل کریں، مگر ایسا مشترک خرچ pilot پر نہ ڈالیں جو اس کے باعث پیدا ہی نہیں ہوا۔

پانچ کڑیوں میں measurement chain بنائیں

AI response سے مالی اثر تک پانچ مرحلوں کی قابلِ آڈٹ پیمائشی کڑی

Dashboard میں الگ الگ metrics جمع کرنا کافی نہیں؛ ہر سطح کو اگلی سطح سے جڑنا چاہیے۔ McKinsey کا پانچ سطحی framework technical performance، adoption، operational KPIs، strategic outcomes اور financial impact کو ایک audit chain میں جوڑتا ہے، جبکہ total cost of ownership میں cloud اور token spend بھی شامل کرتا ہے۔ چھوٹی ٹیم اسے یوں مختصر کر سکتی ہے:

  1. نظام: latency، failure، model یا token cost فی attempt اور guardrail breach؛
  2. استعمال: eligible tasks میں AI کا حصہ، acceptance، correction اور override rate؛
  3. عمل: cycle time، accepted outputs، rework minutes اور defect rate؛
  4. کاروباری نتیجہ: turnaround، service capacity، conversion یا کم outsourcing؛
  5. مالی اثر: فی قابلِ قبول نتیجہ لاگت، حقیقی cash saving، contribution margin اور ROI۔

شرحوں کی تعریف مستقل رکھیں: acceptance rate = قبول شدہ outputs ÷ reviewed AI outputs؛ correction rate = درست شدہ outputs ÷ reviewed outputs؛ override rate = بنیادی انسانی تبدیلی والے outputs ÷ AI-assisted decisions۔ ایک output کو correction اور override دونوں میں شمار نہ کریں، ورنہ ادوار کا موازنہ معتبر نہیں رہے گا۔

PKR worksheet میں مکمل لاگت رکھیں

ہر ہفتے یا مہینے کے لیے ایک قطار بنائیں اور تمام رقم PKR میں درج کریں۔ غیر ملکی invoice کو اسی شرح پر تبدیل کریں جو finance ledger میں متعلقہ transaction کے لیے استعمال ہوئی؛ موجودہ exchange rate سے پرانا خرچ دوبارہ نہ لکھیں۔ مشترک cloud یا model خرچ کو requests، tokens یا کسی مستقل usage driver کے مطابق تقسیم کریں؛ کلاؤڈ کے اضافی اخراجات estimate اور مکمل bill کے فرق کو سمجھنے میں مدد دیتے ہیں۔

  • baseline volume، accepted outputs اور baseline total cost؛
  • AI attempts، accepted، corrected، overridden اور rejected outputs؛
  • انسانی execution، quality review اور rework کے منٹ اور PKR؛
  • licence، API، token، cloud، integration، monitoring اور support cost؛
  • training، change management اور مدت پر تقسیم کیا گیا setup cost؛
  • risk incident کی investigation، recovery، refund، legal یا compliance cost؛
  • استعمال شدہ اضافی capacity کی قدر: بچی ہوئی outsourcing یا حقیقی contribution margin۔

AI cost per accepted output = pilot کی تمام متعلقہ لاگت ÷ قبول شدہ نتائج۔ انسانی review کو صفر فرض نہ کریں: اگر معیار یا خطرہ قابو میں رکھنے کے لیے یہ ضروری ہے تو اس کا وقت AI cost کا حصہ ہے۔ NIST AI RMF Core انسانی oversight، AI errors کے مالی اور غیر مالی اخراجات، production monitoring، override، incident response اور recovery کی دستاویز بندی کو risk management میں شامل کرتا ہے۔

فرضی مثال: بچا وقت نہیں، فی نتیجہ لاگت

فرضی پاکستانی pilot میں 110 قابلِ قبول رپورٹس کی فی نتیجہ لاگت 3,818 روپے نکل رہی ہے

یہ مکمل طور پر فرضی مثال ہے۔ ایک پاکستانی operations team baseline مہینے میں 100 قابلِ قبول reports بناتی ہے اور انسانی محنت، review اور rework سمیت 500,000 روپے خرچ کرتی ہے؛ baseline cost فی accepted report 5,000 روپے ہے۔

AI pilot میں 130 attempts سے 110 reports قبول ہوتی ہیں۔ انسانی execution پر 190,000، review پر 80,000، rework پر 40,000، licence پر 30,000، tokens اور cloud پر 15,000، مدت پر تقسیم شدہ integration پر 35,000، training پر 20,000 اور ایک incident کی investigation پر 10,000 روپے لگتے ہیں۔ کل لاگت 420,000 روپے اور cost per accepted report تقریباً 3,818 روپے بنتی ہے۔

پہلی 100 comparable reports پر operational فرق تقریباً 118,200 روپے ہے: 5,000 میں سے 3,818 منہا کر کے 100 سے ضرب۔ باقی 10 reports کی capacity value صرف تب شامل ہوگی جب وہ حقیقی demand پوری کریں؛ اگر ہر اضافی report کا تصدیق شدہ contribution margin 2,000 روپے ہو تو مزید 20,000 روپے شامل ہوں گے، مگر unused capacity کی قدر صفر رہے گی۔ یوں قابلِ دفاع net value تقریباً 138,200 روپے ہے۔

اگر اس worksheet میں مکمل pilot cost کو investment مانا جائے تو ROI = net value ÷ pilot cost × 100 سے تقریباً 32.9 فیصد نکلتا ہے۔ Finance team اگر investment، tax، depreciation یا working capital کی مختلف منظور شدہ تعریف رکھتی ہے تو انہی inputs کو اس formula میں ڈالے؛ مختلف تعریفوں کے نتائج کو ایک ہی dashboard پر یکساں ROI نہ کہیں۔

Scale، درست یا بند کرنے کا فیصلہ

Pilot شروع ہونے سے پہلے thresholds طے کریں: accepted-output cost میں مطلوبہ کمی، کم از کم acceptance rate، زیادہ سے زیادہ override یا incident rate، اور معیار کی وہ حد جس سے نیچے rollout رک جائے۔ ایک evidence pack میں raw counts، rubric کا version، invoices، time logs، incidents اور حساب رکھیں۔ Model، prompt، workflow یا reviewer policy بدلے تو تاریخ درج کریں تاکہ مختلف configurations کے نتائج ایک مدت نہ سمجھے جائیں۔

Scale تب کریں جب معیار کی حد برقرار ہو، فی قابلِ قبول نتیجہ مکمل لاگت baseline سے مسلسل کم ہو، اور capacity یا revenue کی قدر ledger یا operational system میں دکھائی دے۔ اگر صرف usage بڑھا ہے، corrections بھی بڑھی ہیں اور cash یا استعمال شدہ capacity نہیں بدلی تو ثابت صرف adoption ہوا ہے، ROI نہیں۔ یہی فرق tool کی مقبولیت اور قابلِ آڈٹ کاروباری اثر کو الگ کرتا ہے۔

یہ بھی پڑھیں:

شیئر کریں:

ہمارا نیوز لیٹر سبسکرائب کریں

ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔

0