কাজের ভবিষ্যৎ

কোন কাজ AI-কে দেবেন, Glean Transform সেটিই আগে মানচিত্রে তুলবে

|লেখক: QUASA সম্পাদকীয় দল|4 মিনিটের পাঠ| 6
কোন কাজ AI-কে দেবেন, Glean Transform সেটিই আগে মানচিত্রে তুলবে

Glean ২৬ আগস্ট ২০২৬ Glean Transform নামে একটি early-preview পণ্য ঘোষণা করেছে। Glean-এর ২৬ আগস্টের ঘোষণায় বলা হয়েছে, এটি document, message, call ও CRM update থেকে প্রতিষ্ঠানের কাজের ধারা মানচিত্রে তুলবে, কোথায় AI প্রয়োগ করা যায় তা সুপারিশ করবে এবং পরিবর্তনের ফল মাপবে।

অর্থাৎ কোন কাজ AI-কে দেওয়া হবে, Transform তার আগে connected system-এর activity থেকে recurring workflow, ধাপ ও handoff অনুমান করতে চায়। একই ২৬ আগস্টের ঘোষণায় পণ্যটিকে নির্মাণাধীন early preview বলা হয়েছে—এটি এখনো সাধারণভাবে উন্মুক্ত, পূর্ণাঙ্গভাবে যাচাই করা সেবা নয়।

Activity থেকে workflow map কীভাবে তৈরি হবে

Glean Transform calendar, call, CRM ও document activity মিলিয়ে sales workflow-এর ধাপ ও handoff শনাক্ত করছে

Transform-এর ভিত্তি কোনো লিখিত process manual নয়; কর্মীরা বাস্তবে কোন system-এ কী activity করছেন, তার সমন্বিত সংকেত। একটি workflow calendar, document, message, CRM ও code-এর মধ্যে ছড়িয়ে থাকতে পারে। পণ্যটি এসব activity মিলিয়ে কাজের ধাপ, সংশ্লিষ্ট ভূমিকা, handoff এবং আনুমানিক সময় শনাক্ত করার দাবি করছে।

Glean-এর বর্ণনায় প্রত্যেক কর্মীর individual activity map থেকে signal নেওয়া হবে, পরে তা job family অনুযায়ী একটি function জুড়ে aggregate ও anonymize করা হবে। Sales-এর উদাহরণে Transform discovery ও use-case scoping-এর মতো recurring workflow শনাক্ত করে; session duration, call length ও document activity থেকে প্রতিটি ধাপে ব্যয় হওয়া সময় অনুমান করে।

এখানে ফলটি inferred workflow—কর্মী বা process owner-এর অনুমোদিত বিবরণ নয়। Calendar-এ দীর্ঘ meeting থাকা তার মূল্য প্রমাণ করে না; document বারবার খোলা হলেও প্রতিবার সমান কাজ হয়েছে ধরে নেওয়া যায় না। তাই map-এর নির্ভুলতা বিচার করতে বাস্তব process, ব্যতিক্রম এবং সংশ্লিষ্ট দলের ব্যাখ্যার সঙ্গে inference মিলিয়ে দেখার ব্যবস্থা দরকার।

Automation বাছাইয়ে পাঁচ ধরনের সিদ্ধান্ত

Workflow map তৈরি হওয়ার পর প্রতিটি ধাপের জন্য পাঁচটি সম্ভাব্য সিদ্ধান্ত রাখা হয়েছে: automate, augment, redesign, connect অথবা keep human-ledGlean Transform-এর পণ্যবিবরণ অনুযায়ী, আনুমানিক সময় সাশ্রয় ও business impact-এর সমন্বয়ে workflow-এর অগ্রাধিকার নির্ধারিত হবে; নির্বাচিত সুযোগ থেকে agent বা Skill blueprint-এর খসড়াও তৈরি করা যাবে।

Blueprint তৈরি হওয়া production automation চালুর সমান নয়। পণ্যবিবরণে administrator-এর জন্য প্রয়োজনীয় system, permission ও human review point পরীক্ষা করার সুযোগ রাখা হয়েছে; পর্যালোচনার পর blueprint Glean Agent Builder-এ পাঠানো যাবে। ফলে recommendation, নির্মাণ এবং deployment আলাদা ধাপ হিসেবেই থাকছে।

‘Keep human-led’ বিকল্পটি দেখায় যে Transform-এর প্রস্তাব সব কাজ স্বয়ংক্রিয় করার নয়। Glean-এর sales উদাহরণে গ্রাহকের সঙ্গে সরাসরি কথোপকথন মানুষ পরিচালনা করে, কিন্তু call-এর আগের research ও পরের write-up automation-এর প্রার্থী। তবে সম্পর্ক, বিচারবোধ, আইনি দায় বা সংবেদনশীল সিদ্ধান্তের কোন অংশ মানুষের হাতে থাকবে, তার নীতিমালা vendor-এর classification একা নির্ধারণ করতে পারে না।

