আমাদের দেশের সফটওয়্যার আর আইটি সলিউশনের বাজারটা খেয়াল করলে একটা অদ্ভুত জিনিস চোখে পড়ে। আমরা সারাক্ষণ সফটওয়্যার কোম্পানির যোগ্যতা, কোডের মান কিংবা ভেন্ডর সময়মতো ডেলিভারি দিতে পারল কি না—এসব নিয়ে ভীষণ মেতে থাকি। কিন্তু পর্দার আড়ালের আসল প্রশ্নটা কেউ তুলি না: প্রযুক্তি কিনতে আসা ক্রেতা প্রতিষ্ঠানটি নিজে এই প্রযুক্তি সঠিকভাবে প্রোকিউর বা বাছাই করার জন্য কতটুকু প্রস্তুত?
দীর্ঘদিন এই টেবিলের ওপাশে বসে আমি দেখেছি, প্রযুক্তি কেনা কোনো সাধারণ কেনাকাটা নয়। এটি স্রেফ একটা প্রশাসনিক ফাইলে সই করা বা পকেটে বাজেট থাকার বিষয়ও নয়। প্রযুক্তি পণ্য ও সেবা কেনাকাটা নিজেই একটা গভীর টেকনিক্যাল আর স্ট্র্যাটেজিক আর্ট। বাজেট থাকা মানেই কিন্তু সঠিক প্রযুক্তি চেনার ক্ষমতা থাকা নয়। আসল দক্ষতা হলো—নিজের বিজনেসের ভেতরের সমস্যাটা আগে নিজে নিখুঁতভাবে ধরতে পারা, এবং সেই অনুযায়ী ঠিক যতটুকু প্রয়োজন, ঠিক সেই সঠিক সলিউশনটুকু বেছে নিতে পারা।
আর্থিক ক্ষমতা বনাম কৌশলগত দক্ষতা
আমাদের দেশে একটা বড় মানসিক সমস্যা আছে। যিনি বাজেট দেন, তিনি ধরে নেন তিনি প্রযুক্তিও ভালো বোঝেন। পর্যাপ্ত টাকা থাকলেই যে আপনি সঠিক প্রযুক্তি কিনতে পারবেন, তার কোনো গ্যারান্টি নেই। প্রযুক্তি কেনাকাটার পদ্ধতি জানা না থাকলে দামে তো ঠকবেনই, ভুল জিনিস কিনেও বসে থাকতে পারেন। তাই প্রযুক্তি কেনার দক্ষতা থাকাটা টাকা থাকার মতোই জরুরি।
কোনো কর্পোরেট ক্লায়েন্টকে মুখে সরাসরি বলা যায় না যে—প্রযুক্তি কেনার আগে আপনার নিজের প্রসেসটা বোঝা দরকার। এখান থেকেই মূলত ক্রেতা আর ভেন্ডরের দূরত্ব শুরু হয়। এর ফলে বিজনেস গোল আর প্রজেক্টের রিকোয়ারমেন্ট ঠিকভাবে ডিফাইন করা হয় না। কাজ শুরু হওয়ার পর ক্রেতা পক্ষ থেকে বারবার রিকোয়ারমেন্ট চেঞ্জ করা হতে থাকে। এই পরিবর্তনের যৌক্তিক সীমা বা টেকনিক্যাল সীমাবদ্ধতা যখন ভেন্ডর বোঝাতে যায়, ক্রেতা তখন ভাবেন ভেন্ডরের অনীহা বা অযোগ্যতা। শেষ পর্যন্ত প্রজেক্টের টাইমলাইন আর বাজেট দুটোই বাড়ে এবং প্রজেক্টটি ফেইল করে।
কোর ফাংশন বনাম বাহ্যিক রূপ
আরেকটি বড় সমস্যা হলো সফটওয়্যারের কোর ফাংশনালিটির চেয়ে ইউজার ইন্টারফেসের প্রতি ক্রেতাদের মূল আগ্রহ। সফটওয়্যারটি ব্যাক-এন্ডে ব্যবসার মূল প্রক্রিয়াকে কতটা সহজ করছে, ডেটা ম্যানেজমেন্ট কতটা নিখুঁত রাখছে বা সিদ্ধান্ত গ্রহণকে কতটা দ্রুত করছে—সেটাতে আগ্রহটা কম। সিস্টেমের মূল ফাংশন, পারফরম্যান্স ও সিকিউরিটিতে যতটা সময় আর মনোযোগ দরকার সেটা না দিয়ে স্ক্রিনের রঙ, লেআউট বা ড্যাশবোর্ডের ইন্টারফেসের সৌন্দর্য নিয়ে বেশি সময় নষ্ট হয়। তার মানে আমি বলছি না যে ইন্টারফেসটা জরুরি নয়; আমি বলছি যে এই বিষয়টির পেছনে ক্রেতার যতটুকু সময় দেওয়া দরকার, ঠিক ততটুকুই দেওয়া উচিত, তার বেশি বা কম নয়।
ক্রেতার ঠিক কী কী টেকনিক্যাল স্কিল জানা প্রয়োজন?
আজকের দিনে প্রযুক্তি কেনা মানে কিন্তু শুধু সফটওয়্যার কেনা নয়। এর সাথে সরাসরি জড়িয়ে থাকে সার্ভার, স্টোরেজ, ব্যাকআপ সিস্টেম, রাউটার এবং রেডিও লিংকের মতো নেটওয়ার্কিং ডিভাইস। সেই সাথে আছে ডেটা সেন্টার। তাই যারা প্রতিষ্ঠানের সিদ্ধান্ত নেন, তাদের কিছু সুনির্দিষ্ট কারিগরি ও কৌশলগত আইডিয়া থাকা খুব জরুরি:
আইটি মাস্টার প্ল্যান ও আর্কিটেকচার বোঝা
আলাদা আলাদাভাবে কোনো সফটওয়্যার বা সার্ভার কেনা ঠিক নয়। পুরো প্রতিষ্ঠানের জন্য ৩ বা ৫ বছরের একটি সামগ্রিক আইটি মাস্টার প্ল্যান থাকতে হবে। নতুন সলিউশনটি আগামী কয়েক বছর পর অন্যান্য সিস্টেমের সাথে কীভাবে ইন্টিগ্রেট করবে, সেই দূরদর্শিতা থাকা প্রয়োজন। এটি বোঝার জন্য এন্টারপ্রাইজ আর্কিটেকচার ফ্রেমওয়ার্কের (যেমন TOGAF) বেসিক গাইডলাইনগুলো দেখে নেওয়া যেতে পারে। এছাড়া অন্যান্য সমগোত্রীয় প্রতিষ্ঠান কীভাবে তাদের আইটি রোডম্যাপ সাজিয়েছে, সেই কেস স্টাডিগুলো অ্যানালাইসিস করা দরকার।
‘বেস্ট টেকনোলজি’ বনাম ‘অ্যাপ্রোপ্রিয়েট টেকনোলজি’ চেনা
বাজারের সবচেয়ে দামি বা লেটেস্ট প্রযুক্তি মানেই সেটি আপনার প্রতিষ্ঠানের জন্য সেরা নয়। নিজের ব্যবসার আসল প্রয়োজনের সাথে মিল রেখে “সবচেয়ে উপযুক্ত প্রযুক্তি” (Appropriate Technology) বেছে নেওয়ার ম্যাচিউরিটি থাকতে হবে। ভেন্ডরদের মার্কেটিং ম্যাটেরিয়ালের বাইরে গিয়ে থার্ড-পার্টি আইটি কনসালট্যান্ট বা অভিজ্ঞ সিআইও-দের সাথে আলোচনা করা উচিত। বিভিন্ন প্রযুক্তি পণ্যের নিরপেক্ষ রিভিউ এবং তুলনামূলক বিশ্লেষণ পড়লে বোঝা সম্ভব কীভাবে বাজেট বাঁচিয়ে ব্যবসার জন্য একদম যুতসই টুলটি বেছে নেওয়া যায়।
ফিজিক্যাল স্কেলেবিলিটি ও ক্যাপাসিটি প্ল্যানিং
সঠিক পরিকল্পনার অভাবে অনেক প্রতিষ্ঠান একটা বড় ভুল করে। তারা ছোট ছোট স্টোরেজ আর ছোট ছোট সার্ভার কিনে পুরো সার্ভার রুম ভরে ফেলে। প্রথম ১-২ বছর হয়তো কাজ চলে যায়, কিন্তু এরপর যখন ডেটা ও ইউজার বাড়তে থাকে, তখন পুরো ইনফ্রাস্ট্রাকচার জ্যাম হয়ে পড়ে। নতুন ডিভাইস জোড়াতালি দিয়েও আর পারফরম্যান্স পাওয়া যায় না। তখন বাধ্য হয়ে আগের পুরো ইনভেস্টমেন্ট বাদ দিয়ে নতুন করে সব কিনতে হয়।
এই লোকসান ঠেকাতে ক্রেতার ক্যাপাসিটি প্ল্যানিং বোঝা দরকার। আগামী ৫ বছরে প্রতিষ্ঠানের ডেটা ভলিউম কতটা বাড়তে পারে এবং পিক আওয়ারে কত ইউজার সিস্টেমে হিট করতে পারে, তার একটা বাস্তবসম্মত হিসাব থাকতে হবে। সেই গ্রোথ মাথায় রেখে শুরুতেই স্কেলেবল সার্ভার এবং সেন্ট্রালাইজড স্টোরেজ (SAN/NAS) প্ল্যান করতে হবে, যেন পরবর্তীতে পুরো সিস্টেম ডাউন না করেই সহজে স্টোরেজ বা প্রসেসিং পাওয়ার বাড়িয়ে নেওয়া যায়।
টোটাল কস্ট অফ ওনারশিপ (TCO) এবং ROI হিসাব করা
প্রযুক্তি কেনাকাটার সময় ক্রেতারা প্রায়ই একটা বড় ভুল করেন—তারা শুধু সফটওয়্যার বা হার্ডওয়্যারের মূল দামটা দেখেন। কিন্তু একটা প্রজেক্টের আসল খরচ শুধু কেনার প্রাইস ট্যাগের মধ্যে সীমাবদ্ধ থাকে না। এর পেছনে ডেটা সেন্টারের এসি, পাওয়ার ব্যাকআপ (অনলাইন ইউপিএস বা জেনারেটর), লাইসেন্সিং ফি এবং ভেন্ডরের বার্ষিক মেইনটেন্যান্স খরচ (AMC) জড়িত থাকে। এই সব মিলিয়ে ৫ বা ১০ বছরে প্রজেক্টের প্রকৃত খরচ কত দাঁড়াচ্ছে, অর্থাৎ টোটাল কস্ট অফ ওনারশিপ (TCO) হিসাব করার দক্ষতা থাকতে হবে। তবেই ম্যানেজমেন্ট বা সিএফও-কে এই ইনভেস্টমেন্টের বিপরীতে রিটার্ন অন ইনভেস্টমেন্ট (ROI) কত আসবে, তা বোঝানো সম্ভব।
এই হিসাবটি নিখুঁত করতে ক্যাপিটাল এক্সপেন্ডিচার (CapEx) এবং অপারেশনাল এক্সপেন্ডিচার (OpEx)-এর সম্পর্কটা বোঝা দরকার। প্রযুক্তি কেনার এককালীন খরচ এবং এটি বছরের পর বছর চালিয়ে নেওয়ার রানিং খরচের মধ্যে ব্যালেন্স না থাকলে মাঝপথে গিয়ে প্রজেক্টের বাজেট শর্টেজ দেখা দেয়। আইটি প্রজেক্টের কস্ট-বেনিফিট অ্যানালাইসিসের স্প্রেডশিট বা এক্সেল মডেলগুলো একটু চর্চা করলেই TCO এবং ROI হিসাব করার এই পুরো বিজনেস লজিকটা পরিষ্কার হয়ে যায়।
কম্প্রিহেনসিভ প্রোকিউরমেন্ট রিকোয়ারমেন্ট (হার্ডওয়্যার ও নেটওয়ার্ক)
সফটওয়্যারের রিকোয়ারমেন্ট পেপার তৈরি করার সময় অনেকেই হার্ডওয়্যার এবং নেটওয়ার্কের পার্টটা এড়িয়ে যান বা ভেন্ডরের ওপর ছেড়ে দেন। কিন্তু রিকোয়ারমেন্ট ডকুমেন্টে হার্ডওয়্যারের সুনির্দিষ্ট স্পেসিফিকেশন—যেমন প্রসেসর কোর, র্যাম টাইপ, রেইড (RAID) কনফিগারেশন এবং ব্যান্ডউইথ ক্যাপাসিটি পরিষ্কারভাবে উল্লেখ থাকা দরকার। ক্রেতা পক্ষ এই টেকনিক্যাল রিকোয়ারমেন্টগুলো নিজে বুঝতে না পারলে বড় বিপদে পড়তে হয়। অনেক সময় ভেন্ডর কম কনফিগারেশনের বা ব্যাকডেটেড হার্ডওয়্যার গছিয়ে দিয়ে পার পেয়ে যায়। প্রথম দিকে ইউজার কম থাকায় টের পাওয়া যায় না, কিন্তু লাইভ প্রোডাকশনে ফুল ডেটা নিয়ে সফটওয়্যার রান করার সময় পুরো সিস্টেম স্লো হয়ে পড়ে।
এই ফাঁকি থেকে বাঁচতে ইন্টেল, সিসকো বা এইচপির মতো গ্লোবাল হার্ডওয়্যার ভেন্ডরদের টেকনিক্যাল হোয়াইট পেপার এবং প্রোডাক্ট স্পেসিফিকেশন শিট দেখার অভ্যাস করতে হবে। প্রসেসর কোরের ম্যাপিং কীভাবে হয়, ডেটা সুরক্ষায় রেইড (RAID) টেকনোলজি কীভাবে কাজ করে কিংবা নেটওয়ার্কের থ্রুপুট ক্যালকুলেশন কীভাবে করা হয়—এই বেসিক থিওরিগুলো জানা থাকলে প্রোকিউরমেন্ট রিকোয়ারমেন্ট স্ক্রিন করার যোগ্যতা চলে আসে। তখন ভেন্ডর চাইলেও আপনাকে কোনো কম ক্ষমতার বা ইনকমপ্যাটিবল (Incompatible) হার্ডওয়্যার গছিয়ে দিতে পারবে না।
BRD ও SRS বুঝতে পারা
বিজনেসের প্রয়োজনগুলোকে একটি স্পষ্ট Business Requirement Document (BRD) এবং টেকনিক্যাল বিষয়গুলোকে Software Requirement Specification (SRS) আকারে ডকুমেন্ট করার বেসিক দক্ষতা ক্রেতার থাকতে হবে। এই ডকুমেন্টেশনগুলোর আইডিয়া না থাকলে ভেন্ডরকে নিজের আসল চাহিদার কথা কোনোদিনও বোঝানো সম্ভব না। ভেন্ডর তখন তাদের মতো করে স্কোপ বানিয়ে নেবে, যা পরে আপনার বিজনেসের সাথে মিলবে না।
এই গ্যাপটা দূর করতে সফটওয়্যার ইঞ্জিনিয়ারিংয়ের রিকোয়ারমেন্ট ইলাইসিটেশন (Requirement Elicitation) এবং টেকনিক্যাল রাইটিংয়ের বেসিক নিয়মগুলো একটু দেখে নেওয়া যেতে পারে। এছাড়া ইন্টারনেটে বা অভিজ্ঞ আইটি প্রফেশনালদের কাছ থেকে কিছু স্ট্যান্ডার্ড BRD এবং SRS টেমপ্লেট নিয়ে স্টাডি করলে এই ডকুমেন্টেশনের ভাষা এবং ফরম্যাট খুব সহজে আয়ত্ত করা যায়। এর ফলে ভেন্ডরের সাথে মিটিং বা প্রজেক্ট স্কোপিংয়ের সময় নিজের কন্ট্রোল বজায় রাখা সহজ হয়।
RFP এবং SLA-এর ধারণা
একটি প্রফেশনাল RFP (Request for Proposal) তৈরি করা এবং ভেন্ডরের সাথে চুক্তি হিসেবে SLA (Service Level Agreement) ড্রাফট করার পরিষ্কার আইডিয়া থাকতে হবে। হার্ডওয়্যার ও সফটওয়্যার উভয়ের জন্যই ডাউনটাইম, পার্টস রিপ্লেসমেন্ট ওয়ারেন্টি, বাগ ফিক্সিং টাইমলাইন এবং এস্কেলেশন ম্যাট্রিক্স এই চুক্তিতে একদম পরিষ্কার থাকতে হবে। এই লিগ্যাল পার্টগুলো ডিফাইন করতে না পারলে প্রজেক্ট ডেলিভারির পর ভেন্ডরকে সাপোর্ট বা সার্ভিসের জন্য আর লাইনে পাওয়া যায় না।
এর জন্য আইটি লিগ্যাল কমপ্লায়েন্স এবং প্রোকিউরমেন্ট স্ট্যান্ডার্ড নিয়ে কিছুটা ধারণা থাকা দরকার। আইটি গভর্ন্যান্স ফ্রেমওয়ার্ক (যেমন COBIT) থেকে কীভাবে সার্ভিস লেভেল এবং কেপিআই (KPI) ডিফাইন করতে হয়, তার ইন্টারন্যাশনাল স্ট্যান্ডার্ডগুলো দেখে নিলেই এই চুক্তিপত্র লেখার আসল কৌশলটা ধরা যায়। এর ফলে কোনো ভেন্ডর আর চুক্তির ফাঁকফোকর গলে পার পাওয়ার সুযোগ পায় না।
ডেটা ব্যাকআপ ও ডিজাস্টার রিকভারি (DR) প্ল্যান
অন-প্রিমিস সিস্টেমের সবচেয়ে বড় ঝুঁকি হলো ডেটা লস। ক্রেতা পক্ষের জানা থাকতে হবে কীভাবে একটি কার্যকর ব্যাকআপ পলিসি তৈরি করতে হয় এবং মূল ডেটা সেন্টার ডাউন হলে ব্যাকআপ থেকে কীভাবে সিস্টেম রিকভার করা হবে। এটি না জানলে যেকোনো দিন বড় ধরনের সার্ভার ক্র্যাশ বা সাইবার অ্যাটাকে পুরো বিজনেসের ডেটা হাওয়া হয়ে যেতে পারে।
তাই বিজনেস কন্টিনিউটি প্ল্যানিং (BCP) এবং ডিজাস্টার রিকভারির বেসিক আইডিয়া থাকা দরকার। বিশেষ করে রিকভারি টাইম অবজেক্টিভ (RTO)—অর্থাৎ সিস্টেম ডাউন হলে কত দ্রুত তা আবার লাইভ করা যাবে, এবং রিকভারি পয়েন্ট অবজেক্টিভ (RPO)—অর্থাৎ ব্যাকআপ থেকে কতটুকু ডেটা রিকভার করা সম্ভব হবে, এই ধারণাগুলো পরিষ্কার থাকা উচিত। বিভিন্ন ডেটা লস কেস স্টাডি এবং ব্যাকআপ স্ট্র্যাটেজির গাইডলাইনগুলো একটু দেখে নিলেই এই রিকভারি প্ল্যান তৈরি করার আসল টেকনিকটা বোঝা যায়।
সিকিউরিটি ও এক্সেস কন্ট্রোল
লোকাল নেটওয়ার্কে ফায়ারওয়াল কনফিগারেশন, ডেটা এনক্রিপশন এবং রোল-বেসড অ্যাক্সেস কন্ট্রোল যাচাই করার ক্ষমতা ক্রেতার থাকতে হবে। বিশেষ করে, সিস্টেমে কার কতটুকু ডেটা দেখার বা এডিট করার পারমিশন থাকবে—সেটি ডিফাইন করতে পারা জরুরি। এই সিকিউরিটি চেকগুলো না থাকলে ইন্টারনাল ডেটা লিক হওয়া বা সিস্টেমে ম্যালওয়্যার অ্যাটাক হওয়া সময়ের ব্যাপার মাত্র।
এর জন্য ইনফরমেশন সিকিউরিটি ম্যানেজমেন্টের বেসিক স্ট্যান্ডার্ড (যেমন ISO 27001) সম্পর্কে প্রাথমিক ধারণা থাকা দরকার। নেটওয়ার্ক সিকিউরিটির বুনিয়াদি নিয়ম এবং প্রিভিলেজড এক্সেস ম্যানেজমেন্টের (PAM) আর্টিকেলগুলো একটু পড়লেই ডেটা সুরক্ষার বেসিক ফিলোসফিটি সহজে বোঝা যায়। তখন ভেন্ডর কোনো সিকিউরিটি লুপহোল রেখে প্রজেক্ট হ্যান্ডওভার করতে পারবে না।
UAT পরিচালনা করা
ভেন্ডর সফটওয়্যার বা হার্ডওয়্যার ডেলিভারি দিলেই কাজ শেষ নয়। ক্রেতা পক্ষের জানা থাকতে হবে কীভাবে একটি সুনির্দিষ্ট টেস্ট কেস (Test Case) ধরে স্ট্রেস টেস্টিং এবং User Acceptance Testing (UAT) করতে হয়। লাইভে যাওয়ার আগেই সিস্টেমের আসল লোড নেওয়ার ক্ষমতা পরীক্ষা করার জন্য এটি সবচেয়ে গুরুত্বপূর্ণ স্কিল। এটি ঠিকমতো না করলে লাইভ হওয়ার পরেই দেখা যাবে সামান্য ইউজার প্রেসারেই পুরো সিস্টেম ক্র্যাশ করে বসে আছে।
এর জন্য সফটওয়্যার কোয়ালিটি অ্যাসুরেন্স (SQA) এবং টেস্টিং মেথডোলজির বেসিক গাইডলাইনগুলো একটু দেখে নেওয়া দরকার। কীভাবে টেস্ট সিনারিও লিখতে হয় এবং ফাংশনাল ও নন-ফাংশনাল টেস্টিংয়ের আসল পার্থক্যগুলো কী কী—তা বিভিন্ন প্রজেক্টের রিয়েল টেস্ট রিপোর্ট স্টাডি করলেই সহজে শিখে নেওয়া সম্ভব। এর ফলে ভেন্ডর প্রজেক্ট শেষ করার জন্য তাড়াহুড়ো করলেও, ক্রেতা নিজে শতভাগ নিশ্চিত হয়ে তবেই প্রজেক্ট সাইন-অফ (Sign-off) করতে পারেন।
লোকসান আসলে কার?
এই পরিস্থিতিতে সফটওয়্যার ভেন্ডররা ক্ষতিগ্রস্ত হয় ঠিকই, কিন্তু সবচেয়ে বড় ধাক্কাটা খায় ক্রেতা প্রতিষ্ঠান। আইটি সলিউশন বা সফটওয়্যার কিন্তু রেডিমেড কোনো ফিজিক্যাল প্রোডাক্ট নয় যে এক কাজে ফেইল করলে তা অন্য কাজে খাটিয়ে দেওয়া যাবে। একটি কাস্টম সফটওয়্যার যদি শেষ পর্যন্ত বিজনেসের কাজে না আসে, তবে পুরো ইনভেস্টমেন্টটাই স্রেফ পানিতে যায়।
এখানে ক্ষতিটা কিন্তু শুধু টাকার অঙ্কে হয় না। প্রজেক্ট ঝুলে গেলে বা ফেইল করলে নষ্ট হয় মূল্যবান সময়, ভেঙে পড়ে ইন্টারনাল টিমের মনোবল। সবচেয়ে বড় ক্ষতি হয়—ভবিষ্যতে যেকোনো নতুন প্রযুক্তি ব্যবহারের প্রতি পুরো প্রতিষ্ঠানের আস্থাটাই হারিয়ে যায়। ভেন্ডরের হয়তো একটা ক্লায়েন্ট বা প্রজেক্ট খারাপ যায়, কিন্তু ক্রেতা প্রতিষ্ঠান টেকনোলজির দৌড়ে কম্পিটিটরদের চেয়ে কয়েক বছর পিছিয়ে পড়ে।
সমাধান কোন পথে?
প্রযুক্তি কেনার আগে প্রোকিউরমেন্টের বেসিক ফ্রেমওয়ার্কটা বুঝতে হবে। যারা ম্যানেজমেন্টে বসে সিদ্ধান্ত নেন, তাদের উচিত একটু সময় দিয়ে এই বেসিক বিষয়গুলো জেনে নেওয়া। দরকার হলে শর্ট-টার্ম কোনো ট্রেনিং করা যেতে পারে, অথবা থার্ড-পার্টি নিরপেক্ষ কোনো আইটি কনসালট্যান্টের পরামর্শ নেওয়া যেতে পারে। শুরুতে সামান্য এই ইনভেস্টমেন্ট আর সময়টুকু দিলে, ভবিষ্যতে বড় মাপের আর্থিক লোকসান খুব সহজেই ঠেকানো সম্ভব।
সরকারি বা কর্পোরেট পর্যায়ে বিষয়টা আরও বেশি সেনসিটিভ, কারণ সেখানে জনগণের বা শেয়ারহোল্ডারদের টাকা ইনভেস্ট করা হয়। তাই যেসব কর্মকর্তা প্রযুক্তি কেনাকাটা বা আইটি প্রজেক্ট অনুমোদনের সাথে জড়িত, তাদের টেকনোলজি অ্যাকুইজিশন (Technology Acquisition) এবং প্রজেক্ট ম্যানেজমেন্টের ওপর স্ট্রাকচারড ট্রেনিং থাকা খুব দরকার। প্রযুক্তি কেনা মানে স্রেফ গতানুগতিক ফাইল পাস করার মতো কোনো অ্যাডমিন কাজ নয়; এটি পুরো প্রতিষ্ঠানের জন্য একটি দীর্ঘমেয়াদি স্ট্র্যাটেজিক বা কৌশলগত সিদ্ধান্ত।
ইতিহাস থেকে শিক্ষা
বিশ্বের উন্নত দেশগুলো, বিশেষ করে মার্কিন যুক্তরাষ্ট্র আশির ও নব্বইয়ের দশকে বড় বড় আইটি প্রজেক্টে ব্যাপক ব্যর্থতার পরেই এই শিক্ষাটি পেয়েছে। দুর্বল রিকোয়ারমেন্ট, ভুল ভেন্ডর সিলেকশন এবং চেঞ্জ ম্যানেজমেন্টে (Change Management) ব্যর্থতার কারণেই সে সময় তাদের মিলিয়ন মিলিয়ন ডলারের প্রজেক্ট মাঠে মারা গিয়েছিল। পরে তারা শক্ত আইটি গভর্ন্যান্স ফ্রেমওয়ার্ক এবং কঠোর প্রোকিউরমেন্ট স্ট্যান্ডার্ড তৈরি করে এই সংকট থেকে বের হয়ে আসে।
আমাদের সামনে সেই ইতিহাস একদম পরিষ্কার। সব শিক্ষা নিজেকেই লোকসান করে বা ঠেকে শিখতে হবে—এমন কোনো কথা নেই। বারবার নতুন করে চাকা আবিষ্কার করার (Reinventing the wheel) কোনো মানে হয় না।
দেশীয় সফটওয়্যার ইন্ডাস্ট্রিকে শক্তিশালী করতে হলে কেবল ডেভেলপারদের দক্ষ করলেই চলবে না, ক্রেতাদেরও সমানভাবে টেকনিক্যালি ম্যাচিউর হতে হবে। প্রোকিউরমেন্ট বা টেকনোলজি অ্যাকুইজিশন স্কিল ছাড়া প্রযুক্তি কেনা মানে স্রেফ অন্ধের মতো টাকা ওড়ানো। আমরা যদি সত্যিকার অর্থে একটি টেকসই ডিজিটাল রূপান্তর চাই, তবে প্রযুক্তি কেনার সংস্কৃতি এবং ক্রেতার দক্ষতা—উভয় জায়গাতেই সমান গুরুত্ব দিতে হবে।
আরও দেখুন: