ERP-তে AI Agent: Buyer-কে ভালো Draft দিন, সীমাহীন ক্ষমতা নয়

সোমবারের purchasing meeting-এ চৌদ্দটি প্রস্তাবিত order review-এর অপেক্ষায়। একটি লাইনে লেখা “12 box”; buyer চেয়েছিলেন 12 piece। প্রতি box-এ 12 piece হলে প্রস্তাবটি কিনবে 144 piece। ঘটনাটি কাল্পনিক, কিন্তু সিদ্ধান্তটি বাস্তব: software একটি ভালো প্রস্তাব দেবে, নাকি নিজেই সেটিকে supplier-এর কাছে commitment বানিয়ে ফেলবে?

Buyer চান shortage খোঁজা ও paperwork তৈরিতে সাহায্য। প্রতিটি keystroke দেখার সময় তাঁর নেই; আবার dispatch-এর পর ভুল ধরার খরচও নেওয়া যাবে না। তাই AI agent চালুর প্রথম কাজ হলো এই সীমা ঠিক করা—demo-তে চমকপ্রদ কাজ শেষ করতে পারে কি না, সেটিই একমাত্র প্রশ্ন নয়।

এটি operations-এ AI সিরিজের প্রথম লেখা। দ্বিতীয় পর্বে MCP connection, তৃতীয় পর্বে approval ও audit control। এখানে দেখব কোন কাজ দেওয়া যুক্তিযুক্ত এবং ফল কীভাবে যাচাই হবে।

“Agent” নামটির পেছনের ক্ষমতা দেখুন

AI agent লক্ষ্য পূরণে tool বেছে চালাতে পারে: order দেখা, receipt খোঁজা, draft বানানো বা পরের ধাপ চাওয়া। “Copilot” ও “agent” নামের ব্যবহার অনেক ক্ষেত্রে মিলে যায়। নাম দেখে একটি শুধু কথা বলে, অন্যটি কাজ করে ধরে না নিয়ে actual tool ও execution rights দেখুন।

হিসাব, validation ও পুনরাবৃত্ত transaction-এ নির্দিষ্ট business rule ব্যবহার করুন। Language model এলোমেলো supplier message বুঝতে বা exception ব্যাখ্যা করতে সাহায্য করতে পারে; একমাত্র calculator কিংবা buyer কী কিনতে পারবেন তার authority হওয়া উচিত নয়। Fixed workflow-তেই ভালো সমাধান হলে agent যোগে কাজের সুবিধার চেয়ে খরচ বাড়তে পারে।

ভুল উত্তরেও ক্ষতি বা data leak হয়। Read-only assistant অন্য branch-এর private price দেখালে বা payment status বানিয়ে বললে তা নিরাপদ নয়। Write access বাড়তি ঝুঁকি আনে, কিন্তু পড়ার অধিকারও নিয়ন্ত্রিত হতে হবে।

প্রতিটি কাজের Operating Mode ঠিক করুন

শুধু “undo” আছে কি না নয়—data sensitivity, business impact, বাইরের commitment, volume ও recovery দেখে কাজ ভাগ করুন। শেষ item reserve করে পরে undo করা গেলেও অন্য buyer-এর কেনার সুযোগ চলে যেতে পারে। বহু ছোট action মিলেও বড় exposure হয়।

নিচের mode-গুলো business owner-দের সঙ্গে ঠিক করার operating policy; আইনি risk category বা আপনা-আপনি ওঠার ladder নয়। Draft ভালো হওয়া মানেই send করার অনুমতি নয়।

Mode	কাজের ব্যবহার	প্রয়োজনীয় সীমা
Read ও Explain	অনুমোদিত stock/invoice evidence	Record/field scope, freshness ও output privacy
Prepare	Draft PO, reminder বা match exception	লুকানো downstream effect নয়; human review
Policy মেনে Execute	স্পষ্ট অনুমোদিত একটি সীমিত action	Current authorisation, প্রয়োজনীয় exact approval, duplicate protection
Hold ও Escalate	অস্পষ্টতা, denied access, unapproved commitment	সেই action বন্ধ; দায়িত্বপ্রাপ্ত মানুষের কাছে পাঠান

Purchase Order-এর পুরো পথ ধরে দেখুন

কাল্পনিক buyer-এর জন্য একটি supplier ও product family দিয়ে শুরু করুন। SKU/variant, approved supplier, purchase unit, currency, lead time, usable stock, existing commitment ও incoming receipt যাচাই করুন। একই পণ্যের একাধিক supplier/pack size থাকতে পারে; সবাইকে single-supplier rule-এ বাঁধবেন না।

