এআই কনসালট্যান্টরা কীভাবে একটি ইন-হাউস SaaS রিপ্লেসমেন্টের স্কোপ নির্ধারণ করেন

যে কোনো দক্ষ কনসালট্যান্ট একইভাবে একটি ইন-হাউস SaaS রিপ্লেসমেন্টের স্কোপ নির্ধারণ করেন: প্রতিটি টুলকে আপনার দেখতে পাওয়া অংশ এবং প্রতিবার সঠিকভাবে কাজ করতে হওয়া অংশে বিভক্ত করা। SaaS (প্রতি মাসে ভাড়া নেওয়া সফটওয়্যার) মূলত স্ক্রিন, ওয়ার্কফ্লো এবং রিপোর্টের সমন্বয়, যা রেকর্ড সংরক্ষণের একটি ছোট কোরের ওপর ভিত্তি করে গড়ে ওঠে। এআই প্রথম অর্ধেক অংশ পুনরায় তৈরি করা সাশ্রয়ী করে তুলেছে। দ্বিতীয় অংশটিতেই রিপ্লেসমেন্ট প্রজেক্টগুলো ব্যর্থ হয়, আর আপনার সাবস্ক্রিপশন বিলের ঠিক কতটুকু অংশ সেখানে রয়েছে তা পরিমাপ করার জন্যই একটি ভালো স্কোপের প্রয়োজন হয়।

এখানে ধাপে ধাপে দেখানো হয়েছে কীভাবে একটি ইন-হাউস SaaS রিপ্লেসমেন্টের স্কোপ তৈরি হয়, এবং সেই একটি প্রশ্ন যা এর বেশিরভাগ সিদ্ধান্ত নেয়। (নিচে উল্লিখিত ভেন্ডরের নাম এবং জরিপের পরিসংখ্যান প্রকাশের সময় অনুযায়ী সঠিক; বিস্তারিত তথ্যগুলোকে একটি সাময়িক চিত্র হিসেবে বিবেচনা করুন।)

একটি SaaS রিপ্লেসমেন্ট স্কোপে আসলে কী থাকে?

ফিচারের তালিকা নয়, একটি কাজের ইনভেন্টরি। টুলটি যে প্রতিটি কাজ সম্পাদন করে, কে কে সেগুলোতে হাত দেয় এবং এর আউটপুট ভুল হলে কী ঘটে কনসালট্যান্ট তার একটি তালিকা তৈরি করেন। অনুমোদন প্রক্রিয়া (approval chains), ড্যাশবোর্ড এবং ফর্মগুলো একটি কলামে রাখা হয়। অর্থ স্থানান্তর, স্টকের সংখ্যা, ট্যাক্স এবং কর্মীদের রেকর্ড অন্য কলামে রাখা হয়। মূল ডেলিভারেবল হলো সেই ম্যাপ, প্রতি কাজের জন্য একটি ঝুঁকি গ্রেড, এবং টুলটি গোপনে যেসব সিস্টেমের সাথে যুক্ত রয়েছে সেগুলোর একটি তালিকা।

গ্রেডিং প্রশ্নটিই এখানে মূল বিষয়: যদি এই আউটপুটটি ভুল হয়, আপনি কীভাবে তা বুঝতে পারবেন এবং এতে কত খরচ পড়বে? একটি পুরনো ড্যাশবোর্ড এক নজরেই ধরা পড়ে এবং এতে কোনো খরচ হয় না। কিন্তু একটি ভুল পেআউট টোটাল ট্যাক্সের সময় ধরা পড়ে এবং এর ফলে বড় অঙ্কের ক্ষতি হয়।

কেন প্রোডাক্টটিকে দুটি স্তরে ভাগ করবেন?

কারণ এআই একটি স্তরের খরচ অনেকাংশে কমিয়ে দিয়েছে এবং অন্য স্তরটিকে অপরিবর্তিত রেখেছে। ইন্টারফেস স্তরটি (ফর্ম, ড্যাশবোর্ড, ইন্টারনাল টুল, অ্যাপ্রুভাল ওয়ার্কফ্লো) এখন দ্রুত পুনর্নির্মাণ করা সম্ভব; বর্তমান মডেলগুলো কয়েক ঘণ্টার মধ্যে কার্যকরী ওয়েভ অ্যাপ তৈরি করতে পারে, যা আমরা GPT-5.6 একটি কার্যকরী POS তৈরি করতে পারে কিনা পরীক্ষা করার সময় ঠিক যা পেয়েছিলাম। ইনফ্রাস্ট্রাকচার স্তরটি আলাদা: পেমেন্ট প্রসেসিং, PCI কমপ্লায়েন্স (কার্ড নিরাপত্তার নিয়মাবলী যা প্রসেসররা প্রয়োগ করে), কনকারেন্সিতে ইনভেন্টরি (দুটি কাউন্টার থেকে একই সময়ে শেষ ইউনিটটি বিক্রি হওয়া), এবং মেলাতে পারা যায় এমন রিপোর্ট (আপনার ব্যাংক ডিপোজিটের সাথে যেসব মোট হিসাব মেলে)। কোড দীর্ঘ হওয়ার কারণে এই স্তরটি কঠিন নয়। এটি কঠিন কারণ সেখানে "প্রায় সঠিক" হওয়ার কোনো মূল্য নেই, এবং কোড তৈরির চেয়ে এর নির্ভুলতা প্রমাণ করার খরচ বেশি।

