ভূমিকা

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

এগুলো কামি এক্সেলের পুনরাবৃত্তি হলেও, পরিসর ও নির্ভরতার দিক দিয়ে আরও বড় ঝুঁকি বহন করে। পরবর্তী পর্বে জেনারেটিভ এআই-এর প্রভাব নিয়ে ভাবতে হলেও, আগে এদের প্রকৃত স্বরূপ বুঝে নেওয়া দরকার।

সিরিজের সূচি

আলো—কেন এগুলো গৃহীত হল

তাৎক্ষণিক ফল

প্রোগ্রাম লিখতে না হয়েও GUI অপারেশন দিয়ে ছোটখাটো স্বয়ংক্রিয়তা বা অ্যাপ দ্রুত সম্পন্ন করা যায়। দৈনিক কপি-পেস্ট বা নিয়মিত প্রক্রিয়া কয়েক দিনের মধ্যে বদলানোর ক্ষমতা মাঠের জন্য বিরাট প্রভাব ফেলে।

দৃশ্যমানতার প্রত্যয়ী শক্তি

ফ্লোচার্ট বা পর্দা নকশা চোখে দেখা যায়, ফলে বিশেষজ্ঞ নয় এমন স্তরেরও বোঝা সহজ হয়। ব্যবস্থাপনার কাছে “নড়াচড়া করা ছবি” হিসেবে ফলাফল দৃশ্যমান হওয়াই বড় আশ্বাস দেয় এবং প্রায়ই প্রয়োগের সিদ্ধান্ত নির্ধারণ করে।

নাগরিকের প্রথম পদক্ষেপ

ইনপুট ফর্ম বা সরল ওয়ার্কফ্লোর মতো সীমিত ব্যবহারে অ-ইঞ্জিনিয়াররাও নিজে তৈরি করতে পারেন। এই সীমা পর্যন্ত সত্যিই “যে কেউ করতে পারে” বলে মনে হয়, এবং পুরো সংগঠনে সিটিজেন ডেভেলপমেন্টের পরিসর বাড়ানোর প্রবেশদ্বার তৈরি হয়।

ছায়া (১)—বাস্তব কাজে দেখা দেয় “প্রফেশনালের প্রাচীর”

উপরিপৃষ্ঠে দেখায় “যে কেউ ব্যবহার করতে পারে”, কিন্তু বাস্তবে কাজে লাগাতে গেলে শেষ পর্যন্ত প্রোগ্রামিং-সমতুল্য চিন্তা ও সিস্টেম ইঞ্জিনিয়ারিং দৃষ্টিভঙ্গি প্রয়োজন হয়।

  • নিয়ন্ত্রণ কাঠামোর অবধারিতা
    গ্রাহক শর্ত অনুযায়ী প্রক্রিয়া ভাগ করতে হলে শর্ত-বিচ্ছেদ (If/Else) দরকার। শত শত ডেটা সামলাতে হলে পুনরাবৃত্তি (ForEach) অপরিহার্য। বাহ্যিক সিস্টেমের প্রতিক্রিয়া বিলম্ব বা ত্রুটির জন্য প্রস্তুতি নিতে হলে ব্যতিক্রম পরিচালনা (Try/Catch) লাগবেই। GUI-তে সাজানোর সুবিধা থাকলেও মূলত এটি প্রোগ্রামিং।

  • ডেটা কাঠামো বোঝার প্রয়োজন
    JSON বা অ্যারে বিশ্লেষণ, স্তর ম্যাপিং, তারিখ/সংখ্যার বিন্যাস সামঞ্জস্য করা—এসব কাজ সিস্টেম ইন্টিগ্রেশন-এ অপরিহার্য। শুধু টেবিলের বিকল্পে সীমাবদ্ধ নয়; ডেটা কাঠামো না বুঝলে অনিবার্যভাবে ভেঙে পড়ে।

  • সিস্টেম-সমূহের ইন্টিগ্রেশনের জটিলতা
    API প্রমাণীকরণের মেয়াদ ব্যবস্থাপনা, একাধিক সিস্টেম পেরিয়ে সামঞ্জস্যতা নিশ্চিত করা, রেট লিমিট এড়ানো—প্রচলিত সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের একই চ্যালেঞ্জ 그대로 চলে আসে। GUI কেবল সেগুলো লুকিয়ে রাখে, কিন্তু কঠিনতাও বাড়ে।

  • অপারেশন ও গুণগত চাহিদা
    নজরদারি, লগ সংগ্রহ, টেস্ট ও প্রোডাকশন পরিবেশের পার্থক্য পরিচালনা, রিলিজে রোলব্যাক—অপারেশনাল নকশা ছাড়া দ্রুত বিশৃঙ্খলা দেখা দেয়। কোড দিয়ে নিয়ন্ত্রণ না করায় পর্যবেক্ষণযোগ্যতা কমতে থাকে।

এই প্রাচীরের সামনে সিটিজেন ডেভেলপাররা একা নিজেদের তৈরি সিস্টেম গড়ে তোলা ও রক্ষণাবেক্ষণ করা কঠিন মনে করে, শেষ পর্যন্ত বিশেষজ্ঞদের ওপর নির্ভর করতে বাধ্য হয়। অথচ বিশেষজ্ঞ দলের সক্ষমতা সমস্যাটি আগের মতোই অমীমাংসিত থাকে।

ছায়া (২)—ভেন্ডর লক-ইন ও স্থানান্তরের দুরূহতা

কামি এক্সেলের এখনও কিছু আশ্রয় ছিল। সবশেষে তা একটি ফাইল। টেবিল ডেটা CSV আকারে বের করা যেত, ফাংশন বা ম্যাক্রো Excel-এ লকড হলেও আংশিক মিল থাকা স্প্রেডশিট সফ্টওয়্যার ছিল, এবং কোড বা ফাংশন পড়া সম্ভব ছিল। অন্যদিকে RPA বা নো-কোড/লো-কোডের উৎপন্ন সম্পদ প্রায় পুরোপুরি প্ল্যাটফর্ম-নির্ভর UI বা কনফিগারেশন ফাইলে বন্দী থাকে।

  • অন্য পণ্যে স্থানান্তর প্রায় “শুরু থেকে নতুন করে তৈরি করা”-র সমান।
  • SaaS-এর সেবা বন্ধ বা স্পেসিফিকেশন পরিবর্তন ব্যবহারকারীর নিয়ন্ত্রণের বাইরে, এক রাতে সংগৃহীত সম্পদ মূল্যহীন হতে পারে।
  • PaaS-এ নির্মাণ করলে সেই ক্লাউড ইকোসিস্টেমে আটকে পড়া, অন্য পরিবেশে নিয়ে যাওয়া অত্যন্ত কঠিন।
  • কোডের বদলে UI-তে লজিক নির্ধারণ করলে সমস্যা খুঁজে বের করা বা অনুসন্ধান করা দুরূহ হয়।
  • টুলের নকশা অনুসারে অনেকসময় উপাদান ডাবল-ক্লিক না করলে ভেতরের প্রক্রিয়া বোঝা যায় না, ফলে পাঠযোগ্যতা কমে যায়।

অর্থাৎ ফাইল-ভিত্তিক কামি এক্সেলের তুলনায়ও নির্ভরতা ও ঋণে পরিণতির ঝুঁকি বহুগুণে বেড়ে যায়।

ছায়া (৩)—“দৃশ্যমানতার পক্ষপাত” যেভাবে ব্যবস্থাপনাকে ভুল পথে টানে

প্রযুক্তিবিদের চোখে “প্রফেশনালের প্রাচীর”-এ পৌঁছানো সময়ের ব্যাপারই মাত্র। কিন্তু ব্যবস্থাপনা স্তরকে GUI-তে আঁকা ফ্লো বা স্ক্রিন দেখালে সহজেই মনে হয় “এ তো যে কেউ ব্যবহার করতে পারবে।”

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

এই “ব্যবস্থাপনার নিশ্চিন্ত ভাব” ও “প্রযুক্তিবিদের উদ্বেগ”-এর ফাঁকই প্রয়োগের গতি বাড়াতে গিয়ে ভবিষ্যতের ঋণ বাড়ানোর উর্বর ভূমি হয়।

কামি এক্সেল ২.০ যুগের দিকে

এভাবে সাজালে দেখা যায়, RPA ও নো-কোড/লো-কোড ঠিক কামি এক্সেলের পথেই হাঁটছে। তাৎক্ষণিক ফল দিয়ে মাঠকে বাঁচায়, দৃশ্যমানতার প্রত্যয়ী শক্তি দিয়ে ব্যবস্থাপনাকে সন্তুষ্ট করে, তারপর ব্ল্যাক বক্সে রূপান্তর ও ব্যক্তিনির্ভরতার কারণে সংগঠনে ভারী বোঝা রেখে যায়।

তবে সিদ্ধান্তমূলক পার্থক্য হল প্রভাবের পরিসর। কামি এক্সেল ফাইল স্তরে সীমাবদ্ধ ছিল, কিন্তু আধুনিক সিটিজেন ডেভেলপমেন্ট ক্লাউড ও পুরো কোর ব্যবসা কার্যক্রম-এ প্রবেশ করে, সংগঠনের স্কেলে বেঁধে রাখা ঋণ হয়ে উঠতে পারে। উপরন্তু Excel-এর চেয়েও শক্ত লক-ইন কাঠামো বহন করে। এটাই “কামি এক্সেল ২.০” বলার মতো পরিস্থিতি ডেকে আনবে।

সংক্ষিপ্তসার

  • RPA ও নো-কোড/লো-কোড তাৎক্ষণিক ফল ও দৃশ্যমানতার প্রত্যয়ী শক্তি দিয়ে মাঠ ও ব্যবস্থাপনা উভয়ের কাছে গ্রহণযোগ্য হয়েছে।
  • কিন্তু বাস্তব কাজে টিকে থাকতে নিয়ন্ত্রণ কাঠামো, ডেটা কাঠামো, সিস্টেম ইন্টিগ্রেশন, অপারেশন নকশা—এসব সফ্টওয়্যার ইঞ্জিনিয়ারিং জ্ঞান অপরিহার্য; কেবল সিটিজেন ডেভেলপাররা তা গড়ে তুলতে ও টিকিয়ে রাখতে পারে না।
  • প্ল্যাটফর্ম-নির্ভর UI স্থানান্তরকে অত্যন্ত কঠিন করে তোলে এবং ভেন্ডর লক-ইন জোরদার করে।
  • ব্যবস্থাপনার “দৃশ্যমানতার পক্ষপাত” এ ঝুঁকি কম মূল্যায়ন করায়।

পরিণতিতে আধুনিক সিটিজেন ডেভেলপমেন্ট কামি এক্সেলের চেয়েও শক্তিশালী, আবার একই সঙ্গে আরও ঝুঁকিপূর্ণ। পরের পর্বে দেখব, এই ধারায় জেনারেটিভ এআই যুক্ত হলে কী ঘটে।

পরবর্তী পর্ব: জেনারেটিভ এআই সিটিজেন ডেভেলপমেন্টে কী প্রভাব আনে ৪/৭