ব্ল্যাক ফ্রাইডে সেল60% পর্যন্ত ছাড়
  • বার্ষিক প্ল্যানে প্রথম বছর 60% ছাড়
  • লাইফটাইম লাইসেন্সে 45% ছাড়
শেষ হবে
অফারটি নিন

ব্যবসার ১২টি KPI: সঠিক সংজ্ঞা, বোঝা যায় এমন সিদ্ধান্ত

Sales, inventory, delivery ও cash KPI-এর cohort, formula ও exception সহজে বুঝুন। হিসাবের উদাহরণ আছে, প্রমাণ ছাড়া কারণ ধরে নেওয়া নেই।

লেখক

Anichur Rahaman

1 মাস আগে8 মিনিট পড়া179 দেখা
ব্যবসার ১২টি KPI: সঠিক সংজ্ঞা, বোঝা যায় এমন সিদ্ধান্ত

সোমবার সকাল। এক report-এ net order value ৫০,০০০; আরেকটিতে recognised revenue ৫২,০০০। মালিক “সংখ্যা ঠিক করুন” বলার আগে জানতে চান, কোন report-এ কী গোনা হয়েছে? আলোচনার মোড় বদলায়: নতুন chart-এর আগে সংজ্ঞা পরিষ্কার করতে হবে।

এটি বিষয়টি বোঝানোর কাল্পনিক দৃশ্য, কোনো গ্রাহকের case study নয়। কাজের dashboard সংখ্যার অর্থ এবং তা দিয়ে কী সিদ্ধান্ত হবে বোঝায়। সংজ্ঞা না থাকলে আরও chart বানিয়ে লাভ নেই।

২০২৬ সালের এই guide-এ ১২টি সম্ভাব্য metric আছে; সবার dashboard-এ ১২টিই লাগবে না। প্রতিটির সংজ্ঞা, scope, দায়িত্বশীল owner ও সিদ্ধান্ত ঠিক করুন। উদাহরণে হিসাব করব এবং দেখব, red tile তদন্ত শুরু করে—কারণ প্রমাণ করে না।

Sales, operations ও finance—তিন ভাগে ১২টি সম্ভাব্য business metric।
বাস্তব সিদ্ধান্তের জন্য metric বাছুন। Shared definition view-গুলোকে যুক্ত করে; arrow দেখলেই কারণ প্রমাণ হয় না।

কেন dashboard কেউ খোলে না

দুটি dashboard ভিন্ন fact মাপলে সংখ্যা আলাদা হতেই পারে: accepted order, collected payment বা accounting-এ recognised revenue। সব সময় তা ভুল নয়। প্রতিটির সঠিক নাম দিন, timing ও exclusion মেলান; তিনটিকেই “sales” বলে জোর করে সমান করবেন না।

Metric contract লিখুন: numerator, denominator, cohort, time zone, currency, exclusion, source, freshness ও version। Query সেই সংজ্ঞা প্রয়োগ করে; business decision-এর বিকল্প নয়। Revenue ও cost policy finance অনুমোদন করবে। শুধু order বা payment status দিয়ে recognised revenue ঠিক হয় না।

একটিমাত্র সত্য-উৎস দেখতে কেমন

একটি বিশ্বাসযোগ্য সংজ্ঞা governed reporting model-এ ব্যবহার করা যায়; সব module-এর table সরাসরি join করতেই হবে না। Snapshot বা live view—দুটিই গ্রহণযোগ্য, যদি source lineage, access limit ও freshness পরিষ্কার থাকে। কখন হিসাব হয়েছে এবং কোন input নেই দেখান।

Definition version রাখুন। বদলালে trend-এ break দেখান, অথবা লিখিত নিয়মে history restate করুন। চুপচাপ ভিন্ন সংজ্ঞার সংখ্যা তুলনা নয়। Reporting store-এও role ও location scope লাগবে; data কাছে আছে বলে cashier salary, সব margin বা সব customer দেখতে পারবেন না।

Result, signal ও evidence

Financial result হয়ে যাওয়া কাজ দেখায়; operational signal সামনে কী হতে পারে তা খতিয়ে দেখতে সাহায্য করে। Conversion বা stock accuracy ভবিষ্যতের profit নিশ্চিত করে না। Metric-গুলোর সম্পর্ক evidence না দেখা পর্যন্ত hypothesis।

Sales, operations ও finance আলাদা প্রশ্নের উত্তর দেয়। Demand ভালো হলেও fulfilment খারাপ হতে পারে; revenue বাড়লেও cash আটকে থাকতে পারে। Overview-টি menu হিসেবে নিন, তারপর বাস্তব সিদ্ধান্তের জন্য দরকারি metric বাছুন।

Safety, service, privacy বা compliance-এর control তাৎক্ষণিক profit-এ মাপা না গেলেও দরকারি। Non-financial metric মানেই সাজসজ্জা নয়। প্রতিটি visible metric-এর উদ্দেশ্য, owner ও উপযুক্ত response থাকুক।

বারোটি KPI, সূত্রসহ

নিচের ১২টি metric নিজের business অনুযায়ী সংজ্ঞায়িত করুন। Rate formula-তে percentage দেখানো হয়েছে। আগে cohort ঠিক করুন; denominator শূন্য হলে “প্রযোজ্য নয়”, সরাসরি zero performance নয়। খারাপ order চুপচাপ cohort থেকে বাদ দেবেন না।

KPIসূত্রকত দিন পরপরদায়িত্বে
নিট রাজস্বFinance-অনুমোদিত recognised net revenue; tax, discount ও return policy স্পষ্ট।প্রতিদিনসেলস প্রধান
ConversionPurchasing session ÷ eligible session × ১০০।প্রতিদিনই-কমার্স লিড
Average order valueEligible order-এর net value ÷ সেই order-এর সংখ্যা।প্রতিদিনই-কমার্স লিড
Returning buyer sharePeriod শুরুর আগে order ছিল এমন buying customer ÷ period-এর buying customer × ১০০।প্রতি সপ্তাহেমার্কেটিং
Count-line accuracyসঠিক SKU-location count line ÷ checked line × ১০০।প্রতি সপ্তাহেinventory ম্যানেজার
Order fill rateপ্রথম dispatch-এ complete order ÷ প্রথম dispatch due এমন eligible order × ১০০।প্রতিদিনঅপারেশন লিড
On-time deliveryPromise অনুযায়ী delivered order ÷ promise due হয়ে গেছে এমন সব eligible order × ১০০।প্রতিদিনঅপারেশন লিড
Return rateএকই নির্ধারিত mature cohort-এর returned unit ÷ fulfilled unit × ১০০।প্রতি সপ্তাহেঅপারেশন লিড
Gross margin(Recognised net revenue − COGS) ÷ recognised net revenue × ১০০।প্রতি সপ্তাহেঅর্থ বিভাগ
Cash conversion cycleDIO + DSO − DPO; একই period ও সামঞ্জস্যপূর্ণ ভিত্তি।প্রতি মাসেঅর্থ বিভাগ
DSOAverage trade receivable ÷ net credit sales × period-এর দিন।প্রতি মাসেঅর্থ বিভাগ
Cash runwayব্যবহারযোগ্য unrestricted cash ÷ forecast monthly net cash burn; burn positive হলেই।প্রতি মাসেমালিক

Order fill rate ও unit fill rate আলাদা। Count-line accuracy মানে stock value accuracy নয়। Due হয়ে গেছে কিন্তু পৌঁছায়নি—এমন order on-time delivery-র denominator-এ না রাখলে বড় delay লুকায়। Return window শেষ না হলে cohort provisional দেখান।

এক মাসের হিসাব, ধাপে ধাপে

এটি বোঝানোর উদাহরণ: currency-unit অঙ্ক বানানো, industry target নয়। Financial period ৩০ দিন; operational cohort আলাদাভাবে নির্দিষ্ট। Net order value ৫০,০০০, recognised revenue ৫২,০০০—দুটি আলাদা measure। Cash cycle বোঝাতে নিচের হিসাবে DIO ও DPO component-ও আলাদা দেখানো হয়েছে।

  • Eligible session ৪০,০০০; purchasing session ১,০০০; উদাহরণে qualifying order-ও ১,০০০, net order value ৫০,০০০।
  • Buying customer ৭৮০; period শুরুর আগে order ছিল ৩১২ জনের। Recognised net revenue ৫২,০০০; COGS ৩৩,৮০০।
  • প্রথম dispatch due এমন eligible order ১,০০০; প্রথমবার complete ৯৪০। Delivery due ১,০০০; delivered ৯৬০, সময়মতো ৮৬৪।
  • আলাদা mature return cohort: fulfilled unit ২,৪০০, returned ১৬৮। Count sample: ৪০০ SKU-location line, সঠিক ৩৬৮।
  • Average inventory ৬৭,৬০০; average trade receivable ৬,০০০; net credit sales ১২,০০০; average trade payable ২৫,৩৫০; net credit purchases ৩৩,৮০০।
  • ব্যবহারযোগ্য cash ৫৪,০০০; ভবিষ্যৎ net burn ধরা হয়েছে মাসে ৬,০০০। নয় মাসের ফল একটি scenario, liquidity guarantee নয়।
Metricহিসাবফল
Conversion১,০০০ ÷ ৪০,০০০ × ১০০২.৫%
Average order value৫০,০০০ ÷ ১,০০০৫০.০০
Returning buyer share৩১২ ÷ ৭৮০ × ১০০৪০.০%
Count-line accuracy৩৬৮ ÷ ৪০০ × ১০০৯২.০%
Order fill rate৯৪০ ÷ ১,০০০ × ১০০৯৪.০%
On-time delivery৮৬৪ ÷ ১,০০০ × ১০০৮৬.৪%
Return rate১৬৮ ÷ ২,৪০০ × ১০০৭.০%
Gross margin(৫২,০০০ − ৩৩,৮০০) ÷ ৫২,০০০ × ১০০৩৫.০%
DIO৬৭,৬০০ ÷ ৩৩,৮০০ × ৩০৬০ দিন
DSO৬,০০০ ÷ ১২,০০০ × ৩০১৫ দিন
DPO২৫,৩৫০ ÷ ৩৩,৮০০ × ৩০২২.৫ দিন
Cash conversion cycle৬০ + ১৫ − ২২.৫৫২.৫ দিন
Cash runway৫৪,০০০ ÷ ৬,০০০৯.০ মাস

৪০০ − ৩৬৮ = ৩২টি count line অমিল। এর মানে ৮% unit বা value হারিয়েছে নয়, আর এ কারণেই সব order অসম্পূর্ণ—তাও প্রমাণ হয় না। On-time result ৮৬.৪%, কারণ due হওয়া ১,০০০ delivery-ই denominator। শুধু delivered ৯৬০ নিলে ৯০% দেখিয়ে এখনো না-পৌঁছানো late order লুকাবে। SKU, location ও courier ধরে কারণ খুঁজুন।

Working-capital হিসাবে একই ৩০ দিন ও সামঞ্জস্যপূর্ণ balance নিন। DIO-তে average inventory ও COGS, DSO-তে average trade receivable ও net credit sales, এখানে DPO-তে average trade payable ও net credit purchases। Purchase data না থাকায় COGS proxy নিলে approximation লিখুন। Cash cycle কোনো নির্দিষ্ট bank payment date-এর forecast নয়।

dashboard নকশার নিয়ম

Phone-এ কম tile, পড়ার মতো label ও accessible status দিন। সব screen-এ ১২টি ছোট card গুঁজবেন না। সংখ্যা, context, update time ও অনুমোদিত evidence দেখার পথ রাখুন।

  • Value, baseline বা agreed target, trend, sample size ও last update দিন। Missing data ও zero আলাদা দেখান।
  • Decision অনুযায়ী refresh ঠিক করুন। বড় change হলে monthly forecast-ও নতুন করে দেখা লাগতে পারে।
  • Permission আছে এমন user-ই exception-এর details দেখবেন; aggregate দেখা মানেই সব row-এর অনুমতি নয়।
  • সব report-এ একটি versioned definition; restatement হলে দৃশ্যমান নোট।
  • একজন accountable owner ও backup রাখুন; collaboration ভালো, অস্পষ্ট দায়িত্ব নয়।

যখন একটি KPI লাল হয়

