বিক্রি, অপারেশন ও অর্থ জুড়ে বারোটি KPI, প্রতিটির সূত্র, দায়িত্বশীল আর দেখার ছন্দসহ। এক মাসের পুরো হিসাব, ড্যাশবোর্ড নকশার নিয়ম, আর কোনো সংখ্যা লাল হলে কী করবেন।
Author
Anichur Rahaman
সোমবার সকাল 8:40। একটি অনলাইন স্টোর আর একটি শোরুমের ছোট খুচরা ব্যবসার মালিক তিনটি স্প্রেডশিট আর ব্যাংকের app খুলে বসেছেন। শোরুমের এক্সপোর্ট বলছে সেপ্টেম্বরের বিক্রি 52,000। হিসাবরক্ষক বলছেন 51,300। courier পোর্টালের হিসাবে কতগুলো parcel দেরিতে পৌঁছেছে, সেটা আবার আলাদা। সপ্তাহের প্রথম ঘণ্টাটা চলে যায় সংখ্যা মেলাতে, সিদ্ধান্ত নেওয়ার সময়ই আর থাকে না।
9:45-এ তাঁর হাতে একটা সংখ্যা আসে, যাতে তিনি অর্ধেক ভরসা করেন, কিন্তু কী বদলাতে হবে বুঝতে পারেন না। দৃশ্যটি কাল্পনিক, তবে ছবিটা চেনা: ব্যবসার কাছে data-র অভাব নেই, অভাব এমন একটি সর্বজনস্বীকৃত সংজ্ঞার, যা বলে সংখ্যাগুলোর মানে আসলে কী।
এই লেখার বক্তব্য: বারোটি KPI-ই যথেষ্ট, যদি প্রতিটির একটি সূত্র, একজন দায়িত্বশীল আর একটি উৎস থাকে এবং সব একটি পাতায় দেখা যায়। নিচে আছে সংজ্ঞাগুলো, এক মাসের পুরো হিসাব, যেসব নকশার নিয়মে dashboard রোজ খোলা হয়, আর কোনো সংখ্যা লাল হলে কী করতে হবে।
বেশির ভাগ dashboard একই ভাবে মরে। উৎসাহের ঝোঁকে কেউ চল্লিশটা চার্ট বানিয়ে ফেলে। মাসখানেক পর দুটো চার্টে দুই রকম বিক্রি দেখা যায়, কারণ একটি order দেওয়ার দিন ধরে গোনে, অন্যটি payment-এর দিন ধরে। কোনটা ঠিক কেউ বলতে পারে না, আর সবাই নিজের স্প্রেডশিটে ফিরে যায়।
দোষটা চার্টের টুলের নয়। KPI-কে কখনো কোড বা query হিসেবে সংজ্ঞায়িত করা হয়নি: কী গোনা হবে, কোন সময়ের জন্য, কোন টেবিল থেকে, কী বাদ যাবে। সংজ্ঞা যখন কারও মাথায় থাকে, প্রতিটি এক্সপোর্ট একটু আলাদা সংখ্যা দেয়।
সমাধানটা সাদামাটা, কিন্তু কাজের। প্রতিটি KPI হিসাব হয় একটি নামকরা query-তে, যা ঘটনাগুলো রেকর্ড করা system-এর ওপর চলে: order, stock মুভমেন্ট, ডেলিভারি আর journal এন্ট্রি। রাতে (বা প্রতি ঘণ্টায়) একটি জব ফলাফল একটি স্ন্যাপশট টেবিলে লেখে, প্রতি KPI আর প্রতি সময়ের জন্য একটি সারি, যেমন kpi_id = fill_rate, period = 2026-09, value = 94.0, definition_version = 2। dashboard শুধু এই টেবিলটাই পড়ে।
definition_version কলামটা দেখতে যতটা ছোট, কাজে তার চেয়ে অনেক বড়। return রেট গোনার নিয়ম বদলালে পুরোনো মাসগুলো পুরোনো ভার্সনেই থাকে, আর চার্টে ভাঙনটা দেখা যায়। এটা না থাকলে সংজ্ঞা বদলানো চুপচাপ ইতিহাস নতুন করে লিখে ফেলে, আর ট্রেন্ডের ওপর কারও আস্থা থাকে না। order, stock মুভমেন্ট আর অ্যাকাউন্টিং journal একই database-এ লিখলে কাজটা অনেক সহজ হয়, কারণ KPI-র query তখন ফাইল মেলানোর বদলে টেবিল জোড়া দেয়; StoreConsole-এর inventory অংশ এভাবেই বানানো।
ল্যাগিং ইন্ডিকেটর বলে কী ঘটে গেছে: বিক্রি, গ্রস margin, ক্যাশ। লিডিং ইন্ডিকেটর আগে নড়ে আর ওগুলোর আভাস দেয়: কনভার্সন, stock অ্যাকুরেসি, ফিল রেট। শুধু ল্যাগিং সংখ্যার dashboard মানে রিয়ার-ভিউ আয়নায় তাকিয়ে গাড়ি চালানো। শুধু লিডিং সংখ্যা মানে আন্দাজ। দুটোই লাগে, আর লাগে দুটোর সংযোগ।
সংযোগটা একটি গাছের মতো। মাথায় আছে মুনাফা। সেটা ভাগ হয় গ্রস margin আর বিক্রির পরিমাণে, আর প্রতিটি আবার ভাগ হতে থাকে, যতক্ষণ না এমন চালকে পৌঁছায় যা এই সপ্তাহেই কেউ বদলাতে পারে: একটি ল্যান্ডিং পেজের কনভার্সন, সম্পূর্ণ পাঠানো order-এর হার, বা একটি পণ্যের stock কত দিন অবিক্রীত পড়ে আছে।
গাছটা একটা সাধারণ ভুলও ঠেকায়: যে সংখ্যা কারও হাতে নেই, সেটা ট্র্যাক করা। গাছে কোনো KPI-র মুনাফা বা ক্যাশে পৌঁছানোর পথ না থাকলে সেটা সাজসজ্জা।
বারো একটি সীমা, লক্ষ্য নয়। এগুলো বিক্রি, অপারেশন আর অর্থ জুড়ে আছে, এক থেকে কয়েক ডজন outlet-এর ব্যবসার জন্য এটুকুই যথেষ্ট।
| KPI | সূত্র | কত দিন পরপর | দায়িত্বে |
|---|---|---|---|
| নিট রাজস্ব | বিক্রি বিয়োগ discount ও return | প্রতিদিন | সেলস প্রধান |
| কনভার্সন রেট | order ÷ সেশন | প্রতিদিন | ই-কমার্স লিড |
| গড় order মূল্য | নিট রাজস্ব ÷ order | প্রতিদিন | ই-কমার্স লিড |
| রিপিট রেট | আগে কেনা ক্রেতা ÷ মোট ক্রেতা (ওই সময়ে) | প্রতি সপ্তাহে | মার্কেটিং |
| stock অ্যাকুরেসি | system-এর সঙ্গে মেলা গণনার আইটেম ÷ মোট গণনা করা আইটেম | প্রতি সপ্তাহে | inventory ম্যানেজার |
| ফিল রেট | প্রথমবারেই সম্পূর্ণ পাঠানো order ÷ প্রাপ্ত order | প্রতিদিন | অপারেশন লিড |
| সময়মতো ডেলিভারি | প্রতিশ্রুত তারিখের মধ্যে পৌঁছানো order ÷ ডেলিভারি হওয়া order | প্রতিদিন | অপারেশন লিড |
| return রেট | ফেরত আসা ইউনিট ÷ বিক্রি হওয়া ইউনিট | প্রতি সপ্তাহে | অপারেশন লিড |
| গ্রস margin | (নিট রাজস্ব − পণ্যের ক্রয়মূল্য) ÷ নিট রাজস্ব | প্রতি সপ্তাহে | অর্থ বিভাগ |
| ক্যাশ কনভার্সন সাইকেল | DIO + DSO − DPO | প্রতি মাসে | অর্থ বিভাগ |
| ডেজ সেলস আউটস্ট্যান্ডিং | বকেয়া পাওনা ÷ বাকিতে বিক্রি × সময়ের দিন | প্রতি মাসে | অর্থ বিভাগ |
| ক্যাশ রানওয়ে | হাতে নগদ ÷ মাসিক নিট ক্যাশ খরচ | প্রতি মাসে | মালিক |
ফিল রেট আর stock অ্যাকুরেসি সবচেয়ে বেশি বাদ পড়ে, অথচ পরের ধাপের বেশির ভাগ ঝামেলার ব্যাখ্যা এ দুটোতেই থাকে। যে দোকান বিক্রি করা মাল পাঠাতে পারে না, গ্রাহকসেবার সমস্যা আসার অনেক আগেই তার stock অ্যাকুরেসির সমস্যা আছে।
একটি কাল্পনিক উদাহরণ: এক ছোট খুচরা ব্যবসার সেপ্টেম্বর, মার্কিন ডলারে। ইনপুটগুলো বানানো, তবে নিজেদের মধ্যে মিলে যায়, তাই নিচের প্রতিটি সংখ্যা হাতে কষে যাচাই করা যায়।
| KPI | হিসাব | ফল | লক্ষ্য |
|---|---|---|---|
| কনভার্সন | 1,000 ÷ 40,000 | 2.5% | 2.4% |
| গড় order মূল্য | 52,000 ÷ 1,000 | 52.00 | 52.00 |
| রিপিট রেট | 312 ÷ 780 | 40.0% | 38% |
| stock অ্যাকুরেসি | 368 ÷ 400 | 92.0% | 97% |
| ফিল রেট | 940 ÷ 1,000 | 94.0% | 96% |
| সময়মতো ডেলিভারি | 864 ÷ 960 | 90.0% | 92% |
| return রেট | 168 ÷ 2,400 | 7.0% | 6% |
| গ্রস margin | (52,000 − 33,800) ÷ 52,000 = 18,200 ÷ 52,000 | 35.0% | 36% |
| inventory দিন (DIO) | 67,600 ÷ 33,800 × 30 | 60 দিন | 55 দিন |
| ডেজ সেলস আউটস্ট্যান্ডিং (DSO) | 6,000 ÷ 12,000 × 30 | 15 দিন | 15 দিন |
| পরিশোধের দিন (DPO) | 25,350 ÷ 33,800 × 30 | 22.5 দিন | 25 দিন |
| ক্যাশ কনভার্সন সাইকেল | 60 + 15 − 22.5 | 52.5 দিন | 45 দিন |
| ক্যাশ রানওয়ে | 54,000 ÷ 6,000 | 9.0 মাস | 9 মাস |
টেবিলটা মালিকের চোখে পড়ুন। কনভার্সন আর রিপিট রেট লক্ষ্য ছাড়িয়েছে, মানে চাহিদা ঠিকই আছে। ছয়টি সংখ্যা লক্ষ্য ছোঁয়নি, আর তার চারটি একই শেকলের কড়া: stock অ্যাকুরেসি, ফিল রেট, return রেট আর ক্যাশ সাইকেল। stock গণনা 8% ভুল হলে কিছু order এমন পণ্যের জন্য নেওয়া হয়ে যায় যা শেলফে নেই, আর ফিল রেট নেমে আসে 94%-এ। সেই বিক্রির মাল দেরিতে, অর্ধেক, বা একেবারেই যায় না, পিছু পিছু আসে return। এদিকে 67,600 মূল্যের inventory 60 দিন পড়ে থাকে, ফলে ক্যাশ কনভার্সন সাইকেল 45-এর বদলে দাঁড়ায় 52.5 দিনে। একটি ইনপুট ঠিক করলে কয়েকটি আউটপুট নড়ে, আর গাছ দেখিয়ে দেয় কোনটা আগে ধরতে হবে।
ক্যাশ সাইকেল নিয়ে একটি কথা: DIO আর DPO-তে ভিত্তি হলো পণ্যের ক্রয়মূল্য, DSO-তে বাকিতে বিক্রি, আর তিনটিতেই একই 30 দিনের সময়কাল। সময়কাল বা ভিত্তি গুলিয়ে ফেলা ভুল অথচ বিশ্বাসযোগ্য উত্তর পাওয়ার সবচেয়ে সাধারণ কারণ।
বারোটি সংখ্যা এক পর্দায় ধরে যায়। বাকিটা হলো প্রতিটি টাইলে কী দেখানো হবে, তার শৃঙ্খলা।
লাল রঙের একটা মানে থাকলে তবেই dashboard কাজের। কেউ কিছু করার আগে প্রশ্নটা হলো: সংখ্যাটা ভুল, নাকি ব্যবসাটা?
আগে পাইপলাইন দেখুন। রাতের জব চলেছে কি, কোনো চ্যানেল feed থেকে বাদ পড়েছে কি, কোনো সংজ্ঞা বদলেছে কি? ফিল রেট এক রাতে 94% থেকে 61%-এ নামলে সাধারণত feed ভেঙেছে, গুদামে বিপর্যয় ঘটেনি। data ঠিক থাকলে পরিবর্তনটা সত্যি, আর চারটি জিনিস লিখে রাখতে হবে: দায়িত্বশীল, কারণ, পদক্ষেপ আর রিভিউয়ের তারিখ। রিভিউয়ের তারিখ ছাড়া লাল টাইল দুই সপ্তাহ কেউ না দেখলে নিজে থেকেই হলুদ হয়ে যায়।
8:40-এ সেই মালিকের কাছে ফিরে যাই। স্ন্যাপশট টেবিল চালু থাকলে তিনি একটি পাতা খোলেন। বিক্রি 52,000, হিসাবরক্ষকও এই সংখ্যাই দেখছেন, কারণ দুজনই একই order পড়ছেন। ছয়টি টাইল লাল। ফিল রেট 96%-এর জায়গায় 94%, ড্রিল-ডাউনে 60টি অসম্পূর্ণ order, আর তার 41টিতে একই ছয়টি SKU-র নাম।
কারণ stock অ্যাকুরেসি, তাই পদক্ষেপের দায়িত্ব inventory ম্যানেজারের: ওই ছয়টি SKU আবার গুনবেন, শুক্রবার রিভিউ। মিটিং শেষ হয় পনেরো মিনিটে। যে ঘণ্টাটা সংখ্যা মেলাতে যেত, সেটা এখন যায় ওই ছয়টি SKU-তে।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
