৯০ দিনের ERP roadmap: তথ্য এক জায়গায়, অনুমোদিত ধাপে এগিয়ে যান

শুক্রবার বিকেল। অনলাইন শপে পণ্যটি available, কিন্তু warehouse-এর sheet বলছে stock নেই। ক্রেতা অপেক্ষায়; দুই সহকর্মী export মিলিয়ে দেখছেন। এটি বোঝানোর জন্য তৈরি একটি উদাহরণ, কোনো গ্রাহকের case study নয়। সমস্যাটা পরিচিত: একই তথ্যের কয়েকটি আলাদা সংস্করণ।

আরেকটি dashboard যোগ করলেই এই অমিল মিটবে না। কোন record-এর দায়িত্ব কার, পরিবর্তন অন্য system-এ কীভাবে যাবে, আর message দেরিতে এলে কী হবে—আগে তা ঠিক করতে হবে। ERP-এর আসল কাজ হলো বিশ্বাসযোগ্য business process তৈরি করা।

২০২৬ সালের এই guide-এ প্রায় ৯০ দিনে সীমিত পরিসরের প্রথম ERP rollout সাজানোর একটি নমুনা আছে। এটি delivery guarantee নয়। একাধিক legal entity, জটিল manufacturing, সংবেদনশীল data বা স্থানীয় payroll rules থাকলে আরও সময় লাগতে পারে।

আলাদা আলাদা টুলের আসল খরচ কোথায়

পাঁচটা software-এর লাইসেন্স ফি সাধারণত বড় সমস্যা নয়। আসল খরচ লুকিয়ে থাকে টুলগুলোর মাঝখানের কাজে। কোনো invoice-এ এটা দেখা যায় না, তাই প্রায় সবাই একে ছোট করে দেখেন। সাধারণত চিত্রটা এমন:

• Re-keying। মাস শেষে shop থেকে order export করে accounting-এ তোলা হয়। প্রতিটা manual step-এ একটা decimal বা একটা discount হারিয়ে যাওয়ার ঝুঁকি থাকে।
• stock drift। অনলাইন স্টোর, POS আর warehouse — তিন জায়গায় তিন রকম সংখ্যা। ফলে অনলাইনে overselling হয়ে যায়, আবার তাকে থাকা পণ্য অনলাইনে hidden দেখায়।
• Cash you cannot see। COD-এর টাকা কয়েক দিন courier-এর কাছে পড়ে থাকে। তাদের settlement file order-এর সঙ্গে মেলানো পুরোটাই manual job, আর unmatched row-গুলো নিঃশব্দে লোকসানের খাতায় চলে যায়।
• Payroll in isolation। Attendance এক জায়গায়, leave আরেক জায়গায়, payroll একটা sheet-এ। Payroll run-এর পর সেটা কখনো ঠিকঠাক journal entry হয়ে ledger-এ পৌঁছায় না।
• Reports that disagree। Shop dashboard-এর sales-এর সঙ্গে accounting-এর revenue কখনো মেলে না। তাই প্রতিটা meeting শুরু হয় "কোন সংখ্যাটা ঠিক" সেই তর্ক দিয়ে।

কেনার আগে coordination-এর কাজ মাপুন। ধরুন, চারজন প্রতিদিন আধা ঘণ্টা করে ২০ কর্মদিবস export মিলিয়েছেন। সময় লেগেছে ৪ × ০.৫ × ২০ = ৪০ staff-hour। এটি হিসাব বোঝানোর উদাহরণ; industry benchmark বা পুরো সময়টাই বাঁচবে—এমন প্রতিশ্রুতি নয়।

সাতটি লক্ষণ: বুঝবেন পুরোনো টুলে আর চলছে না

নির্দিষ্ট অঙ্কের বিক্রিতে পৌঁছালেই ERP লাগে — ব্যাপারটা এমন নয়। ERP লাগে তখন, যখন সবকিছু সমন্বয় করে চালানোর খরচ বদলের খরচকে ছাড়িয়ে যায়। আমি এই লক্ষণগুলো খুঁজি:

1. মাসের হিসাব বন্ধ করতে পাঁচ কর্মদিবসের বেশি লাগে, আর বেশিরভাগ সময় যায় হিসাব মেলাতে।
2. গত তিন মাসে অন্তত একবার stock-এর চেয়ে বেশি বিক্রি হয়েছে, কারণ দুটো channel একই stock থেকে বিক্রি করছিল, কেউ কাউকে না জানিয়ে।
3. একজন মানুষই পুরো "integration"। তিনি ছুটিতে গেলে invoice, বেতন বা courier-এর হিসাব — সব আটকে যায়।
4. সহজ প্রশ্নের উত্তর তাড়াতাড়ি পান না। যেমন, "এ মাসে কোন পণ্যে কত লাভ হলো?" বা "courier-এর কাছে এখনো কত টাকার COD আটকে আছে?"
5. গ্রাহকের তথ্য ছড়িয়ে-ছিটিয়ে আছে। order, সাপোর্ট টিকিট আর loyalty পয়েন্ট আলাদা আলাদা টুলে, তাই কেউ একজন গ্রাহককে পুরোটা দেখতে পায় না।
6. নতুন channel মানেই নতুন ঝামেলা। দ্বিতীয় outlet বা নতুন সেলস channel খোলা মানে আরেকটা টুল আর আরেক দফা export।
7. audit-এর কথা শুনলে অস্বস্তি হয়। কে কবে দাম, বেতন বা stock-এর সংখ্যা বদলেছে — তা দেখানোর উপায় নেই।

লক্ষণগুলো দেখলে কারণ খুঁজুন; সঙ্গে সঙ্গে নতুন software কেনার সিদ্ধান্ত নেবেন না। একটি গুরুতর control failure কয়েকটি ছোট অসুবিধার চেয়ে বেশি গুরুত্বপূর্ণ হতে পারে। সম্পূর্ণ system বদলানোর পাশাপাশি ছোট integration বা process improvement-এর খরচও তুলনা করুন।

"ইন্টিগ্রেটেড" কথাটার আসল মানে

একটি login থাকলেই integration হয় না। প্রতিটি business fact-এর দায়িত্ব ঠিক থাকতে হবে। Stock movement-এর মালিক Inventory; posted journal-এর মালিক Accounting। অন্য module প্রয়োজনে read model রাখতে পারে, কিন্তু সেটি যেন আরেকটি প্রতিদ্বন্দ্বী master record না হয়।

Event দিয়ে module যুক্ত করা যায়, তবে event থাকলেই data সঠিক থাকবে না। Retry, duplicate detection, reconciliation এবং failure দেখা ও সামলানোর ব্যবস্থা লাগবে। Audit trail-এর জন্যও পরিচয়, সময়, retention ও access control আলাদাভাবে নকশা করতে হয়।

• প্রতিটি তথ্যের একজন দায়িত্বশীল owner; স্পষ্ট interface ও reconciliation।
• Dependency ও পুরো workflow যাচাই করে নতুন module যোগ করুন।
• Audit record, approval ও recovery আলাদাভাবে তৈরি করুন; এগুলো আপনা-আপনি হয় না।

order থেকে টাকা হাতে আসা পর্যন্ত, ধাপে ধাপে

একটা বিক্রিকে ইন্টিগ্রেটেড systemের ভেতর দিয়ে অনুসরণ করলেই পার্থক্যটা চোখে পড়ে:

Business checkpoint	কী প্রমাণ রাখবেন
Order গ্রহণ	Order ও প্রযোজ্য commercial rules যাচাই করুন।
Stock reserve	বিক্রয়যোগ্য quantity ধরে রাখুন; cancel বা মেয়াদ শেষ হলে ছাড়ুন।
Payment record	Authorised, captured, failed, refunded ও unpaid আলাদা রাখুন।
Fulfilment নিশ্চিত	কী পাঠানো, পৌঁছানো ও ফেরত এসেছে তা লিখুন।
Accounting posting	Finance-অনুমোদিত recognition, tax ও receivable rules প্রয়োগ করুন।
Settlement মেলানো	Order-এর সঙ্গে payment/courier remittance, fee ও adjustment মিলিয়ে নিন।

এই table একটি business checklist; সবার জন্য নির্দিষ্ট accounting sequence নয়। Payment exception, refund approval এবং stock difference মানুষকেই সামলাতে হবে। Order acceptance, delivery, revenue recognition ও cash settlement আলাদা ঘটনা; প্রযোজ্য accounting rules finance team অনুমোদন করবে।

৯০ দিনে ধাপে ধাপে ERP চালু করার roadmap

ছোট ও পরস্পরনির্ভর scope একবারে cutover করা কখনো যৌক্তিক হতে পারে। তবে ঝুঁকি এক জায়গায় জমে। ধাপে rollout করলে প্রথম ধাক্কার পরিসর কমে, কিন্তু কিছুদিন অতিরিক্ত integration ও reconciliation লাগে। দলের সক্ষমতা ও dependency দেখে পথ বেছে নিন।

নিচের সময়গুলো planning window। একটি location বা শুরু থেকে শেষ পর্যন্ত একটি process দিয়ে শুরু করুন। নির্ধারিত evidence পাওয়া গেলে পরের ধাপে যান; calendar-এর তারিখ পার হওয়া acceptance test নয়।

ধাপ ০ — data audit (সপ্তাহ ১–২)

কোনো কিছু সেটআপ করার আগে একটা তালিকা বানান: কোন কোন টুল চলছে, কে কোনটার দায়িত্বে, কোথায় কী data আছে। তারপর প্রতিটা ধরনের dataর জন্য ঠিক করুন মূল রেকর্ড কোনটা — পণ্য, গ্রাহক, supplier, কর্মী। চোখে পড়ার মতো সমস্যাগুলো এখনই সাফ করুন: একই গ্রাহক দুবার, এক SKU দিয়ে দুটো আলাদা পণ্য, একই supplier-এর নাম তিন বানানে।

ফলাফল: এক পাতার একটা মাইগ্রেশন ম্যাপ, যাতে লেখা থাকবে নতুন systemে প্রতিটা গুরুত্বপূর্ণ সংখ্যা কোথায় থাকবে।

ধাপ ১ — catalog ও stock (সপ্তাহ ৩–৫)

পণ্য, ভ্যারিয়েন্ট আর বারকোড তুলুন। locationগুলো সাজান: গুদাম, outlet আর পথে থাকা মাল। শুরুর stock দিন কেনা দামসহ, কারণ পরে লাভ-ক্ষতির report অর্থবহ হয় এই দামের কারণেই। ধাপ শেষে সরেজমিনে গুনে systemের সঙ্গে মিলিয়ে নিন।

ফলাফল: stock-এর একটাই হিসাব, যেটা সব channel পড়ে।

ধাপ ২ — order ও টাকা (সপ্তাহ ৬–৮)

Order, payment, refund, tax ও settlement পুরো পথ ধরে পরীক্ষা করুন। Opening balance ও posting mapping finance অনুমোদন করবে। Parallel comparison চললেও কোন ledger অফিসিয়াল তা নির্দিষ্ট রাখুন; অন্যটির ফল তার সঙ্গে মিলিয়ে দেখুন।

ফলাফল: মাসের হিসাব বন্ধ হয় system থেকে, স্প্রেডশিট থেকে নয়।

ধাপ ৩ — কর্মী ও বেতন (সপ্তাহ ৯–১১)

স্থানীয় নিয়ম, privacy control ও দায়িত্ব পরিষ্কার হলে payroll আনুন। Leave, overtime, deduction, correction এবং journal-সহ সম্পূর্ণ pay cycle তুলনা করুন। আরও সময় দরকার হলে নিয়ন্ত্রিত integration চালু রাখুন; জোর করে ৯০ দিনের মধ্যে payroll আনার প্রয়োজন নেই।

ফলাফল: হাজিরা ও ছুটির সঙ্গে যুক্ত, যাচাই করা payroll process।

ধাপ ৪ — report ও automation (সপ্তাহ ১২–১৩)

data এখন বিশ্বাসযোগ্য। তাই ঠিক করুন কোন দায়িত্বের মানুষ রোজ সকালে কোন সংখ্যা দেখবেন। stock কমে গেলে সতর্কবার্তা, channel ও আউটলেটভিত্তিক দৈনিক বিক্রির সারাংশ, আর refund ও পারচেজ orderের অনুমোদনের ধাপ চালু করুন। AI অ্যাসিস্ট্যান্ট ব্যবহার করলে শুরুতে তাকে শুধু দেখার অনুমতি দিন; কোনো কাজ করবে কেবল মানুষ অনুমোদন দিলে।

ফলাফল: এমন data থেকে সিদ্ধান্ত, যার ওপর সবার ভরসা আছে।

Phase gate: process owner মেলানো data, বাস্তব exception test, প্রশিক্ষিত operator ও support plan দেখে অনুমোদন দেবেন। এক সপ্তাহ শান্তভাবে চলা ভালো লক্ষণ, কিন্তু তা month-end close বা refund-এর মতো কম ঘটা গুরুত্বপূর্ণ কাজের test-এর বিকল্প নয়।

Go-live-এর আগে কঠিন দিনটির মহড়া দিন

যাঁরা কাজ করেন, তাঁদের নিয়ে একটি order, partial delivery, return ও failed settlement-এর মহড়া দিন। একই webhook আবার এলে এবং provider বন্ধ থাকলে কী হয় দেখুন। কে retry, adjustment approve এবং salary বা customer data দেখতে পারবেন তা ঠিক করুন। Cutover freeze, final export, reconciliation total, সিদ্ধান্তের owner ও rollback trigger লিখুন। নতুন system-এ transaction নেওয়া হয়ে গেলে পুরোনোটিতে ফিরতে সেই নতুন record-ও নিয়ন্ত্রিতভাবে মেলাতে হবে; শুধু পুরোনো backup restore করা নিরাপদ rollback নয়।

নিজের চোখে দেখুন: জোড়া লাগানো ব্যাক অফিস

এই ছোট ভিডিওতে ওপরের প্রক্রিয়ার অ্যাকাউন্টিং অংশটা দেখানো হয়েছে: হিসাবের খাতা, ব্যবসার ঘটনা থেকে নিজে তৈরি হওয়া journal, আর সেগুলো থেকে বানানো report।

যে পাঁচটা ভুল ERP প্রজেক্ট ডুবিয়ে দেয়

১. অগোছালো data হুবহু তুলে আনা

Business need ও প্রযোজ্য retention obligation দেখে migration scope ঠিক করুন। Opening quantity, value ও balance মিলিয়ে নিন; প্রয়োজনীয় history খোঁজার ব্যবস্থা রাখুন। পুরোনো বলেই record বাদ দেবেন না। Backup-এর ওপর নির্ভর করার আগে restore করে যাচাই করুন।

২. ব্যবহারের আগেই কাস্টমাইজ করা

Customisation-এর আগে standard workflow ব্যবহার করে দেখুন। তবে বাস্তব legal, safety বা operational gap লিখে রাখুন। দায়িত্ব ও মাপা যায় এমন উপকার দেখে change বাছুন; এক মাস পর বেশির ভাগ requirement উধাও হবে—এমন নিশ্চয়তা নেই।

৩. প্রতিটা moduleের কোনো দায়িত্বশীল নেই

প্রতিটা moduleের জন্য প্রতিষ্ঠানের ভেতরে একজন মানুষ দরকার, যিনি ঠিক করবেন সেটা কীভাবে ব্যবহার হবে — inventory-র একজন, অ্যাকাউন্টিংয়ের একজন, HR-এর একজন। দায়িত্বশীল না থাকলে সেটআপের সিদ্ধান্ত নেন যিনি সবচেয়ে জোরে কথা বলেন।

৪. মাঠের কর্মীদের প্রশিক্ষণ বাদ দেওয়া

ম্যানেজাররা demo দেখেন, আর ক্যাশিয়ার বা পিকাররা পান একটা ছাপানো কাগজ। এরপর কাউন্টারের কর্মীরা নিজেদের মতো শর্টকাট বের করেন, আর stock-এর হিসাব নষ্ট হয়। যাঁরা system সবচেয়ে বেশি ব্যবহার করবেন, তাঁদের প্রশিক্ষণ দিন তাঁদের নিজেদের screenেই।

৫. চালু হওয়াকেই শেষ ধরে নেওয়া

চালু হওয়া মানে আসল কাজের শুরু। ৩০ দিনের একটা স্থিতিশীলতার সময় রাখুন: রোজ ১৫ মিনিটের একটা চেক-ইন, সবার দেখা যায় এমন একটা সমস্যার তালিকা, আর প্রতিটা সমস্যার জন্য একজন নির্দিষ্ট দায়িত্বশীল।

মেপে দেখুন: যে KPI বলবে ERP সত্যিই কাজ করেছে

প্রথমে baseline লিখুন; প্রতিটি process-এর দায়িত্বে থাকা মানুষ target ঠিক করবেন। নিচের worksheet কী মাপবেন তা বোঝায়; বানানো before–after benchmark নয়।

কী মাপবেন	সংজ্ঞা
Close duration	Finance sign-off পর্যন্ত কর্মদিবস; বাকি অমিলের ব্যাখ্যা।
Count-line accuracy	সঠিক SKU-location line ÷ পরীক্ষা করা line × ১০০।
Overselling	ভুল sellable stock-এর কারণে পূরণ করা যায়নি এমন গৃহীত order।
Reconciliation effort	একই data তোলা ও মেলাতে ব্যয় হওয়া staff-hour।
Unmatched settlement	অমীমাংসিত টাকার পরিমাণ ও বয়স; fee, refund ও partial payment-সহ।

ধরুন, পরীক্ষা করা ২০০টি SKU-location count line-এর মধ্যে ১৯৬টি সঠিক। Count-line accuracy = ৯৮%। এর অর্থ stock value-ও ৯৮% সঠিক নয়। একই sampling method, unit ও সময়সীমা ধরে তুলনা করুন।

এখানে StoreConsole-এর ভূমিকা

StoreConsole demo-তে শুধু feature list দেখবেন না; নিজের একটি workflow পরীক্ষা করুন। প্রয়োজনীয় module, permission, integration, hosting ও recovery-এর দায়িত্ব যাচাই করে তারপর scope ও launch date ঠিক করুন।

সংক্ষেপে

• একটি ব্যয়বহুল coordination problem ও মাপা baseline দিয়ে শুরু করুন।
• Owner, duplicate handling, reconciliation ও recovery আগে ঠিক করুন।
• Evidence না মিললে সময় বাড়ান; অনুমোদিত ধাপ ধরে এগোন।
• Sensitive decision ও ব্যতিক্রমী transaction মানুষের নিয়ন্ত্রণে রাখুন।

তথ্যসূত্র ও পর্যালোচনা

Microsoft-এর implementation guidance-এ migration rehearsal ও business sign-off-এর গুরুত্ব আছে। এখানে দেওয়া সময়সূচি ও হিসাব আমাদের planning example; Microsoft-এর বাধ্যতামূলক নিয়ম নয়। পর্যালোচনা: ৪ নভেম্বর ২০২৬।

• Microsoft Learn: go-live checklist
• Microsoft Learn: cutover strategy

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।