আলাদা আলাদা টুলের কারণে বাড়তে থাকা ব্যবসার প্রতি মাসে নিঃশব্দে ৪০ থেকে ১২০ ঘণ্টা নষ্ট হয়। event-driven ERP আসলে কীভাবে কাজ করে, কোন লক্ষণে বুঝবেন পুরোনো টুলে আর চলছে না, আর ব্যবসা চালু রেখেই ৯০ দিনে ধাপে ধাপে ERP চালুর পরিকল্পনা — সব এই লেখায়।
Author
Anichur Rahaman
কোনো ব্যবসাই পরিকল্পনা করে স্প্রেডশিটে চলা শুরু করে না। ব্যাপারটা ধীরে ধীরে ঘটে যায়। প্রথমে একটা অনলাইন শপ, তারপর কাউন্টারের জন্য একটা POS অ্যাপ। ভ্যাট-ট্যাক্সের জন্য আসে অ্যাকাউন্টিং সফটওয়্যার, বেতনের জন্য একটা Excel শিট — যেটা অফিসে মাত্র একজনই ঠিকমতো বোঝেন। আর কুরিয়ারের পোর্টালে কেউ একজন রোজ সন্ধ্যায় ঢুকে স্ট্যাটাস দেখেন। কেনার দিন প্রতিটা টুলই ছিল ঠিক সিদ্ধান্ত।
তিন বছর পর দেখা যায়, সেই একই প্রতিষ্ঠান প্রতি মাসের প্রথম সপ্তাহটা কাটাচ্ছে এক টুলের হিসাব আরেক টুলের সঙ্গে মেলাতে। ড্যাশবোর্ডের সংখ্যায় কারও পুরো ভরসা নেই, কারণ প্রতিটা সংখ্যা অন্তত দুই জায়গায় আলাদা আলাদা করে লেখা থাকে। ঠিক তখনই ERP আর "বড় কোম্পানির জিনিস" থাকে না। প্রশ্নটা হয়ে দাঁড়ায় খুব বাস্তব: ব্যবসা না থামিয়ে কীভাবে সব হিসাব এক জায়গায় আনা যায়, যেখানে প্রতিটা সংখ্যা একবারই লেখা হবে?
মালিক বা অপারেশনস ম্যানেজাররা যখন আমাকে এই প্রশ্ন করেন, তখন আমি যে রোডম্যাপটা দিই, সেটাই এখানে লিখছি। একজন সফটওয়্যার আর্কিটেক্টের চোখে দেখা: "ইন্টিগ্রেটেড" বলতে আসলে কী বোঝায়, কোন লক্ষণ দেখে বুঝবেন পুরোনো টুলে আর চলবে না, ৯০ দিনে ধাপে ধাপে কীভাবে চালু করবেন, কোন ভুলগুলো ERP প্রজেক্ট ডুবিয়ে দেয়, আর কোন সংখ্যা দেখে নিশ্চিত হবেন যে কাজটা সত্যিই হয়েছে।
পাঁচটা সফটওয়্যারের লাইসেন্স ফি সাধারণত বড় সমস্যা নয়। আসল খরচ লুকিয়ে থাকে টুলগুলোর মাঝখানের কাজে। কোনো ইনভয়েসে এটা দেখা যায় না, তাই প্রায় সবাই একে ছোট করে দেখেন। সাধারণত চিত্রটা এমন:
একটা সহজ পরীক্ষা করে দেখুন: আপনার টিম প্রতি মাসে এক সিস্টেম থেকে আরেক সিস্টেমে ডেটা তুলতে বা মেলাতে কত ঘণ্টা দেয়? ১০ থেকে ৫০ জনের যেসব প্রতিষ্ঠানে আমি কাজ করেছি, সেখানে সৎ উত্তরটা সাধারণত মাসে ৪০ থেকে ১২০ ঘণ্টা। মানে শুধু সফটওয়্যারগুলোকে একে অপরের সঙ্গে মিলিয়ে রাখতেই একজন খণ্ডকালীন কর্মীর বেতন চলে যাচ্ছে।
নির্দিষ্ট অঙ্কের বিক্রিতে পৌঁছালেই ERP লাগে — ব্যাপারটা এমন নয়। ERP লাগে তখন, যখন সবকিছু সমন্বয় করে চালানোর খরচ বদলের খরচকে ছাড়িয়ে যায়। আমি এই লক্ষণগুলো খুঁজি:
এর তিনটা বা তার বেশি আপনার সঙ্গে মিলে গেলে প্রশ্ন আর এক জায়গায় আনবেন কি না নয়; প্রশ্ন হলো কীভাবে নিরাপদে আনবেন।
অনেক প্রোডাক্ট শুধু একই লগইন পেজ থাকায় নিজেকে "ইন্টিগ্রেটেড" বলে। আপনি কিন্তু সেজন্য টাকা দিচ্ছেন না। সত্যিকারের ইন্টিগ্রেটেড ERP-তে একটা ঘটনা একবারই ঘটে, আর যে যে মডিউলের সেটা জানা দরকার, তারা নিজে থেকেই সাড়া দেয়। কাউকে কিছু এক্সপোর্ট, ইমপোর্ট বা দ্বিতীয়বার টাইপ করতে হয় না।
এটা সম্ভব হয় event-driven আর্কিটেকচারে। প্রতিটা মডিউল নিজের ডেটার মালিক — অর্ডার, স্টক, হিসাবের খাতা, কর্মী। গুরুত্বপূর্ণ কিছু ঘটলে মডিউলটা একটা event ঘোষণা করে: অর্ডার এসেছে, পেমেন্ট হয়েছে, স্টক সরেছে, জার্নাল পোস্ট হয়েছে। বাকি মডিউলগুলো সেই ঘোষণা শুনে নিজের কাজ করে। StoreConsole ঠিক এভাবেই বানানো: মডিউলগুলো কথা বলে শুধু event আর listener দিয়ে, কেউ কারও টেবিলে সরাসরি হাত দেয় না। এতে তিনটা বড় সুবিধা পাওয়া যায়:
একটা বিক্রিকে ইন্টিগ্রেটেড সিস্টেমের ভেতর দিয়ে অনুসরণ করলেই পার্থক্যটা চোখে পড়ে:
| ধাপ | কী হয় | কোন মডিউল |
|---|---|---|
| ১. অর্ডার | অনলাইন, POS, ফোন বা চ্যাট — যেখান থেকেই আসুক, একই দাম, একই ট্যাক্স, একই চেকআউট নিয়ম। | Checkout |
| ২. স্টক রিজার্ভ | যে লোকেশন থেকে পণ্য যাবে, সেখানে পরিমাণটা আটকে রাখা হয়; অন্য কোনো চ্যানেল আর সেটা বেচতে পারে না। | Inventory |
| ৩. পেমেন্ট | কার্ড, COD, ব্যাংক ট্রান্সফার, অথবা আগে থেকে ঠিক করা পেমেন্ট শর্ত। | Payment |
| ৪. জার্নাল পোস্ট | আয়, ট্যাক্স আর পাওনা টাকা নিজে থেকেই খাতায় উঠে যায়। | Accounting |
| ৫. কুরিয়ার বুকিং | ডেলিভারি ইঞ্জিন চার্জ হিসাব করে কুরিয়ারে পার্সেল বুক করে দেয়। | Delivery |
| ৬. স্ট্যাটাস আপডেট | কুরিয়ারের আপডেট অনুযায়ী অর্ডার হয়ে যায় ডেলিভারড, আংশিক ডেলিভারড বা রিটার্ন। | Order |
| ৭. টাকা সমন্বয় | কুরিয়ারের তোলা COD-এর টাকা অর্ডারের সঙ্গে মিলিয়ে খাতায় তোলা হয়। | Accounting |
| ৮. গ্রাহককে মনে রাখা | লয়্যালটি পয়েন্ট যোগ হয়, CRM-এ টাইমলাইন আপডেট হয়, রিভিউর অনুরোধ যায়। | CRM, Loyalty |
আটটা ধাপ, অথচ মানুষের একমাত্র কাজ পার্সেলটা প্যাক করা। "আমাদের সব কাজের জন্য সফটওয়্যার আছে" আর "আমাদের সফটওয়্যারগুলো একসঙ্গে কাজ করে" — এই দুইয়ের পার্থক্য ঠিক এখানেই।
ERP প্রজেক্ট ব্যর্থ হওয়ার সবচেয়ে বড় কারণ হলো সব একসঙ্গে চালু করা: এক সপ্তাহান্তে সবকিছু অন, সোমবার পুরোনো সিস্টেম অফ। তারপর কিছু একটা গোলমাল হলে (আর হয়ই) কেউ বুঝতে পারে না সমস্যাটা ঠিক কোন জায়গায়।
এর বদলে ধাপে ধাপে এগোন: প্রতিটা ধাপ চালু হবে, কিছুদিন স্থির হয়ে চলবে, তারপর পরেরটা শুরু হবে। এক থেকে পাঁচটা লোকেশনের ব্যবসার জন্য আমার পরামর্শ ১৩ সপ্তাহের এই পরিকল্পনা।
কোনো কিছু সেটআপ করার আগে একটা তালিকা বানান: কোন কোন টুল চলছে, কে কোনটার দায়িত্বে, কোথায় কী ডেটা আছে। তারপর প্রতিটা ধরনের ডেটার জন্য ঠিক করুন মূল রেকর্ড কোনটা — পণ্য, গ্রাহক, সাপ্লায়ার, কর্মী। চোখে পড়ার মতো সমস্যাগুলো এখনই সাফ করুন: একই গ্রাহক দুবার, এক SKU দিয়ে দুটো আলাদা পণ্য, একই সাপ্লায়ারের নাম তিন বানানে।
ফলাফল: এক পাতার একটা মাইগ্রেশন ম্যাপ, যাতে লেখা থাকবে নতুন সিস্টেমে প্রতিটা গুরুত্বপূর্ণ সংখ্যা কোথায় থাকবে।
পণ্য, ভ্যারিয়েন্ট আর বারকোড তুলুন। লোকেশনগুলো সাজান: গুদাম, আউটলেট আর পথে থাকা মাল। শুরুর স্টক দিন কেনা দামসহ, কারণ পরে লাভ-ক্ষতির রিপোর্ট অর্থবহ হয় এই দামের কারণেই। ধাপ শেষে সরেজমিনে গুনে সিস্টেমের সঙ্গে মিলিয়ে নিন।
ফলাফল: স্টকের একটাই হিসাব, যেটা সব চ্যানেল পড়ে।
চেকআউট, POS আর পেমেন্ট যুক্ত করুন। হিসাবের খাতা (chart of accounts) সাজান, আর বিক্রি থেকে জার্নাল যেন নিজে থেকে পোস্ট হয় সেটা চালু করুন। এই ধাপে দুটো সিস্টেম পাশাপাশি চালানো সবচেয়ে কাজে দেয়: পুরোনো অ্যাকাউন্টিং সফটওয়্যারটা এক মাস রেখে দিন, দুই জায়গাতেই মাস বন্ধ করুন, তারপর মিলিয়ে দেখুন। যেখানে পার্থক্য, সেখানেই সেটআপের ভুল।
ফলাফল: মাসের হিসাব বন্ধ হয় সিস্টেম থেকে, স্প্রেডশিট থেকে নয়।
কর্মীদের তথ্য, ডিউটির সময়সূচি, ছুটির দিন আর ছুটির নিয়ম তুলুন। ভাতা আর কর্তনসহ বেতনের কাঠামো বানান। একবার পুরোনো পদ্ধতির পাশাপাশি বেতন চালিয়ে মিলিয়ে নিন, তারপর থেকে বেতন পোস্ট করলেই জার্নাল এন্ট্রি নিজে তৈরি হবে — বেতনের খরচ আর দেনা কারও হাত না লাগিয়েই খাতায় উঠবে।
ফলাফল: হাজিরা আর ছুটির সঙ্গে জোড়া, এক ক্লিকে বেতন।
ডেটা এখন বিশ্বাসযোগ্য। তাই ঠিক করুন কোন দায়িত্বের মানুষ রোজ সকালে কোন সংখ্যা দেখবেন। স্টক কমে গেলে সতর্কবার্তা, চ্যানেল ও আউটলেটভিত্তিক দৈনিক বিক্রির সারাংশ, আর রিফান্ড ও পারচেজ অর্ডারের অনুমোদনের ধাপ চালু করুন। AI অ্যাসিস্ট্যান্ট ব্যবহার করলে শুরুতে তাকে শুধু দেখার অনুমতি দিন; কোনো কাজ করবে কেবল মানুষ অনুমোদন দিলে।
ফলাফল: এমন ডেটা থেকে সিদ্ধান্ত, যার ওপর সবার ভরসা আছে।
একটা সহজ নিয়ম: আগের ধাপ অন্তত পুরো এক সপ্তাহ হাতে কোনো সংশোধন ছাড়া না চলা পর্যন্ত নতুন ধাপ শুরু করবেন না। এক সপ্তাহের ধৈর্য এক মাসের দৌড়ঝাঁপের চেয়ে অনেক সস্তা।
এই ছোট ভিডিওতে ওপরের প্রক্রিয়ার অ্যাকাউন্টিং অংশটা দেখানো হয়েছে: হিসাবের খাতা, ব্যবসার ঘটনা থেকে নিজে তৈরি হওয়া জার্নাল, আর সেগুলো থেকে বানানো রিপোর্ট।
দশ বছরের এলোমেলো রেকর্ড নতুন সিস্টেমে তুললে এলোমেলো অবস্থাটাই শুধু দ্রুত হয়। খোলা ব্যালান্স, চালু পণ্য, বর্তমান গ্রাহক আর সাম্প্রতিক ইতিহাস তুলুন। বাকিটা একটা আর্কাইভ ফাইলে রেখে দিন, দরকার হলে সেখান থেকে খুঁজে নেবেন।
প্রথম সপ্তাহে টিম যে পরিবর্তনগুলো চায়, ছয় সপ্তাহ পর প্রায়ই সেগুলো আর লাগে না। আগে এক মাস স্ট্যান্ডার্ড প্রক্রিয়ায় চালান। ইন্টিগ্রেটেড প্রবাহটা চোখে দেখার পর বেশিরভাগ "এটা না হলে চলবেই না" ধরনের দাবি নিজে থেকেই হারিয়ে যায়।
প্রতিটা মডিউলের জন্য প্রতিষ্ঠানের ভেতরে একজন মানুষ দরকার, যিনি ঠিক করবেন সেটা কীভাবে ব্যবহার হবে — ইনভেন্টরির একজন, অ্যাকাউন্টিংয়ের একজন, HR-এর একজন। দায়িত্বশীল না থাকলে সেটআপের সিদ্ধান্ত নেন যিনি সবচেয়ে জোরে কথা বলেন।
ম্যানেজাররা ডেমো দেখেন, আর ক্যাশিয়ার বা পিকাররা পান একটা ছাপানো কাগজ। এরপর কাউন্টারের কর্মীরা নিজেদের মতো শর্টকাট বের করেন, আর স্টকের হিসাব নষ্ট হয়। যাঁরা সিস্টেম সবচেয়ে বেশি ব্যবহার করবেন, তাঁদের প্রশিক্ষণ দিন তাঁদের নিজেদের স্ক্রিনেই।
চালু হওয়া মানে আসল কাজের শুরু। ৩০ দিনের একটা স্থিতিশীলতার সময় রাখুন: রোজ ১৫ মিনিটের একটা চেক-ইন, সবার দেখা যায় এমন একটা সমস্যার তালিকা, আর প্রতিটা সমস্যার জন্য একজন নির্দিষ্ট দায়িত্বশীল।
শুরু করার আগেই এই সংখ্যাগুলোতে একমত হোন, ধাপ ০-তে একবার মাপুন, আর চালুর ৯০ দিন পর আবার মাপুন:
| KPI | সাধারণত আগে | ভালো অবস্থায় পরে |
|---|---|---|
| মাসের হিসাব বন্ধ করতে কত দিন | ৭–১২ | ২–৩ |
| স্টকের নির্ভুলতা (সিস্টেম বনাম গণনা) | ৮৫–৯২% | ৯৮%+ |
| মাসে স্টকের বেশি বিক্রি হওয়া অর্ডার | কয়েকটা | প্রায় শূন্য |
| ডেটা আনা-নেওয়ায় খরচ হওয়া ঘণ্টা | ৪০–১২০ | ১০-এর কম |
| না-মেলা COD সেটেলমেন্ট | কেউ জানে না | রোজ তালিকা, সপ্তাহে নিষ্পত্তি |
| "পণ্যভিত্তিক লাভ কত?" — উত্তর পেতে সময় | কয়েক দিন | কয়েক সেকেন্ড |
"আগের" সংখ্যাগুলো আলাদা আলাদা টুলে চলা ছোট ও মাঝারি প্রতিষ্ঠানে আমি সাধারণত যা দেখি। তবে আমার সংখ্যার চেয়ে আপনার নিজের সংখ্যা অনেক বেশি গুরুত্বপূর্ণ — এখনই লিখে রাখুন, যাতে পরে উন্নতিটা স্পষ্ট দেখা যায়।
StoreConsole বানানো হয়েছে ঠিক এই রোডম্যাপ মাথায় রেখে। কমার্স, ইনভেন্টরি, POS, ডেলিভারি, অ্যাকাউন্টিং, HR, পেরোল, CRM — প্রতিটা আলাদা মডিউল, কিন্তু সবাই একটাই ডাটাবেস ব্যবহার করে আর event-এর মাধ্যমে একে অপরকে খবর দেয়। আজ যা লাগে শুধু সেটুকু চালু করুন, প্রস্তুত হলে বাকিটা যোগ করুন। আর সবকিছু চলে আপনার নিজের সার্ভারে, তাই ডেটা থাকে আপনার হাতেই। পুরো প্রক্রিয়াটা দেখতে চাইলে লাইভ ডেমো খোলা আছে, আর সব মডিউলের তালিকা পাবেন ERP পরিচিতি পেজে।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