Tool তারিখসহ evidence ও স্পষ্ট quantity দেয়: 12 piece = 1 box, 12 box নয়। Business logic হিসাব ও quantity limit যাচাই করে। Conversion অস্পষ্ট, stock stale বা supplier record অমীমাংসিত হলে buyer-এর exception queue-তে যাবে; model missing value বানাবে না।

Draft যেন সত্যিই draft থাকে। Save করলেই budget reserve, supplier email বা অন্য workflow চালু হয় কি না পরীক্ষা করুন। Review-তে supplier, destination, item, quantity/unit, price, currency, tax, total ও source timestamp থাকবে। অনুমতিপ্রাপ্ত buyer সেই exact version approve করবেন। গুরুত্বপূর্ণ field বদলালে বা evidence-এর মেয়াদ পেরোলে নতুন যাচাই, প্রয়োজন হলে নতুন approval লাগবে।

Execute করার সময় current permission ও business constraint আবার যাচাই হবে। System committed result নিশ্চিত করলেই purchase order তৈরি হয়েছে বলা যাবে। Supplier-কে পাঠানো আলাদা ধাপ হলে সেটির outcome-ও আলাদা রাখুন। Document তৈরি, পাঠানো ও supplier acceptance এক অবস্থা নয়।

Permission কথোপকথনের বাইরে প্রয়োগ করুন

Interactive request-এর effective access হলো requesting user-এর rights, agent/tool scope এবং current business policy—তিনটির মিলিত অনুমোদিত অংশ। শুধু menu নয়, record ও field-এও এটি প্রয়োগ করুন; প্রতি tool call-এ আবার যাচাই করুন। এক store-এর প্রশ্ন অন্য store-এর private document বা cached answer খুঁজতে পারবে না।

Unattended job-এর নিজস্ব সীমিত service identity, দায়িত্বপ্রাপ্ত owner ও expiry/review থাকতে হবে; shared admin account বা কোনো human session-এর অস্পষ্ট permission নয়। Prompt, retrieved file, output, log ও model-provider access একই data policy-তে রাখুন। Retention, region, subprocessor ও training terms দেখুন; ERP self-hosted হলেই external model call স্থানীয় হয়ে যায় না।

Supplier PDF, customer message ও web page তথ্যসূত্র; নতুন authorisation নয়। Invoice-এর একটি বাক্য bank details বদলানোর অনুমতি দিতে পারে না। প্রয়োজনের অতিরিক্ত tool, permission ও autonomy-কে OWASP excessive agency হিসেবে ব্যাখ্যা করে। Limit application-এ enforce করুন; শুধু prompt-এ নয়।

যেখানে Review-এর উদ্দেশ্য স্পষ্ট, সেখান থেকে শুরু

Stock question: অনুমোদিত location/status অনুযায়ী stock ও evidence time দেখান। Physical on-hand, available-to-promise, estimate ও allocation আলাদা রাখুন।

Purchase proposal: সীমিত draft ও input-এর ব্যাখ্যা তৈরি করুন। Quantity, supplier commitment ও release approved workflow-তেই থাকুক।

Invoice exception: agreed tolerance-এ invoice, PO ও receipt মেলান; partial receipt, currency ও tax-ও ধরুন। Uncertain match flag করুন, নীরবে payment/posting নয়।

Overdue reminder: আগে due date, dispute ও recent payment যাচাই করুন। সঠিক অনুমোদিত recipient-এর জন্য draft লিখুন। আগের draft accepted হলেই unattended send যুক্তিযুক্ত হয় না; outreach rule ও escalation limit প্রযোজ্য থাকবে।

Product copy: verified attribute থেকে লিখুন। Editor ভাষা, ingredient/safety claim, size ও warranty যাচাই করবেন। অনুবাদে দাবি একই থাকবে, আরও জোরালো হবে না।

Payroll release, supplier-bank change, refund, পুরো catalogue-এর price, deletion ও accounting correction-এ নির্দিষ্ট control design চাই। অনেক business approved rule ও audit evidence দিয়ে routine ledger posting আগে থেকেই automate করে। সমস্যা automation নিষিদ্ধ করা নয়; probabilistic agent-কে গুরুত্বপূর্ণ কাজে সীমাহীন authority দেওয়া।

সহজ কাজের আগে কঠিন Failure-গুলোও পরীক্ষা করুন

Vendor-কে denied cross-store query, supplier document-এ malicious instruction, approval-এর পরে order change এবং expired permission দেখাতে বলুন। Refusal সুন্দর শোনালেও লাভ নেই, যদি data/action ইতিমধ্যে বাইরে চলে যায়।

Order তৈরি হওয়ার পর acknowledgement আসার আগে timeout ঘটিয়ে দেখুন। Retry-এর আগে existing operation/reference query করুন। Duplicate protection, retryable failure-এ bounded exponential backoff ও jitter, retry budget এবং unresolved outcome-এর owner রাখুন। Uncertain purchase/payment/refund অন্ধভাবে replay করবেন না। Invalid request বা permission denial-এ correction দরকার, একই retry নয়।

প্রতি operation ও মোট value, record, tool call, runtime, provider spend-এর limit রাখুন। Stop করলে নতুন কাজ বন্ধ হচ্ছে, কিন্তু চলমান কাজের outcome reconcile করার জন্য থাকছে কি না দেখুন। Actor, delegated scope, source reference, proposed change, approval/version, tool outcome ও operation ID record করুন। Log-এ access সীমিত ও sensitive data redact করুন; প্রতিটি customer file কপি করবেন না।

সংক্ষিপ্ত evidence-based ব্যাখ্যা চাইবেন, hidden model chain-of-thought নয়। কে evidence দেখতে/export করতে পারবেন, কতদিন থাকবে ও incident কীভাবে investigate হবে যাচাই করুন। NIST AI Risk Management Framework একটি voluntary organising reference; product certificate নয়।

Accepted Draft মানেই সঠিক—এভাবে Pilot মাপবেন না

চাইলে 30/60/90 দিন review window করুন, automatic permission upgrade নয়। Scoped lookup, তারপর supervised draft। সীমিত write action-ও নতুন সিদ্ধান্ত; failure test ও accountable owner লাগবে। Draft-only-তে সর্বোত্তম অর্থনৈতিক ফল হলে সেখানেই থাকুন।

কাল্পনিক 200 case-এ staff 160 draft unchanged accept, 30 edit, 10 reject করলেন: unchanged acceptance 80%। Accepted draft-এর independent sample 40টিতে material error 2টি, sample-এর 5%। এটি সব case-এর নিখুঁত estimate নয়; acceptance-ও correctness প্রমাণ করে না। কঠিন case, language, abstention ও rare high-impact failure ধরুন।

নিচের সময়ের model একই 200 case-এর বানানো measurement। একই ধরনের কাজ তুলনা করুন; review, exception handling ও ongoing support-ও খরচ।

একই 200 Case-এর হিসাব	Minute
Baseline: 200 × 6	1,200
AI-assisted review: 200 × 3	600
অতিরিক্ত exception handling	120
এই pilot-এ allocated setup/support	90
মোট assisted effort	810
খালি হওয়া কাজের সময়	390 (6.5 ঘণ্টা)

Labour value 24/hour ধরলে 6.5 ঘণ্টার capacity value 156। Model/tool charge 40 বাদে allocated benefit 116, অন্য খরচের আগে। এগুলো currency-neutral teaching unit; guaranteed return বা cash saving নয়—বেতন একই থাকতে পারে। সময়ের সঙ্গে turnaround, verified error, data incident ও customer/supplier outcome মাপুন। ছোট pilot-এ zero incident মানে zero risk নয়।

সোমবারে ফিরুন একটি ছোট, কাজের প্রতিশ্রুতি নিয়ে

Buyer এখন চৌদ্দটি reviewable proposal পান। Box/piece mismatch exception হিসেবে থাকে; সবাই ঘুমানোর সময় supplier-কে order email হয় না। তিনি source conversion ঠিক করে affected proposal আবার চালিয়ে ফল দেখেন। ভালো master data একটি failure mode কমায়; পরের run আর ভুল করবে না, এমন প্রমাণ নয়।

Product নেওয়ার আগে নিজের permission ও কঠিন case দিয়ে demo দেখুন। StoreConsole Intelligence tour product বোঝার উপায়; সব workflow/connector enabled হওয়ার প্রমাণ নয়। নিজের installation-এ draft, approval, execution ও recovery কেমন কাজ করে যাচাই করুন।

Customer-facing AI-তে পরিষ্কার disclosure ও প্রযোজ্য নিয়ম দেখুন। EU AI Act-এর Article 50-এ direct interaction-এর transparency duty আছে, নির্দিষ্ট scope ও exception-সহ; প্রতিটি internal ERP action-এর জন্য এক নিয়ম নয়। Employment, credit ও অন্য sensitive decision আলাদাভাবে assess করতে হবে।

কাজের ফলটি বাস্তবসম্মত: কম routine search, ভালোভাবে প্রস্তুত সিদ্ধান্ত, যাচাইযোগ্য evidence এবং buyer-এর নিয়ন্ত্রণে থাকা authority।

পর্যালোচনা: 5 নভেম্বর 2026। Anichur Rahaman StoreConsole-এর নির্মাতা। Purchasing-এর ঘটনা, pilot count ও cost model শিক্ষামূলক উদাহরণ।