ROI ledger ফলের সঙ্গে অনুমান তুলনা করবে

Deployment-এর পর Transform একই workflow আবার map করার কথা বলছে। সময় কোথায় সরে গেল এবং প্রত্যাশিত outcome পাওয়া গেল কি না, তা আগের estimate-এর সঙ্গে ROI ledger-এ তুলনা করা হবে। এর উদ্দেশ্য কেবল AI adoption গোনা নয়, বরং নির্দিষ্ট agent বা process change চালুর আগে ও পরে workflow-এর পরিবর্তন অনুসরণ করা।

তবে প্রকাশিত পদ্ধতি audited financial ROI-এর পূর্ণ সংজ্ঞা দেয় না। কর্মঘণ্টাকে অর্থমূল্যে রূপান্তর, ভুল সংশোধনের খরচ, output quality, customer outcome বা অতিরিক্ত human review-এর ব্যয় ledger-এ কীভাবে যুক্ত হবে, তা এখনো বিস্তারিত প্রকাশিত হয়নি। Workflow দ্রুত হওয়া এবং ব্যবসায়িক মূল্য তৈরি করা তাই একই দাবি নয়।

আরও একটি attribution সমস্যা আছে: deployment-এর আগে ও পরে পার্থক্য দেখা গেলেই পুরো পরিবর্তন AI-এর কারণে হয়েছে বলা যায় না। মৌসুমি workload, staffing, policy বা অন্য software update একই সময়ে ফল বদলাতে পারে। নির্ভরযোগ্য ROI-এর জন্য baseline period, outcome metric এবং অন্য পরিবর্তনের প্রভাব আলাদা করার পদ্ধতি স্পষ্ট হওয়া প্রয়োজন।

Employee data নিয়ে procurement-এর অমীমাংসিত প্রশ্ন

Glean Transform recommendation চালুর আগে administrator permission, aggregated employee activity ও human review point যাচাই করছেন

Transform-এর সুবিধা ও নজরদারির ঝুঁকি একই activity data থেকে আসে। Glean aggregate ও anonymized view-এর কথা বললেও প্রকাশিত বিবরণে minimum group size, raw activity retention, re-identification ঠেকানোর control কিংবা ভুল inference সংশোধনের পদ্ধতি ব্যাখ্যা করা হয়নি। Calendar, message, call ও CRM activity ব্যবহারের ক্ষেত্রে এসব সীমা বিশেষভাবে গুরুত্বপূর্ণ।

বাংলাদেশ ও ভারতের enterprise buyer-দের জানতে হবে প্রতিটি connector থেকে কোন field নেওয়া হবে, ব্যক্তিগত message বা sensitive CRM record বাদ দেওয়া যাবে কি না এবং source system-এর permission একইভাবে কার্যকর থাকবে কি না। কে individual-level signal দেখতে পারবেন, process owner কীভাবে ভুল map চ্যালেঞ্জ করবেন এবং সংশোধনের audit trail থাকবে কি না—এসবও product evaluation-এর অংশ হওয়া উচিত।

Human review point শুধু agent চালুর আগের security check কি না, সেটিও পরিষ্কার করা দরকার। কোনো ধাপ human-led রাখার সিদ্ধান্ত কে অনুমোদন করবেন, ranking বদলালে review আবার হবে কি না এবং কর্মীরা mapping সম্পর্কে জানতে বা আপত্তি জানাতে পারবেন কি না—প্রকাশিত পৃষ্ঠাগুলো এসব governance প্রশ্নের উত্তর দেয় না।

এখনকার অবস্থা: early preview, পূর্ণ প্রাপ্যতা নয়

Glean-এর পণ্যপৃষ্ঠায় Transform এখনো ‘Coming soon’। Enterprise DNA-র ২৭ আগস্টের প্রতিবেদনে পণ্যটির সাধারণ প্রাপ্যতা ২০২৬ সালের শেষের আগে আনার পরিকল্পনার কথা বলা হয়েছে, যদিও নির্দিষ্ট release date দেওয়া হয়নি।

ফলে map–recommend–measure ধারাটি আপাতত Glean-এর product proposition, স্বাধীনভাবে যাচাই করা customer outcome নয়। পরবর্তী গুরুত্বপূর্ণ তথ্য হবে production availability, connector ও permission-এর পূর্ণ বিবরণ, anonymization control, workflow inference সংশোধনের ব্যবস্থা এবং বাস্তব deployment থেকে তুলনাযোগ্য before-and-after ফল। এসব না আসা পর্যন্ত Transform কোথায় AI বসানো যেতে পারে তার কাঠামো দেখায়, কিন্তু recommendation ও ROI হিসাব কতটা নির্ভরযোগ্য—তার উত্তর অসম্পূর্ণ।

শেয়ার করুন:

আমাদের নিউজলেটার নিন

সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।

0