লাল রঙের একটা মানে থাকলে তবেই dashboard কাজের। কেউ কিছু করার আগে প্রশ্নটা হলো: সংখ্যাটা ভুল, নাকি ব্যবসাটা?

Missing feed, stale job ও definition change দেখার পাশাপাশি চলমান operational সমস্যা থেকে customer-কে রক্ষা করুন। Data ও business—দুটিতেই একসঙ্গে সমস্যা হতে পারে। হঠাৎ পতন মানেই pipeline খারাপ নয়। Evidence, hypothesis, দায়িত্ব, action ও review date লিখুন; snapshot correction-এর history রাখুন।

ভ্যানিটি metric আর অন্যান্য ফাঁদ

  • Traffic context দেয়, profit নয়। Audience quality, cost ও contribution দেখুন; শুধু conversion নয়।
  • Revenue বাড়লেও margin বা cash খারাপ হতে পারে। একই scope ও window তুলনা করুন।
  • যথেষ্ট sample থাকলে courier, channel ও location ধরে average ভাঙুন; ছোট group-এ personal data রক্ষা করুন।
  • Decision-কেন্দ্রিক ছোট dashboard সুবিধাজনক হতে পারে; ১২ বা ২০ tile-এর universal limit নেই।
  • Target ও assumption ভেবে review করুন। ফল ভালো দেখাতে পুরোনো target পাল্টাবেন না; history রাখুন।

ধাপে ধাপে dashboard pilot

  1. অল্প কয়েকটি decision বাছুন; exclusion-সহ metric contract লিখুন।
  2. Owner, permission, freshness ও baseline ঠিক করুন।
  3. Source record-এর সঙ্গে মিলিয়ে অমিল ব্যাখ্যা করুন; missing data ও zero denominator test করুন।
  4. Versioned definition-সহ readable view ও অনুমোদিত drill-down বানান।
  5. Pilot review করে hypothesis, action ও review date লিখুন।
  6. Reconciliation, user acceptance ও retention need মিটলে duplicate report সরান। এটি staged plan, চার সপ্তাহের guarantee নয়।

সোমবার সকাল, আবার

সেই কাল্পনিক সোমবারে ফিরি। Owner এখন ৫০,০০০ net order value ও ৫২,০০০ recognised revenue আলাদা বুঝতে এবং reconciliation দেখতে পারেন। Order fill rate ৯৪%। ধরুন, অসম্পূর্ণ ৬০ order-এর ৪১টিতে ছয়টি SKU আছে—এটি তদন্তের সূত্র, stock count-ই কারণ তার প্রমাণ নয়।

Inventory manager count, reservation ও pick exception দেখবেন; operations dispatch constraint দেখবেন। Evidence-এ সমস্যা নিশ্চিত হলে correction ও review ঠিক করবেন। উপকার হলো ব্যাখ্যা করা যায় এমন সিদ্ধান্ত; meeting নির্দিষ্ট মিনিটে শেষ হবে বা এত ঘণ্টা বাঁচবে—এমন প্রতিশ্রুতি নয়।

সংক্ষেপে

  • Calculation-এর আগে fact, cohort ও timing সংজ্ঞায়িত করুন।
  • Order, cash collection ও recognised revenue আলাদা রাখুন।
  • Due-but-open delivery ও অপরিণত return cohort সৎভাবে দেখান।
  • সম্পর্ক দেখলে সূত্র হিসেবে নিন; evidence দেখে কারণ ঠিক করুন।
  • Permission ও freshness দিয়ে reporting data রক্ষা করুন।
  • হিসাব দিয়ে দায়িত্বশীল সিদ্ধান্ত নিন; ফল নিশ্চিত ধরে নয়।

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

পর্যালোচনা: ৪ নভেম্বর ২০২৬। ACCA working-capital ratio ও cash operating cycle ব্যাখ্যা করে। IFRS 15-এ revenue recognition শুধু order বা cash পাওয়ার থেকে আলাদা; প্রযোজ্য accounting framework finance প্রয়োগ করবে। Cohort, অঙ্ক ও scenario আমাদের বোঝানোর উদাহরণ, benchmark বা গ্রাহকের ফল নয়।

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

লেখকের পরিচয়

Anichur Rahaman

পড়া চালিয়ে যান