উন্নত মডেলগুলোও এই সীমাবদ্ধতা দূর করতে পারে না। মূল বাধা হলো ভেরিফিকেশন এবং দায়বদ্ধতা, কোড জেনারেশন নয়, তাই একটি সঠিক স্কোপ ভেরিফিকেশনের দাম নির্ধারণ করে। জেনারেশন হলো ডেমো। ভেরিফিকেশন হলো ইনভয়েস।

Klarna-র SaaS রিপ্লেসমেন্ট আসলে কী প্রমাণ করেছে?

সবচেয়ে বেশি প্রচারিত "আমরা আমাদের SaaS-কে এআই দিয়ে প্রতিস্থাপন করেছি" গল্পটি আসলে স্কোপিংয়ের একটি শিক্ষা। ২০২৪ সালের শেষের দিকে, Klarna-র সিইও ঘোষণা করেন যে কোম্পানিটি এআই ওভারহলের অংশ হিসেবে Salesforce এবং Workday বাদ দিচ্ছে, এবং সংবাদপত্রের শিরোনামগুলোতে বলা হয়েছিল যে এআই পুরোপুরিভাবে SaaS-কে প্রতিস্থাপন করছে। পরবর্তী প্রতিবেদনে আরও নির্দিষ্ট তথ্য পাওয়া গেছে: Klarna তাদের HR অন্য একজন ভেন্ডরের কাছে স্থানান্তর করেছে এবং বিকল্প টুলস ও ইন-হাউস সমাধানের মিশ্রণের সাথে এআই যুক্ত করে তাদের CRM চাহিদা পূরণ করেছে¹। ফিনটেকের অন্যতম আগ্রাসী এআই প্রোগ্রাম চালানো একটি লাইসেন্সপ্রাপ্ত ব্যাংকও তাদের সিস্টেম অফ রেকর্ড (আপনার ব্যবসায়িক তথ্যের নির্ভরযোগ্য কপি) বিশ্বস্ত প্ল্যাটফর্মগুলোতে বজায় রেখেছে এবং শুধুমাত্র বাহ্যিক অংশগুলো পুনর্নির্মাণ করেছে।

এটি সাহসের অভাব ছিল না। এটি ছিল স্কোপের সঠিক কার্যকারিতা।

কোন সংখ্যাগুলো একটি রিপ্লেসমেন্ট প্রজেক্টকে যৌক্তিক করে তোলে?

প্রথমে অপচয় কমান, তারপর তৈরি করুন। Zylo-র ২০২৬ SaaS ম্যানেজমেন্ট ইনডেক্স, যা ৪০ মিলিয়নেরও বেশি পরিচালিত লাইসেন্স থেকে তৈরি, দেখাচ্ছে যে প্রতি বছর কর্মীপ্রতি গড়ে ৯,৪৫৫ ডলার SaaS খরচ হয়, গড়ে ৩৬% লাইসেন্স অব্যবহৃত অবস্থায় থাকে, এবং ব্যবসা প্রতিষ্ঠানগুলো SaaS খরচের ৮১% নিয়ন্ত্রণ করে যেখানে IT সরাসরি ১৫% পরিচালনা করে²। একজন কনসালট্যান্ট কোনো প্রস্তাব দেওয়ার আগে এই সংখ্যাগুলোর সাথে আপনার স্ট্যাকের তুলনা করেন: অব্যবহৃত সিটগুলো বাতিল করুন, ওভারল্যাপিং টুলগুলোকে একত্রিত করুন এবং শুধুমাত্র তারপরই পুনর্নির্মাণের জন্য সম্ভাব্য তালিকা তৈরি করুন।

তালিকায় স্থান পাওয়া টুলগুলোর একটি সাধারণ বৈশিষ্ট্য রয়েছে: উচ্চ পুনরাবৃত্তিমূলক খরচ, বেশিরভাগ কাজ যা ইন্টারফেস স্তরে থাকে এবং কিছু ভেঙে গেলে এর প্রভাব তুলনামূলক কম হয়। প্রজেক্টটি তখনই অনুমোদন পায় যখন সাবস্ক্রিপশন খরচ তৈরি ও রক্ষণাবেক্ষণের খরচের চেয়ে দ্রুত বৃদ্ধি পায়, এবং প্রতিটি 'অবশ্যই সঠিক হতে হবে' এমন কাজ অন্য কারো পরিচালিত ইনফ্রাস্ট্রাকচারে রাখা সম্ভব হয়।

এই স্কোপিংয়ে একটি POS কোথায় অবস্থান করে?

সম্ভাবনার সবচেয়ে কঠিন প্রান্তে। একটি পয়েন্ট অফ সেলকে একটি ইন্টারফেস প্রজেক্টের মতো মনে হয়—বাটনের গ্রিড এবং কার্ট, তাই মালিকরা মনে করেন এর স্কোপ একটি ড্যাশবোর্ডের মতোই হবে। বাস্তবে অনুপাতটি ঠিক উল্টো। চেকআউট স্ক্রিনটি প্রজেক্টের একটি ছোট অংশ; বাকি অংশ হলো পেমেন্ট, সার্টিফাইড কার্ড-প্রেজেন্ট হার্ডওয়্যার, একই সময়ে দুটি রেজিস্টার থেকে বিক্রি হলেও সঠিক থাকা ইনভেন্টরি, ট্যাক্সের নিয়মাবলী এবং দিন শেষের সমন্বিত রিপোর্ট। একটি POS যখন ভুল করে, তখন এটি প্রতিদিন অর্থের হিসাব নিয়ে ভুল করে।

তাই কনসালট্যান্টরা Klarna যেভাবে তাদের লেজারের স্কোপ নির্ধারণ করেছিল সেভাবেই একটি POS পুনর্নির্মাণের স্কোপ তৈরি করেন: কাস্টম ইন্টারফেস, প্রমাণিত ইনফ্রাস্ট্রাকচার। এই বিভাজনের জন্য আগে একটি ডেভেলপার টিমের প্রয়োজন হতো। এটি এখন একটি প্রোডাক্ট ক্যাটাগরি: Final's Build সাধারণ ভাষার প্রম্পটকে এমন একটি চেকআউট ফ্লোতে রূপান্তর করে যা আপনি প্রিভিউ এবং ডেপ্লয় করতে পারেন, এবং একই কমার্স ইনফ্রাস্ট্রাকচারের ওপর কাজ করার জন্য আপনি MCP-এর মাধ্যমে আপনার নিজস্ব এআই কানেক্ট করতে পারেন। পেমেন্ট, ইনভেন্টরি, রিপোর্টিং এবং হার্ডওয়্যার সেই স্তরেই থাকে যা আগেই ভেরিফাই করা হয়েছে।

তাহলে আপনি কীভাবে একটি ইন-হাউস SaaS রিপ্লেসমেন্টের স্কোপ নির্ধারণ করবেন?

প্রতিটি টুলকে দুটি স্তরে ভাগ করুন, অলক্ষিত ভুল আউটপুটের খরচের ওপর ভিত্তি করে প্রতিটি কাজকে গ্রেড করুন এবং কোডের চেয়ে ভেরিফিকেশনের দাম নির্ধারণ করুন। ইন্টারফেস এবং ওয়ার্কফ্লো নির্দ্বিধায় পুনর্নির্মাণ করুন; তবে সিস্টেম অফ রেকর্ড এমন ইনফ্রাস্ট্রাকচারে ছেড়ে দিন যা অন্য কেউ সঠিক রাখে। কোনো টুল ইন-হাউস পুনর্নির্মাণ করার আগে নিজেকে জিজ্ঞাসা করুন: এর আউটপুট ভুল হলে আমি কত দ্রুত তা জানতে পারব? যদি উত্তর হয় "দ্রুত নয়", তবে সেই কাজটি পরীক্ষিত ব্যবস্থার ওপর ছেড়ে দিন।

আর যদি আপনার স্ট্যাকের কমার্স অংশটি আপনি পুনর্নির্মাণ করতে চান, তবে বর্তমান মডেলগুলো নিজেদের শক্তিতে কী তৈরি করতে পারে এবং কী পারে না সে বিষয়ে একটি স্বচ্ছ ধারণা দিয়ে শুরু করুন: একটি বাস্তব POS নির্মাণে Claude বনাম ChatGPT বনাম Gemini, অথবা কাস্টম POS তৈরি করতে Gemini 3.6 Flash কীভাবে ব্যবহার করবেন-এ বর্ণিত দুটি নো-কোড পদ্ধতি দেখুন।